This summer, FDA proposed lifting regulations from certain currently regulated medical devices. This unprecedented policy shift targets devices known as Medical Device Data Systems (MDDS) and is intended to benefit the mobile app industry and companies like Google, Apple and others. The current regulatory burden for MDDS devices is Class I, 510(k) exempt. This means manufacturers have to follow a basic quality system (i.e., design controls) on par with ISO9001, and report instances of patient injury or death in addition to any product recalls to FDA.

The following is a guest blog post embodied in an abridged version of a comment submitted to FDA in response to their draft guidance.


Many EHRs and a significant number of health IT (HIT) and clinical decision support (CDS) systems are, by current law, de facto Class III Medical Devices because they have not heretofore been regulated and classified.  Class III devices are the high-risk devices and subject to the highest level of regulatory control.  Because they are new and have never been regulated (and thus embody an unknown level of patient safety risk) new products are by default classified as Class III devices. Most products that come to market are “updates” of existing solutions based on older technology. These products can claim previously regulated devices, known as predicate devices, and are typically classified as Class II devices. After their initial regulation as a Class III device, new products for which there is no predicate device are often classified as Class II devices.

The FDA currently practices regulatory enforcement discretion over many HIT and CDS systems (but not quite all – e.g. Blood Bank software), leaving them in a sort of classification limbo.  If properly classified, some might end up Class II, Class I, or even unregulated.  (

In 2011 the FDA took a concrete step to rationalize regulation in the HIT space when it finalized the Medical Device Data System (MDDS) rule basically a new Class I, 510(k) exempt device regulation for the simplest type of HIT medical device interfaces that transmit, store, and display medical device data without significantly altering it.  Since then at least 316 MDDS devices have been listed with the FDA. (To view current FDA registered MDDS devices, go here and enter “oug” into the Product Code field in the query form.)

In a surprising move, in June 2014 the FDA issued the Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices Draft Guidance for Industry and Food and Drug Administration Staff (MDDS Draft Guidance) that proposes to eliminate FDA regulatory oversight of MDDS through enforcement discretion.  The agency’s justification was:

“Since down-classifying MDDS, the FDA has gained additional experience with these types of technologies, and has determined that these devices pose a low risk to the public.”

The MDDS Draft Guidance did not describe what the “additional experience” was to merit their determination, “that these devices pose a low risk to the public.”  Separately, on public blogs FDA officials have stated they expect HIT products to be regulated by a different agency within HHS – even though no law or authority de-classifying those products (such as EHRs) as medical devices has been passed.

We personally don’t know anyone who doesn’t feel the FDA and their processes couldn’t be improved, but in our opinion it’s the best system we have in place now.  Like other HIT, MDDS’s can create significant patient safety and cybersecurity risks even if their intended functionality is as a simple data pipe. Dropping regulatory oversight over MDDS  devices is throwing the baby out with the bathwater.  The quality and value of HIT technologies like MDDS and their connected EHR and CDS systems depends on having interfaces that provide trustworthy data. Otherwise garbage inputs will result in garbage outcomes.

We submitted a comment through opposing the proposal to eliminate enforcement of the MDDS rule.  The major points are summarized below.  The entire MDDS rule can be found here, and the MDDS Draft Guidance Document can be found here.  Our full comments are available here, as published on


Our Comment on the Draft MDDS Guidance Document covers three topics:

1)     Cybersecurity Risks

2)     Software Defects from Complex Connected Systems

3)     Known MDDS Device Defects

Cybersecurity Risks

In any component, system, or system of systems, the security of the whole is only as good as its weakest link.  FDA’s “accessory rule” concept applies well in the domain of security and privacy.  Any interface, as a component of a larger system, poses a potential security or privacy vulnerability. Additionally and importantly the functionality, classification, interface standard conformance, or intended use of the interface does not correlate with the potential for that interface to contain a security or privacy vulnerability. For example a wireless connection is not any more or less vulnerable to cyber attack if it is intended only to receive occasional physiological data. Every MDDS, especially wireless ones, create potential cybersecurity vulnerabilities.  Design controls are a necessary, but not a sufficient, means to reduce those vulnerabilities.  Without them MDDS’s and everything they touch becomes more vulnerable.

We believe providers and clinicians under-report security and privacy violations and will continue to do so until they have additional liability protection. Thus the FDA’s collection of cybersecurity vulnerabilities is incomplete.  The only argument can be over how much they miss.  Post-market surveillance of cyber security should probably be beefed up for all medical devices, particularly for HIT such as EHRs.

There may well be systemic, real, or imagined reasons why providers, hospitals and HIT manufacturers are reluctant to report cybersecurity vulnerabilities in their medical devices and HIT systems.  Which is why we further suggest that the in addition to the FDA continuing regulatory oversight over MDDS’s including post-market surveillance, the FDA as well as other agencies such as NIST, FCC, and ONC should expand their cooperative efforts to improve collection and analysis of the nation’s entire HIT infrastructure’s cybersecurity vulnerabilities. But that is a large topic best left for another article.

Software Defects from Complex Connected Systems

In 2012 The Food and Drug Administration Center for Devices and Radiological Health Office of Compliance Division of Analysis and Program Operations published Medical Device Recall Report FY2003 to FY2012. The entire report can be found here (pdf).

The report concluded (see page 18) that software design failures were the most common cause of medical device recalls and recommended expanding regulatory oversight of software medical devices.  We agreed with that finding in 2012 and still agree with it now. Increasingly connected, integrated, interfaced, or interoperable systems are more complex and have more complex interactions.  Therefore they are more likely to contain defects in their individual components or the systems as a whole.

