Interoperability – Barriers to Adoption
There’s been some great comments on the recent post about the announcement of MD FIRE. That plus some other activities I’ve been involved in have inspired some thoughts on barriers to adoption for medical device interoperability.
For this discussion, interoperability refers to the ability of a medical device to be controlled by another medical device or third party information system. Medical device systems from a single vendor frequently include interoperability between the medical devices and applications running on general purpose computers, but since all the components are from the same vendor I’m excluding them from this discussion.
Like everything else, medical device interoperability will walk before it runs. In a recent comment, JimW suggests that MD FIRE’s focus is on driving the adoption of, “tightly coupled, low latency, deterministic connection[s].” I beg to differ; I found the MD FIRE text to be very general and that it avoided any kind of design solution whatsoever. Further, it is interesting that what little multi vendor interoperability that is actually on the market, is based on “tightly coupled, low latency, deterministic connection[s].” The example that comes to mind (actually the only one I can think of right now) is the use of CANopen to integrate radiographic equipment with contrast injectors in diagnostic imaging. Perhaps someone can provide additional examples.
Jim is right that such interoperability presents considerable product design and verification challenges, which is why I think that a different kind of interoperability will broad gain market traction before designs with tightly coupled deterministic connections. If you’ve heard Julian Goldman speak on this topic, he provides numerous examples of interoperability that revolve around simple safety interlocks like:
- Using a patient monitor to cease therapy delivery (and sound an alarm, of course) on a PCA pump when respiratory arrest is detected,
- Linking a heart lung machine and ventilator in surgery to ensure that one is turned on when the other is turned off, and
- Linking diagnostic imaging with a ventilator to ensure ventlation is restarted after it is stopped to reduce motion artifact during imaging.
A portion of the 500 patients who die unnecessary deaths every day in U.S. hospitals are killed because simple safety interlocks like these don’t exist. Why? Clearly such interoperability is not rocket science.
The Challenge of Automating Workflow
What with all the effort required to get everything plugged together and talking, it is easy to forget that medical device connectivity is really about workflow automation. In other words, providing everything “connects” and works, the question of how it works becomes critical. The October 2008 issue of 24×7 has a story by yours truly on workflow along with some suggestions on how to deal with workflow.
The complexity and costs of implementing a medical device system that uses specialized peripheral devices, applications and systems integration with third party applications can add considerably to the cost and time required to install and implement such systems. This seriously impacts one of the most common tools providers have for evaluating vendor’s products.
The on-site evaluation is becoming a weak link in the conventional equipment evaluation process when complex systems are under consideration. An on-site evaluation can certainly reveal how effective the medical device itself may be in a specific clinical environment. This evaluation tool breaks down with purchases that require additional peripherals like personal data assistants or computers on wheels, application software installations, and, especially, systems integration with other hospital information systems. All of these components—that extend beyond the actual medical device—come at considerable expense and time required for systems integration. The result is frequently an on-site pilot that represents only a small fraction of the total system under consideration, leaving the buyer in the dark as to how the complete solution would perform in their environment.
Providers Press Vendors for Medical Device Interoperability
At the annual meeting of the ASA this morning, a group of providers announced RFP and purchase contract language for use by hospitals in an effort to hasten the availability of medical device interoperability. According to the founders, Massachusetts General Hospital, Partners Healthcare, Kasier Permanente, Johns Hopkins Medicine, and CIMIT (the MD PnP Program), hospitals,
“must lead a nationwide call to action for interoperability of medical devices and systems. One way that HDOs [Healthcare Delivery Organizations] can effect this change is by including medical device interoperability as an essential element in the procurement process and in vendor selection criteria.”
According to Julian Goldman, interoperability rocket scientist and anesthesiologist at Mass General, this announcement kicks off the beginning of an effort to build on Kaiser’s connectivity contract language (more here, here and here) and foster the adoption of similar language among providers world wide. The intent is to increase the glacial pace of industry standards based medical device connectivity adoption among medical device vendors.The program is called MD FIRE, Medical Device Free Interoperability Requirements for the Enterprise. According to Goldman,
“MD FIRE comprises a white paper and shared sample RFP and Contracting language requirements to promote the adoption of fully interoperable medical devices and systems in support of patient safety. The MD FIRE document was drafted by the CIMIT MD PnP Program Interoperability Contracting Requirements Working Group, that convened experts from The Massachusetts General Hospital, Partners HealthCare, Kaiser Permanente, and Johns Hopkinsin 2008.We are announcing the project in conjunction with the American Society of Anesthesiologists annual meeting in Orlando this weekend with an exhibit called, “Consumer” Empowerment: Hospitals Can Accelerate the Adoption of Medical Device Plug-and-Play Interoperability for Patient Safety with “MD FIRE.”
Updated Standards Aim to Encrypt Wired Networks
Securing Ethernet networks has not received the interest that wireless LANs have gotten, for a variety of reasons.
Physical layer security is viewed by most IT professionals as a low-priority problem because cables are run behind walls or in ceilings, beyond the accessibility of most people. Wiring closets and data centers often are locked, and anyway, there are easier ways to subvert a network than by recabling it.
With all those open RJ47 Ethernet jacks everywhere, it would seem to me that someone interested in data would just plug in, rather than recabling anything. The aforementioned security is done with encryption, and the standards are 802.1AE and 802.1X-REV. The first standard ensures the integrity and privacy of data between peers at Layer 2 (switches and NICs). The second standard, 802.1X-REV is currently being revised to automate the authentication and key management requirements for 802.1AE. If you’re a networking rocket scientist, you can read more about the potential implications for these revised standards here.
With their concerns about security and HIPAA, will health care enterprises move to encrypt the physical layer? Such an option will be increasingly possible, according to this Information Week story from last week (emphasis mine):
You’ll be answering that question in the next few years as two new network security protocols come to a switch near you. Together, these two protocols–IEEE 802.1AE-2006, Media Access Control Security, known as MACsec; and an update to 802.1X called 802.1X-REV–will help secure Layer 2 traffic on the wire. 802.1AE is a completed standard and will be appearing soon in hardware. 802.1X-REV could be ratified as early as the first quarter of next year.
History of Medical Device Connectivity for CIS
With all the focus on medical device integration for EMRs and middleware vendors like Emergin, many of the hospital’s looking for solutions today know little about how connectivity has evolved. So, we were talking at Capsule the other day and here is a timeline we came up with. This surely isn’t a complete list, and we’re sure there are other significant efforts that should be included. We tried to keep it focused on successful implementations in a production environment of a system extracting data from a medical device into a clinical information system. So let us know what you think is missing!
1970’s and 1980’s
Early systems evolved from research work performed in some of the large university teaching hospitals. For more background – see this link. Eventually the market evolved from patient management systems (for example the HP Patient Data Management System or PDMS.) which were the first commercially available systems to provide any type of automated data capture between a medical device and a computerized system.
1992-94
Standalone or independent connectivity solutions — Early efforts started in 1992 with Hewlett-Packard’s CareVue (now Philips) using the HP CIS Gateway. Early ventilator interfaces were implemented with custom serial cabling pulled to each bedside to connect ventilators via serial home-run cables back to wiring closets. The HP CIS Gateway was the data consolidation point and an early version of HL7 (2.1) was used to interface to the CIS. Other vendors such as EMTEK, Clinicom, and CliniComp also developed similar capabilities in this timeframe. There were a handful of drivers written for only the most common mainstream ventilators. In the peri-operative market, most surgical/peri-operative CIS vendors leveraged the local PC platform for serial connections directly to a multiplexor card.
Patient monitoring-based solutions – In parallel to the standalone connectivity solutions, key patient monitoring vendors including HP, Marquette, SpaceLabs, and Siemens developed monitoring-centric connectivity. These early products were proprietary “plug-in” modules that connected the medical device serial ports to the patient monitor. In these deployments, the patient monitor became the central “hub” for data consolidation. Here is primary purpose of the interface was to display non-monitoring data such as ventilation parameters and waveforms in a correlated display along with the physiological monitoring data. Alarms are also processed via these types of connections and sent to the monitoring central station. However, these types of interfaces have somewhat diminished in value over time – mainly because ventilator devices now have very advanced graphical user interfaces (less of a clinical need to correlate device data on the monitoring display) and alarm management and directed notification systems (i.e. Emergin) are now mainstream products.
