Medical Connectivity: Plug and Pray?

24x7 Magazine published a story of mine on connectivity. Variously described as "automating workflow" and "deciphering medical device connectivity," the story approaches the topic from a provider's viewpoint. After a bit of history and description of immediate and longer term reasons to connect (EMR integration and point of care workflow automation), we dive right into the part about "plug and pray."

Connectivity is really easy if you're willing to buy all new devices, and buy some new IT infrastructure to boot. Oh, and you have to be willing to replace most or all of it every time you change vendors (or even product lines from the same vendor). Oops, almost forgot, none of the different categories of devices will work together - and forget about any cross vendor compatibility. If this sounds unappealing to you, you're not alone.

The story addresses legacy devices, proprietary end-to-end systems and some interesting third party connectivity solutions on the market. And you can't talk about connectivity without mentioning standards:

Medical device connectivity requires a connection between the device and the target information systems. Legacy devices use a serial connection to a terminal server that converts the RS-232 signal to a network connection. Both wired and wireless local-area networks are used to connect devices to information systems. Older device-connectivity systems run on “private” networks that are physically or logically separate from the wider hospital network. The resulting proliferation of these “islands of information” is giving way to integrating devices into the hospital network. Because health care is inherently mobile, with patients moving throughout their stay and highly mobile caregivers, wireless networks offer the most flexible and least obtrusive network connection.

With the exception of diagnostic imaging modalities and some clinical lab equipment, the data that comes out of medical devices is in a proprietary format. Devices with end-to-end connectivity systems aggregate data from devices at a server, which converts the data into a standard—typically Health Level Seven (HL7) or SOAP/XML—and passes it on to another system. Devices that have only an RS-232 output must convert the serial interface to a network connection, where the data from multiple devices is aggregated in a server, which also converts the data into a standard for use by other systems.

Efforts of the Integrating the Healthcare Enterprise patient care device workgroup, standards bodies like the Institute of Electrical and Electronics Engineers Inc 1073 workgroup, and HL7 are working to improve the plug-and-play capabilities of medical devices. Goldman’s MD PnP group is also driving connectivity with use case development and a new verification lab. But it will probably be years before medical devices like those mentioned above achieve the ease of connectivity currently enjoyed in radiology with digital imaging and communications in medicine.

The real question is not about standards but what a provider can do to navigate this confusing mess.

How one finds their way through this bewildering sea of competing choices is a challenge. The interrelated nature of the devices, users, and workflows means that any one connectivity choice will inevitably impact subsequent decisions down the line. “With many connectivity projects you don’t find all the hidden costs until after the project is complete,” says Craig Bakuzonis, director of clinical engineering, Shands Hospital (Gainesville, Fla). “Detailed planning and experience have been our best project-management tools.”

Perhaps the most important part of connectivity planning and execution is needs assessment. Unlike many projects in health care, connectivity crosses multiple organizational silos in a hospital and must sync up multiple moving targets. These moving targets are changes that occur in care delivery methods, medical device upgrade and purchase plans, and information technology (IT). Any resulting solution must fit today’s environments and support future changes planned across overlapping areas. Even seemingly unrelated projects are interrelated—will nurses want to carry a PDA for spot vital signs capture and another PDA for the Baxter “smart” pump system budgeted for next year? Probably not. Can we run both applications on the same PDA? Good question; probably not.

Good planning for connectivity incorporates requirements from nursing, biomedical engineering, and IT into a series of road maps. Each road map starts with current requirements and captures planned clinical and operational changes into the future. A good time
horizon would be one that equals the operating life your hospital expects from a new medical device. Each milestone on the road map needs an associated project description and list of requirements. If no one in your hospital can plan out as far as the estimated useful life of your medical devices, make sure constraints posed by keeping those devices are understood by all parties.

This is a rapidly evolving area with few established best practices. The classic business term is discontinuity, which certainly applies here. As providers seek to integrate medical devices with information systems, and medical device vendors and HIT vendors eye one another's markets for future growth, the tradition of adopting vendor's end-to-end solutions is getting more expensive and delivering less value. Much like the early PACS market, the "DICOMification" of medical devices - the breakdown between the actual device and associated analysis software on general purpose computers - requires buyers to chart their own course.

As medical device connectivity has evolved, administrative applications are giving way to those impacting patient care and safety. Systems have evolved from data gathering and export to alarm management. According to Goldman, the next big connectivity application will entail medical device interoperability. “In the future, connectivity will include medical device control that permits the
integration of distributed medical devices to produce ‘error-resistant’ systems with safety interlocks between devices,” Goldman says. This error resistance will decrease user errors and provide closed-loop systems to regulate the delivery of medications and fluids, improving patient safety and outcomes.

Special thanks to the following folks to provided their time and experience for this story:

Craig Bakuzonis, director of clinical engineering,
Shands Hospital (Gainesville, Fla)Troy Gillette,
director clinical engineering and patient equipment, Robert Wood Johnson
University Hospital (Brunswick, NJ)

Julian Goldman, MD, program leader of the Medical Device Plug-and-Play
(MD PnP) interoperability program, departments of anesthesia and biomedical
engineering at Massachusetts General Hospital (Boston)

Bridget Moorman, clinical systems engineer, biomedical engineering, Kaiser
Permanente (Berkeley, Calif)

Elizabeth Wykpisz, vice president,
Washington Heart and Vascular (Washington, DC)

Eric Yablonka, VP, CIO, University of Chicago Hospitals and
Health System (Chicago)