I've recently received a number of inquiries about medical device connectivity standards in general, and IEEE 1073 in particular. The following is an overview and my take on connectivity standards.
Most medical devices use serial ports to export data. These ports are wildly non-standard; the pin-outs and actual connectors vary between vendors, and even within devices from the same vendor. The serial protocols are all proprietary and have only slightly less variability than pint-outs and connectors. Things are so bad that some vendors can't even produce serial port documentation on products they currently sell.
Efforts to create a medical device connectivity standard go way back to Hewlett Packard and the Medical Information Bus - MIB (1980s), the evolution of the MIB into the IEEE 1073 standard, Agilent and the Andover Working Group (1996), which sort of merged into the Connectivity Industry Consortium (1999), and most recently the IHE Patient Care Device Committee. There is a small number of standards that have been used (okay, mostly talked about) in medical device connectivity - HL7, CANopen, and what was until recently called IEEE 1073.
Health Level 7 has been around for some 20-odd years. Developed mostly by vendors, HL7 has a lot of what are generously called "options" that allowed individual vendors to keep a cherished proprietary feature or support a new version of the standard without actually changing their product to conform to the standard. This um, flexibility is why the vast majority of HL7 interfaces are table driven affairs that are configured for each installation.
CANopen was developed to provide communications and control between safety-critical devices in a variety of industries. (You can read more about CANopen in this previous post.) A surprising number of vendors have quietly adopted CAN - GE Healthcare, Philips, Hill-Rom, Siemens and others. As a standard, CANopen operates at a very low technical level coordinating multiple devices (from different vendors, of course) so they can perform as one unit. For example, CANopen is used to sync X-ray equipment with contrast injectors, making cath exams more automatic. CANopen might be a great standard for medical device interoperability that includes medical device control - the integration of distributed medical devices to produce "error-resistant" systems with safety interlocks between devices. (For more on error-resistant systems see the Medical Device Plug and Play Interoperability Program at MGH.)
The 1073 effort has been ongoing, in one form or another, since the 1980s and is now known as ISO/IEEE 11073. The group has done some very valuable work, exploring the requirements, complexity and structures for a medical device connectivity standard. (You can read a great overview paper written by two well known Connectologists, Richard Schrenker and Todd Cooper.) Politically, 11073 has made great progress. The 11073 standard has been adopted as part of the federal Consolidated Health Informatics (CHI) initiative, and is included in the CCHIT EMR certification process. The standard has also been designated the principal standard to be used by the IHE Patient Care Device Committee.
Despite all this adoption on paper 11073 has not been able to generate any, you know, adoption by the industry. The only vendor I know that's adopted 11073 is Philips and their implementation is not fully conformant with the standard. Rumor has it a couple of major medical device vendors have evaluated 11073 and decided to pass, supposedly based on complexity and performance issues. According to health care provider organizations that I've talked to, the current standard suffers from too much complexity.
Certainly there are structural barriers to adoption of 11073. Medical device vendors, especially those with a large installed base to protect, prefer product architectures that lock in customers by erecting high changing costs. An increase in customer choices created by industry standard interoperability is inconsistent with traditional industry strategy.
One difference I see between 11073 and the evolution of DICOM in diagnostic imaging is the lack of facilitators. Back in the early 1990s companies like DeJarnette and Merge Technologies provided software toolkits that most vendors used to implement DICOM in their products. Over time open source software libraries became available. An extension of basic software libraries were products like the MITRA broker that provided higher level DICOM interoperability services between imaging modalities and other information systems. If there are 11073 facilitators out there, they're well hidden.
Medical device connectivity is certainly complex. Rather than just pushing data to a target system, connectivity works at several different levels. The foundation is establishing and maintaining patient context, or in other words making sure the right data is reliably associated with the correct patient in a way that is efficient for the user and safe for the patient. This seemingly simple requirement varies greatly based on how things are connected (RS-232, Ethernet, WLAN, etc.) and the use cases involved (roaming device with multiple patients, continuous patient connection). In addition, each class of medical device has their own specific workflow to automate. Infusion pumps have to deal with the drug delivery process; ventilators have their own therapies to support. Patient monitors share requirements for surveillance and alarm notification with both infusion pumps and ventilators. On top of all this patient context, workflow and alarms, there needs to be a messaging system that ensures that the right data message gets to the right person or system. And behind the scenes, some sort of "flight recorder" is needed to provide feedback to improve operations, clinical performance and support FMEA (failure mode effects analysis). Oh, and of course caregivers (not to mention IT) would like one system that supports all the devices in their hospital, not one system each for patient monitors, vital signs monitors, infusion pumps and vents. This is pretty complicated stuff.
Perhaps the complexity of 11073 is not the issue. The other day I stumbled across an interesting paper about developing standards. Standards are developed in two basic ways, either they formalize existing practice or invent new practice without experience. By necessity, the long effort of 11073 has been inventing new practice, blazing a new trail in the industry. The author of this paper used CORBA as an example of why standards tend to be more successful when they formalize existing practice rather than inventing new practice. A related paper, Web Services - Nonexistent Standards, offers some interesting suggestions for the standardization process.
Finally, we come to a problem that is specific to the medical device industry. Medical devices are embedded systems, black boxes in which the vendor controls everything. This characteristic has given rise to many of the proprietary approaches to medical device systems and connectivity, and answers questions like, "Why do medical device vendors manufacture their own personal computers?" To an embedded systems engineer it makes perfect sense to create from scratch a standard for interoperability and connectivity.
As vendors have extended embedded thinking to medical device systems that incorporate a growing number of general purpose computing components, general purpose computing technology has evolved considerably. Today's networks with SNMP and QoS, and software tools like SOAP and XML, make it possible to build medical device connectivity using existing IT standards rather than a purpose-built standard. Both health care IT and medical device vendors are currently building connectivity based on existing IT standards. Companies like Cerner, Cardinal (Alaris), Emergin and others are pushing the boundaries of connectivity and workflow automation without 11073.
So, is 11073 a viable standard? Perhaps. A lot of great thinking and work has gone into 11073, but what's needed now are facilitators - some way to make adoption easy. Otherwise, these de facto IT standards will proliferate and over time we'll end up formalizing what becomes existing practice.
Pictured right is the Tower of Babel by Pieter Brugel the Elder, painted in the sixteenth century - it seems some themes are eternal.
Great article ! Any updates for 2008 ? It seems that Europe have a lot more efforts toward a universal interface and for device inner-connectivity as a need. Do you think that CANopen is the only available interface to work with device inner-connectivity ? It seems so to me.
CANopen is the best standard for device interoperability that must be deterministic. But much interoperability could be done with less stringent integration - things like safety interlocks between PCA pumps and monitors.
The biggest barrier is vendors concerned about giving up proprietary end-to-end solutions and the resulting (potential) loss of control. As medical device and HIT markets continue to zero in on the point of care, vendor centric products will become increasingly untenable and customers will demand patient-centric solutions.