Managing Patient Context for Bedside Medical Devices – Today’s Situation
Clinical users have been managing patient context in various ways with medical devices for many years. With some classes of medical devices, this is nothing new. So you might ask — what is the big deal here with patient context and what has changed that makes this topic relevant today?
As I stated in a previous post, managing patient context is all about the clinical workflow. My working definition of patient context for medical devices is the linking of any information produced by a medical device (including data parameters, alarms, control settings, waveforms, etc.) with a specific patient identifier.
From a patient safety perspective, the best way to establish patient context is to tag data leaving a medical device with a unique patient identifier. And ideally this should be performed at the patient’s bedside where devices can come and go. There is clinician workflow associated with managing patient context – and this is perhaps the most important aspect.
We live in a dynamic world where technologies, products, and user requirements are constantly evolving. Take wireless medical devices for example. Wireless has evolved over the past few years and adoption will increase for the foreseeable future. When connectivity is wireless, patient context becomes even more challenging. Another example is with the evolving requirements for automatically integrating device data in to an EMR. The EMR market is moving beyond relatively simple patient monitoring vital signs interfaces and is now looking to integrate all bedside device data including smart pumps.
If you look at what is quickly evolving at the point of care today, patient context is becoming more of a challenge for vendors that manufacture the medical devices and as a result, end users (clinicians) are being asked to perform the task of establishing patient context at the point of care. So let’s look at how patient context is currently managed (if at all) and the impact on workflow.
Why Wireless Connectivity is Different
Wireless changes everything …
I have been watching the evolution of wireless bedside medical device connectivity for several years now. It is now fairly common for medical devices to communicate wirelessly and most hospitals now have the requisite Wi-Fi networks installed and operational. In fact, the saturation point of WLAN adoption in US hospitals has been reached as the numbers are quickly approaching 90% of all US hospitals.
But this posting is not about Wi-Fi or other wireless technologies used in medical devices. Rather it is about additional connectivity considerations beyond the actual wireless connection of the device to a network. Regardless of the wireless connection technology or standard used, wireless changes everything when it comes to connectivity.
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.”
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.
