By Bradley Merrill Thompson, Epstein Becker & Green, P.C.
To many people, including especially those who are not familiar with FDA's medical device regulations, reading the new MDDS rule is a bit difficult. We all like to read stories that have a beginning, a middle and an end. They paint an entire picture. Unfortunately, reading the MDDS rule is like reading just the middle of the story -- it leaves you unsure about what went on before and what will go on after.
Using a different metaphor, FDA has published just one piece to a puzzle, only the rabbit’s nose, and we have to use our imagination and some logical inferences to see the rest of the rabbit. We will only know for sure what the rest looks like as FDA continues to publish new classifications that cover software. Eventually, all of these classifications taken together will show us the agency's approach to regulating software.
Falling outside the MDDS classification has two potentially opposite consequences. On the one hand, falling outside might mean that the product is not regulated by FDA at all. On the other hand, falling outside the MDDS classification might mean that the product is a class II or III medical device, a very different outcome. So every time FDA says in the preamble to the final rule that something might fall outside of the classification, it could be for either reason. Sometimes you might actually prefer to be in MDDS to avoid class II status.
So the good news, at least for those companies that already knew their products were regulated, is that FDA maintained its proposal to place MDDS in class I, exempt from premarket notification (510(k)). The bad news for those who were on the edge and thought they might not be regulated is that being in the MDDS classification means they need to adopt a quality system, register and list with FDA, and report adverse events associated with their product to the agency.
Scope of the Classification
Remember, software only falls into the medical device category and the MDDS rule if the organization selling, renting, or otherwise sharing the software makes claims that the software is useful for the medical purposes described in the MDDS classification. FDA will not regulate generic IT software that is not promoted for medical uses and that is not specially designed for those purposes.
Simply stated, the MDDS category includes all those systems designed and marketed to transfer, store, convert according to preset specifications, or display medical device data without controlling or altering the function or parameters of any connected medical device. That seems simple enough. Software that provides functionality such as decision support is not within that definition. Likewise software that includes active flagging on behalf of the medical device also will not fit. Basically, MDDSs are passive databases and communications software products. But the exact parameters of those systems required FDA to refine its original proposal on how to regulate MDDSs.
Focusing on the big picture, the changes FDA made to its proposed MDDS rule simultaneously enlarge the MDDS category to capture more software that we might have assumed would be unregulated, but also enlarged the MDDS category to capture software that might otherwise have been placed in class II or III.
Among those changes that enlarge the MDDS classification to include products that might have otherwise been unregulated are:
- Software designed to convert medical device data from one computer language to another (e.g., HL7 to XML, PDF, etc.).
- Hospital-derived software designed to have an intended use consistent with an MDDS.
- Some workflow or billing systems that transfer, store, covert, or display medical device data.
- Hardware, such as modems, that are expressly promoted as part of the system
Among those changes that enlarge the MDDS classification to include software that might otherwise have been in class II or III include:
- In the revised rule, FDA will permit flagging if done on behalf of the MDDS system, meaning to indicate that the MDDS system is malfunctioning.
- FDA dropped the limitation that would have required a premarket notification for any software that performed irreversible data compression (okay, it was still to be in class I, but having to file a premarket notification makes it like class II)
- Likewise, FDA dropped the limitation that would have required a premarket notification for any software intended for lay users.
In addition to those changes that enlarge the classification, FDA made a few changes that shrink the classification, thus potentially expanding the categories of software that might be placed in class II or III, including:
- FDA dropped the use of the word "exchange" because the agency feared use of that word would suggest that software that plays a more active role in interacting with medical devices might be swept into the MDDS category.
- In the same vein, the agency dropped the word “retrieval.”
- Likewise, FDA deleted the phrase "from a medical device.”
FDA also made numerous changes just to clarify the scope, without necessarily trying to shrink or enlarge the category, including:
- FDA tried to simplify the language by replacing the cumbersome phrase "real-time, active, or online patient monitoring" with simply "not intended to be used in connection with active patient monitoring". The goal was to express more succinctly the passive role MDDS devices play in comparison to an active decision-making function.
- FDA also clarified that it does not matter whether the medical device data flow to or from the system.
- While it may have been implied in the proposal, the agency expressly states that the category does not include software that calls for manual data entry. The defining characteristic of the MDDS classification is the automatic flow of medical device data into the system. Unfortunately, the agency doesn't define medical device data very precisely, leaving us to infer that it is somehow bits and bytes that automatically flow out of a regulated medical device.
What If The Medical Device Data Passes Through Other Systems First?
Let's say a piece of software gets data from a medical device four steps removed. There is no limitation based on how distant the original source of the data is, so long as the flow of that data is automated and not manual. The final rule indicates that medical device data are any electronic data that are available directly from a medical device or that were obtained originally from a medical device. This second clause implies there can be intervening steps between the medical device and the MDDS device.
Does MDDS Include Electronic Health Records Or Personal Health Records?
Well, yes and no. If an electronic health record or personal health record meet the core definition of MDDS, then it would be in this classification. FDA is anticipating, however, that many such records will not. The basis for their assumption is the view that electronic health records, at least the old-fashioned variety, depend on manual entry of data of any medical device data. Those who are watching the market realize, though, that more and more electronic health records are accepting automatic transfers of medical device data.
The strategy might therefore be to try to quarantine that portion of the record that would constitute an MDDS device. Thus, the part of the system into which the doctor or other caregivers simply input their information would fall outside the MDDS classification. The underlying software of health information exchanges—where patient data (including medical device data) are transferred between healthcare facilities—may now more easily fall within the definition of MDDS.
Does This Only Apply To Companies Traditionally Recognized As Manufacturers?
Nope. FDA makes it clear that hospitals and other healthcare institutions that choose to create this software will be treated as the manufacturer of an MDDS device. This includes those healthcare institutions that make these systems from scratch, and also those healthcare institutions that materially modify purchased MDDS systems outside the parameters set by the original manufacturer. The one exception is buying an off-the-shelf system not intended for medical purposes, and using it without modification.
How Does This Relate To Other Classifications?
Industry will need to sort that out. Basically, if a piece of software arguably fits into two different classifications, it may be regulated in the lowest classification it fits. In many ways, the MDDS classification is very narrow, and if a piece of software can fit that classification, then it will be in class I even if it might also arguably fit into another classification such as PACS. But if a piece of software has functionality elements that are found in the PACS classifications that are not found in the MDDS classification, it will be placed in the PACS classification.
Applying the Accessory Rule.
Remember the accessory rule says that any medical device promoted for use specifically with another medical device will be regulated in the same classification as that other medical device. Anticipating questions around this, FDA explains that if the piece of hardware such as a modem is promoted specifically for use with an MDDS, then that modem would itself become a part of the MDDS.
The converse raises some interesting questions. If a company selling an MDDS says that it is for use with another medical device such as a blood glucose meter, how will FDA regulate the MDDS? It would appear that so long as the MDDS manufacturer stays within the contours of what defines an MDDS, the product will stay in that MDDS classification, even though a blood glucose meter is in class II. I have to say, though, the language in the preamble is not crystal clear on this point.
Implementation
The rule becomes effective on April 14. By May 14, companies that make MDDS must have registered with FDA and listed the MDDS product. By April 14, 2012, about 14 months from now, companies making MDDS must have fully functioning quality systems and be in compliance with the medical device reporting rules.
FDA says implementing a quality system should cost around $20,000. Unfortunately, in my experience, that estimate is simply way too low. The actual cost depends on the size of the operation, but also the degree to which the company has already implemented a quality system. As discussed in my prior post, a quality system meeting FDA requirements has some important differences from a quality system that implements just ISO standards. Fortunately, though, FDA seems willing not to require everyone to go back and try to create design controls that may not have been employed when the MDDS was made.
FDA justifies the costs that the rule imposes on industry by observing that these types of software have always been regulated, and by this action FDA technically is deregulating this category of software from its automatic class III designation. That's a bit of a stretch considering in reality FDA never enforced the class III designation. So all of this sure feels like new requirements.
Conclusions
As I said, reading the Federal Register notice does not shed a lot of light on the big picture of how software, broadly speaking, will be regulated by FDA. By design, FDA took one piece of the overall software puzzle, and a fairly small piece at that, and determined its classification. We will have to wait over the coming months and years to see how FDA classifies other related categories of software. That said, we have more clarity today than we did yesterday.
