Why Medical Device Makers Love/Hate Wi-Fi

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.

Love

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.

Hate

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!]

Share

8 comments

  1. Brian Long

    When dealing with WiFi and patient medical device monitoring, it is first and foremost important to understand the Use Case in which WiFi is going to be used for. Too many times is the situation run into that “we want wireless”, when asked why?, the vast majority of the time the answer is “because we do”. Many folks believe that WiFi is the “cutting edge” or “newest” technology and if they don’t have WiFi, then they don’t have the “latest” technology. Why must an alarm be sent to a clinician standing right next to a patient, walking them around for physical therapy, when a simple hand held device will provide the same end result?

    In working for a medical device manufacturer, looking at the *love* of the WiFi, the best overall love is definitely standards. Developing to standards definitely provides a common ground of which to base product solutions on.

    On the flip side some other challenges faced on the Device Manufacturer side are the design of the wireless network and the knowledge of wifi within the facility. Related to design, it is imperative to design the wireless network for the business purposes of which it is to serve. Countless times it has occurred when asked if there is wireless coverage in the patients room, the answer is undoubtedly ‘Yes’. After performing a wireless site survey, the network was clearly designed for charting, as there is only coverage in the hallways.

    The understanding of frequency spaces and the items within the hospital that may affect wifi is also extremely important. Such as microwaves (2.4 GHz), food carts, or those linen carts, that just happen to be the same width as the 5 GHz waves that are being transmitted. My favorite was a large vase of flowers with a mylar ballon placed directly in front of a wifi monitoring device. Of course it was an easy fix, move the vase to the other side of the bed, however, these little things have major impacts.

    WiFi knowledge within hospitals has also been challenging for medical device manufacturers. Many times, it has been discovered that wifi networks have just been “adding AP’s when necessary” or it was a “summer student project”. Other experiences have ranged from wireless network with directional antennas on the same channel facing each other, or antennas mounted upside down. Of course, these situations were not allowed to move forward with a wifi solution, however, this is additional cost and time to the medical device manufacturer.

    Ideally more and more hospitals, with setup a testing environment with the WiFi vendor of choice, design and test the applications for which WiFi is to serve. As mentioned above, healthcare for WiFi are extremely complex with monitoring, VoIP, RTLS, charting, etc….

    On the brighter side, when the Use Case calls for WiFi and knowledgable WiFi personnel within hospitals have proper design, frequency space knowledge and *partner* with medical device vendors, WiFi is a wonderful solution that meets the needs of clinicians and patients that it serves.

  2. Brian, lots of great observations and comments!

    You’re right that wireless for wireless sake is not always a good idea. For example, equipment that’s mounted permanently probably doesn’t need to be wireless — although direct observation of existing workflow captured in a formal use case is best practice for making this determination. In general, though, I have to say that wireless connectivity is industry best practice for most connectivity applications.

    This hits on another issue I see frequently, where device makers go out and simply ask customers what they want regarding connectivity. Asking such questions (often called “Voice of the Customer”) for evolutionary enhancements to a core medical device with which users have years of experience works well. Asking customers to imagine what they want for features, like connectivity, that they’ve never had before is a recipe for disaster. While this VoC data often contains *some* good ideas, use cases based on direct observation of current workflow are necessary to filter out the things users imagine would be cool but would not fit with their workflow.

    It’s nice to see that your remaining points validate the observations reflected in the blog post.

    As you point out, installation is particularly problematic, because Wi-Fi is a powerful but also complex IT infrastructure that must be properly designed and managed. Most hospitals still have a ways to go, when it comes to best practice for managing Wi-Fi networks – especially for life critical applications. Most manufacturers aren’t in a position to do a thorough (and expensive) Wi-Fi site survey for every sales prospect who wants a quote – so they wing it. If they get the sale, buyers then hold their feet to the fire regardless of how good the device maker’s guess is or how badly the hospital manages their network.

  3. Tim, a great post and I like your love/hate flair! You touched on a few areas related to use cases and clinical workflow, and I wanted to add to this.

    I sometimes converse with medical device manufacturers that are investigating the technical aspects of the data interface – including any of clinical parameters, alarms, waveforms, etc. for their device. This might be for a brand new device still in the design stages or an upgrade to an existing device. Often the conclusion is that WiFi is the best choice for all the reasons you state here. But as you point out, the use cases are what should be one of the driving factors in the decision. The use cases will flesh out exactly how the clinicians will interact with the devices in order to make them really “work” in a clinical setting. And as you often talk about, the resulting workflow for the clinician is what can often make or break the success of any connectivity solution.

    In reality, in order to accomplish the use case and workflow analysis, the medical device manufacturer has to consider the fact that their device will become part of the hospitals overall connectivity solution and strategy. Once you connect the device wirelessly to the enterprise network, you often must deal with other issues that are outside your direct control. These issues include things like: what system(s) do you plan to transmit the device’s data to – such as a central gateway (yours or some other vendor), central review or monitoring station, another device, etc., and how will the device data get associated to the right patient. The latter definitely requires some attention to the workflow.

    Granted that some of these issues are not specifically related solely to WiFi as a technology choice, but they certainly can tend to make your “hate” list a bit longer when you consider the added complexity created by adding wireless and/or WiFi to a medical device. And my takeaway point here is that from my own experience, sometimes after evaluating all of the use cases and proposed workflows for the health care enterprise, WiFi may not be the best technology choice in the first place. In this market, it almost never comes down to just a technology decision.

  4. Brian, you’re spot on with the importance of use cases and workflow. It reminded me of a post I wrote 3 years ago titled, Medical Device Startups and Device Connectivity.

    For those interested, here’s the URL: http://medicalconnectivity.com/2008/06/24/medical-device-start-ups-and-connectivity/

    Wi-Fi is not a panacea for connectivity, but for the many situations for which it is the best solution it is also clearly an imperfect solution. The intent of this post is to explore the strengths and imperfections of Wi-Fi, so that in some future post we can delve into specific things we can do to remove those imperfections and… fall in love with Wi-Fi all over again – this time for good.

  5. Tim,
    How do other systems fit in? I remember that for a while it was all about ZigBee, but that seems to have fallen out of the discussion. Are medical device makers “doomed” as it were to design with WIFI?

  6. Heather, let’s consider two key ways to frame wireless communications. The first is the frequency band over which the communications takes place, and the other is the protocol used to organize and manage that communications. Each country has a department like FCC that designates what frequency bands are applicable for specific applications. They define the requirements for using those bands like licensing, or using certain standards.

    Any radio, like ZigBee, is designed to operate on a specific frequency band and protocol. Protocols are often defined in standards. ZigBee and Bluetooth are standards and define how data is transmitted and received, in addition to how communications sessions are established and torn down between nodes (i.e., different senders and receivers). Standards can also be extended to include capabilities to improve throughput or bandwidth, coexistence among other users of the same frequency and prioritizing traffic based on a prioritization scheme.

    The vast majority of silicon and component radios available are designed to operate in the ISM band frequencies, and support standards based protocols developed for the ISM band. This is because the ISM band is about the only common world wide frequency allocation rendering the ISM band one of the largest single technology markets in existence.

    Within the ISM band ecosystem there is a lot of competition among chip makers and standards based protocols. Like any other product, standards need a unique value proposition that differentiates them from the many other standards targeting the ISM band. A consequence of this are the occasional “must have” technologies like ZigBee that are promoted by their supporters. Each mini-ecosystem, e.g., ZigBee, Bluetooth or Wi-Fi, has their own cadre of manufacturers who make chips and more complex products, contribute to developing associated standards, and often participate in test and certification alliances to ensure cross-vendor interoperability.

    Technologies like ZigBee are great for what they do, but they weren’t designed to substitute for Wi-Fi. In fact 802.15.4 and ZigBee were designed to wirelessly enable sensors, either in a mesh or hub and spoke network. They use little power, operate over short ranges and are capable of transmitting small volumes of data. So as noted by Brian and Brad, it is important to understand the specific communications objectives that are to be achieved for a wireless product (if in fact wireless is needed at all).

    Important wireless requirements can include send/receive distances, the amount of data to be transmitted, how quickly the data must be received, whether the data is a continuous stream or “bursts” of data, whether data transmission is needed at regular periods or on a random basis, the degree of mobility (whether or not, or to what degree, radios are in motion during communications), etc. Only through a proper identification of requirements can a manufacturer chose the most effective communications technology. To date, and in most cases, medical devices being pushed around hospitals use Wi-Fi because it provides the best fit (although far from ideal) for the requirements.

    There’s a whole other set of selection criteria for selecting a frequency band for a new product that we won’t go into here.

  7. Another great post, Tim. Decisions about medical device connectivity at the transport level is one aspect of a decision for both the producer and customer. The customer (in this case, the provider) needs to understand what the mission of that particular device is and then allocate the network transport requirements based on the risks associated with the loss of that connectivity to the functioning of that device. Wi-Fi is not the answer for everything and should not be. There should still be wired components in the healthcare enterprise and/or workflow that can accommodate some fixed assets.

    Managing the network transports is a full-time job – and can make or break the performance. Having deep knowledge within the healthcare staff to understand the different protocols and choices available will become (if it has not already!) imperative for efficient infrastructure functioning. This will become even more complex in the remote monitoring settings…managing the expectations for the connectivity will be very important.

  8. At this stage of Wi-Fi deployment in the health care industry I think it can perhaps be instructive to look back at the evolution of what is today a ubiquitous, reliable and mature communications medium for medical devices: Ethernet.

    As it happens, the core 802.11 standards borrow heavily from the 802.3 Ethernet standards and indeed the original 802.11 marketing name was was “Wireless Ethernet”.

    Early on, Ethernet competed with a number of alternative technologies including Token Ring, ArcNet, ATM and others. Many provided tangible technical advantages relative to Ethernet. Nevertheless, as Ethernet’s capabilities increased (twisted pair media, increasing data rates, switched ports, etc.), it supplanted each competing technology and is today the norm for (wired) connectivity in health care.

    I think there are two related points that come from this:

    1. Today, there are a number of wireless options available for medical device connectivity, e.g. WMTS, UWB and Zigbee. Each present tangible benefits, each have a very (very) small fraction of the unit volume and resulting economies of scale provided by Wi-Fi. The core 802.11 standards and the growing number of follow on 802.11 standards provide the flexibility needed to address each of the applications envisioned for these other wireless technologies. It suggests an eventual level of ubiquity for 802.11 similar to that of 802.3. It suggests a fate for WMTS, UWB and Zigbee similar to that of Token Ring, ArcNet and ATM.

    2. Originally a slow non-deterministic technology with limited interoperability, early versions of Ethernet were ill-suited for mission critical and certainly life-critical applications. The same is true for earlier Wi-Fi instantiations. However, in the same way that Ethernet evolved so too is Wi-Fi evolving. WEP has been replaced by WPA2/802.1x. 802.11b evolved to 802.11g and now 802.11n. Dual band 2.4/5 GHz infrastructure, providing as much as seven times the capacity as that of a single band infrastructure, is the norm for new enterprise deployments. I think that today Wi-Fi has evolved to the point that it’s the best option for mobile medical device connectivity with further improvements yet to come.

    As they mature, technologies, like people, sometimes present more to love (and less to hate).

Trackbacks/Pingbacks

  1. Wi-Fi Capacity and New Devices | Medical Connectivity - [...] VoIP. Medical devices are also increasingly wireless as has been noted in these pages before here and here. There is …
  2. “Microchip Medicine” Will Save Millions of Lives | Era of Radical Change - [...] keep you safe, your doctor will get alerts from your body delivered wirelessly from your chip directly to his computer [...]
  3. Guidelines for Using Wi-Fi for Medical Devices | Medical Connectivity - […] written before on WMTS and Wi-Fi, and you can read those two posts for more in depth discussions on …

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>