Cisco CCX and Medical Devices
When it connects to a wireless LAN, a medical device uses the Wi-Fi® radio to send data to and from network infrastructure such as access points. If the medical device’s Wi-Fi connection is unreliable, then the device’s operation will become unreliable, and users will be reluctant to use the device. In some hospitals, network-ready medical devices sit unused in closets because users could not rely on the devices to maintain consistent network connections, especially when the devices were mobile.
Wi-Fi radios adhere to a set of IEEE and industry standards that define how the radio interoperates with a wireless LAN infrastructure. Devices that bear the Wi-Fi CERTIFIED™ seal have passed a set of interoperability tests defined by an industry association called the Wi-Fi Alliance®. A medical device that is Wi-Fi CERTIFIED should interoperate with any wireless LAN infrastructure, but there are no guarantees that operation will be flawless or that connections will be reliable. That’s because Wi-Fi interoperability testing uses access points (APs) from only a few vendors and doesn’t include such things as roaming from one AP to another.
What Is CCX?
Philips Launches Wireless Monitor/Defibrillator
Philips does it again, with an announcement that is sure to cause consternation among their competitors (press release). Philips has launched a wireless version of their HeartStart MRx monitor/defibrillator. The device will run on 802.11a/g wireless LANs, “with [the] capability to network with the Philips IntelliVue Clinical Network.” The press release starts off talking about workflow and clinical benefits:
Using the HeartStart MRx, hospitals will be able to transport patients who require cardiac monitoring or therapy between departments or within the same unit without changing equipment. The MRx can also be used at the bedside in departments that would benefit from having both centralized surveillance and cardiac therapy at their fingertips.
There are two big markets for monitor/defibrillators, hospitals and ambulances. While wireless connectivity in the EMS (emergency medical services) world has been around for some time, adoption is severely hampered because hospitals and EMS providers are separate entities. Given the propensity for vendors to create proprietary end-to-end solutions, pre-hospital connectivity necessitates that numerous independent hospitals, and the EMS providers who serve them, must use monitor/defibs and hospital based clinical information systems from the same vendor. Sadly, the structure of the pre-hospital EMS market, and the proprietary strategies of device vendors, has resulted in just a few high profile beta site/trials (that demonstrated meaningful improvements in patient outcomes) and a smattering of adoptions. The return for vendors on their R&D costs for developing this connectivity has been less than poor – not that they can blame anyone but themselves.
In the hospital, monitor/defibs have been standalone devices used in emergency situations. Of course there’s been a need for connectivity (data capture, surveillance and alarm notification) all along. The absence of connectivity has made it possible for a standalone company like Zoll to grab a piece of the hospital market. With the advent of wireless connectivity for the HeartStart MRx, Philips has a powerful new competitive differentiator. Philips is now the only vendor with both full line patient monitors and defibrillators integrated via connectivity into one system – this will be a big deal. GE now has a reason to go buy a defibrillator company. (Maybe Physio-Control, I hear they’re for sale.) Patient monitoring vendors without defibrillators will have another lock-out spec to fight. And defib companies, like Zoll and CardiacScience, will slowly and irretrievably lose hospital market share. Could there be a whole round of defib company acquisitions in the near future?
This tactical move by Philips is shaping up to be an example of leveraging connectivity for competitive advantage. Unfortunately there are few such examples – a hesitancy to adopt connectivity and poor strategies and execution have plagued many vendors. The words, “you don’t know what you don’t know” were never truer then when referring to medical device connectivity.
Pictured right is the Philips HeartStart MRx.
Comments on FDA Wireless Medical Device Guidance
After reading the above guidance document I was struck by how it provides such a good review of the quality system regulation (QSR). If you’re not a regulatory person and you want to get a high level view of the QSR, and especially how it might apply to wireless medical devices, check it out (updated link).The overall tenor of the document is to point out all the pesky safety things that “should” be done to ensure the safety and effectiveness of wireless medical devices. The term “should” here is, in most cases a “must.” As with other FDA regs, if you can provide a written justification for not doing something and the FDA agrees, you’re off the hook. Another nice thing about the guidance is that it provides a pretty good list of exactly what the FDA’s looking for in a premarket submission or site inspection. Here’s a good example of how the guidance document covers all the bases:
Many RF wireless devices use the industrial, scientific, and medical (ISM) frequency bands such as 2.4GHz, and these can incorporate technology to minimize interference and data errors or corruption (e.g., RF frequency hopping protocols). However, wireless coexistence and data latency remain concerns because the data transfer rate can slow slightly or even dramatically with an increase in the number of similar transmitters in a given location. In many cases it is essential that medical data, including real-time waveforms and critical control signals and alarms, be transmitted and received without error.
They’re not saying, “don’t use ISM:” they’re saying do your homework. The engineering problem of quantifying RF and wireless data performance boundaries around a product is not trivial. But you can’t design a product without specifications, and of course you have to verify the resulting design against those same specifications. And the comment about the number of similar transmitters is a great catch.First generation WLANs installed in hospitals were designed around coverage, and it took some iterative fiddling, and not a few unanticipated dollars, to provide good coverage as wireless applications evolved. Second generation WLAN designs took into account latency, jitter and throughput in order to support wireless VoIP – resulting in another set of site surveys and a “redesign” of the WLAN. Third generation WLAN designs will take into account capacity, so that the number of wireless devices (COWs, VoIP phones, PDAs, wireless medical devices) that can come together in an area won’t overwhelm the WLAN. Some day every hospital will have a wireless LAN that provides top notch coverage, latency, throughput, and capacity – we’re a long way from that even today.To better describe the focus of the guidance, let me set a frame of reference.
- A standalone medical device is a world unto itself – this greatly simplifies meeting regulatory requirements. Vendors only grapple with their device (which they control completely), and interactions with the patient and the user. This is also known as “the good old days.”
- Adding connectivity to a medical device extends the boundaries of both the product and the regulatory burden. Connectivity is usually implemented using general purpose computing technology that, unlike the medical device, is not completely controlled by the device vendor. Connectivity that integrates the device with hospital information systems, or creates a system for remote surveillance or alarm notification, causes the resulting medical device to touch the customer’s IT environment – a major loss of control on the part of the device vendor, and one they try to limit (frequently to the detriment of their product and user). The most common examples are general purpose PCs, servers and LANs.
- By making connectivity wireless the resulting product is exposed to a much broader environment – a busy wireless LAN, and a host of electromagnetic interactions.
Yes, I know – in my world everything is about connectivity. If you look at operating data on devices like two-way telemetry systems one sees that wireless connectivity can be virtually as safe and effective as a wired solution, even if a wired solution should theoretically be safer and more reliable. Achieving wireless performance that is equivalent with wires, however, is neither easy nor inexpensive.In addition to all the specific issues and risk factors noted in the FDA’s guidance document (and there are many), consideration of the environment in which the wireless device is used gets surprisingly little attention. You could read between the lines and say that this is implied, but then why write a guidance document?Device vendors’ connectivity solutions started out very proscriptive – requiring private networks and specifying exact models/versions and vendors of hardware and software used. As connectivity has become more prevalent, both in the number of vendors and systems in a hospital, and the broader deployment of systems (across major portions of a hospital rather than just a single department or unit), customers have chaffed at the unnecessary duplication and complexity resulting from device vendors’ obsessive need to control things.When you go wireless, vendors’ control issues become even more problematic. You can’t have a “private” 802.11b/g WLAN if there’s already one installed in the hospital. Even if your system runs on a VLAN, you have to configure that on the hospital’s infrastructure, not the device vendor’s infrastructure.So we finally get to the rub – how much of the customer environment must be accommodated in the development of the medical device? The short answer is a whole heck of a lot – especially if you want your solution to support a broad number of hospitals with different environments. Of course things were easier in the good old days for hospitals too, when devices were just standalone boxes with a power cord and connections to the patient. In the guidance document, the FDA recommends the following issues be included in wireless device labeling:
- data throughput
- latency
- integrity
- security characteristics and associated precautions
- need for spectrum management
- limitations on number, output power, or proximity of other in-band transmitters used in vicinity.
The above issues are examples of what must be documented, quantified, verified and validated and managed throughout the QSR – all the way to your CAPA system..The “need for spectrum management” is another nice touch. Most hospitals still have no formal spectrum management function. Hospitals will have to change along with vendors if they’re going to be able to create and manage a safe and effective environment and infrastructure for wireless medical devices. The alternative here is to buy proprietary end to end solutions from vendors (where everything is specified, private, and controlled by the vendor). The resulting price premium and unnecessary duplication in infrastructure, not to mention the “lock-in” vendors will exert, will not serve hospitals needs very well.One final bit of guidance on the last page:
FDA recommends you investigate EMI as a possible explanation for device malfunction when no problem is found in a device received for service, particularly where RF transmitters were located near the malfunctioning device. EMD from outside transmitters may be intermittent, and the electromagnetic environment of the service location can be very different from the location where a device malfunctioned. To aid in proper analysis and investigation, we recommend you identify if RF wireless transmitters or sources of EMD that were in the vicinity of the malfunctioning device.
Hmmm, how are you going to do that after the device is back in the plant? Removing the device from the customer site before determining where the failure occurred is problematic – it is impossible to diagnose EMD or network problems with a device in the factory. Having the right product design will be critical to determining the cause of failures with devices that interoperate deeply with the customer’s environment. And for that EMD problem, people are going to need one of these.Pictured right is a new class of wireless device: the portable, battery powered, and wireless CereTom CT from NeuroLogica.
Potential Interference for MIMO Wi-Fi?
It seems that the Boston Globe is spreading inaccurate info on MIMO (multiple input/output) technology. This from the Boston Globe:
Another caution: avoid MIMO routers. These Multi Input, Multi Output gadgets achieve excellent signal quality and range by hogging the wireless spectrum up to 219 yards away. If you live in the city or suburbs, your MIMO router will knock out your wireless-enabled
neighbors’ connections.
And if your neighbors also have MIMO, you’ll all lose your connections. MIMO also won’t work with those free Wi-Fi hotspots that are popping up in increasing numbers of cafes and libraries.
And this is the reply from Glenn Fleishman, blogger at Wi-Fi Net News:
“Less Is More” (Apr. 9, 2005) contains a glaring error regarding multiple antenna wireless networking. The reporter says that MIMO (multiple not “multi” input/output) gateways hog spectrum and knock out neighbors’ reception. This is entirely untrue. MIMO gateways for Wi-Fi, unlike previous range-extending Wi-Fi, are more sensitive receivers not more powerful transmitters.
There’s more if you want all the technical details. It does seem that MIMO and/or 802.11n could become a source of coexistence and interference concerns, if not actual problems.
