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."
Medical device connectivity is the automation of workflow through the integration of medical devices and information systems. A potential capability enabled by medical device connectivity is device interoperability. This medical device interoperability means that the data from one medical device can affect the behavior of another device. This interaction is mediated by software running on general purpose computing platforms. As an aside, direct device-to-device interoperability is theoretically possible although writing such software on medical devices is considerably more expensive than implementing it on computers.The rationale for this initiative describes how interoperability will significantly improve health care.
Why is medical device interoperability necessary to improve patient safety? As an example, when taking an x-ray in the Intensive Care Unit, the ability to synchronize the x-ray with the patient’s breathing cycle has been demonstrated to improve image quality. Unfortunately, the capability of interconnecting and synchronizing these devices is not available today. Similarly, a safety interlock that would stop the flow of opioid pain medication from an infusion pump and call the nurse if a patient showed signs of respiratory distress could save lives. There are numerous other examples whereby medical device interoperability and medical system integration, if available, will improve patient safety.Standards-based medical device interoperability can provide real-time comprehensive population of the electronic medical record (EMR), and in the future will permit the creation of integrated error-resistant medical systems that will support advanced capabilities such as automated system readiness assessment; physiologic closed loop control of medication delivery, ventilation, and fluid delivery; decision support; safety interlocks; monitoring of device performance; plug-and-play modularity to support “hot swapping” of replacement devices and selection of “best of breed” components from competitive sources; and other innovations toimprove patient safety, treatment efficacy, and workflow efficiency.
The Contracting Requirements Working Group group does a great job of describing specifics. Here is the group's "reality check" of where they see the market and what they hope to accomplish.
We HDOs wish to adopt interoperability standards for medical device interconnectivity. We also recognize that the necessary standards are not yet fully developed or widely implemented by medical equipment vendors. However, we believe that adoption of standards-compliant interoperable devices and systems will enable the development of innovative approaches to improve patient safety, healthcare quality, and provider efficiency for patient care; will improve the quality of medical devices; will increase the rate of adoption of new clinical technology and corresponding improvements in patient care; will release HDO resources now used to maintain customized interfaces; and will enable the acquisition and analysis of more complete and more accurate patient and device data, which will support individual, institutional, and national goals or improved healthcare quality and outcomes. Our goal is to document the clinical demand and to strongly encourage the development and adoption of medical device interoperability standards and related technologies.
What these providers say is true. The question is whether vendors will pick up the pace of connectivity adoption, or will instead continue to drag their feet.UPDATE: Reader Scot M. noted that I didn't provide a direct link to the MD FIRE document. He's right, so here it is. Enjoy.UPDATE: The ASA issues a press release urging leading institutions to "Get Connected for Patient Safety."
Many people confuse device connectivity with device interoperability.
Device connectivity is the ability of a device to stream data to a charting/archiving system. Most device vendors do this, either directly in HL7 or in a proprietary communication protocol to an intermediary that converts the data to HL7. As far as connectivity goes, this is all that the device vendor is required to do. The charting/EMR vendor needs to take the HL7 messages and interpret them. As long as the device vendor provides HL7, we would consider their devices “connectable”.
There are some unscrupulous vendors (even some big ones) in the market who claim “device interoperability” on the basis of HL7 export. This is why a proper definition of device interoperability is important.
Device interoperability should be defined as the ability of a device to pass data to / receive data from a 3rd party (ie manufactured by a different vendor) device, and pass control commands to / receive control commands from such a device if permitted. Some vendors claim device interoperability on the basis that their devices talk to other devices they make, using a proprietary protocol. A stricter definition as above would prevent them from making such claims.
The HP Open Interface Protocol in the late 90s and later, MIB format, were proposed as a common format vendors can implement. The HP format was only adopted by a few small time device vendors who wanted to capitalize on the HP market share in monitoring. The MIB was scuttled by one vendor’s insistence on developing their own “flavor” of MIB for their ventilators and anesthesia machines (they modified their old protocol a bit and renamed it MIB).
MIB still has the potential of being a common platform for device interoperability. Until the industry finally agrees on, and freezes the MIB format, device interoperability will remain a dream.
And yeah, I’m a born pessimist.
This is a very interesting topic. How about the Gartner study, which predict that, by 2009, healthcare investments in IT will increase by more than 50 percent, which could enable clinicians to reduce the level of preventable deaths by 50 percent by 2013. Of course, nowadays most healthcare organizations have already invested in IT outsourcing, for anything from Telco and Wireless, to Application Data Development (i.e. LIMS, SOA), or even Business Process Management.
We’ve put together a detailed white paper on these subjects: http://www.outsourcing-factory.com/en/stay-informed/white-papers/outsourcing-healthcare.html . What is your experience with IT outsourcing in healthcare? Are these figures close to your personal experience or do you think there are certain issues we’ve missed covering? I strongly appreciate your professional opinions.
Pete, many of the terms associated with HIT and medical device connectivity are poorly defined and used in various ways. That’s why it is so important for prospective buyers to carefully evaluate exactly a vendor’s offering, and how it works.
There is indeed a substantial difference between basic connectivity and true interoperability. One must certainly have connectivity before one can hope to realize interoperability. The MD FIRE program is a worthy effort in advancing the industry in the right direction.
Regarding “shameless plugs” and comment spam, I refer readers to the About page of this site. There you will find a copy of the comments policy and where I draw the line on self promotion. Gerard does meet the hurdle to “contribute to the conversation” (barely) by noting Gartner’s study and the scandelous level of preventable patient deaths that still occur in hospitals today.
It would be useful to separate the requirement for “interoperability” from any specific implementation as proposed by MD plug n play.
Interoperability is like arguing against motherhood. Everybody agrees that such a goal is laudable. The challenge becomes one of cost vs risk vs benefit.
The proposed MD FIRE is based on a tightly coupled, low latency, deterministic connection. Achieving this on todays platforms will add both cost and complexity. For example, how would vendors validate such a system? Would end users assume responsibilities and liability for use outside of the design specifications? Who will design the use case scenerios, and where are they today? The implementation of such a scheme could ripple through the fundamental architecture of many current medical devices, and may increase the cost and complexity of next generation devices.
Putting vague language in purchasing contracts, when few or no vendors can address such requirements dilutes the intent of MD pnp. How could such a clause be enforced? The effort is praise worthy, the time to force ambiguous purchasing requirements on industry is counterproductive.
Re JimW’s comments, the reason why clinicians are so excited about device interoperability is that it opens up many frontiers:
1. Possibility of “remote control” - in times where the scarcity of clinicians has lead to eICU concepts, the ability to, let’s say, adjust the ventilator settings or infusion rates from the eICU control room is invaluable
2. Possibility of creating semi-automated feedback loops - eg. setting up rules such as - when blood pressure drops, increase the dopamine drip
3. Setting up specialized automated care protocols - a CIS system being able to control devices according to the protocol the clinician selected
4. Cut down on the learning curve - today, every device has it’s own user interface and operating principle. The nurses and physicians need to memorize the controls of, let’s say, an intellivue monitor, an evita ventilator and a bbraun space stack. If these devices were interoperable, the clinicians would be able to control these devices via a common user interface built in to the CIS, for example. This will reduce a huge amount of training, and possibility for errors. This is why the drager cockpit concept is intriguing - but unfortunately, as I am given to understand, drager cockpit will only support their own equipment, and will only be available in the market shortly after pigs evolve wings.
Scary as those concepts may sound, the advent of automated care is inevitable. By adopting an interoperability standard, the industry will not only facilitate a smooth, safe introduction of such technologies, but also save a huge amount of costs associated with developing proprietary communication protocols, validating them, and then writing drivers for them. The latter cost, to be precise, is borne by hospitals when they integrate the proprietary devices to their IT systems.
I notice there are five different definitions of interoperability - even the MDs can’t agree on what it means except ‘plug and play.’ I suspect the definition of interoperability might be like that of pornography - we’ll know it when we see it.
Frankly, there is not much on the market which meets even a rudimentary interoperability - has anyone actually read an HL7 specification document? The only thing standard is the field name (MSH, PID, PV1, OBX…..) all else is defined by the vendor sending the info - the receiver still has to parse the information and place it in the right ‘bucket.’ Where’s the plug and play?
By not defining a non-standard standard for the interface, the healthcare providers are putting the responsibility on the vendors for interoperability where it belongs. The healthcare organization delivers healthcare….and isn’t the expert on the standards or non-standards - what the healthcare organization can do is not buy equipment that doesn’t interoperate and isn’t transparent/open. The healthcare vendors can run operational tests to determine how those products will work - I did it - and found a lot of ‘marketing’ fluff.
The operators define requirements, the designers/implementers define how the requirements can be met.
Although I agree with Bridget’s comments, I would not belittle what HL7 has achieved. At least now, we get data as a string of characters that can be parsed (not as a stream of bits that only the vendor knows how to decypt). HL7 3.0 makes it easier by adopting XML structures, allowing “almost” automatic parsing for applications using .NET framework.
Compare this with device interfacing “standards”. The only standard in that industry is the physical RS232 D-sub connector (some vendors even have their own proprietary connectors). The protocols they use are proprietary, and with the exception of a very few vendors, not even documented. It’s a jungle out there.
Imagine if you could standardize the following things in medical devices:
1. physical data port (either RS232 D-sub or RJ45) - then we don’t need to by weird expensive connector cables
2. A standard transport layer, preferably something used in IT applications (eg. IP), so that we can use existing code and .NET assemblies
3. A common communication protocol (eg. TCP or UDP) - again, see reasons above
4. A common schema for the data with a structure and headers, so that we can parse and bin the data )eg. XML)
Just this would revolutionize the industry.
Mr McMillan - I did not mean to belittle HL7 - however, your comment about 3.0 needs to be taken into context as well. As I understand it, HL7 3.0 will not be backwards compatible to HL7 2.5. If you have an enterprise which has spent millions of dollars already getting their devices to ‘interoperate’ with an EMR/CIS using HL7 2.5, it will be a long time before you upgrade to 3.0 if you truly understand the costs involved…..it could mean a large re-do…..now I understand that many of the device intermediary vendors already use an XML format and convert that to HL7, however, what about the other side? Again, rewriting of the database and/or code costs money.
So, true ‘plug and play’ to my mind is a long way off - and then for ‘control loops’ to occur that are trustworthy (across an enterprise that could be quite large geographically) would take quite a leap of faith and trust.
Dear Bridget. Neither was it my intention to glorify HL7. As you noted HL7 has it’s drawbacks. However, HL7 was a major leap forward from the dark ages where applications spoke in bit-streams. HL7 gave this primodial babble a structure.
My point was - a similar “standard” (for the want of a better word) for devices would bring us out of the dark ages in device communication as well.
Migration from HL7 2.4 to 3.0 is difficult - but it definitely does not involve re-writing all the application code. A good translator should take care of it. And again, that just highlights how far we have come.
Pete, what better way to slow the adoption of interoperability than by, “developing proprietary communication protocols, validating them, and then writing drivers for them.” That’s the status quo.
I think what Bridget is looking for is something more along the lines of DICOM. Much of the implementation variability has been wrung out by the market. This happened because hospitals almost always bought the DICOM option and didn’t pay the vendor’s invoice until, you know, it actually worked in their hospital. Vendors quickly learned that making DICOM “hard” only added costs that came out of their profits.
Such a dynamic has yet to be established among medical devices outside radiology (and to a lesser extent diagnostic cardiology).