UPDATE: This post discusses the proposed MDDS rule that came out in 2008. If you’re looking for the final MDDS rule that came out in early 2011, look here.
On February 8, 2008 the FDA published a proposed new rule for public comment (pdf version). The new rule provides some definitions of connectivity software and proposes to reclassify some types of connectivity software. The rationale for the proposed rule is as follows:
Since 1989, the use of computer-based products and software-based products as medical devices has grown exponentially. In addition, device interconnectivity and complexity have grown in ways that could not have been predicted in 1989. This growth and expansion have created new considerations for elements of risk that did not previously exist.
Up to this point the FDA has relied on their “Draft Software Policy” published in 1989 (link – pdf). This software policy recognized that software could (and did) meet the definition of a medical device and extended the FDA’s purview from conventional devices to software. This was not a bureaucratic land grab, but a recognition that the legal definition of a medical device could and had been met by software.
What is an MDDS? From the proposed rule (emphasis mine):
A medical device data system (MDDS) is a device intended to provide one or more of the following uses:
- The electronic transfer or exchange of medical device data from a medical device, without altering the function or parameters of any connected devices. For example, this would include software that interrogates a ventilator every 15 minutes and transfers information about patient CO2 levels to a central patient data repository;
- The electronic storage and retrieval of medical device data, without altering the function or parameters of connected devices. For example, this would include software that stores historical blood pressure information for later review by a healthcare provider;
- The electronic display of medical device data, without altering the function or parameters of connected devices. For example, this would include software that displays the previously stored electrocardiogram for a particular patient;
- The electronic conversion of medical device data from one format to another format in accordance with a preset specification. For example, this would include software that converts digital data generated by a pulse oximeter into a digital format that can be printed.
- Examples of medical device data systems that would be used in the home are systems that periodically collect data from glucose meters or blood pressure devices for later review by a healthcare provider.
Medical device data consist of numerical or other information available from a medical device in a form suitable for processing by computer. Medical device data can represent many types of information (e.g., clinical values, alarm conditions, error messages). MDDS are not intended or designed to provide any real time, active, or online patient monitoring functions. Medical device data systems can deliver and store alarm data but do not have the capability to display, create, or detect alarm conditions, or to actually sound an alarm. In particular, a MDDS can record the fact that an alarm sounded, but cannot by itself sound an alarm in response to patient information. Medical device data systems cannot create alarms that are not already present from the connected medical devices. By themselves, MDDS do not provide any diagnostic or clinical decision making functions. Medical device data systems can transmit, exchange, store, or retrieve data in its original format or can be used to convert the medical device data from one format to another so that the arrangement or organization of the medical device data is in accordance with preset specifications.
From the definition above, products from Capsule Tech, Sensitron, Cerner, Cardiopulmonary Corp., GlobeStar Systems, LiveData, Global Care Quest, iSirona and many more, fall under the MDDS definition. Emergin may not meet the definition if they do not take data directly from the medical device (they use Capsule Tech for at least some of their device connectivity). Also falling under this MDDS definition are the proprietary APIs for integrating medical devices into physician office EMRs from Midmark, Welch Allyn, Cardiac Science, AllScripts and others.
Further down in the proposed ruling, it says, “A manufacturer of a MDDS device that is indicated for use by anyone other than a healthcare professional or that performs irreversible data compression would need to submit a premarket notification…” And at the end of the rule (emphasis mine), “When the device is indicated to be prescribed by a healthcare professional for use by a lay user, or performs irreversible data compression, or for over-the-counter use by a lay user, the device requires the submission and clearance of a premarket notification.” The Microsoft HealthVault Connection Center is software intended to acquire data from medical devices for use by patients, and will apparently be a Class III device.
The whole “reclassification” issue is a bit of a red herring. As William Hyman explained on the Biomed Listserv, “…all medical devices unknown prior to 1976 are automatically Class III. Thus if the FDA defines something as a new medical device, it is Class III [by default], unless it is reclassified to some other class.” Up until now, the FDA was not been particularly aggressive in regulating what will from now on be called medical device data systems. One might draw the conclusion that, with the advent of this new rule, the FDA will be more aggressive in regulating these devices (one can hope).
Besides the obvious question of whether the FDA is really serious about regulating MDDS, a few things jump out as areas that need clarification. Medical device interoperability is clearly a step beyond MDDS, as is continuous monitoring functions like surveillance. But the differences between handling alarms that is part of an MDDS and that which is a Class III device are less clear.
Software that can, “display, create, or detect alarm conditions, or to actually sound an alarm” does not qualify as a MDDS and is thus a Class III device. But, “Medical device data systems can deliver and store alarm data.” The text goes on to state, “In particular, a MDDS can record the fact that an alarm sounded, but cannot by itself sound an alarm in response to patient information.” So does a system that effectively repeats an alarm received from a medical device, as opposed to sounding an alarm based on “patient information,” fall under Class III? Is the alarm generated by the medical device “patient information” or must the software generate its own alarms based on physiological data received from the medical device (e.g., like OBS Medical) qualify as Class III? Just what does “patient information” really mean?
This ambiguity around alarms threatens to end the current exemption for “secondary” alarm notification systems and pull them under FDA regulation. Based on the proposed rule, it seems safe to say that an alarm notification delivered with a physiological waveform will be a Class III device (i.e., a monitoring function). And from the text, “to actually sound an alarm,” and “sound an alarm,” any software that delivers alarm notifications will be a Class III device. Vendors like Emergin, Global Care Quest, GlobeStar Systems, and LiveData could be impacted by this new rule.
During HIMSS this week, I asked many vendors about their take on this proposed rule. Responses fell into 3 groups: the clueless (or in denial), those that don’t do alarm notification and are regulated or preparing to become regulated, and those that do alarm notification and hope that the FDA won’t close the door on “secondary” alarm notification. An outlier is Cardiopulmonary Corp who received premarket approval for their alarm notification features years ago.
The effective date for these changes will be 60 days after the date of the publication of the final rule. Here is the FDA’s schedule:
FDA intends to continue to exercise enforcement discretion after publication of any final rule so that manufacturers who are already on the market with MDDS devices may have sufficient time to come into compliance as follows: FDA expects manufacturers who are already marketing a MDDS device before publication of a final rule and who meet the criteria for list under part 807 within 60 days after publication of the final rule. If a premarket notification is required, FDA expects manufacturers who are marketing an MDDS device without FDA clearance to submit a premarket notification within 90 days of the effective date of a final rule and to obtain final clearance of a premarket notification within 180 days after publication of a final rule. FDA expects manufacturers who are required to obtain clearance of a premarket notification to register and list within 30 days after receiving a substantial equivalence order for their device. Manufacturers who are not already marketing an MDDS device will be required to comply with any final rule as of the effective date.
So, if you end up as a Class I MDDS or Class III device you have between 60 and 90 days after the final rule to get your act together. This is clearly not the time to delay action.
For a vendor who has never been regulated or faced the prospect of a Class III designation, this new rule can be intimidating. But things are not as bad as they seem; note that when the FDA regulated MDDS as Class III devices, they waived the most onerous and expensive parts of Class III regulatory requirements resulting in what was equivalent to a Class II regulatory burden. The point here is that those looking at a potential Class III designation are not as bad off as they likely imagine.
Depending on your situation, the biggest regulatory requirement is probably supporting the Quality System regulation, or QSR. This is a basic safety engineering framework intended to maximize product quality and safety. We all know that product defects are significantly less expensive to fix the earlier in the development process they are addressed. Most any software vendor – in our outside of health care – would benefit from the kind of checks and balances the QSR brings to the design process. If you write code first, do the design later and maybe document everything if you have time (or feel like it), implementing the QSR will be an expensive and character building process. If you operate at a software Capability Maturity Model level of 3 or higher (there are 5 levels), implementing QSR will be relatively painless.
If you’re a vendor, go ahead and get a legal opinion on the likelihood you’re product will be regulated and become a Class I or Class III medical device. Note that actually developing a regulatory strategy after classification is determined is where things get complicated.
Like life, regulatory strategy is neither black or white, but shades of gray. The job of regulatory attorneys is to identify regulatory risk. It is the role of management to determine the level of risk to be assumed by the company. Set that risk level too low and men with badges show up muttering, “adulterated product.” Set the level of risk too high and you place your firm at a competitive disadvantage against vendors who strike a better risk/benefit balance. Letting regulatory law firm define your regulatory approach is a mistake.
Implementing the QSR is not rocket science, although it can be mind numbingly detailed. Look for a reputable regulatory consulting firm who can provide a template product development process (PDP) that is QSR compliant. Keep things simple – I’ve seen PDPs defined in tens of pages and those that span 2 or 3 binders. The FDA does not grade you on the complexity of your PDP, they grade you on how well you follow your own PDP – one that’s easy to understand and follow is best.
After the QSR, you need to develop a regulatory strategy for each of your products. Developing the strategy is an iterative process that balances various aspects of the product definition and the regulatory process. My approach to is entails a holy trinity in regulatory strategy: the intended use of the medical device, how your product is specified, and the risk analysis done during the design phase. Where a product falls regarding regulatory requirements is heavily influenced by how these key factors are managed and applied. (There are many other factors, of course, but these 3 can serve as guideposts.) The optimal balance results in the most competitive product at the lowest cost with the shortest time to market that is in full regulatory compliance.
Regulated software that automates workflow through the integration of medical devices with information systems is different from straight embedded devices or software applications. For firms new to all this (i.e., the majority) you should get advice and guidance that span both device and software regulatory perspectives. The most common vendor mistake that I see is the application of embedded system regulatory strategies to software products – a very expensive error.
If you need any help – finding regulatory attorneys or consulting firms, let me know. I can help personally with overall guidance and in developing regulatory strategies for product lines or individual products.
UPDATE: Here’s a nice summary of the proposed rule from CIMIT (here).
UPDATE: You can read a new blog post on the proposed MDDS rule here.