Medical device wireless adapter

Abstract

The invention relates generally to a medical device wireless adapter, and more particularly, to a module that adapts an existing legacy or newly designed medical device to a healthcare provider's wireless infrastructure.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS [0001] This application claims priority from U.S. Provisional Patent Application Ser. No. 60 / 750,202, filed Dec. 14, 2005.FIELD OF THE INVENTION [0002] This invention relates generally to a medical device wireless adapter, and more particularly, to a module that adapts an existing legacy or newly designed medical device to a healthcare provider's wireless infrastructure. BACKGROUND OF THE INVENTION [0003] A broad range of existing and newly developed medical devices have a need for wireless connectivity. Such medical devices range from complex medical instrumentation incorporating embedded computers, including patient diagnostic equipment and patient monitors, to so-called “dumb” instruments that are network-unaware, such as a simple electronic thermometer with a serial output port that might do little more than make one type of measurement and output digital data representing the measurement. [0004] The WiFi (Wireless-Fidelity) Alliance is an...

AI Technical Summary

Benefits of technology

[0029] More particularly, the invention includes a medical device wireless adapter comprising a radio section; one or more means for exchanging data between said adapter and said host device; one or more means for exchang...

Problems solved by technology

While adoption of these network standards has been widely viewed as successful and deployments are wide spread (including healthcare institutions), initial mechanisms provided by these standards for managing a secure network have been proven to be vulnerable.

However, commercial products that implement these standards rely on the host processor in a PDA, laptop or desktop computer to implement the computationally intensive Public Key portions of these standards.

When these products are applied to the types of Medical Devices introduced above, this places an enormous computational burden on a real-time processor that is generally not well suited to the task.

While chip manufacturers typically develop drivers and supplicants for common operating systems and microprocessors, these are generally not available for embedded platforms.

Porting this sizable set of functionality to a broad range of processors and real-time operating systems (RTOS) for a diverse set of medical devices presents a significant development and computational burden that impacts each of the products that need wireless connectivity.

While modern object oriented design practices do help alleviate the development burden, porting code is still a manual process.

Many of these legacy medical devices simply do not have the CPU or memory resources necessary to accommodate Public Key Cryptography.

In the case of a network-unaware medical instrument, there are likely no available computational resources within the medical device to assist in any aspect of wireless connectivity.

Configuring medical devices on a medical network, particularly if authentication is used, can be a daunting and time consuming process as every device must be manually configured.

Even if many clients use strong authentication and encrytion, when some client devices do not, unauthorized devices may access the network, leaving it vulnerable unless the network is careful designed.

Another problem in adding a network-unaware medical device to a medical network involves defining the instrument and its control and measurement parameters and presenting them in a meaningful way to the medical network.

Another problem in adding wireless connectivity to a medical device is power consumption.

WiFi products that have been developed for the laptop and general purpose computer market lack the power options needed for the typical modes of operation used by wireless medical devices and do not support the complexities of state of the art medical-grade wireless devices and networks.

Another problem with commercial WiFi products is personal radio frequency (RF) safety.

However, these methods require ongoing communications operations of the commercial WiFi device and if the commercial WiFi device is set to a power save mode where the transceiver is inactive, tracking ceases.

Yet another problem with commercially available WiFi devices is reliability.

Generally the communication lines of these devices (including signal, data, and control lines) lack filtering to protect them from radio frequency interference (RFI) or electromagnetic interference (EMI).

A static discharge or other interfering signal can cause most WiFi devices to do an uncommanded reset.

A related problem with commercial WiFi devices is that these devices can hang or freeze in operation.

It is not practical to reboot most patient care and monitoring devices while they are in patient service.

In fact, a medical device reboot could be dangerous or life threatening to the patient in the case of some critical care medical devices.

Yet another problem for a commercial WiFi device is to reestablish its network association after a reset.

Yet another problem for commercial WiFi devices involves updating the configuration and firmware within the device.

The problem is that in a typical medical environment the host processor might only be minimally involved in WiFi operation and not able to conveniently accept (as by download) and then update its attached (or otherwise installed) medical WiFi adapter.

Moreover, some medical WiFi adapters might not have an available host processor to assist in performing software updates.

Medical devices typically lack a interface for configuration and further lack a means of remotely configuring the medical device.

Another problem in medical device applications is that a very large number of medical monitors, instruments, and network-unaware devices can be spread out over a large building or complex of buildings and over many floors of the buildings.

Another problem is that commercially available WiFi devices are not well suited to handling input and output (I / O) to or from any port or bus other than the port or bus to which the WiFi device is attached.

Bartek does not teach an adapter capable of transmitting data wirelessly to a network, such as a healthcare provider's wireless infrastructure.

Like Bartek, however, Al-Ali does not teach an adapter that is capable of transmitting the data to a health care provider's wireless infrastructure.

Parks II, however, does not teach a medical adapter that includes a bi-directional wireless radio transceiver.

Images