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.