On February 14, 2011 the FDA published notice (press release) of the long awaited final rule for medical device data systems (MDDS). The real news behind the final MDDS rule is not the less-burdensome path to market trumpeted by many news stories, but the FDA’s stated intent to exercise “enforcement discretion” with regard to those who create MDDS. For the MDDS vendors who are already regulated (Capsule Tech, Cardiopulmonary Corp, Dawning Technologies,  Nuvon and others) this final rule is an easing of the regulatory burden. For those that aren’t (e.g., Bridge-Tech Medical, CareTrends, iSirona and others – I currently track 16 companies in the MDDS category) this final rule signals that FDA enforcement actions will be forthcoming for manufacturers that don’t meet FDA’s implementation deadlines (more on that later).

The final rule reclassifies MDDS from a Class III postamendment device to a Class I device (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 1990s, 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:

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.

republished and adapted with permission from Tim Gee, Medical Connectivity Consulting

Learn more about how FDAzilla can help you achieve your quality and inspection preparation goals: get 483s, Inspector Profiles, Enforcement Analytics, and GMP Regulatory Intelligence.