Medical Device Networks Trouble Industry
Over the past few years, medical device networking has become increasingly problematic. There is a growing perception of declining service levels and network reliability. (I’ve not seen or heard about any quantitative data to back this up – let me know if you’ve got any – but these are substantive issues.) As medical devices, by way of connectivity and workflow automation, have been pulled into the sphere of the IT department risks to patient safety have increased.
These growing problems are a key factor in the creation of IEC 8001 – which will have a major impact on how hospital’s deploy and manage networked medical devices. The current situation provides a lot of the impetus behind a meeting this week at Villanova on wireless technology in health care. So what’s the big deal?
Private Medical Device Networks
In the good old days, all medical device systems operated on private networks that were designed, installed and supported by the medical device vendor. Vendors decided exactly how the would handle IP addressing (static or DHCP) and every other configuration option. This minimized vendor’s product development costs, shortened time to market, and made service and support easy (because the network was their sandbox). When they got the inevitable calls from customers that, “your system just brought down our network,” vendors could quickly and easily determine if that was the case – and just as importantly, quickly prove to hospital network administrators why their answer was correct.
Providers benefited from this approach in a number of ways. First, vendor system support was quick, efficient and reasonably priced. This approach also relieved hospitals of the need to assume responsibility for supporting life critical applications themselves.
Of course nothing’s perfect, and relying on private networks created a few problems of its own. As more medical devices evolved to become components in medical device systems connected by networks, these private networks proliferated. The IT department of a thousand bed hospital system on the east coast did a survey a couple years ago of their networked medical device systems, and “discovered” over 200 private networks. And unlike enterprise networks that must be kept up to date to ensure cross vendor interoperability and coexistence, private medical device networks are like time capsules. With the exception of occasional failures of a switch or router, medical device networks remain unchanged from the day they’re installed; the hospital mentioned earlier found numerous ThickNet and ThinNet Ethernet networks in their survey of medical device systems.
Over time, medical device vendors have given some ground by moving from physically separate private networks, to creating logically separate private networks through the use of network switches and routers.
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.
Hospira Acquires EndoTool
On Oct. 13, 2008 Hospira announced that it had acquired the EndoTool business from MD Scientific. (Press release) The EndoTool glucose management system is software used to determine optimal insulin dosages to help establish and maintain glycemic control. Target markets for the product include critical care and surgery, as well as lower acuity areas on hospitals. Hospitals are also considering use EndoTool in Labor and Delivery. The product was launched 18 months ago by MD Scientific, and seen increadible adoption (60 hospitals currently). The product won’t be “relaunched” under the Hospira brand. You can read the publicly available FDA 510k stuff here.
Software designed to support the application of clinical protocols has been in the works from various vendors. Patient monitoring examples include Philips Protocol Watch, soft-launched back in February 2007, and . These applications automate what are otherwise onerous manual calculations with data acquired from medical devices and integrated with data from other information systems. This is workflow automation of the most important kind, diagnosis and therapy delivery. These applications are typically regulated as Class II medical devices.
Last week I spoke with Philip Settimi, MD, vice president of global strategic marketing for Hospira. According to Settimi, “EndoTool replaces spreadsheets of physician preferences and worksheets full of manual calculations for managing patient glucose levels.” Such manual methods are obviously inefficient, but also susceptible to human error. This approach provides an effective tool to impose a controlled and centralized tool for managing tight glycemic control (TGC). Endo Tool comes with a specific protocol based on sophisticated algorithms to support glucose management. The key: taking all that complexity (the calcs) at the point of care and automating those 33 different non-linear equations.
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.
