Last month, the FDA issued its guidance document Design Considerations and Premarket Submission Recommendations for Interoperable Medical Devices and a commentary by Bakul Patel. The essence of the form of interoperability addressed is the transfer of data from one medical device to another or perhaps from one or more medical devices to a separate processing system which might then command one of the devices, or a different device, to do something. As Patel puts it, “Interoperability is when devices talk to each other in a safe and effective way enabling smarter care.” His lead example is two devices (EKG and pulse oximeter) talking to a third computer which, somehow, has been programmed to use both sets of data to better interpret the patient’s condition. Safe and effective smarter care is a fine goal, while not so safe, marginally effective and kind-of-dumb care should be avoided. Note that this form of interoperability is different from devices sending data to electronic medical records (EMRs), or EMRs sending data to each other, both of which remain a challenge. It is also different from collecting data from multiple devices for an integrated display (e.g., via an MDDS).
It is one thing to move data sets around, although this of course must be done in a way that makes the data useable to the receiving system through known and consistent units, formatting, and timing—whether standardized or proprietary. It also is critical to properly associate device and data streams to a particular patient, and to dissociate them when that patient is no longer involved. Such data movement has been talked about for many years ranging from common information formats (e.g., the medical information bus of the last century) to beneficial hacking of nontransparent device outputs.
However, it is quite another thing for a device or data integrator to process the data in a way that is clinically meaningful, and perhaps use that processing to change one or more device functions. As the guidance notes, device interoperability in its broadest form “includes more complex interactions, such as exerting command and control” over a medical device or devices. Command and control also requires that the end point device has the capability to be operated by another device or system, i.e., it can receive and respond appropriately to external commands.
A key question here is who created the software that does the interpretation and, if present, command and control? If all of the involved devices are from one manufacturer, and interoperability is an intended use, then that manufacturing clearly has the full responsibility for how the exchanged data is processed and for what purpose. When more than one manufacturer or software developer is involved, things get murkier. In the FDA blog example, the EKG may be from one manufacturer, the pulse oximeter from a second, and the integrating software from a third. Assuming the EKG and the oximeter provided the data in an as expected fashion, then it is third party who is responsible for the proper interpretation of the two data streams. Any “advice” (or recommendations, or suggestions, or list of possibilities) arising from that interpretation is the responsibility of that system, whatever “do-not-rely-on” disclaimers it may proffer.
In this context, the manufacturer of a particular device may be hard pressed to imagine all the things some other party might do with its data stream, or what other devices or systems might be allowed to send data to it and exercise control. The guidance hints at the unique device identifier (UDI) system being used as an identifier for what other devices a device might listen to, perhaps like a safe caller list. Here a device may be designed to listen to some devices but not to others, even if those devices are of the same type and the data is fully compatible. Refusing to talk to others may be used as another sales point for buying all of the relevant devices from the same manufacturer. Accepting automated external control might also raise security concerns, and is likely to increase the manufacturer’s potential liability for control algorithms that turn out to be problematic in at least some situations.
The guidance states that risk analysis must include “reasonably foreseeable combinations of events that can result in a hazardous situation.” Traditional risk analysis, which is often a “what if” exercise, has usually involved only one “if” at a time. When “ifs” start being combined, the scope of the problem escalates exponentially. In this regard, the guidance notes that “FDA believes that an interoperable system should maintain basic safety and essential performance during normal and fault conditions.” I find this assertion curious in that one would not expect such a device should ever abandon basic safety and essential performance. The guidance also makes a number of suggestions about labeling, including interface connections and control options. This may end up in an attempt to “fix” designs with instructions and warnings.
Interoperability is simple in concept and complex in execution. When devices talk to each other, it is important to know who is saying what, the basis for saying it, who is listening, and who is standing behind what is said and done.
William Hyman, ScD, is an adjunct professor of biomedical engineering at The Cooper Union and a consultant in New York. He is also a professor emeritus of biomedical engineering at Texas A&M University.