The use of the product in question was given as:

• a networked solution system used to monitor a patient’s vital signs and therapy, control alarms, review Web-based diagnostic images, and access patient records. The number of monitored vital signs can be increased or decreased based on the patient’s needs

Curiously only one customer was identified as having received the product, or at least this particular version of the product. While the manufacturer and product in question is a matter of public record, and available at the link, I chose not to include it here because my objective is not to repeat the recall information, but to suggest the reasons for the recall, an associated labeling issue, and offer some general lessons.

The reason given for the recall had two seemingly separate parts. The first is that “The weight-based drug dosage calculation may indicate incorrect recommended values, including a drug dosage up to ten times the indicated dosage”. This sounds like a software problem yet the fix was not to “upgrade” the software but to suggest a workaround. (I love the term upgrade to when applied to fixing something that doesn’t actually work!)  According to the FDA the firm’s letter stated that “users should enter the patient’s weight by way of the admin/demographics screen to ensure the drug dosage is calculated as intended.” (I did not find the firm’s letter on its website, but it might be one of those hidden page situations since I did find, with a struggle, two other recalls, though using the search term “recall” produced no results). Again speculating, the workaround sounds like a user dependent way to do something that was supposed to happen automatically. At least part of the value of automation is largely diminished, and opportunities for use error increased, when such additional demands are placed on the user.

The second reason given for the recall was that there may be a 5-10 second delay between the electrocardiogram and blood pressure curves (waveforms) at the central station.   This is an interesting technical issue that may be related to software and/or communication protocols. In either case it illustrates that multiple data streams may only be useful if they are properly timed stamped, and then properly aligned at the receiver. Out-of-sync data when subsequently processed either by eye, or automatically, can give erroneous and misleading results that might appear to be correct, i.e. the results could be in the category of erroneous but believable.

For one or both reasons the FDA found that, “This product may cause serious adverse health consequences, including death.” Yet it should be noted that this was a voluntary recall, as most recalls are, despite the fact that people who surely know better reported this as “FDA recalls…”

The FDA announcement goes on to say that the company pointed out that the instructions for use state that: ”For primary monitoring and diagnosis of bedside patients, use the bedside monitor. Use the…Central Station only for remote assessment of a patient’s status.” This sentence seems to be illustrative of the fundamental problem of remote information receivers and integrators that carry a disclaimer that in sum says that you shouldn’t rely on them. But isn’t the ability to rely on it exactly why you bought it? Moreover, promotional materials available on the web do not appear to echo this disclaimer. For example it is stated that ”Applications…enhance patient care management by providing rapid assessment, decision support and clinical reporting.” Does that sound like it isn’t for primary diagnosis? Or does “Data accessible from the…Central Station includes real-time waveforms” sound like those waveforms shouldn’t be used for primary monitoring? For one more example it is said that “arrhythmia events are detected with an unprecedented degree of accuracy.” Accuracy is certainly a good thing, but detecting arrhythmias at the central station when only the beside monitor is to be used for “primary monitoring and diagnosis” appears to be less than highly useful.

Furthermore the statement that the central station is only for remote assessment seems both definitional and contradictory. It is obviously for remote assessment–because it is a central station and thus remote! But then what does “assessment of the patient’s status” mean if not monitoring and diagnosis?

The disclaimer game has been addressed in these pages before. Here it seems to involve a product that is being marketed, sold and bought for exactly the reasons that the manufacturer is saying it shouldn’t be used. I didn’t spot the disclaimer language in any of the promotional materials, but maybe it is there somewhere.

So, we have here an apparent example of software driven miscalculations, network transported data that is not time synchornized, and a reminder not to use the central station for primary assessment. Important examples to remember as we charge ahead with software driven networked solutions.

[The products in the photo with this post above are not associated with the recall discussed, and are for illustrative purposes only.]

William Hyman is Professor Emeritus of the Department of Biomedical Engineering at Texas A&M University. He recently retired and has moved to New York City where he continues his professional activities.

Health IT Risks

The potential for health IT to improve both the quality and efficiency of medical care has been much noted to include more complete and timely records, ready exchange of information between providers, clinical decision support, and in turn a reduction in errors associated with the quality and availability of patient information. Efficiencies may arise from electronic capture of data which would eliminate manual entry, and time savings in accessing and reviewing patient information, and perhaps in passing information to third party payers. Additional public health value might accrue from the enhanced searchability of electronic records with respects to trends, treatments and outcomes. These benefits assume well designed, user friendly, compatible systems not withstanding that the U.S. model is to allow for numerous independent products that may or may not be able to exchange information nor display it in a consistent manner. Not surprisingly the report notes that the IT imperative will likely not be fruitful without associated attention to the people and the clinical system they work in.

However there is also the potential for health IT to add to, rather then reduce complexity; misplace, lose or garble patient information, and to provide clinical decision support that is incorrect or unreliable. Thus health IT itself has risks that the IOM found have not yet been adequately addressed or monitored. The IOM also cites the lack of an effective health IT problem reporting system compounded by contractual language that may actually impede such reporting. In addition some vendors include disclaimers as to their responsibilities even for software defects and errors. The latter suggests the all purpose liability disclaimer language: “Notice-this product may be badly designed and therefore not suitable for its intended purpose.” Alternatively one could try: “Due to software defects the information in this EHR may or may not be complete and/or may not pertain to  the patient of interest. Do not use this information for medical treatment”. The value of such disclaimers will no doubt be tested.

Of course it is not only coding defects that can make heath IT less than effective. The well established issue of usability, or user friendliness, lives on, as does interoperability, training and workflow design. In this regard it might be noted that user friendly features such as pull down menus also facilitate quick but erroneous entries. Thus while an IT product might be theoretically capable of being used properly and effectively, whether it will achieve that goal in the real environment of use, when used by real people, is a separate matter. In this regard when faced with use issues and adverse events vendors will want to say that their product could have provided the correct functionality if only it had been used correctly–and don’t forget our disclaimer. The counter argument is that it was badly designed to the degree that “correct” use was predictably not likely to consistently occur. There are many anecdotes in this regard. A favorite of mine was an order entry system to which was added a physical sticky note on the monitor that read “Do not press Enter to Enter”.

Actual health IT hazards are at least in part separate from the questions of privacy, hacking and other mischief.

It must also be remembered that quantitative data (e.g. lab results and other medical device data), or reasonably well standardized data (e.g. images) are potentially much easier to capture, transmit and display than narrative information. The selection and arrangement of information on a display can also be a significant challenge with respect to density, utility and how many pages the clinician has to look at to get all the information needed–and you can’t spread those pages out. There is also a significant issue with the lack of standardization of “look and feel” factors. In this regard it must be remembered that clinicians of various types, working in multiple environments, might see multiple systems during even a single day. This is analogous to the reality of nurse use of infusion pumps. Ask the nurse if they know how to use an infusion pump and they will most likely say yes (and be insulted). But then ask them if they know how to use a particular infusion pump and they might say, no, I’ve never seen one of those before. In this regard a health IT application may be plug-and play, but that isn’t the same as plug-and-effectively-use.

IOM Report Recommendations

The report has several specific recommendations:

• A comprehensive effort to asses safety and risk
• Vendors should support the free exchange of information about health IT experiences and issues and not prohibit sharing of such information, including details (e.g., screenshots) related to patient safety
• HHS should make comparative user experiences publicly available
• A new Health IT Safety Council should be funded by HHS to evaluate criteria for assessing and monitoring the safe use of health IT and its ability to enhance safety
• The registration and listing of products from all vendors
• Specification of the quality and risk management process requirements that health IT vendors must adopt, with a particular focus on human factors, safety culture, and usability
• Establishment of a mechanism for both vendors and users to report health IT related deaths, serious injuries, or unsafe conditions
• Establishment of an independent federal entity for investigating patient safety deaths, serious injuries,or potentially unsafe conditions associated with health IT
• Regular monitoring and reporting of health IT safety by HHS, and the FDA should be charged with developing applicable regulations
• HHS should support usability research

Readers familiar with the FDA regulation of medical devices will recognize many of these items as standard fare. These include registration and listing, quality systems, and problem reporting. However since the FDA has not asserted that EHRs are medical devices, and the IOM elected not to make that specific recommendation.

