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.
Specialized OS: Option 2 (Customized Driver)
Microsoft is the dominant supplier of operating systems for desktop, laptop, and handheld computers. In the world of desktops and laptops, Mac OS and Linux run a distant second and third, respectively, to the current versions of the Microsoft Windows® operating system such as Windows XP and Vista. Windows CE and Windows Mobile are the runaway leaders among handheld computers (not including phones, where Symbian leads Windows Mobile). Palm OS used to dominate on handhelds used at the point of care, but today Palm OS is an also-ran to Windows CE and Windows Mobile, the latter of which has Windows CE at its core.
Unlike desktop, laptop, and handheld computers, many medical devices run specialized operating systems, often called real-time operating systems, or RTOSs. Operating systems that run on medical devices include OSE, ThreadX, FileX, PEGX, VxWorks, and pSOS. These RTOSs are popular because they offer:
- Low licensing fees
- Support for the building of a customized operating system image that includes only those services required by the device
- Low overhead to enable high performance from demanding embedded applications
- Small memory footprints, enabling use in devices with limited memory capacity and reducing power consumption
One downside of these RTOSs is that there are few or no off-the-shelf Wi-Fi radio drivers for them. Typically, the Wi-Fi driver for a medical device that runs an RTOS must be custom-made. Writing a driver for an RTOS requires a programmer who:
- Has the source code for a driver, typically a Linux driver, for the chosen radio
- Has experience with Wi-Fi drivers
- Understands specialized areas such as radio frequency (RF) technology and Wi-Fi security
- Is self-reliant and can achieve success without development support from the Wi-Fi silicon provider
- Is willing to support and maintain the developed driver or, at a minimum, document the driver well enough that someone else can fix bugs or make enhancements in the future
Another potential option for a medical device that runs an RTOS is a self-contained Wi-Fi module. Such a module includes not just a Wi-Fi radio but also a processor and memory to run the driver for that radio. At least a half-dozen vendors offer such modules, each with its own feature set and proprietary interface.
Windows CE: Option 1 (Vendor-Supplied Driver)
For medical devices with sufficient processing power and memory, Windows CE is a viable operating system. Microsoft positions the latest version of CE, Windows CE 6.0 (or CE 6), as real-time software that can be used to build a customized operating system for a medical device. Some argue that previous versions of CE should be considered RTOSs, too, because they have the same characteristics as other RTOSs and perform just as well for embedded applications.
Medical device makers, including those that have relied on specialized operating systems in the past, are taking a hard look at CE because the operating system is “friendly” to Wi-Fi in the following ways:
- CE includes security software called an 802.1X supplicant that provides support for Wi-Fi Protected Access (WPA) and WPA2 with both pre-shared keys and two Extensible Authentication Protocol (EAP) types, PEAP-MSCHAPv2 and EAP-TLS
- CE includes a configuration facility, often referred to as Windows Zero Config, that makes it relatively easy for a user or administrator to configure a device’s Wi-Fi radio to connect to available Wi-Fi infrastructures
- CE device drivers for various Wi-Fi radios are relatively plentiful
- Several Wi-Fi radio suppliers promote the fact that their CE drivers support “fast roaming”, “enterprise security”, and other features that may address requirements for medical devices
To CE or not to CE? That is the question for medical device makers. For those who want an easier path to Wi-Fi support on their devices, the answer, increasingly, is yes.
There is a third way, which is becoming more popular as companies start to understand the potential for Wi-Fi in embedded devices, which is to use a Wi-Fi module that embeds the appropriate protocol stacks, drivers and security. These provide a simple interface, such as a serial port, allowing designers to use them to add wireless connectivity to their device. An important advantage is that they insulate the product designer from the complexity and vagaries of the wireless conenction. We make modules like this, but we’re not alone.
Increasingly these modules have spare processing capability, which can be accessed to run the rest of the tasks for simpler medical devices, or automate the connection management. In some cases that means that the module can run the entire application - all that needs to be added is a sensor, user interface, battery and enclosure. The added advantage, is that because they’re designed as integrated Wi-Fi devices for embedded applications, they’re normally a lot more power efficient and lower latency than a CE solution, as they’re optimised for the job.
You can find more information on our offerings at http://www.ezurio.com/products/wlrange. We alos have a white paper explaining the issues of wireless for medical devices at http://www.ezurio.com/ehealth.
Tim,
This article is very timely. Hospitals are deploying RTLS asset management systems and a majority are told that
LWAPP a Cisco solution is the best interconnective option deploy an asset management system.
How does LWAPP play into the article’s medical device wireless connectivity solution?
Can you or Chris comment on the above statement and give a more little clarity on the similarities of asset tracking RTLS and medical device (Tracking/ Monitoring) wireless connectivity solutions?
Hi Brad,
LWAPP is the protocol that Cisco APs use to talk to Cisco controllers. APs and controllers from other WLAN infrastructure vendors use alternatives to LWAPP. The AP-controller protocol should be transparent to medical devices that connect to the APs.
Cisco is promoting not LWAPP but the Cisco Wireless Location Appliance, which interacts with Cisco APs and controllers to track the physical locations of devices with Wi-Fi radios. I believe that the Cisco appliance, like similar offerings from other vendors, relies on measurements of signal strength from 802.11 radios. Those radios can be used for Wi-Fi connectivity, or they can be location tags that do not connect to APs but simply “beep”. If three APs can measure the signal strength from a client radio, then the location appliance or server can use triangulation to estimate the location of that client radio.
802.11-based location solutions from some vendors provide better accuracy for Wi-Fi clients that connect to a WLAN than for location tags that “beep” but don’t connect. Most 802.11-based location solutions, however, track assets with location tags in exactly the same way that they track Wi-Fi clients.
As with many products in the wireless sphere, a comparison of location tracking solutions from different vendors is incomplete without a good understanding of the technology used by each. Customers should challenge vendors to explain the technology that they use.
Thanks,
Chris
Hi Nick (#1),
I described self-contained modules in one of the paragraphs in my post. While such modules have some attractive features, especially for devices that run RTOSs and lack robust processing power and memory, they have their disadvantages, too. For example, none are certified for Cisco Compatible Extensions (CCX). Medical device makers certainly should consider all options, including self-contained modules from your firm and its competitors.
Thanks,
Chris