Having been beyond frustrated more than once in trying to get an IBM PC to talk to another device, I was more than slightly skeptical on seeing a booth at an annual AAMI meeting in the late 1980s devoted to selling the concept of getting medical devices to talk to computers. Suffice it to say that 20 years later it remains reasonable to ask, “What changed to make me believe interoperability is still not just a pipe dream?”
Perhaps we finally have a good answer: The medical device communications standards landscape that was once almost solely defined by the activities of IEEE 11073 (nee 1073/medical information bus or MIB), is now dotted with implementation groups that leverage the work of 11073 as well as other standards bodies. We will touch on the objectives and activities of three of these groups here: the Continua Health Alliance, Integrating the Healthcare Enterprise Patient Care Device Domain (IHE PCD), and the Medical Device Plug and Play program (MD PnP). That these have all come into being within the last 5 years is indicative of a shift in the dynamics that have until now squelched developments in this domain. The focus here is not on technical details, but the provided URLs and Google links should help to that end.
Why Connectivity Isn’t Enough
Treatises on this topic can be found elsewhere, but analogies serve well here. When you place a phone call, do you worry about what kind of phone is on the other end? If you have a connection clear enough to hear a pin drop, will you have successful communication if the people using the phones do not speak the same language?
For communications in a medical device system to be successful, achieving error-free transmission and reception from device to device (connectivity) is necessary but not sufficient; sharing understanding across a system of heterogeneous and independent devices (interoperability) is a requisite as well. Currently, medical device connectivity is accomplished on a case-by-case basis, with someone somewhere writing codes for each and every interface to be implemented. This is inefficient and expensive, not only in terms of development and maintenance, but also sustainability in the face of the increasing rate of change in technology. Interoperability in the “able to play well with others” sense cannot be realized in this fashion, and we are already living with the consequences. System integration is slow and complicated. Attention to innovation is diverted to connectivity details, which not only impacts existing companies but also can make the cost of market entry prohibitive for innovative small companies.
Since healthy skepticism is a hallmark of engineers, anyone associated with 11073 has probably been challenged to address two issues:
- Why has it not been realized?
- Is it too complex?
They are not new. A 24×7 “Soapbox” column by Tim Gee touched on these last January, and I asked them a decade ago. The answer to the first has not changed over the years. As 11073 General Committee Chair Todd Cooper explains, “Medical device companies have no motivation to dedicate schedule and resources on open standards-based plug-and-play connectivity [until technology consumers unite and demand it].”
As to complexity, Cooper cites the recent 11073 Personal Health Devices Work Group (PHD) evaluation of 11073 for simplification. With PHD focused on small personal-use devices like glucometers, any opportunity to simplify and lower cost without sacrificing safety is key. Yet PHD has come to adopt much of the 11073 model.
Around the time you are reading this, 11073 will be meeting with the HL7 working group meeting in San Antonio. In addition to its usual work around standards harmonization, the list of topics to be covered continues to grow. Offerings include the new standard being developed (ISO 80001) covering risk management for IS networks incorporating medical devices; an update on testing strategy and tool development from NIST; a review of IHE and Continua approaches to the clinical document architecture, or CDA; and a session on the universal device ID, or UDI.
The Continua Health Alliance
Formed in June 2006 to bring interoperability to personal health devices and enable better management of health and wellness, chronic illness, and aging independently, Continua has grown to include 133 member companies. Technical Working Group Chair Rick Cnossen and Marketing Working Group member Troy Severson note that personal health devices today are subject to the same communications challenges as their acute care counterparts. Continua intends to address this by creating guidelines specifying how to use existing standards to build interoperable sensors, home networks, and telehealth platforms. Continua will also establish a product certification program to assure the user of interoperability with other Continua-certified products.
Continua is currently developing Version One standards that unite health care informatics with consumer electronics standards, including the Bluetooth medical device profile specification, USB health device specification, IEEE 11073 personal health device specification, and HL7.
IHE Patient Care Devices
Sponsored by the American College of Clinical Engineering and HIMSS, IHE PCD is probably the most familiar of these initiatives to the clinical engineering community. The PCD scope is on communication when at least one system is a regulated medical device. Todd Cooper notes that clinical engineers have been more involved in this effort than any other. Regular readers have seen PCD work and goals reported in 24×7, including Elliot Sloane’s March 2007 overview of the scope of PCD efforts.
By leveraging the resources of its membership as well as the larger IHE organization, PCD was able to achieve its year 1 goal of a cross-vendor demonstration of enterprise-level data sharing across a set of medical devices at the HIMSS 2007 Interoperability Showcase. At HIMSS 2008, the demonstration will incorporate more companies, including a medical records vendor.
PCD maintains a 5-year road map, and with the year 1 objective of exporting device data demonstrated, it is broadening its attention to year 2 topics, including patient identification binding, real-time device integration, and telehealth. Years 3 through 5 touch on a menagerie of topics, such as device location, transport, alarm interoperability, device control, and smart alarm applications.
Medical Device Plug-and-Play
Frustrated by the stifling impact of the lack of interoperability on the operating room of the future project at Massachusetts General Hospital, Julian Goldman, MD, led the establishment of the MD PnP Program in 2003. Goldman notes how MD PnP informs and is informed by all of these groups. “Our focus is on iteratively developing an interoperability infrastructure to support creating innovative tools and systems.” Goldman says. “We don’t even know what these will look like yet, but we do know that the communications infrastructure will have to be sufficiently flexible and extensible to support the introduction of disruptive technology directly to the point of high-acuity care, wherever that may be.”
In addition to clinicians and engineers from Partners Health Care and Kaiser Permanente, as well as many of the same manufacturers working in the initiatives already described, MD PnP pulls together world-class engineering firms like MITRE and Draper Labs, academic colleagues like UPenn, and the FDA. In addition to pushing ahead with its ongoing projects to illuminate the spectrum of processes needed for point-of-care success, over the last year MD PnP co-hosted with UPenn the “Joint Workshop On High Confidence Medical Devices, Software, and Systems and Medical Device Plug-and-Play Interoperability” and received the 2007 “Edward M. Kennedy Award for Healthcare Innovation.”
The story tells itself. The clinical needs driving the need for medical and related devices and systems to intercommunicate has resulted in the establishment of communities intent on addressing one or more aspects of the clinical needs. These communities have identified shared requirements for standards-based tools that they can leverage so as to focus their energies on the clinical needs, not the tools. Each community continues to identify at least one other shared requirement, which is the greater involvement of the clinical engineering community, particularly in requirements and validation efforts.
“Each of these efforts contains a thread in the fabric of interoperability,” says Raymond Peter Zambuto, CCE, FASHE, FHIMSS, FACCE, president, Technology in Medicine Inc, Holliston, Mass. “The good news is that we all talk to one another, and there is a real hope that a consistent framework will emerge from these parallel processes.”
Something Else We Share
Anyone involved in medical device communications interoperability has been informed and influenced by the leadership of Jack Harrington. I know I have. The first time I met him was at a working group meeting where I barked for about 20 minutes about the lack of interoperability. Jack listened patiently and then turned the tables, arguing that if providers would demand it, it would happen. He proceeded to challenge me to learn about requirements engineering, which led me onto a path even less traveled than clinical engineering. And indeed, it has made all the difference. As I write this, Jack is at home and recovering from a stroke. Get well soon, Jack. We need you back. But don’t worry; you’ve got us on the right path.
Rick Schrenker is a systems engineering manager, department of biomedical engineering, Massachusetts General Hospital, Boston. For more information, contact .
Links to Knowledge:
The following Web sites will link you to the implementation groups covered in this article that leverage the work of 11073 as well as other standards bodies.