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.
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.
Scalabilility Challenges Wireless LANs
When thinking about wireless networks in hospitals, most people think about coverage, and coverage is certainly an important requirement. A network performance metric that is less obvious but perhaps even more important is capacity. Capacity refers to the number of clients associated with an access point (AP) and the total bandwidth that’s available in a given location.
All of this was once again brought into focus for me during a conversation with Phil Belanger, founder and chief marketing officer for consulting firm Novarum. Phil has been in the wireless LAN market a long time, starting with Zilog and Corvus and served as co-chair for the IEEE work group that defined part of the initial 802.11 wireless LAN standard. He ended up at Cisco when they acquired Aironet.
As more medical devices incorporate connectivity, the number of potential WiFi clients around a patient increases. For example, let’s imagine a patient with 5 B Braun infusion pumps, each with its own WiFi radio. Add to this a Dash patient monitor and a ventilator; the Dash has embedded WiFi and the vent has a third party wireless module. Besides these 7 wireless clients, each caregiver has a wireless VoIP phone and most physicians also have WiFi devices (PDAs or smart phones).
Now imagine that there are similar patients in just 3 near by rooms. What happens when a code is called in one of those rooms and 3 caregivers, and a bit later a couple physicians respond. Let’s see, that’s 7 wireless devices times three patients, for 21 active associations with the network. Of the 5 people responding to the code, say 2 of them are having wireless VoIP conversations (say with specialist, or looking for a STAT diagnostic test result) and 1 is charting the code on a COW. That’s 24 associations.
What happens if an acute care patient being transferred goes by, adding 3 more associations and another wireless VoIP call? Or another code is called in the same vicinity? Do calls get dropped and the means to receive urgent information is lost? Are associations with the network lost by medical devices? Which ones? Could it be a device connected to a lone patient in a private room? Might life critical alarms be missed?
Draeger Certifies Trapeze Wi-Fi with Infinity Patient Monitoring Line
Yesterday, Draeger announced that they had completed interoperability testing with WiFi infrastructure vendor Trapeze Networks. What they call a “Certification Notice” indicates that they’ve completed formal verification testing (and probably a “letter to file” for regulatory purposes) to ensure that their regulated medical devices, running on a Trapeze wireless LAN, operate within specifications. Aruba announced at HIMSS 08 their certification for use with Draeger’s Infinity patient monitoring system. Also, Aruba and Welch Allyn announced interoperability at HIMSS 07.
Here’s how Draeger describes their certification effort (emphasis mine):
In Drager’s notice of certification, Lars Roth of Drager’s Monitoring Systems and IT group, wrote, “Due to the critical nature of medical devices, Drager Medical tests and verifies network hardware components used for communication between medical system devices. These tests include proper IP Multicast handling, wireless roaming, wireless encryption and load testing. In addition, tests with competing traffic are run in order to understand and detect the proper Quality of Service settings. These are the key parameters that will ensure that in a shared Infinity OneNet installation, the data flow of the Drager patient monitors is being prioritized over non-patient monitor data.”
Most medical device vendors complete validation test for a new product supporting that one WiFi infrastructure vendor at market launch and beyond. Depending on the regulatory strategy of individual vendors’ products, completing the validation with additional wireless LAN vendors can be very time consuming and expensive. Compounding this is the fact that verification test is a common R&D bottleneck for many medical device vendors.
Cisco Changing to Support Health Care
Many things have changed at Cisco since they were visited by the FDA in 2006. Awhile back Kent Gray, global lead for Healthcare Solutions at Cisco, explained to me that the FDA was responding to a brochure produced by Cisco that included a photo of a 7921 handset displaying a patient monitor alarm and associated waveform. The FDA observed that the photo represented labeling of a Class III medical device for which Cisco did not have regulatory approval. Thus began a crash course in the health care school of hard knocks for Cisco.
To Cisco’s credit they have since made many substantive changes to their traditional approach to vertical market marketing in response to the special requirements of health care. During the AAMI conference this week in San Jose, I had a chance to meet with Erik Petersen, the Global Healthcare Solutions & Technology Partnerships Manager, to talk about what Cisco’s been doing in health care.
Health care has strategic importance to Cisco. After their run in with the FDA – a rite of passage for health care vendors – Cisco’s commitment to the market was confirmed by no less than CEO John Chambers.
As a corporation that has experienced enviable growth, the company is grappling with the transition from a $40 billion company to one doing $60 billion. “Cisco wants to offer a strong proactive value proposition in health care,” said Petersen, “rather than just providing a piece of infrastructure that the customer has to deal with for an overall project.” To meet their growth objectives, the company is shifting from a horizontal market company to one focused on vertical markets and applications. To us in health care, this means responding to the unique requirements of our vertical market.
Medical Devices: To CE, or not to CE?
In my last blog post, I explained that:
- Mobile medical devices must establish and maintain secure Wi-Fi connections in environments that present challenges to wireless connectivity
- Most of the Wi-Fi functionality of a mobile medical device is supplied by the Wi-Fi radio device driver
- Reference drivers from Wi-Fi silicon providers are designed for mainstream devices such as laptops, not for medical devices
- Customizing a Wi-Fi device driver for a medical device requires the skills of an experienced Wi-Fi driver developer who has source code for the driver
- Obtaining driver source code can be difficult, and experienced Wi-Fi driver developers are in short supply
The primary options for a medical device maker are:
- Find a Wi-Fi client radio with a driver that works (well enough) on the medical device
- Hire an employee or contractor, or work with a contract development shop, to customize a driver for the device
The decision on which option to pursue often depends on the operating system that runs on the device.