Record-type health IT products remain in a regulatory vacuum–except with respect to acquisition funding subject to the meaningful use requirements. In this regard the report includes a dissenting statement from Richard Cook, MD (director of the Cognitive Technologies Laboratory at the University of Chicago) who asserts that health IT products should not only be declared to be medical devices, but that they should be Class III, the most stringently regulated device classification. In this regard he includes the following quote: “Medical and diagnostic devices have produced a therapeutic revolution, but in doing so they have also become more complex and less easily understood by those who use them. When well designed, well made, and properly used they support and lengthen life. If poorly designed, poorly made, and improperly used they can threaten and impair it.” While this quote could appear in nearly any one of the posts here, it actually dates to 1976 as part of President Gerald Ford’s signing statement for the Medical Device Amendments that ushered in the modern era of medical device regulation. While these amendments are often thought of as the beginning of  FDA medical device regulation, such regulation actually stems from the 1930′s. What did start in 1976 was before-marketing restraints as opposed to the FDA’s prior post market authority. (And no, 1976 is not ancient history. Some of us actually remember it.)

Health IT is caught in the corn maze of promise vs usability and hazards. With quality design and thoughtful implementation the exit may be found before nightfall. Without it someone is going to have to call 911.

William Hyman is Professor Emeritus of the Department of Biomedical Engineering at Texas A&M University. He recently retired and has moved to New York City where he continues his professional activities.

David suggests that FDA regulation will stifle mobile app innovation, and observes that brand-name phone manufacturers are in a better position to shoulder FDA regulations than startups.  He further wonders why an App Store that takes a 30% cut of app revenue does not appear to draw any regulatory attention from FDA.

Nathan agrees that over-regulation could stifle innovation and suggests that the regulatory burden should vary based on the intended user. Nathan implies, I think, that apps for health care professionals should face greater regulatory scrutiny than apps for use by patients. He also laments that FDA has not designated specific standards that would facilitate cross-vendor interoperability in the mHealth ecosystem.

I don’t mean to pick on David and Nathan, it’s just that they raise some excellent points that I’ve seen repeatedly in other forms. The problem with many people’s constructive criticism of FDA’s draft guidance is that they are criticizing or suggesting things that lie outside FDA’s legal framework. Criticism that ignores this legal framework really barking up the wrong tree.

Suggestions that go beyond the FDA’s legal framework are not possible without Congress passing major new legislation. Unless the law empowering FDA changes, we have to consider mobile apps within the existing regulatory framework. What you’re seeing in the draft guidance is an expression of the FDA’s current framework applied to mobile apps.

The objective of this post is not to interpret the current draft guidance on mobile apps, but to describe some basic concepts of FDA regulations to better understand the perceived limitations or choices made by FDA in their draft guidance, and to enable more constructive criticism and suggestions that are consistent with FDA’s existing legal framework. FDA regulatory stuff is rather complicated, so please forgive me if I oversimplify some things in an effort to provide some basic explanations.

Limits on FDA’s Ability to Regulate

Legally, the FDA can’t distinguish between small business innovators and large market incumbents. Nor can they take different regulatory approaches solely based on the user of the medical device – at least in the way that it seems to be implied. The targets of FDA’s regulatory power, and how that power is applied are determined by different factors.

A key regulatory concept of the legal foundation for FDA regulations is that the FDA can only regulate manufacturers. An important corollary is that only one manufacturer may be regulated for a given medical device system, regardless of what (or how many) off-the-shelf technologies are incorporated in the overall medical device system.

Another important part of this regulatory framework is that manufacturers are regulated based on two primary things: the claims they make about their product, and the product’s inherent functionality.

Probably the most fundamental concept that underlies almost everything FDA does is patient safety or risk. The greater perceived risk, the higher the regulatory burden. As reinforced in this draft guidance, medical devices are divided into three classes based on risk, with the lowest risk being Class I and the highest being Class III.

Another important concept about  FDA regulations is that FDA ensures safe and effective medical devices by requiring manufacturers to follow a quality system process, rather than testing and certifying a particular product, standard or piece of technology. The FAA tests and certifies airframes, the FDA ensures manufacturers follow a quality system. The intent here is to promote innovation by defining the basic processes followed  by the manufacturer to create, manufacture, market and service the resulting device.

By freeing the manufacturer to chose what they think is the best way to implement a design (as long as they follow a quality system process) is supposed to encourage innovation. In many situations, I suppose this approach does promote innovation. Yet as automation transforms medical devices into information appliances, the lack of an agreed upon technical foundation (such as interoperability standards) stifles a different kind of innovation.

Applying FDA’s Framework to Mobile Apps

Who Gets Regulated

Whoever designs and markets (directly or indirectly) the mobile health medical device – be they a startup, a carrier or a mobile phone manufacturer – is the entity the FDA will regulate. In the case of a startup that bases their medical device on say the iPhone, how would FDA go about regulating Apple (solely or in conjunction with the startup)? Also, while FDA only regulates manufacturers, health care providers can meet the legal definition of a manufacturer if they create a medical device, or modify an existing medical device, and use it in clinical practice.

FDA regulations (the Quality System regulation) impose a basic quality system on the design, manufacture, sales and service of a medical device. In the LinkedIn discussion example, the manufacturer (the startup) does the design, marketing (defines the claims and intended use) and provides any service and support. Apple is simply an indirect distribution channel. Apple makes no additional or different claims for the product, nor do they provide any service other than distribution of the software that runs on their phone.

If the FDA were to regulate Apple, how would this improve the safety and effectiveness of the medical device? I can’t see how it would. I suspect that if FDA were to attempt to regulate Apple for their sale of medical device applications, Apple would kick all medical device apps out of the App Store – definitely impacting innovation.

The Intended User

The user of the medical device is an important consideration for FDA. When the user is a clinician, with all that implied knowledge and expertise, certain assumptions are often made by the manufacturer – and accepted by FDA – that in the event of a problem (e.g., a limitation of the product, a deterioration in the patient’s condition or an adverse event), the user has the wherewithal to “do the right thing,” rather than continue blindly down the path that may be indicated by the medical device.

When the user of a medical device is a patient of family member – what the FDA calls a “lay person” – the user lacks the broad and deep knowledge that a clinician brings to the use of a medical device. Thus the device must have a better user interface and a safer design to ensure an outcome on par with that obtained by a clinician user. This is not a new issue for FDA.

The past several years have seen a number of hospital products pushed for use in home health. From this experience, the industry and FDA have learned the lessons described above. Consequently, FDA considers medical devices designed for use by lay people to generally be higher risk than those whose intended user is a clinician.

The result is that FDA will likely bring a higher level scrutiny to devices intended for use by lay people, compared to devices intended for use by professionals. The result will not be a lowering of the regulatory bar for products targeting patients, but a higher regulatory hurdle.

Industry Standards Adoption

Many of the comments about the FDA’s draft rule on mobile apps lament the absence of industry standards to facilitate cross-vendor interoperability. The implied or explicit solution being that the FDA mandate a specific standard. While there is a great need for a minimal level of cross vendor interoperability to foster market adoption, the FDA has no legal foundation for placing a specific standard on industry. In short, great idea, but a complete waste of time. Instead, one should look to see how this problem has been solved in other industries.

There are plenty of standards bouncing around, some, like 11073 for more than 30 years. The challenge is picking a standard(s), getting a critical mass of vendors to adopt said standard(s), and providing a meaningful level of test and certification for compliance. Most any health care market can be divided between acute care (i.e., hospitals where the patient’s too sick to be walking araound) and ambulatory care (i.e., home health, chronic disease management, physician offices and clinics – where the patient’s sick but is still ambulatory).

Most mobile apps target ambulatory care markets. There is a test and certification alliance, the Continua Health Alliance, that exists for selecting standards and providing the necessary test and certification for the ambulatory market. There are admittedly several big holes in FDA’s regulatory famework when one considers mobile app products (that are all outside the scope of this blog post). While not a standards oriented group, the mHealth Regulatory Coalition, that is working to address shortcomings in FDA’s current regualtory framework for mobile apps. Be sure to check them out.

