FDA MDDS – Still Confusing After All This Time

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.

 

SoftwareCPR Training Courses:

IEC 62304 and other emerging standards for Medical Device and HealthIT Software

Our flagship course for preparing regulatory, quality, engineering, operations, and others for the activities and documentation expected for IEC 62304 conformance and for FDA expectations. The goal is to educate on the intent and purpose so that the participants are able to make informed decisions in the future.  Focus is not simply what the standard says, but what is meant and discuss examples and approaches one might implement to comply.  Special deep discount pricing available to FDA attendees and other regulators.

3-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Brian Pate

Next public offering:  TBD

Call or email now to schedule a private, in-house class. The fall schedule is filling up!

Email training@softwarecpr.com to request a special pre-registration discount.  Limited number of pre-registration coupons.

Registration Link:

TBD

 


 

Being Agile & Yet Compliant (Public or Private)

Our SoftwareCPR unique approach to incorporating agile and lean engineering to your medical device software process training course is now open for scheduling!

  • Agile principles that align well with medical
  • Backlog management
  • Agile risk management
  • Incremental and iterative software development lifecycle management
  •  Frequent release management
  • And more!

2-days onsite (4 days virtual) with group exercises, quizzes, examples, Q&A.

Instructors: Mike Russell, Ron Baerg

Next public offering: TBD

 


 

Medical Device Cybersecurity (Public or Private)

This course takes a deep dive into the US FDA expectations for cybersecurity activities in the product development process with central focus on the cybersecurity risk analysis process. Overall approach will be tied to relevant standards and FDA guidance documentation. The course will follow the ISO 14971:2019 framework for overall structure but utilize IEC 62304, IEC 81001-5-1, and AAMI TIR57 for specific details regarding cybersecurity planning, risk characterization, threat modeling, and control strategies.

2-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Dr Peter Rech, 2nd instructor (optional)

Next public offering:  TBD

Corporate Office

15148 Springview St.
Tampa, FL 33624
USA
+1-781-721-2921
Partners located in the US (CA, FL, MA, MN, TX) and Canada.