Time to Take a Closer Look at FDA MDDS Moves
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 the 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.
Explaining the Medical Device Data Systems Draft Guidance
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.” 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,” the FDA wrote. “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 US 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 health care. Creating affordable and efficient health care systems is a critical challenge for everyone, and mobile health solutions offer tremendous potential by improving and lowering the cost of health care 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 that 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 data stored, transferred or converted was done so 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.”
Medical Device Software Requirements
Here is the rub: however simple the application, there is very little credibility in claiming that a particular software application is “bug free.” Simply ask “how frequently does your iTunes Store app alert you to application updates for bug fixes?” This gives you a sense for the state of software development in the absence of strong quality controls and the rigorous software lifecycle planning that are part of medical device regulations and standards, such as 21 CFR Part 11 and IEC 62304.
If MDDS application developers are not required to have a competent software development lifecycle, not required to test or validate their software, not required to manage their quality…what assurances does the user have that the software operates as intended, and the data is 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 the patient themselves, increases as do the consequences for misdiagnosis. The more widely distributed mobile health care monitoring and treatment options become and the fewer requirements for ensuring data integrity, the more likely patients will be exposed to such risks.
Originally published at Assurx.com.