Interoperability is an increasingly important component of med tech, due to the need for communication and data exchange within a networked system of other devices, electronic health records and clinicians. Poor interoperability is blamed for problems like "alarm fatigue" whereby poorly networked devices produce an excessive number of loud warnings out of an abundance of caution, leading to the risk that a necessary alarm will be ignored.
To help solve such problems, the FDA just released a draft guidance on design considerations and premarket submission recommendations for interoperable devices to help manufacturers conduct activities like performance testing, risk management and labeling.
The FDA advises manufacturers to consider the anticipated users of an electronic interface and their unique needs, including clinicians, engineers, and IT professionals.
Examples of information to be transmitted from and between devices include UDI information, ECG Waveforms, but the FDA points out that transmission of weight in kilograms to a device that assumes the measurement in pounds can lead to patient harm, or even death.
Safety is the number one consideration when designing an interoperable device. And the FDA notes that interoperability can be used to exert command and control over a medical device, as former Marine Billy Rios famously demonstrated when he remotely controlled an infusion pump, leading the FDA to issue its first ever cybersecurity guidance urging hospitals to discontinue use of a device (Hospira's Symbiq infusion pump).
The FDA said interoperable devices should be designed with specific error scenarios in mind, including malfunctions caused by problems with connected devices, invalid commands, the receipt of erroneous data and "not adhering to the non-functional requirement of the communications specification."
The guidance concludes with an all-important section on the content that should be submitted for the approval of interoperable devices. It includes a description of key interoperability features, such as whether the device is meant to transmit, receive or exchange information.
A risk analysis of "fault tolerant behavior, boundary conditions, and fail safe behavior, including "how the device handles delays, corrupted data, data provided in the wrong format, and any other issues with the reception and transmission of data" is also called for. Verification testing is also recommended, though the specifics vary depending on the type of device.
Finally, the labeling should specify whether the data being interpreted or transmitted is meant for anyone to access or a specific person, the relevant third-party standards used, contraindications and limitations of the data, and other items specified in the guidance document.
- read the guidance (PDF)