FDA regulation of Medical Device Data Systems has changed significantly over the years. This, together with the blurred line between MDDS and general health information technology, interfaces between MDDS and regulated medical devices, the actual criteria for deciding if something is classified as a Medical Device Data System, and different regulatory requirements outside the US leaves significant confusion despite FDA’s attempts to clarify their current position.
FDA’s use of the term Medical Device Data Systems (MDDS) makes it pretty clear that MDDS fit the definition of a Medical Device in medical device law and regulation. So, the real question is how does FDA choose to regulate MDDS at a given point in time or by specific staff in specific situations. At one point FDA put significant effort into ensuring that industry understood that MDDS are regulated and compliance with the 21 CFR 820 and related regulations was required and this was specifically stated in an actual classification rule 21 CFR 880 in 2011. Representatives of FDA also worked with the Association for the Advancement of Medical Instrumentation on AAMI / ANSI SW87:2012, Application Of Quality Management System Concepts To Medical Device Data Systems which was released in Jan 2013.
For Medical Device Manufacturers with experience with FDA this was taken in stride for the most part. For general providers of Health IT systems ranging from start-ups to large companies, there was significant concern and confusion.
In February 2015 FDA issued the guidance “Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices” which exempts certain types of MDDS from FDA regulation using “enforcement discretion” although the actual rule 21 CFR 880 has not been modified. Since this is discretionary FDA could change its position at any time.
In December 2016, the “21st Century Cures Act” became law and placed certain functionality outside the scope of FDA regulation, but FDA continues to evaluate how to interpret and apply this law.
So what’s a company supposed to do? The short answer is to first ensure its product really does fit FDA’s definition of MDDS under enforcement discretion, and if it does, then compliance is not currently required.
The longer answer is a bit complicated as it relates to future regulatory risk and field safety liability risk. Whether compliance with FDA regulation is a requirement or not, it is clear that MDDS presents some health risk. Since communication of medical data can result in data corruption, loss, or patient mix-up there is certainly safety risk. If patients are directly or indirectly injured as a result there are a variety of risks. Depending on the intended use of the MDDS, including the type of medical data and patients involved, risk may vary.
In addition, FDA may change their position in general or in a specific situation to address a threat to the public health. If one has developed and validated the MDDS informally with no documented design controls, safety risk management, or formal field surveillance what does one do if FDA suddenly changes its policy again. No change in the law is needed in instances of “enforcement discretion.”
While there is currently a Bill in the US congress that could move some of this “discretion” into law there are no guarantees the Bill will pass or won’t change significantly. At the same time Rule 11 in the new EU Medical Device Regulation appears to raise regulation on standalone medical devices including MDDS.
My personal recommendation varies a bit depending on the type of company developing the MDDS. If it’s a medical device company why not just follow existing internal procedures but scaled to fit the reduced regulatory risk? If it’s a small startup, rather than focus on overall FDA Medical Device compliance, use the current enforcement discretion but ensure formal risk management and software lifecycle and maintenance controls and documentation to demonstrate safety and effectiveness internally, and if needed in the future, to FDA and to other regulatory authorities.
For larger Health IT companies that can vary depending on the formality and effectiveness of current internal software and field support quality procedures. If current procedures are formal and effective then perhaps just stick with them. If not then focus on the same items as mentioned for startups but also focus on incorporating the wide range of available Health IT standards for software and requirements set by the Office of the National Coordinator for Health Information Technology (ONC) in the Department of Health and Human Services.
There is no one-size-fits all for MDDS so confusion is likely to persist. There is significant complexity in assessing the varying types of risk involved, tailoring a specific approach to ensure efficiency as well as effectiveness, and articulating the approach taken in a defensible manner both for regulatory and patient safety.