Implementing Wireless Communication in Hospital Environments with Bluetooth, 802.11b, and Other Technologies

Originally Published MDDI July 2003

ELECTRONICS

Wireless technologies offer a number of benefits in healthcare. But what issues remain to be addressed?

Brian Senese

The medical community continues to look for ways to maintain accuracy while improving operational efficiency. For instance, doctors can access and update patient information using computers at the patient's bedside instead of manually keeping charts that are kept either at the bedside or nurses station. Equipment used to monitor patient well-being can be hard-wired to the nurses station to provide remote access to vital data.

It is easy to see that the trend toward the use of technology in managing patient care is beneficial. Yet concern is often expressed over using wireless technology to advance operational efficiency. Interference—an issue associated with the use of multiple emitters within the same spectrum—seems to obscure perceptions of data-link reliability.

There is additional concern regarding the perceived complexity of implementing a wireless solution. The challenge of network planning, tracking the use of users and technology, and debugging (when things fail to work) can inhibit the use of an unseen radio link to replace a hardwired connection.

Why Wireless?

Let's first examine how wireless connections can increase operational efficiency while maintaining accuracy. Medical records can be accessed by a medical practitioner from any place and at any time by using a radio-enabled PDA or laptop.

Records can be maintained on a central database server for access by authorized users. Wireless access provides these benefits:

Medical equipment used to monitor a patient is typically mobile and can be readily moved anywhere along with the patient. Typically, such equipment is disconnected and reconnected via hardwire to each network-equipped room every time the patient is moved.

If the monitoring equipment has a wireless capability, on the other hand, connections can be managed automatically by the equipment itself—making the device truly mobile.

Medical telemetry, which is used to monitor ambulatory patients while they move about, can be easily managed with wireless systems. This has been the case since the 1960s— at least where community antenna television, or CATV, technologies in the VHF and UHF spectrum have typically been used. Wireless Medical Telemetry Service (WMTS) bands have now been further defined for use (see Table I).

Several other medical applications (or instruments) have been considered as candidates for using a wireless link. These are identified in Table II. In some instances, trials have begun with the instrument to see how the device works under real-world untethered conditions. Other medical instruments are being considered for conversion as indicated in the table.

In many cases, the medical device incorporates an embedded device. This means that there is a processor and software running on the device, yet their operation is unseen by the user. The PC-based solutions are used to collect data from the embedded device for storage and access at a later time.

Needless to say, wireless connectivity should not be used to establish connections to every medical device. Life-critical monitors used in intensive care units still need to be connected via wireline to ensure reliability.

Competing Technologies

A number of wireless technologies exist commercially. The question is, Which technology is best to use and what applications are best suited for these systems?

There are radio frequencies that can be used in the unlicensed, low-power bands. Frequencies dedicated to the medical industry are listed in Table I. The modulation scheme used within the 600-MHz band of the WMTS can be either AM or FSK, and the data format sent across this band is proprietary. There is virtually no interoperability among manufacturers. Also, FCC regulations restrict the use of this channel to short, noncontinuous messaging. Although data rates are considered to be low compared with other technologies, they are more than adequate to support the applications required. A nonstandard communications channel is the result.

Another wireless medium, 802.11b, perhaps better known as WiFi, is considered promising for use in data transport. WiFi uses the unlicensed ISM (Industrial, Scientific, and Medical) band centered at 2.4 GHz. Data rates upwards of 11 MHz can be achieved; however, it is more typical to see data flow at 5 MHz or less. Additionally, 802.11a and 802.1g standards were introduced recently and are also considered promising for supporting wireless data transport.

Bluetooth is yet another standard (IEEE 802.15) that has gained some level of popularity in commercial applications. As a standard, it has attracted significant attention in both the corporate and commercial electronics segments. Devices are currently being offered that support this standard, making platforms that are readily available for development of applications or to simply deploy as is. Data bandwidth is limited to 723 kilobytes per second (kb/sec), and the spectrum used falls within the ISM band.

Technology Fallout

Multiple technologies, some of which utilize common frequency bands, tend to generate confusion over which technology to actually use. In addition, reliability can be called into question when interference between different public standards is considered. Deploying an 802.11b local-area network (LAN) and a Bluetooth LAN, both operating within the ISM band, will result in some level of interference. This will raise questions of reliability of instruments attempting to use the allocated spectrum.

There has been significant discussion regarding this issue—and understandably so. Colocation of Bluetooth and 802.11b systems can be successful. An IEEE working group has been established to investigate ways to limit the level of interference between 802.11b and Bluetooth devices. Adhering to the working group's recommendations can help make the coexistence of both technologies a reality.