For acute care, there are a number of industry standard setting initiatives. The oldest is the IHE PCD domain. This group has been working since 2005 on medical device connectivity and interoperability. This test and certification group is mainly held back by the absence of a standard that’s been adopted by medical device manufacturers, and the resulting glacial pace of adoption – but they are making progress. Another hotbed of standards work comes from the Medical Device Plug and Play Interoperability Program at CIMIT and Partners Healthcare. They’re working on the Integrated Clinical Environment standard, MD Fire connectivity purchase contracting language and also working with FDA on dealing with developing a more effective interoperability regulatory framework.

International Markets and Quality Systems

Before I posted this, Dayle Kern added to the LinkedIn discussion asking, “What about mobile apps for developing countries?” My first thought is that as a market, mobile apps is still very much in the pilot stage. While there’s a perception that adoption is much greater outside the U.S. (especially in the third world), the reality is that there’s just a lot of pilots being run in other countries in addition to those in the U.S. My next thought is that while the regulatory burden may be lower outside the U.S. (and especially in the third world), why shouldn’t the patients in those countries get a product that’s as safe and effective as the ones intended for U.S. or European users?

I have clients doing clinical trials outside the U.S., and who launch products outside the U.S. first. The reasons behind those decisions have everything to do with time to market and costs – much of which are determined by relative regulatory burdens here and in other countries. But, without exception, they’re following appropriate quality systems to ensure a safe and effective product. The costs they’re saving are not on the design side, but on the regulatory side. And consequently, their products are as safe and effective as they would be if the U.S. was where they were doing trials or launching their product.

Finally, in a world where it’s almost impossible to buy a hot water heater or air conditioner from a manufacturer who is not ISO9001 certified, it’s almost as impossible to buy an healthcare IT software application from a vendor following the same or similar basic quality system. From their resistance to adopt quality systems, one would almost think that vendors in health care consider quality and safety to be less important than do companies in the HVAC business.

Manufacturers in many other industries don’t seem to have a problem innovating or competing while broadly adopting quality systems – on a voluntary basis, I might add. Please explain to me how a similar quality system for medical devices – regulated or otherwise – is an unreasonable burden?

On July 19, 2011 the FDA announced its proposed official action in this regard, including defining “mobile medical applications”  that are the subject of this action. (I will use the acronym MMA, although the FDA did not.) . This includes a new FDA web page for mobile apps (here), with links to a new Draft Guidance, information for consumers, and a press release. This action by the FDA has a parallel to the recent final rule on Medical Device Data Systems (MDDS), discussed by Tim here, which also addressed what is it, what is it not, and how that which is will be regulated.

The Draft Guidance, dated July 21, 2011, defines an MMA as a ”software application that can be executed (run) on a mobile platform, or a web-based software application that is tailored to a mobile platform but is executed on a server”, where that software already meets the general definition of a medical device as found in 210(h)of the FD&C act. In brief, the relevant part of this definition is that a medical device is used in the diagnosis, treatment, cure, mitigation or prevention of disease.  If there was any prior doubt, this again establishes that software that is intended to do any of those things is a medical device, even in this case  if downloaded from the app store, and run on a smart phone. Intent here can  be a key issue in that general purpose software that might be used for a medical application is in general not regulated as a medical device, unless the software manufacturer promotes such applications. This guidance does not specifically address wireless safety considerations, classification and submission requirements related to clinical decision support software (once called expert systems), or the direct application of quality systems to software, all challenging issues.

That software can be a regulated medical device has been asserted by the FDA on a number of occasions, and they note in this guidance multiple examples of medical device software that has already been defined and classified. The FDA’s justification for doing this is also familiar; besides its congressional mandate, the FDA notes that “As is the case with traditional medical devices, mobile medical apps can pose potential risks to public health”. However the FDA makes clear here that the mobile device itself (the mobile platform) is not considered to be a medical device, even if it is running an MMA – unless the seller of the platform makes a corresponding claim for its medical use.

Among all mobile apps, the FDA in this guidance has defined the MMA subset that is the subject of the guidance. However we are reminded that other mobile apps may still be medical devices, and therefore potentially subject to regulation, but under the FDA’s “enforcement  discretion” they will not be actively regulated at this time. However manufacturers of even these devices are invited to register and list with the FDA, and it is suggested that they follow the FDA’s Quality Systems Regulations, even if they don’t register at this time. Enforcement discretion is one of my favorite regulatory categories because that discretion can end at any time, and that which was previously not being actively regulated can easily become actively regulated. A no doubt bad automotive analogy here is to the long alleged grace speed overage before being subject to a speeding ticket.  However true or not true this is, a ticket can still be issued for speeds over the limit but under the rumored true limit.

The guidance goes on to define the scope of regulated apps (MMA) , and who is a MMA manufacturer. I will not repeat this information here, except to note that the download store distributors, like the platform makers,  are defined as not being manufacturers. Further, it is the creator of the software concept and its specifications, not the code writer  who is on the regulatory hook. Good news for programmers who aren’t the originator of the device. Time here for some perhaps artificial humility in the form of, “Hey, I just wrote the code to make the software do what they said it should do.” Also of particular interest to some, devices that create alarms are expressly addressed as being included. This is consistent with the FDA’s attention to alarm issues, which will be the subject of a forthcoming multi-sponsored Alarms Summit.

The appropriate FDA classification for MMAs will vary depending on the actual intended use. Thus, there is no reclassification here as there was in the MDDS final rule.

This FDA action can be viewed as one of several efforts in which the FDA must address rapidly evolving technologies, and systems of technologies, that in some cases have been deployed ahead of the FDA’s ability to deal with them under existing regulatory frameworks. Or as perhaps in this case, where developers have charged ahead with product introductions with disregard for medical device regulatory requirements, either from not knowing these regulations, or intentionally ignoring them.

William Hyman is Professor Emeritus of the Department of Biomedical Engineering at Texas A&M University. He recently retired and has moved to New York City where he continues his professional activities.

I came across this via a Modern Healthcare blog post by Joseph Conn. Like me, Conn was drawn to the first recommendation (from the NRC report):

Recommendation 1. The U.S. Food and Drug Administration and the Office of the National Coordinator for Health Information Technology should collaborate to regulate, certify, and monitor health care applications and systems that integrate medical devices and health information technologies. As part of the certification process, the agencies should require evidence that manufacturers have followed existing accessibility and usability guidelines and have applied user-centered design and validation methods during development of the product.

In his blog post, Conn quoted David Wegman, the chairman of the NRC’s Committee on the Role of Human Factors in Home Health Care, which produced the report, on the roles of the ONC and FDA as it relates to medical devices and HIT:

“As it is now, the ONC has the responsibility for the credentialing and oversight for health information technology and the FDA over devices,” Wegman said. “The gap is when those devices are interconnected.”

It seems to me that Wegman’s wrong about the FDA and the purported gap between medical devices and HIT. First, depending on the intended use claimed by the manufacturer, software applications can (and do) meet the legal definition of a medical device, and are regulated as such by FDA. Also, the FDA neither certifies products (like the FAA does airplanes), or compels manufacturers to adopt specific standards for their products (although this is encouraged). The principal mission of FDA is to ensure the safety and effectiveness of medical devices. Wegman’s right about the ONC, although they don’t directly certify HIT products. The ONC is focused on driving interoperability, standards adoption, usability, and the actual use of HIT products in a meaningful way.

Who Will Regulate EMRs?

The gap between ONC and FDA is not so much the types of products they regulate; I suspect that they will increasingly claim oversight of many of the same products in the near future. The gap lies between the different missions of the two organizations. For example, the ONC gives little attention to patient safety. There are no certification tests that ensure patient safety, instead they are focused on providing a base line set of functionality (including support of certain standards), and end-user usability. The ONC has no reporting mechanism or legal requirement that HIT vendors and providers report incidents that could have or did result in a patient’s injury or death.

Another important difference lies in how they’re legislatively empowered. These two different operating approaches, combined with different legal and bureaucratic authorities, could easily result in gaps that will impact products that pass through both organization’s purview.

As an aside, FDA has undertaken a big initiative focused on the use of medical devices by lay-people. The option to take an infusion pump designed and intended for use in the hospital, and labeling it for home use is pretty much over. And a key lever for ensuring the safety of the home based devices is usability – if the patient or caregiver can’t effectively use the device, how could it be safe?

