Time to Take a Closer Look at FDA MDDS Moves

Down-classifying medical device data systems may put the public at risk

Published: Wednesday, August 6, 2014 - 15:12

The FDA recently released a new draft guidance document for medical device data systems (MDDS). The FDA defines MDDS as “hardware or software products that transfer, store, convert formats and display medical device data. An MDDS does not modify data, and it does not control the functions or parameters of any connected medical device. MDDS are not intended to be used in connection with active patient monitoring.”

The core issue it raises, I believe, is one of data integrity. More on that later.

The new draft guidance cites the growing trend “that many medical devices be interoperable with other types of medical devices and with various types of health information technology,” the FDA wrote. And further, “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.... Therefore, the FDA does not intend to enforce compliance with the regulatory controls that apply to MDDS devices, medical image storage devices, and medical image communications devices.”

The FDA’s interest in this kind of risk-based approach has pleased a great many. On the one hand, the draft guidance demonstrates a proactive approach by the FDA for addressing the explosion of mobile health applications in the light of pending legislation on the same topic in the U.S. Congress. It frees application developers to innovate without the additional burden of regulatory compliance, and it dovetails with the rapidly expanding electronic health ecosystem servicing the informational appetites of healthcare providers and patients alike.

Driving this trend are advances in mobile networks, and the proliferation of smart phones and tablet devices, which the Cisco Visual Networking index projects will result in 10 billion mobile devices around the world by 2016. This revolutionary expansion constitutes a global service delivery platform for many industries, including healthcare. Creating affordable and efficient healthcare systems is a critical challenge for everyone, and mobile health solutions offer tremendous potential by improving and lowering the cost of healthcare interactions for everyone.

But, there are also some complications to consider with this overall approach. Creating mobile medical device applications is relatively easy and inexpensive, which enables developers inexperienced with the medical device industry to quickly develop applications that are, in fact, medical devices. This ranges from hospital software developers creating interfaces that network device data to electronic health records to college students with a basic understanding of iOS for iPhone applications.

Regardless of whether the applications are distributed to clinicians by hospital IT staff or available as a download from iTunes to clinicians and patients alike, once in the hands of the user, the data from MDDS applications will be used for diagnostic purposes—even if the expressed intended use of such applications is to the contrary. We would be naïve at best to believe otherwise.

The use of a device “off label” or contrary to its intended use, however, is not the concern here. Reconciling the conflicts between the intended use of devices and the intentions of end-users is a different kind of problem more properly framed by the argument between those advocating stronger, more far-reaching government controls and those advocating more personal responsibility. Instead, the issue here is one of data integrity and the risks associated with compromising those data.

The draft guidance for MDDS, in essence, proposes a lifting of controls that are otherwise designed to ensure data integrity of MDDS software applications. In the absence of those controls, what assurances will we have that the storing, transferring, or converting of the data was done in a way that did not create an unintended change in the data? At this point, advocates for the draft guidance might remind us that the FDA “has determined that these devices pose a low risk to the public.”

Here’s the rub: However simple the application, there is little credibility in claiming that a particular software application is “bug free.” Simply consider how frequently your iTunes Store app alerts you to application updates for bug fixes. This gives you a sense of the state of software development in the absence of strong quality controls and the rigorous software life-cycle planning that are part of medical device regulations and standards, such as 21 CFR Part 11 and IEC 62304.

If MDDS application developers aren’t required to have a competent software development life cycle, not required to test or validate their software, and not required to manage their quality, what assurances do users have that the software operates as intended, and the data are not compromised in some fashion due to software bugs? And, if we take for granted that the data from MDDS applications will be used for diagnostic purposes despite their stated intended use, what risks are we accepting on behalf of patients?

In short, the risk of misdiagnosis, either by the clinician or patients themselves, increases, as do the consequences for misdiagnosis. The more widely distributed mobile healthcare monitoring and treatment options become and the fewer requirements for ensuring data integrity, the more likely patients will be exposed to such risks.

First published July 29, 2014, on the AssurX blog.

About The Author

Russ King

Russ King is president of Methodsense, a consulting firm that helps clients deliver medical and technological breakthroughs by effectively meeting the requirements needed to bring their products to market.