Limitations of Medical Device Data Systems as a Feeder of an EHR

EHR meets MDDSEHR Meets MDDS

COMMENTARY
William A. Hyman
Professor Emeritus, Biomedical Engineering
Texas A&M University, w-hyman@tamu.edu

With the exception of imaging and lab results, the EHR Meaningful Use (MU) requirements through Stage 2 do not require that medical devices communicate directly with the EHR. For example, the MU mandate of recording certain vital signs can be accomplished with manual entry rather than by having the device making the measurements communicate directly with the EHR. While not required for MU there has been much technical discussion on the value and challenges of having certain medical devices (e.g. monitors, ventilators, infusion pumps) send data directly to an EHR. This would be an example of seeking a use of the EHR that is outside of the MU requirements. This is of course fully allowed, i.e. MU is a minimum set of requirements that does not preclude other uses.

The challenges of moving data from device to EHR arise from the lack of interoperability, here meaning medical device to EHR rather than EHR to EHR. So far accomplishing such data transfers usually requires something in between, often known as “middleware”. Such middleware is typically needed to format the data and properly identify it as coming from a particular patient. The Food and Drug Administration (FDA) has interest in data movers because they themselves meet the broad definition of a medical device. It might be noted that while EHRs may also meet that definition, the FDA has chosen to stay out of the regulation of EHRs.

The FDA’s interest in data movers is reflected in part by its codification of Medical Device Data Systems (MDDS) which are systems that “transfer, store, convert formats, and display medical device data” under a particular set of restrictions. Systems (called “devices” in FDA parlance even though they may consist of a combination of hardware and local or distributed software) meeting these restrictions are in FDAs Class I and require minimal before market scrutiny, although the manufacturer/developer must still be registered with the FDA and comply with the FDA’s Quality Systems Regulations (QSR). Systems that do not meet the MDDS restrictions are presumably some higher class (II or III) for which there is greater FDA scrutiny. Despite the relatively clear FDA assertions of jurisdiction in this arena, there appear to be vendors and system configuration consultants who are operating outside of FDA purview because of real or feigned ignorance.

MDDS has an interesting limitation with respect to utility as a feeder of an EHR. The applicable regulation (21CFR880.6310) includes the proviso that MDDS does not include devices intended to be used in connection with active patient monitoring. The preamble to the regulation found in the Federal Register  further explains that active monitoring means an intended use that includes that it be relied on in deciding to take immediate clinical action. A device intended to be used for active patient monitoring or decision support is not an MDDS. While one of the promises of EHRs is to inform direct clinical care, and decision support is part of MU, it cannot be an MDDS that enables this functionality with respect to data coming from medical devices. Thus even when MDDS providers are in compliance with FDA regulations, what they are doing still cannot be part of active monitoring and decision support. Of course a non-MDDS system could provide such capability, but it would then require more FDA scrutiny, not less.

One lesson here is to ask middleware system providers about their FDA status. It is not a good sign if they look confused or brush you off. And even if they assert that they are MDDS compliant, this may not cover some of your objectives.