I expect ONC to continue to squabble with FDA, in an effort to protect their clients (EMR vendors) from an additional regulatory burden. It is doubtful that FDA will roll over for ONC. Rather, they will likely continue their planned approach and ONC – along with HIT vendors – will just have to deal with it. In fact the expectation that FDA will eventually regulate EMRs, or at least parts of EMRs, has been around for some time.

Medical Device Interoperability

One remaining problem that was explored in Conn’s blog post is how to incentivize medical device manufacturers (and EMR vendors to a lesser degree) to adopt industry standards and pursue the certification efforts necessary to realize actual cross-vendor interoperability. As noted above, FDA lacks the authority to make that mandate. The ONC can mandate standards on the HIT side – which is an important first step, but lacks any authority over medical device manufacturers.

Fortunately, there are two ongoing industry efforts working to drive medical device interoperability. The one most closely related to the home health market is that undertaken by the Continua Health Alliance. This organization, mostly driven by manufacturers, is working at break neck speed (at least for the medical device industry) to create cross vendor interoperability for the ambulatory remote monitoring market that they target.

Another interesting initiative are the efforts behind the Integrate Clinical Environment standards effort. The implementation of ICE is being driven by a number of government grants from places like the NIH and DoD. Another facet of the ICE effort is work with FDA, Continua, AAMI and the Medical Device Plug and Play Interoperability Program at CIMIT.

A third effort, and one that’s farther down the road in many ways, is the IHE PCD domain. The IHE was created as a test and certification consortium for HIT applications and the integration of HIT with medical devices.

Two very successful areas for IHE are the radiology and clinical lab domains. In both cases there were industry standards adopted by both HIT and medical device vendors, and the IHE facilitated the agreement on use cases, and provided certification tests to prove conformity. The PCD (patient care device) domain is hobbled with a major weakness, there is no industry standard that’s been adopted by industry that can be used to integrate medical devices and HIT.

Consequently the PCD domain has had to select industry standards to support the use cases they wanted to implement, and wait for manufacturers to build those standards into their products. Rather than select one broad standard, like DICOM, the PCD domain has taken a piecemeal approach, using bits and pieces of standards, and when necessary creating their own “standards” such as rosetta terminology mapping.

Started in 2005, there are finally a goodly number of vendors with commercial products that support the basic profiles (use cases). The more recent profiles shown at the Interoperability Showcase at HIMSS are mostly works in progress and not yet available as commercial products. It is the slow progress of the participants in the IHE PCD that gave rise to more recent efforts like the ICE standard.

Once characterized as a “market expense” by industry participants, the IHE PCD has become a more serious forum for cross vendor interoperability. This was probably inevitable as the number of defined uses cases or profiles grew to encompass more complete and meaningful workflows like alarm notification. The IHE’s biggest strength is the adoption of its profiles as selection criteria in providers Requests For Proposals. Support for IHE PCD profiles will be increasingly important to connectivity solution vendors targeting applications like clinical documentation, alarm notification/messaging middleware, remote surveillance and data aggregation.

One final effort that should have an important role to play is the MD FIRE project. This effort, called the Medical Device “Free Interoperability Requirements for the Enterprise,” is the result of collaboration by legal council at Partners Healthcare, Johns Hopkins and Kaiser. These institutions came together and created legal language that can be inserted into Requests for Proposals and purchase agreements that places legal burdens on medical device manufacturers to provide connectivity and interoperability capabilities.

It is well known that providers want open systems with cross vendor interoperability. Sadly, it is also well known that most providers will simply buy whatever their currently favored vendor wants to sell them. It is only by including requirements like those in MD FIRE that manufacturers will be incented to actually make those features available – some day, hopefully before I retire.

The rationale behind the workshop is the need to clear up confusion on the part of many product developers regarding regulatory issues like,

• Is my product a regulated medical device?
• What does it mean to be regulated?
• If I don’t want to be regulated, can I avoid regulation – and if so, how?

Ideally, we can structure the workshop around attendees actual products and situations. This, of course, will depend on folks registering in advance with sufficient lead time to actually prepare some content around their unique situations. Using participant’s products as case studies should be more engaging and relevant for everyone. If you’re registered for the workshop and want to provide a case study, let me know by completing this contact form.

