Why Medical Device Makers Love/Hate Wi-Fi
In this post we’re going to lift the window shade a bit on why many manufactuers love Wi-Fi, and why they also hate it with equal passion.
You see, I’m often asked by manufacturers about alternatives to Wi-Fi for wireless medical devices. And I’ve done a number of wireless technology surveys for manufacturers, looking for attractive alternatives. There are no attractive alternatives, at least for most medical device applications at this point in time.
Before we dive into this sordid tale of passion and betrayal, let’s frame the discussion. The wireless application I’m referring to is the connection between a portable or mobile medical device and the enterprise wired network. While the examples in this post come from hospitals, there is much here that is applicable to ambulatory settings. Applications that are not considered are cable replacement applications (Bluetooth or wireless USB) or wireless sensors in body area networks (BANs) that are, by their nature, low power and short range, are a different animal.
UPDATE: This post is intended to focus solely on networking issues around medical device connectivity. Issues about requirements, use cases, workflow or any issues dealing with medical device or application layer features are outside the scope of this post.
Wi-Fi, how do we love thee? Let’s count the ways…
Off the Shelf Components
When contemplating the beauty that is Wi-Fi, where does the besotted medical device manufacturer start? Many manufacturers fist fall in love with Wi-Fi as an off the shelf (OTS) solution to a big problem. Those three magical words – off the shelf – can significantly reduce time-to-market and product development costs, and in this respect, Wi-Fi really delivers.
Imagine what a bleak and barren world it would be without Wi-Fi. A world where manufacturers have to design their own radios to wirelessly enable their medical devices. It can easily cost a few to several million dollars and three or four years to build a component radio around an existing radio chip from Freescale, Broadcom or some other supplier. GE got their WMTS technology through their acquisition of DataCritical. Philips chose to develop their own, based on Philips chips repurposed from DECT telephony applications.
If you make a radio, it’s got to have something to talk to on the other end, the end connected to the wired enterprise network. Without Wi-Fi, medical device makers would also have to design and manufacturer their own transceivers, much like how GE and Philips make their own proprietary WMTS access points.
Another OTS characteristic is that there are numerous potential suppliers, for both client radios and infrastructure. Wi-Fi suppliers compete on price, features, technical support and availability, and medical device makers can readily source parts from a second or third supplier if the need arises.
Economies of Scale
Another source of device maker’s infatuation is with economies of scale. Economies of scale results in lower unit costs and a richer feature set, compared to wireless technologies developed specifically for medical device wireless enablement. The thought of all the millions of Wi-Fi client radios made each year (and especially the ever falling cost per unit) quickens the pulse of any device maker contemplating wireless enablement. The broad market for Wi-Fi dramatically lowers the cost of radios, access points and related infrastructure. Even a large manufacturer with widely deployed wireless devices, like CareFusion or Philips Medical, will only sell thousands of wireless devices in a year – practically a rounding error to Wi-Fi manufacturers who sell millions of units in a month or quarter.
Leveraging Planned or Existing Infrastructure
And Wi-Fi infrastructure, it’s pervasive, and growing in reach and depth every day – world-wide! What is the likelihood of going into a hospital (at least in the US) that doesn’t have Wi-Fi deployed somewhere – if not everywhere. Because Wi-Fi is a part of hospital’s IT infrastructure, medical device makers are able to share the infrastructure costs for wireless medical devices with other wireless enterprise applications. Even in cases where a hospital has to install the Wi-Fi network to support a new wireless medical device, they don’t mind because it’s part of the enterprise IT infrastructure and will be used for bedside charting, meds administration, wireless voice over IP (VoIP) phones, or some other application.
In situations where the hospital’s already invested two or three million dollars in Wi-Fi, adding a wireless medical device application often represents a nominal incremental investment. A broadly deployed dedicated wireless infrastructure, like WMTS, 802.15.4 or ZigBee, can easily run an additional one million dollars or more to the cost of the medical device system. This puts manufacturers using Wi-Fi at a competitive advantage, which they love.
Single World Wide Product
Next in the pantheon of manufacturer’s love of Wi-Fi are standards. Standards enable medical device makers to create wireless products that can be sold world wide. Having a single world wide product lowers costs and time to market for manufacturers. The industrial, scientific and medical (ISM) bands are reserved internationally – one of very few frequency bands that are designated world wide. Consequently, a wireles medical device that uses the ISM band can be sold world wide. Yes there are a few tweaks required for certain nations, but those are built in to the OTS radios and infrastructure medical device makers already use. OTS, be still my beating heart!
The other set of standards are defined by the IEEE, called 802.11. Each different standard is a letter after the numbers, for example 802.11a/b/g/n are the four different standards that define the various communications protocols that are supported. There are also standards for security, quality of service, improved mobility performance, and much more. In fact the alphabetical identification of individual 802.11 standards has gone from a through z to double letters. The most recent double letter designation is “ai” for Fast Initial Link Setup.
Cross Medical Device Maker Coexistence
Coexistence is the magic that enables wireless devices from different manufacturers to work on the same network infrastructure, along with all the non-medical device Wi-Fi devices found in a hospital. The 802.11 standards, and especially 802.11a/b/g/n are what provide the framework for this coexistence. The vast majority of frequency allocations, for example WMTS, do not include standards that ensure coexistence. They rely on limiting users to specific applications and a first come/first serve registration basis. For example, there are frequencies allocated for broadcast television, mobile phones, radio astronomy, and aviation radar – those frequencies can only be used for the applications for which they were designated. The users of these types of frequencies must also register with the designated registrar (often a government agency) to become licensed. A potential user wishing to be licensed, can only qualify if there is sufficient capacity. Should the registrar determine the capacity for that frequency and location is already licensed by another, than the potential user is out of luck – hence the first come, first user nature of licensed frequencies.
The ISM band is unlicensed by design, and by using the rich standards available and how a wireless device is designed, many users can share the same frequency bands.
Hatred… loathing… abhorrence… enmity… revulsion… the emotional range for what medical device makers feel towards Wi-Fi is both deep and nuanced – and often for good reason.
Too Many Configuration Choices
Probably the first on any medical device maker’s list of reasons they dispise Wi-Fi is the wide range of configuration choices. There’s seemingly an 802.11 standard for everything. And for most standards there are a myriad of configuration choices. When managing a Wi-Fi infrastructure one must select the specific standards to be supported at your site, and how they are to be configured. In particular, one must chose how to authenticate devices that want to associate with your Wi-Fi network, how encryption will be configured to assure security, and how quality of service is defined. To medical device maker’s frustration, for every configuration choice, there are hospitals that have standardized on that configuration.
Medical device makers design highly regulated products that must be both safe and effective. To that end, manufacturers have traditionally designed products in a way that reduces variables and complexity in an effort to improve reliability and safety. The rational approach to Wi-Fi for a medical device maker is to select only those standards that are essential and specify the one way they will support their configuration. For example, take 802.11a/b/g/n and pick one. Hmm, 2.4GHz or 5GHz, pick one. Encryption and authentication methods? Pick one. Voila, fewer variables! This also serves to make their product less expensive to design and test, with a shorter time to market.
To their customer’s frustration, manufacturer’s choices are often different from the choices they made when designing their enterprise network. When this happens, providers have two choices: to reconfigure their network to accommodate the medical device their clinicians can’t live without, or tell their clinicians to pick another vendor who meets their network standards. Depending on the kinds of choices device manufacturer’s make, they can find themselves excluded from a substantial number of sales. At best, the device maker has a new customer that’s already dissatisfied with their product.
Demands to Support Multiple Wi-Fi Network Vendors
Due to the technical demands of their wireless application, their regulatory strategy, or both, medical device makers often design their products for use with a specific vendor’s infrastructure, e.g., Cisco, Aruba, Meru, Trapeze, etc. So what happens when a medical device maker designed their product for Cisco and their largest sales opportunity ever has Meru? Hate, rage, and seething animosity. And most likely a lost sales opportunity. In this case there are two choices: the provider can install a Cisco Wi-Fi network, in addition to their Meru installation, to run the wireless medical devices, or the device maker can redo their verification testing (and possibly some additional engineering work) to support the Meru network.
There is only one medical device maker that I know of that’s tested and certified more than one Wi-Fi vendor’s infrastructure for their wireless medical devices. Draeger has tested and certified Cisco, Aruba, Meru and Trapeze. This testing effort probably cost them a half a million to over one million dollars per vendor. That’s serious money that wasn’t invested in new clinical features.
In both these situations, configuration choices and the selection of a specific Wi-Fi infrastructure vendor to support, medical device makers have the choice of spending a lot more money on design and verification testing, or face a reduced number of hospitals in which to sell their wireless medical devices. Such a conundrum to make a manufacturer’s blood boil, their heart turn to stone.
Frequent Provider Network Remediation
Now let us shift to the Wi-Fi networks installed in hospitals, the fertile fields upon which device makers must sow their wireless medical devices. Even medical device makers with relatively undemanding wireless applications find the vast majority of hospital networks insufficient, sub par or inadequate to their needs. This loathsome deficiency results in frequent installation delays, while hospitals spend weeks or more often, months, whipping their Wi-Fi networks into shape. And while hospital networks are being rehabilitated, device makers face delays in revenue recognition and additional installation and support costs. Curse you, Wi-Fi!
Short Life Cycle of Wi-Fi Products
Yet another sling and arrow relentlessly tormenting device makers using Wi-Fi is change. When medical device systems were physically or logically separate networks, completely controlled by the device maker, they chose when to upgrade systems. Of course, since they were separate networks there will little or no need to upgrade anything – unless something broke and the original component was discontinued and had to be replaced by a new model. Even today, it is still possible to find medical device systems that were installed 5, 10 or 15 years ago, running on ThinNet or ThickNet Ethernet cable. Those are days of innocence fondly remembered by more than a few manufacturers, before the dark and sultry sirens song of Wi-Fi.
Now when a wireless medical device is installed, it’s only weeks or a few months before the phone rings with an unrequited provider complaining that your wireless medical device system failed them after they upgraded all their Wi-Fi controllers to a new firmware release – that you failed to test. So now, when device makers aren’t spending resources on complaints generated by configurations they neither sold or tested, they’re feverishly testing new firmware for APs, controllers, switches, routers and testing new models of those same components when they are released. If you wondered why device makers only support one Wi-Fi infrastructure vendor, wonder no more. Imagine the scope of effort required to stay current with three or four Wi-Fi vendor’s product lines.
Costly Failure Mode Testing
The final outrage for some device makers is the lack of support or even disclosure from network vendors regarding latent defects in their products that impact the medical device system. Network manufacturers test their products for mission critical applications. Unfortunately, some medical device applications are life critical. Consequently, some manufacturers have to do their own failure mode testing of network components. These test results must be shared with the network vendor if they are to be expected to fix defects found in the testing. A common response from network vendors is, “oh ya, we knew about that. Thanks for the data.” Imagine the revulsion, the odium that device makers must feel.
Can Love Succeed?
As a technology, Wi-Fi is well proven. Yet, every new wireless application adopted by a hospital is almost always being implemented by that hospital for the first time. (Remember the saying, “You don’t know what you don’t know.”) How many times has a hospital attempted to implement a new wireless application – say indoor positioning or wireless VoIP – and had to go back, do another site survey, reengineering the network and install or move APs and other equipment?
Health care, and especially hospitals, are one of the most demanding Wi-Fi markets in existence. Few vertical markets include the high degree of mobility, high number of users, numerous advanced applications, and life critical safety demands of health care. Where else can you find a site with portability (computers on wheels for meds admin and charting), mobility (clinicians and caregivers), wireless VoIP, indoor positioning systems, and a thousand odd infusion pumps, a few hundred continuous patient monitors, and more? Sadly, nowhere. We are on the pointy end of the Wi-Fi stick, and medical device makers are not the only ones conflicted about this.
There are certainly things medical device makers can do to on their own to improve their relationship with Wi-Fi, and myself and others in the industry can help. Unfortately, there’s only so much individual device makers can do to mitigate the inevitably rocky relationship between them, Wi-Fi and their provider customers.
UPDATE: The ideas presented here are based on work that was started in 2008, when I developed the concept of an industry alliance to address network layer issues faced by manufacturers and providers. Over the years, I have presented this concept to many medical device and network manufacturers, several provider organizations, and in public venues like the FDA’s interoperability workshop. For no good reason I have never written any blog posts on this topic. This is the first of probably 3 or 4 posts exploring network issues and potential solutions.
[Photo credit: Tarina Tarantino necklace available through kaboodle - get one for your favorite vendor/CIO today!]