Desired Features and Values

Bluetooth technology was introduced to the marketplace as a wireless technology that was well suited to use in battery-powered commercial electronic devices, such as PDAs, cell phones, and a variety of other mass-produced electronics.

To conserve precious battery power, all components required to support this technology use very little power, which limits the transmitting power available. The end result is a 30-ft operating radius, which is typically the limit in which this technology functions.

Nevertheless, popular applications have found this quite sufficient. For example, a wireless link between a cell phone and an earpiece supporting an audio link is currently available in the marketplace. The distance between the devices is no more than 3 ft. Personal-area networks (PANs) are also being developed that support ad hoc networking, allowing multiple devices to communicate with one another, all within a few feet of one another.

On the other hand, 802.11b supports a data rate that can be 10 times greater. But it also requires significantly more power to operate a transceiver, which has an impact on battery life if the device runs on a battery.

Possible Solutions

In some medical applications, Bluetooth in particular can be deployed to establish short-range communications links. The technology can also be incorporated into existing embedded applications.

Consider the most basic wireless application as an example—one in which a device must simply send serial data to another device. For instance, this could be a transfer of historical data from a defibrillator to a laptop computer. Currently, infrared data association (IrDA) is used to transmit, or beam, such information as hours of use to portable computers, giving service technicians information needed to maintain equipment. Bluetooth could replace this technology, eliminating the need to properly align the infrared (IR) ports of the defibrillator and computer.

This type of Bluetooth application is simple to implement. The data source, the defibrillator in this case, can be considered a server. The laptop can be considered a client that extracts data from the medical device. In many cases, this type of communications architecture is already in place and is supported by a cable running between the defibrillator and the laptop. Figure 1 shows a typical wireless connection between a defibrillator and a laptop. Additional components required to make this connection are identified.

The medical instrument's embedded software is responsible for managing equipment operation. In addition, the device will need protocol software and radio-control software to manage the Bluetooth radio integrated circuit (IC). It is important to note that in embedded devices, memory is relatively limited and any protocol software that is used should be compact and efficient in terms of code size. Application software necessary to glue the radio protocol to the medical device application is to be developed. This exercise may be nothing more than

The amount of memory required to run such an application should be less than 64K of program memory and 5K of scratchpad data memory.

Notice that the radio-control software has not been mentioned as a component of this architecture. This software typically is provided by the radio IC vendor on a separate microcontroller. That is, the radio solution comes as a chip set consisting of the radio IC and a specialized (ROM burnt) microcontroller. Figure 2 shows this completed architecture.

Assuming that the additional hardware required to support the Bluetooth radio has been added, application software must be developed to communicate through the protocol stack. As illustrated in Figure 1, two personalities must be accounted for; the client and the server.

The client device establishes the radio link with any Bluetooth device, determines what that device does, and then can attach itself to that device to take advantage of the services provided. In the example given, the laptop is the client. Its role is to work through the following sequence of events:

Figure 3 illustrates the components and activities required to make a wireless transport link possible from the perspective of the client. On the server side, the software architecture is significantly different. The server responds to requests from the client, and the software architecture differs as a result. Much of the difference resides in the setup procedures required in preparation for accepting requests from clients. The setup procedures that must be completed before services are offered include the following:

Configuring the SERVICE DISCOVERY data. The server configures itself to respond to client requests with the services it offers. This must be set up prior to it responding to such requests.Optionally configuring the SECURITY data.The server can request that an authentication procedure be used to ensure that access to the server application is provided only to approved users. More importantly, this option is used to make certain that an exclusive link is established between client and server. If the security option is implemented, two devices can be bonded, and a communications link can be established only between those two devices. This leads to exclusivity, a desired trait for many applications.With the setup process completed, the server remains dormant until it detects an INQUIRY message to which it responds and also a CONNECT message. When it accepts a connection, permitting a radio-frequency (RF) link to establish itself, the services offered can then be accessed. This is dependent upon whether the security procedures have been configured and then passed successfully by the client when requesting services.

Figure 4 illustrates the data configuration of the server, as well as the procedures that are followed when the server application is accessed.

Basically, an application architecture has been examined for both embedded and PC-based Bluetooth solutions. Nevertheless, there are many details that must be considered before developing such applications. First, when addressing an embedded solution, the processor hardware used must have sufficient power to run the application, the protocol stack, and the data transport interface. The Bluetooth stack requires .005 MIPs when processing data at a rate of 57 kb/sec through the serial port interface. This is minimal, to say the least. Additional MIPs are required by the transport layer and the application. This must be determined by the system designer.

