Earlier this week I was asked what connectivity capabilities are being built into medical devices now, what factors are driving these changes, and are there barriers to adoption?

The biggest trends driving what I call medical connectivity are EMR integration, workflow automation and alarm notification.

The basic capabilities required to meet the above include:

  • the ability to establish patient context, acquire and transmit data from the medical device
  • a server to capture, store, queue and transmit data (optionally, an HL7 interface for EMR integration, and logic to analyze data)
  • client applications (usually served up by the server) to enter, review and edit patient data.

The current state of the art for medical device connectivity is wireless, due to the inherently mobile nature of patients, equipment and caregivers in hospitals. Wireless enablement can be found in continuous patient monitors, smart IV pumps, ECG carts, and point-of-care diagnostics. Two frequency bands are available for medical devices, WMTS and ISM (aka WiFi and 802.11). The Wireless Medical Telemetry Service bands were designated by the FCC and FDA as replacements for telemetry frequencies that were reassigned for digital TV. The Industrial, Scientific and Medical bands are unlicensed bands available for a variety of applications. There is a great deal of controversy and marketing spin that surrounds the use of these two bands. There are significant differences between the two bands that impact performance, cost, and time to market.

Establishing and maintaining patient context is critical to ensuring that the proper data is associated with the right patient. This means that the medical device knows the name of the patient whose data it is capturing. Establishing patient context requires data entry at the device, a bar code reader (like Alaris has) the ability to pick a patient off a list (like the Welch Allyn Micropaq) or a keyboard for entering patient name and ID (like on an ECG cart). An HL7 ADT interface can provide a pick list and validation of captured or entered data.

Once the data is acquired, it most be sent somewhere where it can be stored, edited, reviewed and converted to HL7; this is the medical device server that supports multiple devices on a unit or hospital wide basis. In the acute care setting, the market does not currently provide servers (from HIT vendors or anyone else) that medical device vendors can simply plug in to. Vendors must provide server software as part of their connectivity solution.

The final piece of the puzzle is the client. The client can be a personal computer on the nursing unit, computer on wheels (COW), tablet PC, PDA or VoIP phone. Users can establish patient context, enter and edit data, respond to alarms, etc. General purpose computers are frequently shared with other applications, but as hardware becomes smaller or more specialized they tend to become single purpose.

The adoption of EMRs is the biggest factor driving connectivity. Hospitals want to get device data into their information systems as soon as it's acquired (not an hour later when someone has time to type it in) and without likely data entry errors. These applications can be segmented into monitoring/surveillance, diagnostics, and therapy. These applications transmit spot data, discreet readings that are taken on a non-continuous basis. There is also continuous monitoring via telemetry or multi parameter patient monitors, where any loss of communications results in gaps in waveform data (and potentially missed alarms).

Another driver for connectivity is workflow automation. The new smart IV pump is a good therapy workflow example, where the process of initiating the delivery of infusion therapy is automated to improve patient safety. Diagnostic workflow will include managing orders, establishing patient context, and the capture and validation of diagnostic data.

The final driver for connectivity is alarm notification and management. Caregivers must respond to a wide variety of medical device alarms, many of which are LTAs (life threatening alarms). With the exception of wireless continuous monitoring systems, these alarms are generated at the device in the patient's room. Continued emphasis on patient safety will drive improved alarm notification. These types of solutions are
just coming to market.

Many barriers exist to the "IT enablement" of medical devices. The first barrier is the absence of one or more core competencies required for medical device connectivity and workflow automation. Competencies frequently lacking include managing patient context, wireless enablement, and the development and management of general purpose IT products (the servers, HL7 interface and client applications mentioned above). Due to the variability and rapid change of general purpose computing technologies, appropriate regulatory strategies for IT enabled devices are considerably different from those used for embedded devices.

The next major challenge is money; medical device connectivity requires substantial investment. For example, the cost to develop an embedded radio can easily run $2 to $3 million and client/server applications much more. And unlike an embedded device whose R&D spend ends with the hand off to manufacturing, software components require constant enhancement.

The most pervasive major barrier is the business delivery system required to sell, install, in service, and support connectivity solutions. With connectivity, a business built around an embedded device with limited options is transformed. There are new decision makers (IT) to deal with and unique system configurations for sales to deal with. Installation is now dependent on device communications and interoperability with networks and third party information systems. If they are not fully operable, the device is not installed (regardless of how well the embedded device itself works). Customer training must extend beyond "knobology" to encompass workflow, transactions and the operation of client applications and the administration of servers.

Field service now requires network engineering skills and diagnostic tools. Remote service technicians must know computer operating systems, networking, and how to rebuild files and read log files. Adding IT features to embedded devices only starts with R&D, then it ripples throughout a vendor organization.

The ultimate challenge is crafting a business strategy that provides a roadmap to meeting connectivity market requirements profitably, at an affordable cost and within a reasonable time to market. This takes planning at coordination across the organization with success dependent on senior management involvement and commitment.