If we can’t get participant provided cases, I plan to use some example products from companies like AirStrip Technologies, MIM Software’s Mobile MIM, and MobiSante’s MobiUS ultrasound product.  I’m also open to suggestions about other companies or products for case studies (again, leave your thoughts on the contact form.

Like any other business activity, if you want any hope of meeting your objectives, you need a plan. The same holds true regarding regulatory issues, whether you want to avoid or embrace being regulated by FDA. The objective of the workshop is to lead you through the process of putting together a plan.

Here are the topics I’m pulling together for the workshop. The first issue is whether your product as it exists or is conceived meets the legal definition of a medical device. For those outside the regulatory field, the answer to this question is both simpler and more complex than many think. We’ll look at the typical artifacts and indications for making this determination.

Next we’ll work to bring into focus the boundaries between what makes a product a regulated medical device or not. You will find that the degree of focus will vary depending on the nature and characteristics of the product. We will then consider what would be necessary for the product to move from being regulated to unregulated and vice a versa.

The most basic decision in your regulatory strategy is whether or not your product will be regulated. Once we’ve worked that out, we will develop a plan to realize your strategy. This plan will focus mostly on your product roadmap, sales and marketing. We’ll define the strategy as it will be applied company operations, to include clearly defined product feature boundaries, a defined claims and intended use framework, and a few other components. In cases where the strategy entails being regulated, we’ll include those requirements in the plan as well.

I am hoping you can answer this question for me.  Would [redacted company name] a data storage company come under the MDDS final Ruling?  Are hw/sw services all types of companies including medical.

Unfortunately, where the FDA is concerned, very little is black or white. Short to-the-point questions usually don’t result in meaningful answers.

One unambiguous issue we can get out of the way is that the FDA regulates products through their regulation of manufacturers. All regulatory questions revolve around the product, but it is the manufacturer of the product that has to jump through the regulatory hoops. A manufacturer may chose to have one set of policies and procedures that conform to the FDA regulations for their medical device, and another for unregulated products.

Is Your Product a Medical Device?

Now let’s get into the basic issues. The first is whether you have a product that meets the legal definition of a regulated medical device. If so, then one must consider whether it is a device the FDA feels compelled to regulate (some are already regulated, while others are not – typically because the FDA views the products as low risk). How all this applies to any one company and their products is not so cut and dried.

Are You Making Medical Device Claims?

The next basic issue targets the claims you make about a product. Claims include your product’s value proposition or intended use, features and benefits as described in promotional materials, by employees like sales reps, and in your user manuals. If you make medical device claims, even if your product does not meet the definition of a regulated medical device, FDA may want to regulate you (again, based on their perception of risk).

All this is intended to indicate that there’s a lot more to this than the short and sweet question that I usually receive.

Is It a MDDS?

Regarding the specific question, “Is my product a MDDS?” if you have a product that:

• Directly receives data from medical devices,
• Converts the data from one format to another according to preset specifications (e.g., parses the original protocol and converts it into a format used by your system, and/or converts units of measurement or changes data labels),
• Stores and/or displays the data, and
• Makes that data available to other systems,

then yes, your product is a MDDS. A product must meet the minimum requirements above to qualify as a MDDS. If you fall short of the criteria, you do not have an MDDS. If you exceed the criteria, i.e., provide additional capabilities or features beyond what’s defined for a MDDS, you do not have a MDDS – but your product is likely still a regulated medical device, it’s just something other than a MDDS.

UPDATE: Be sure to read this post, Final MDDS Rule Signals FDA Shift to Enforcement, to get a more definitive definition of MDDSs. You can also find a link to the actual rule in aforementioned post.

What about Claims?

Should you make MDDS claims however, don’t be surprised if the FDA knocks on your door whether your product meets the definition of a MDDS or not. Suppose you provide a component or some necessary infrastructure for a MDDS (or any other kind of medical device) and want to do some “solution” marketing to end-user-buyers – where you promote the entire solution that’s made up of your product and those of other solution “partners,” that are all described in the brochure.

Typically resellers or systems integrators are the ones that actually assemble the components described in your brochure and sell it to health care providers. Your intent is to just sell your part of the solution by presenting the overall MDDS in your marketing materials. You clearly don’t manufacture the entire MDDS solution.

This marketing technique results in you making a marketing claim for a MDDS, or perhaps something else, that’s a regulated medical device. Legally, you’re now a medical device manufacturer simply based on your claims regardless of your product. At their discretion, the FDA can pursue enforcement actions against your company for making these claims.

What’s Next?

In most cases when I get questions like this, the company’s product is probably not a medical device. But from a corporate risk management perspective, it’s a good idea to make sure whether your product is a regulated medical device or not. If it is, then you need a business strategy to deal with that. If your product is not a MDDS or other kind of regulated medical device, you need to figure out exactly what you need to do and not do to maintain your status as “not a medical device.” This is not a huge effort, but it does take some work.

See this post, Charting Your Regulatory Course for next steps.

What is a Medical Device?

Let’s start with the first category; there is an astounding amount of misinformation and just plain wrong-headedness on the part of many vendors (and providers) who are outside the ranks of traditional medical device manufacturers. The first issue we need to address is the question, “What is a medical device?” Here’s the legal definition of a medical device, courtesy of FDA:

A device is:

• an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:
  • recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them,
  • intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or
  • intended to affect the structure or any function of the body of man or other animals, and which does not achieve any of it’s primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes.

If you look up the word contrivance, you’ll see that almost anything can be a medical device:  tongue depressor, superglue, software, even services – let your imagination run free. If it quacks like a duck – is intended for use in the diagnosis, cure, mitigation, treatment, or prevention of disease (or other health related conditions like injury), it is a duck. Calling it a chicken or even a turkey does not change a regulatory agency’s perception of the quacking product’s “duckness.”

There is also a new classification of medical device call a Medical Device Data System, or MDDS. An MDDS acquires data from one or more medical devices, stores it, can transform it per written specifications (e.g., change units of measurements or labels of data elements), display the data and make the data available to other applications. Thus if a product meets the definition of an MDDS it is a duck, and cannot claim to be something else because all their doing is automated record keeping.

Automated record keeping is generally held by regulators to not be a medical device – but the first step of acquiring data from the medical device does qualify as a medical device. The only way to acquire medical device data without being categorized as an MDDS is to get the data from another application that is an MDDS, or have users hand enter the data into your application.

I’ve heard the argument that, “we’re only storing the data, and that’s not a medical device.” This can be true, if what you’re doing with the data (besides storing it) does not meet the definition of a medical device, and if you’re not acquiring the data directly from the medical device (because that’s an MDDS).

The Regulatory Significance of Marketing Claims

Fierce Mobile Healthcare captured a great quote in a story the other day by Bakul Patel, a policy advisor in CDRH at FDA about the potential for smart phone app regulation,

Companies that make health claims in their marketing, or actually perform clinical operations on their mobile devices, may be the first targets.

So we’ve already dealt with the second part of Patel’s statement, about whether the product preforms clinical operations and thus meets the definition of a medical device. The first part, about marketing claims is next important regulatory concept. Claims are also referred to as “labeling” by FDA, and include a product’s positioning statement, brochures, advertisements, white papers, and what sales reps tell customers verbally, in email or PowerPoint presentations.

You can’t take a duck and call it a chicken in your marketing claims if its really a duck. Likewise, if there’s a likelihood customers will use it as a duck after purchase, regulators will treat it as a duck. For example, say you develop software to view DICOM images (xrays, CT scans, MRIs, maybe some sexy 3D reconstructions) on the iPhone and iPad – but you tell physicians they can’t use your product to render an actual diagnosis. What then are they to use the app for, a novelty? A similar product was identified as a duck by FDA a couple years ago, and just recently received FDA clearance for sale by the vendor.

Another important thing regarding claims about medical devices is that regulatory agencies will treat your product like a regulated medical device if you make claims that your product is a medical device. For example, Apple came perilously close to claiming the iPhone was a medical device during their iOS 3.0 intro event. Since then, Apple’s toned down their aggressive marketing of the iPhone (and iPad) as medical devices, though they still show examples of medical device applications in commercials, at events and on their web site. In another example, a few years ago Cisco produced a brochure that showed a patient monitor alarm message and associated waveform displayed on a Cisco VoIP handset. This quickly drew a visit by FDA and a “request” to withdraw the brochure, which they did.

The bottom line is whether your product is a medical device or not, if you make claims that give the impression that it is a medical device, you are likely to find yourself regulated – or claw back your claims.

Regulation of Off-the-Shelf Technologies

A similar topic that is rife with confusion is whether generic products like smartphones, wireless carriers or network equipment will be regulated. Currently available smartphones, by themselves, do not meet the definition of a medical device. There are three ways the smartphone itself could become regulated:

1. The smartphone manufacturer could make medical device claims – even though the product does not meet the definition of a medical device
2. The smartphone manufacturer could add features, say an interface to acquire data from sensors like glucometers, implanted pacemakers or some other medical device
3. A third party could develop a product, notably software that runs on the smartphone, and perhaps other components, that all together meet the definition of a medical device

Item one above relates to the Apple and Cisco examples used earlier. If your product is not a duck, don’t make claims that it is and you need not have to deal with FDA and their international brotherhood of regulators.

The second scenario above is really just as straightforward. If HCI built an Android smartphone with an interface for glucometers, and then promoted the product to diabetics like, “Hey, buy my smartphone to acquire data from your glucometer to better manage your diabetes,” they’ve transformed their product into a medical device. Another similar situation would be where the smartphone manufacturer creates a port on their phone to attach a blood pressure cuff, which they sell as an accessory to their smartphone. A generic equipment manufacturer who does something like this will likely see someone from FDA in the very near future.

Now what about a generic interface like Bluetooth? What if a third party uses that Bluetooth interface already built into the smartphone to connect a glucometer to help diabetics manage their disease? Then the third party becomes the regulated entity, and the smartphone is just another off-the-shelf component that goes into the overall medical device. In this case, the medical device is regulated – through the third party/manufacturer – and the smartphone maker never hears from FDA. From this example you see that which manufacturer ends up getting regulated is what’s important, and not the device itself.

Bottom line, general purpose smartphones, tablets, personal computers, wireless carrier’s networks, LAN equipment – none of these manufacturers will be regulated, with one exception. If the general purpose equipment manufacturer makes medical device claims, the general purpose equipment manufacturer will be regulated. If a third party uses general purpose equipment as off-the-shelf technology in their medical device, the third party gets regulated and not the general purpose equipment manufacturer. (Of course there’s a third possibility where the general purpose manufacturer adds specific features to their product transforming it into a medical device – which we’ve addressed above.)

So when people ask, “Is the FDA is going to regulate smartphones?” they are asking the wrong question. If the smartphones are components in a medical device, or transformed into a medical device themselves, the manufacturer of the medical device will be regulated. It is true that indirectly smartphones are regulated by FDA, but such a statement really distorts what’s actually going on.

Regulatory Agency Actions

Regulators have what’s called, “discretion,” whereby they decide if they want to ignore something they legally could pursue or not. This can be divided into regulatory discretion, where they chose not to regulate, and enforcement discretion where they do regulate.

It is common for regulators to observe the development of new medical device markets without enforcing regulations, provided there is no undue risk to patient safety. This action (or inaction) is called regulatory discretion. At some point, when the market has matured sufficiently, and/or FDA’s understanding of the new market matures, or risk to patient safety becomes to big to ignore, the regulator shifts from regulatory discretion to enforcement discretion. Regulators may signal this shift through a reclassification of the device category (as FDA recently did with MDDS), by publishing a guidance document (there’s one in the works by FDA on smartphones), or they may simply start enforcing regulations.

Regulatory discretion in no way limits a regulator’s future actions. Just because they chose to look the other way before doesn’t mean they can’t change their minds – at any time – and later pursue enforcement. This is true in relationship to past inaction and future regulatory actions, and the retroactive enforcement of actions that previously received regulator discretion.

Regulators rarely, if ever, publicly announce a policy of regulatory discretion regarding a medical device market or product. They only sometimes signal a shift to regulatory discretion. Nor do regulators clearly state that, “if you do x, we will not pursue enforcement, but if you do y we will pursue enforcement.” It is possible to infer such distinctions retroactively, but with nothing on the record either way this becomes an exercise in supposition.

What types of products meet the legal definition of a medical device is pretty black and white; what makes things confusing is all the products that meet the definition that aren’t actively regulated due to discretion. All of this discretion creates a lot of uncertainty for manufacturers. This uncertainty requires management to make judgement calls about how much regulatory risk they want to assume with a given product in a given market. Unlike mature markets like hospital patient monitors, emerging markets like smartphone apps have a lot of uncertainty.

Probably the biggest risks are having to incur unanticipated costs and time-to-market to become a regulated manufacturer and, if necessary, receive clearance from the regulatory agency to sell the product. The manufacturer of the smartphone app for viewing DICOM images mentioned above was delayed 2 years in getting their product to market, and they had to bear significant costs to bring company operations in to regulatory compliance and generate clinical data to demonstrate their products safety and effectiveness. If they’d had a regulatory strategy from the get-go, their costs would have been substantially less (but still more than an equivalent product that’s not a medical device) and probably gotten to market sooner. Eliminating regulatory uncertainty is all about getting informed and planing, rather than having to react to something you’d hoped to avoid.

What is a Manufacturer to Do?

The first thing is to pay attention! Actively track regulators to learn about any enforcement actions against vendors or products similar to yours. Seek access to informal or back channel communications with regulators. You can do this by attending meetings attended by regulators and building personal relationships with regulators through standards work and other means. If your company lacks the resources to do these things directly, engage with someone who can do them for you. Next, continuously apply your awareness of the regulatory environment around your product to your specific situation.

If you manufacture general purpose products or services (e.g., smart phones, cellular carrier networks, Ethernet or Wi-Fi equipment) and you know your products are being used in medical devices, you should probably have or develop a regulatory strategy to ensure you maintain your unregulated status. If you’re a general purpose manufacturer or service provider, know your stuff is used in medical devices, and want to encourage the medical device market for your products, you definitely need a regulatory strategy. Encouraging the use of your products or services in medical devices can cause you to become regulated, if you don’t do things in the right way.

If you are using off-the-shelf components and creating your own stuff (writing software, creating services or developing specialized hardware) for health care related activities, you too should have a regulatory strategy. If your product does not meet the definition of a medical device, you need a strategy that clearly demarcates what makes your product not a medical device, and the actions you will take to maintain those distinctions.

Most likely your product does meet the definition of a medical device, and in many nascent markets – like smartphone apps – enforcement discretion is not being pursued by regulators. In that case you need a more complex strategy. Your strategy should include:

• An attempt to discern what, if any, actions will cause regulatory discretion to shift to enforcement, and if or how to avoid those actions
• Judge the maturity of your market and any indicators (especially actions or comments by regulators) as to when regulators might shift from regulatory discretion to enforcement
• Evaluate the impact of being regulated on both your operations and external market factors like potential competitive advantage – it is common for some companies to voluntarily be regulated before the actual shift to enforcement discretion
• Develop your plan for when and how to become regulated

Like any evolving situation, the biggest challenge comes from not knowing what you don’t know. Hope is not a plan, and the worst thing you can do is nothing. Start turning over those rocks – you may find a few icky things, but there’s no monsters.

Related posts:

Charting Your Regulatory Course

Final MDDS Rule Signals FDA Shift to Enforcement

Comments on FDA Wireless Medical Device Guidance

Facing FDA Regulations for the First Time

The photo accompanying this post was taken at the 2010 mHealth Summit – this is definitely a medical device!

There are all kinds of regulatory strategies. Any new product development project for a regulated product should have a regulatory strategy that optimizes requirements, specifications, risk and verification testing, especially as it relates to the off the shelf components of a medical device. I would call this a product-specific regulatory strategy.

At the other end of the spectrum, a company should have a regulatory strategy that charts the regulatory course of the company in addition to its relevant products. Companies already regulated by FDA should have one of these as part of their management responsibilities – and it should be kept up to date as products, the company, and the regulatory environment change over time. Let’s call this a corporate regulatory strategy.

You especially need a corporate regulatory strategy if your company’s products, or the products of companies you see as direct competition, are in that gray zone that could maybe be interpreted as a regulated medical device.

Sadly, there is no one unambiguous line that a product has to cross to be a regulated medical device. Clearly an implanted heart valve replacement or patient monitor is a medical device. The definition of a medical device is unambiguous, but so general as to encompass a lot things that are not currently regulated by FDA.

A good example are Medical Device Data Systems (MDDS) – this market has existed since the 1980s, yet it wasn’t until earlier in 2011 that FDA signaled enforcement discretion, reclassified the product, and gave manufacturers a schedule to come into compliance. Up until this year, most MDDS were not regulated. There are other markets where FDA is pursuing regulatory discretion (i.e., looking the other way), giving a market segment time to mature, and for FDA to learn more about the product category – the risks to patient safety, its use by providers or patients, and developing ideas on how best to regulate when the time comes.

If your product and company are in this gray area, whether you feel you should be regulated or want to avoid regulation, you need to know where you stand and have a plan. Otherwise, you’re just winging it.

In this case, the regulatory strategy has 3 objectives:

1. Get a clear reading of where your product(s) stand relative to FDA regulation, by identifying boundaries and specific features or claims related to your product(s) that make a device regulated or not.
2. Make an informed strategic decision to either be a regulated manufacturer, or not.
3. Develop and implement a strategy based on your decision from step 2.

Let’s look at each step in detail.

Regulated or Not?

Step one is to describe the regulatory boundaries around your product(s) and market. This includes applying the definition of a medical device to your product, looking at the claims or intended use of your product, how your product is used by customers, considering competitors and similar products. While technology is a consideration, more important factors are patient safety risk (direct and indirect), and the marketing claims made about the product. Evaluating the market means looking to see if any competitors are regulated, and if so, how? You also want to consider market requirements and where the market is evolving – is this evolution getting closer to the point of care?

An attorney could spend six figures researching the above and the relevant case law – and in some situations that is what’s needed. But for most companies this assessment is less ambiguous or complex. The end product will be talking points based on research that you would want to have should someone from FDA walk in your offices, flash a badge and start asking questions.

To Be Regulated or Not?

The answer to this question is often not as clear cut as it seems, especially if your motivation is to avoid regulation. Regardless of your initial preferences, this phase entails a decision making process that takes the output of the first phase and applies filters, for example:

• What’s the likelihood FDA will regulate your product in the foreseeable future?
• How would your product and its market claims change if they were regulated or unregulated?
• What are the tactical and strategic advantages of being regulated and not regulated?
• What are the risks and associated costs of being regulated or not?

The decision to be regulated or not is based on information generated by the questions above.

Crafting a Regulatory Strategy

It is important to have a regulatory strategy whether you decide to be regulated or unregulated. Should you decide to be regulated, your strategy is geared towards becoming regulated and how you position your product from a regulatory perspective for maximum competitive advantage, lowest cost, and shortest time to market (or through regulatory hurdles). If you decide to not be regulated, your strategy defines all the things you must do to actively avoid regulation.

Depending on your situation, the actual implementation of the strategy can vary greatly. If you’re putting yourself on the path to be an FDA regulated manufacturer, you will want to do another layer of implementation planning and you probably have a substantive implementation effort ahead of you, say 6 to 12 months of work, or more.

If your strategy is to avoid regulation, the critical part is defining the boundaries you plan to maintain to avoid regulation, and making sure everyone in your company knows their part in successfully executing the strategy. Training employees (especially, product development, marketing, sales, installation and service staff) is key to successful implementation of your regulatory strategy.

Once you have your strategy in place, you’ll want to keep it up to date. A relevant announcement by FDA could trigger a reassessment of your strategy, as could a competitor submitting a product for regulation. Should one or more customers start using your product in a way that transforms it into a medical device is another potential trigger point for a reevaluation. In most cases though, taking a half day to do an annual review of the strategy and relevant internal and external changes should be sufficient.

If you’re in need of a regulatory strategy, let me know.

[Credit: Gizomdo.  The photo above from Apple iPhone 3 introduction, and an example of a company that needs a regulatory strategy - they came very close to making claims at this event that could render their iPhone a regulated medical device.]

The final rule reclassifies MDDS from a Class III postamendment device to Class I (general controls). Device reclassification has been used before to signal industry that FDA is transitioning from “regulatory discretion,” where the FDA takes a wait-and-see approach to nascent markets, to pursuing “enforcement discretion” to actively regulate new market segments.

The FDA did the same thing in the early 90s, with the development of fetal monitoring surveillance and archiving systems from QMI/Corometrics/Marquette/GE, WatchChild and others. These systems that acquired data from fetal monitors and provided remote surveillance, bedside documentation, event review and a long term archive, were also postamendment devices in which manufactures sought to avoid FDA regulation. The FDA watched the market for these systems develop over a number of years without interference and eventually reclassified them from postamendment Class III to Class II devices. That announced the shift to enforcement discretion and, like with the MDDS final rule, provided time frames in which manufacturers had to come into regulatory compliance.

A Bit of Regulatory Inside Baseball

Before we get into the meat of this, let’s get a few terms like “postamendment devices” out of the way.  By law, devices that were not actively manufactured and sold prior to May 28, 1976, are termed postamendment devices, and are automatically classified as Class III devices – the highest risk classification with the most onerous level of regulations. A device that was labeled, promoted, and distributed in interstate commerce before May 28, 1976 is a “preamendment device.” The magic date is from an  amendment to the Food, Drug and Cosmetics Act. Most Class II devices require premarket notification – also known as a 510(k) – where the device is cleared by FDA prior to selling or delivering the device to customers. (Here’s a good summary on the regulatory frameworks for Class I, II and III devices, where you can quickly see that Class III is the most burdensome.)

Legally, to qualify for the 510(k) process, the medical device must be a preamendment device. Many Class II devices today don’t qualify directly as preamendment devices, but have been accepted by FDA on the basis of “substantial equivalence.” A new device that claims substantial equivalence with a preamendment device (called the “predicate device” in this case) must have the same intended use.

Since the May 28, 1976, electronic medical devices have gone from analog circuits to digital devices, often incorporating off the shelf computers and networks. Consequently, a device designed today, especially one including connectivity, is likely to have very different technological characteristics compared to the predicate device.  So besides the same intended use, the manufacturer must provide objective evidence that the technological differences do not raise new questions of safety and effectiveness, and demonstrate that the device is as safe and as effective as the legally marketed predicate device.

A big part of regulatory strategy for some new medical devices is determining whether to seek a 510(k) and then how make a case for substantial equivalence to a preamendment device, or to engage the FDA in discussions about how they might want to regulate the new device as a postamendment device. While postamendment devices are automatically classified as Class III devices, typically the manufacturer presents their case on which classification and related regulatory framework they think should be applied to the device, and the FDA tells them what they’re going to do. Regardless of whether the device qualifies as pre or post amendment, it will most likely be regulated based on the inherent risk of patient injury or death.

Often the FDA takes the “least burdensome approach” to regulating a device (postamendment or otherwise) that ensures safety and effectiveness. Not surprisingly, both Capsule Tech and Cardiopulmonary’s products are regulated as Class II devices with premarket clearance (in the form of a 510(k)). So if a MDDS manufacturer had approached the FDA a year or 6 months ago, their MDDS would probably be regulated as a Class I or Class II device anyway (although the MDDS classification removes uncertainty for both maker and regulator). This is why the reclassification of MDDS is not the big news – the real news is that the FDA’s put a number of stakes in the ground and signaled their intent to begin enforcing regulations they have chosen not to enforce up to now.

The final rule imposes “general controls” on manufacturers. This term refers to the Quality System regulation (QSR) and, “governs the methods used in, and the facilities and controls used for, the design, manufacture, packaging, labeling, storage, installation and servicing of devices and is intended to ensure that finished devices will be safe and effective.”

Finally, let’s briefly look at the term “regulatory discretion.” This concept allows the FDA to chose whether or not to enforce regulations whenever they want, without giving up any enforcement claim in the future. An important feature of regulatory discretion is that it can be exercised sporadically and change without notice, and enforcement can be applied retroactively.

Often FDA does not provide notice to industry that they are exercising regulatory discretion regarding a certain area or topic, but refers to regulatory discretion as it relates to past actions or inaction. Regarding an action that falls under the FDA’s purview – say meeting the legal definition of a medical device manufacturer – one might anticipate that if all goes well the FDA will not become interested, but if something bad happens they will be interested. In that latter case they could find you out of compliance even though they had no previous interest in your activities. FDA often applies regulatory discretion to emerging medical device market segments, like MDDS.

Final Definition of MDDS

Since the proposed rule from 2 years ago, FDA has made some changes. Here’s the definition of an MDDS from the final rule:

An MDDS is a device that is intended to transfer, store, convert from one format to another according to preset specifications, or display medical device data. An MDDS acts only as the mechanism by which medical device data can be transferred, stored, converted, or displayed. An MDDS does not modify the data or modify the display of the data. An MDDS by itself does not control the functions or parameters of any other medical device. An MDDS can only control its own functionality. This device is not intended to provide or be used in connection with active patient monitoring. Any product that is intended for a use beyond the uses (or functions) identified in this final classification rule is not an MDDS and is not addressed by this rule.

The definition of a MDDS at § 880.6310 further states:

An MDDS may include software, electronic or electrical hardware such as a physical communications medium (including wireless hardware), modems, interfaces, and a communications protocol. This identification does not include devices intended to be used in connection with active patient monitoring.

According to the published notice (page 14 of the PDF), “A system that performs any other function or any additional function is not an MDDS.” The above is in pretty plain language and the message is clear:  don’t try reading anything into the definition of an MDDS or stretching it in an attempt to score a Class I classification for a device that is really higher risk. There’s some interesting things in the FDA’s responses to the public comments that were submitted in response to the draft rule that we’ll get into later.

As the FDA sees it, “the risks associated with MDDSs are generally from inadequate software quality and incorrect functioning of the device itself. These failures can lead to inaccurate or incomplete data transfer, storage, conversion according to preset specifications, or display of medical device data, resulting in incorrect treatment or diagnosis of the patient.” It’s their opinion that general controls (i.e., the adoption of the QSR by manufacturers), “will provide a reasonable assurance of safety and effectiveness of MDDSs.” The application of risk analysis required under § 820.30 (g) is also called out in the final rule. This is sort of like when your teacher says, okay listen up, this will be on the exam, indicating that when FDA inspects manufacturers, they will look for sufficiently robust risk analysis for MDDS devices.

Section II, Overview of this Rulemaking (page 6 in the PDF) describes in detail what’s changed from the draft rule. We won’t go into the minutia here, except to note a couple of important changes about intended users of MDDS and the use of irreversible data compression.

Based on comments received and a review of data compression features in MDDSs and similar device types, FDA has determined not to require premarket notification for MDDSs that feature irreversible data compression. In addition, the limitation on the scope of the premarket notification exemption to use by health care professionals has also been removed. Based on comments received and information FDA has gathered, FDA does not have reason to believe there is a potential unreasonable risk of illness or injury from an MDDS, even when used by someone other than a health care professional.

In a nod to the growing interest in mHealth, the reference to “intended user” means that a patient or layperson caregiver can be the intended user of a MDDS, as opposed to limiting MDDSs to use by health care professionals.

Who Is Impacted by the Final Rule?

Obviously manufacturers selling products labeled as a MDDS are impacted by this rule, like the 16 companies I track in this product category – they and their customers know what business they’re in. Note that this group currently includes at least one EMR vendor, Cerner.

Another group of manufacturers, targeting the physician office market, also fall under the MDDS rule. These products are intended to acquire medical device data and automatically incorporate it into the appropriate patient’s EMR record. This market segment is dominated by proprietary APIs offered by market leaders (the only ones with sufficient clout to get others to write to their APIs).

These companies include Cardiac Science, Midmark and Welch Allyn on the device side, and a small number of EMR vendors who’ve decided they can play that game too and created their own proprietary medical device connectivity APIs, such as Allscripts’ Helios. Certainly the intended use of these manufacturer’s APIs matches that for a MDDS; should the functionality in the API match that described in the final rule (whereby medical device data can be transferred, stored, converted, or displayed) FDA will likely come a knockin’.

Another group received a surprising amount of attention in the final rule notice, health care providers. From a regulatory perspective, any entity that makes a medical device is a “manufacturer.” Hospitals and even physician practices can be designated manufacturers by FDA and regulated as such. For the most part, the FDA has used its regulatory discretion to not treat providers as manufacturers. The final MDDS rule seems to strongly signal FDA’s interest in regulating providers who assume the activities of a manufacturer. In the draft rule (PDF here), providers barely got a mention – and then only in the context of a user of MDDSs.

During the public comments period after the publishing of the draft rule, FDA received a comment that asked, “whether a health care facility or other purchaser that buys software or hardware that has not been labeled or otherwise denoted as an MDDS, and that then subsequently utilizes the software or hardware for functionalities within the scope of this MDDS regulation, will be considered a manufacturer.” Here’s FDA’s response:

A health care facility or other purchaser that buys software or hardware that has not been labeled or otherwise denoted as an MDDS, but is used as an MDDS, is not considered to be a manufacturer. If, however, the purchaser adds to or modifies any hardware or software such that the software is intended to provide the transfer, storage, conversion according to preset specifications, or display of medical device data (or otherwise modifies the product to render it a medical device) and uses it in clinical practice, the purchaser becomes a device manufacturer in accordance with § 807.3(d). If a third-party company or hospital develops its own software protocols or interfaces that have an intended use consistent with an MDDS, or develops, modifies, or creates a system from multiple components of devices and uses it clinically for functions covered by the MDDS classification, then the entity would also be considered a device manufacturer.

If you’re a provider, read that paragraph again. Since the data protocols coming out of virtually all medical devices are proprietary, and you can’t buy a general purpose product that includes those protocols, creating a system that acquires medical device data will necessitate actions that will render you a manufacturer.

In a following comment about medical device reporting (MDR), FDA stated that, “Manufacturers, including hospitals that develop custom systems that meet the definition of an MDDS, must comply with the MDR requirements in part 803.” So there are two gotcha’s for providers that can get them sideways with FDA:  by doing things that make them a manufacturer, and by not reporting deaths and serious injuries to which the MDDS may have caused or contributed. As a hospital, if you meet the definition of a manufacturer, you also must establish and maintain adverse event files, and submit summary annual reports to FDA.

Manufacturers with products similar to MDDSs are also addressed in the final rule. Both alarm notification and surveillance are mentioned specifically in the draft rule as falling outside the MDDS classification. Two market segments that fit the comments in the draft rule are alarm notification or messaging middleware systems (I track 13 companies here, like Ascom, Philips/Emergin, GlobeStar Systems and Extension) and what I call data aggregation systems (less than a handful companies like, LiveData and Global Care Quest/Storz). The final rule streamlines the text around these applications and simply states, “A device intended to be used for active patient monitoring (or decision support) is not an MDDS,” and, “This identification does not include devices intended to be used in connection with active patient monitoring. There are existing classifications for patient monitoring devices.”

Obviously, alarm notification and surveillance of near real time waveforms are functions related directly to active patient monitoring. The proposed MDDS rule generated a lot of comments about whether or not alarm notification is part of a MDDS. Certainly an MDDS acquires alarms along with other physiological data from a medical device and passes it on to other devices or systems. And the MDDS system itself will likely have alarm notification covering the operation of MDDS itself – if an important parameter or component in the MDDS fails, some sort of notification is needed so the failure can be addressed. All true agrees the FDA in the final rule (page 26), and they even removed, “sound an alarm” from the final regulation.

It’s clear from the final rule that alarm notification or messaging middleware systems are not MDDSs. But FDA goes even farther: “Any device that transmits, stores, converts, or displays medical device data that is intended to be relied upon in deciding to take immediate clinical action or that is to be used for continuous monitoring by a health care professional, user, or the patient is not an MDDS.”  This means that alarm notification systems that rely on MDDSs for alarm and other medical device data have a problem. They’ll either have to shoulder the MDDS component themselves, or go with a manufacturer with premarket notification.

All this mentioning of alarm notification and surveillance indicates that the FDA expects the manufacturers of these devices that are not regulated to get with the program. Conversations with many of the alarm notification vendors indicates that they are preparing to become or are already in the process of becoming regulated. Interestingly, Philips received 510(k) clearance on Emergin as an Event Management system on January 4, 2011. And just for comparison, here’s the 510(k) for Welch Allyn’s Clinician Notifier that was issued in 2007.

In summary, FDA is signaling the manufacturers in market segments related to MDDS that they too are facing enforcement discretion and better get with the program.

Manufacturer Responsibilities and Timing

The rule becomes effective 60 days after the data of publication of the final rule in the Federal Register. The magic publication date was February 15, 2011. Here’s a listing of key milestones:

• All MDDS manufacturers have 90 days after the date of publication (May 16, 2011 by my counting) to electronically register and list with FDA as a medical device manufacturer.
• Manufacturers have a generous 12 months (February 15, 2012) to implement a compliant quality system, including Medical Device Reporting. FDA also states that, “FDA expects all MDDS manufacturers to establish and maintain adequate design controls as part of their quality system.”
• FDA is also pretty generous regarding the adoption of design controls: “FDA does not intend to enforce design control requirements retroactively to any currently marketed device that would be classified as an MDDS under this rule; however, FDA does intend to enforce design control requirements for design changes to a currently marketed device once there is a design change.”

What To Do Now

If you are or want to be a MDDS manufacturer (and you know who you are), and you’re not presently regulated, you need to put together an initial roadmap. After that comes more in depth planning and budgeting. If you’re a MDDS manufacturer and already regulated, an analysis of your regulatory options is called for. For example a manufacturer’s product that’s regulated as a Class II device has a number of options: shift to Class I, stay at Class II with the same intended use, or perhaps adjust the intended use to address specific market opportunities.

If you’re an EMR vendor how even might meet the definition of a MDDS manufacturer, and haven’t already put together your roadmap and plan, don’t wait any longer. Sixty days will be up before you know it, and you really don’t want to learn first hand the meaning of the term “adulterated device.”

If you’re a health care provider – a hospital or large group practice – and you too might meet the definition of a MDDS manufacturer, and haven’t already put together your roadmap and plan, don’t wait any longer. Sixty days will be up before you know it, and you really don’t want to learn first hand the meaning of the term “adulterated device.” In your case, an adulterated device finding will keep you from using your own system.

If you’re a health care provider and you’re looking to purchase a MDDS, alarm notification or data aggregation system, seek some expert advice. Things are changing relatively quickly (for health care) and this final rule will have a ripple effect on manufacturers.

If you’re an unregulated manufacturer in a market segment close to MDDS, like alarm notification or data aggregation, you too need a roadmap and plan. Many of your competitors are already down this path, some quite a ways.

There’s still some issues in the final MDDS rule that we’ve not reviewed, some interesting comments and FDA responses, and analysis. I’ll be posting more on this, and responding to comments. I will also be doing an updated version of the Compliance Online webinar on the MDDS rule (here’s a link to the original).

If you found this post entertaining, you might like the article in this month’s Patient Safety & Quality Healthcare magazine, The Case for Regulating EMRs, by yours truly.

Here are some other sites with posts on the final rule:

• MorganLewis blog post by Beth Bierman offers a very high level summary and some interesting observations
• The inestimable Brad Thompson as another of his great posts on regulatory issues at mobihealthnews with some great analysis
• Health IT Exchange has a post focused on the FDA’s apparent intent to regulate hospitals who act like manufacturers
• And here’s my post on the draft rule from 2 years ago

DISCLAIMER:  Nothing in this blog post, or in any of the content in this site, is intended as legal or regulatory advice, and is provided as opinion and commentary on current events.

UPDATE: I revised the blog post title to make it easier to find in search engines.

UPDATE: William Hyman was kind enough to pass on this information:

April 19, 2011 – The FDA has posted the new MDDS Rule and associated explanation and comentary at its website.