Basic Systems Engineering tells us that the FDA’s proposal to drop design controls over the MDDS “connection” part of such systems is exactly wrong.  It creates a potential weak link, and makes detecting and fixing other defects within systems, more difficult.  The MDDS Draft Guidance is a step backwards for cybersecurity, software quality, and patient safety.

Published MDDS Defects

A search of the FDA’s MAUDE database for the keyword “MDDS” returned 66 hits – reports on MDDS’s, or devices or EHRs connected to MDDS’s.  Yet only 316 or so MDDS’s have been listed to FDA for commercial marketing, ever since April 18, 2011.  This seemed on the surface to be a high rate of reports.  We examined a few MDDS-related MAUDE reports, MEDSUN entries, and Recall Letters.  None of the defect descriptions contained anything surprising to someone with even a modicum of hands-on IT experience.  Four selected MDDS defect reports are described below.  We quote directly from the FDA databases (typos may be from the original documents) and provide a link to the original complete documents.

Abbott Initiates Voluntary Recall of FreeStyle lnsulinx Blood Glucose Meters

The company has determined that at extremely high blood glucose levels of 1024 mg/dL and above, the FreeStyle lnsulinx Meter will display and store in memory an incorrect test result that is 1024 mg/dL below the measured result. For example, at a blood glucose value of 1066 mg/dL, the meter will display and store a value of 42 mg/dL (1066 mg/dL – 1024 mg/dL = 42 mg/dL). No other Abbott blood glucose meters are impacted by this issue.

The functionality described in the recall included only the communication, storage, and display of a physiological value (blood glucose levels) from a medical device.  If those functions were compartmentalized they would be an MDDS.  In other words, Abbott found a defect in an MDDS serious enough that they issued a voluntary recall of that device.  Abbott is a large highly respected medical device manufacturer with vast experience in design controls and post-market surveillance.  We are concerned that had a similar MDDS been developed by a different company without design controls and no experience with medical devices, this defect would unlikely have been detected and the product would not have been voluntarily recalled.

The following three reports describe defects in systems incorporating MDDS’s, and speak for themselves.

General Electric Centricity MDDS PACS

A critically ill pt under went radiographic eval of chest and abdomen. The last name of the pt contained one apostrophe. The radiograph images could not be accessed on the ehr results mdds. It was determined that the one entering the pt’s name at the imaging vendor entered a double apostrophe, rather than one. It could not be corrected for days, once the images were found, 5 days after they were done. It took another 3 days for pacs vendor to correct this misidentification issue. The vendor’s device is defective because it allowed absurdity (there is never a name with consecutive apostrophes) and it failed to warn of the error. These mdds devices need tighter regulation, surveillance, and safety.

ProTouch MDDS/EHR Device

Complex case with multi organ failure was on high doses of potassium supplements and potassium sparing medications. The potassium level obtained in the lab and electronically sent to the dhr mdds had increased from 4. 0 to 4. 9 mg% over a 24 hour period of tome. The nurses were not alerted by the mdds of new results, nor did they open the mdds to check the interval change of the potassium level prior to administering 40 meq potassium chloride twice. This points out the defect in the mdds, which is its failure to notify of new results and provide meaningfully useful decision support. These devices are not safe and require oversight.

Seimens Soarian

Cultures were obtained from a deep skin infection involving an implanted medical device. Multiple cultures grew serratia marcescens. The antibiotic sensitivities were lost from the mdds section of the ehr, or they were never posted due to an interface failure. A work around was required to find the results, but they remain absent from the silo of the ehr where they should appear. This defect causes delays in care and adversity due to delays in pinpointing the correct antibiotic to use in this critical situation. This genre of flaw raises doubt in the health care professionals as to whether the presentation of results on any pt are accurate.

The last MAUDE report nicely summarizes systemic risks of MDDS devices. A flaw in any MDDS whose purpose is to populate a patient record with physiological data raises doubts on the accuracy of ALL patient data in ALL EHRs.  Modernizing our country’s healthcare delivery system requires EHRs and associated HIT systems that are well designed, correctly implemented, diligently operated, and trusted by payers, providers and patients.  If only a few MDDS’s are found to be significantly defective in functionality, reliability, operation, security, or privacy, then the trust placed in all EHR data (including financial and demographic data) by clinicians and patients will be broken – regardless of the quality of their own particular systems.

There is no doubt that implementing design controls is a non-trivial effort, particularly when compared to the pure development cost of small mobile software applications that may perform, on the surface, similar functionality.  But the country is not in need of cheap vulnerable apps and untrustworthy interfaces. Improving healthcare requires high quality, reliable, and effective software that safely and correctly interacts with other regulated and unregulated HIT systems.

The FDA has been improving their regulatory processes and supporting innovation with the Mobile Medical Apps guidance document, recognizing more standards, and other published and in-process guidance’s and rules.  We applaud the FDA for their diligent work protecting patient safety and improving their regulatory processes.  However we disagree with the MDDS Draft Guidance.  We recommend that for Systems Engineering, Cybersecurity, and Patient Safety reasons the FDA should continue regulatory oversight over MDDS class devices.

The authors would like to thank the numerous subject matter experts who have contributed suggestions, critiques, and edits to our comments and to this post, but for professional reasons choose to remain anonymous.  You know who you are.


John Denning, MHA
Lynn Haven, FL
Robert J. Morris, MD (UK)
Pasadena, CA
Mikey Hagerty, Ed.D., CISSP/ISSAP, CIPP/IT
Carmel, CA
Michael Robkin, MBA
Los Angeles, CA
George Konstantinow, PhD
Santa Barbara, CA

Pictured above is the Capsule Neuron, a major component of Capsule’s MDDS.