Next, the amount of memory required to support the Bluetooth stack and application must be assessed. The stack itself can be configured to use approximately 40K of program memory and 4K of data memory. The hardware engineer must ensure that this memory is available.

Many embedded solutions use a pre-emptive operating system (OS), such as VxWorks, Nucleus, or QNX. The protocol stack has to be ported to the OS; the Bluetooth solution generally takes five days or less and requires the following OS resources: 2 semaphores, 1 timer, and 1 event flag. The stack runs under a single task. If the embedded solution does not run a preemptive OS, then porting the Bluetooth stack to the system requires only one routine call, and porting takes as little as one day.

An equally important task is interfacing the protocol stack running on the host processor to the radio hardware. This typically happens through a UART interface running at a speed of 57–115 kb/sec. High-speed UARTs up to 1 Mb/sec can also be used. A transport layer interface handles this in either a single asynchronous task or as an interrupt service routine. One simple solution is to use interface software, which can be integrated with radio IC chip sets. The designer's job is to write the UART driver running on the actual hardware, taking bytes of data from a buffer and sending them to the radio. Conversely, this driver also accepts data bytes from the radio hardware and writes these data to a buffer for processing later by the protocol stack. Figure 5 illustrates the elements of the solution that require attention in addition to application development.

On the server side, the PC-based solution is quite different. Protocol stacks exist on a Windows-based platform and can be used by applications that make calls to the stack DLL. Usually, the client side application developed under Windows accesses a virtual COM port. It communicates with the server application through this COM port in a manner similar to one that uses a hardwired connection. As a client, the Windows-based application must be structured in the manner outlined on above.

A connection to the server (that is, the defibrillator in the example given) must be made initially through connection management software provided through Windows. Once the connection has been established with the correct server, the application can access the server application, and the wireless transfer of data can be achieved. Figure 1 illustrates a Windows-based client communicating via the COM port.

Aiming at Security

Security, the protection of data, is a significant factor when considering the deployment of any wireless technology. Bluetooth technology offers multiple levels of security for this purpose. A process known as authentication requires that an identical personal identification number be entered into devices that are to communicate with one another. This is intended to help prevent unwanted access by hackers.

Authorization is a second security precaution that asks the Bluetooth server if it will allow an identified user access to a particular set of services. The server can accept or reject a particular user even if that user has passed the authentication procedures. The data link can also be protected by encryption, once enabled, and is possible only after the successful completion of authentication.

After a solution is developed and tested, additional steps must be taken prior to market introduction. Bluetooth solutions must be certified by a Bluetooth qualification board (BQB). The BQB typically provides a set of tests that the product must pass before being granted certification. It becomes the responsibility of the product developer to conduct such tests in-house and prove compliance. With successful test results and a fee paid to the BQB, certification is granted. Without such certification, products are in violation of patents.

Conclusion

Bluetooth wireless technology can be used for many applications. It can also be implemented into existing products. The current price point for an OEM module is approximately $25, with this cost decreasing in accordance with the number of modules purchased. Designing a hardware solution into an embedded platform is less expensive, with a material cost of approximately $10 or less. As the technology is accepted into the mainstream and the price comes down, the question becomes whether the technology offers sufficient value to the medical industry for adoption.

Current discussions in the community are focused not on whether this technology can help increase efficiency, but rather on issues related to interference with radio channels that either exist now or will exist. Reliability is the key component in any solution. With many channels being allocated for the telemetry application and its successful operation for well over 30 years, it can be argued that Bluetooth can be effectively used within hospital environments—especially if used for short-range cable replacement communication.

A secondary issue that has plagued the medical device industry has been a lack of standardization. Again, looking at the telemetry application, disparate solutions exist that are not interoperable. Bluetooth technology can bring a common standard, especially to embedded services.

For a more in-depth discussion of such matters, it is advisable to get information from individuals who have worked in the wireless arena.

BIBLIOGRAPHY

Beaumont, Daniel D. "Bluetooth Brings Mobility to Healthcare," Planet Wireless, June 2002.

Bray, Jennifer et al. "The Bluetooth Application Developers Guide," Syngress Publishing, 2002.Hoglund, David H. "Dynamics of the Wireless Change in Healthcare, Overview and Synopsis," Integra Systems Inc., November 2, 2002.

Saltzstein, William E. "Exploring a Wireless Future for Medical Electronics," Medical Electronics Manufacturing, 2002.

Brian Senese is the co-author of The Bluetooth Application Developer's Guide and is author of Successful High-Tech Product Introduction and other publications. Post your questions and comments for him in MD&DI's Author Forums at www.devicelink.com/mddi.

Illustration by AMY DeVOOGD

Copyright ©2003 Medical Device & Diagnostic Industry