First up today, the Clinical Engineering Symposium: Medical Device Integration Projects. A panel of rock stars will present case studies on medical device connectivity. Steve Grimes kicked things off to a full house - SRO, actually.

Case Studies from Beth Israel Deaconess

First up will be John Halamka, CIO at Beth Israel Deaconess Medical Center. His themes are:

  1. The importance of including medical devices in enterprise-wide EMR projects
  2. The importance of including clinical engineers and IT people during the planning stages
  3. The importance of looking to consensus-based standards

The American Health Information Community (known as "the community" rather than "a-hick") identified 4 requirements to tackle in 2006 - a certification commission, standards, security and privacy, and a nationwide health information network architecture. Halamka noted there are over 700 health care standards that could be applied. He presented a nice model with a basic use case, actors, tasks and documentation - that is intended to lead up to the blessing of specific interoperable standards that will go into federal procurement standards (effectively a de facto standard). All of this has been worked through and presented to AHIC for formal adoption.

In 2007 the focus is privacy and security, emergency responder, PHRs, meds management, and quality (QI) - with the goal to again review, align and harmonize all of these areas into a common manageable process. Preliminary requirements for privacy and security are completed. For 2008 AHIC is looking at medical device standards, with focus on remote monitoring outside acute care settings.

The projects they've done at Beth Deaconess over the past few years include mobile glucometer interfaces to a lab system, an ICU information system (Philips monitors with MDsoft), anesthesia information system (Compurecord system from Philips), positive patient ID/eMAR (passive RFID for neonates and barcode), and active RFID.

The RFID deployment was justified on improved asset tracking -loss prevention, reduced time looking for assets, eliminating device hoarding. Their consensus on active RFID: not yet ready for prime time. Beth Israel went with WiFi based RFID and PanGo. He notes the higher access point (AP) density requirement - wireless data requires 1 AP visible per client, RFID requires 3 for even modest performance (and notes increasing co-channel interference issues with higher AP densities). They started with 450 Cisco APs, and they expect to add an additional 100 thin APs and one controller.

Tags were found to be a weakness - too expensive, too big, too short a battery life. With the release of third generation tags, most weaknesses are being overcome. Accuracy results: 33% of readings were room-level accurate; 50% of readings were off by one room; 17% were off by 2 or more or the tag was not even seen. This is great for finding IV pumps squirreled away nurses, but of little value for staff and patient tracking applications.

Note that this was a pilot evaluating just one vendor, and not RFID in general. They have decided to deploy the system house-wide for large assets and applications that require no more than 10 meter (30 feet) accuracy. The biggest surprise in the RFID project was with the Cisco wireless LAN. According to Halamka, there are two kinds of Cisco code: "safe harbor" code that is rock solid with basic functionality, and "bleeding edge" code that has all the cool advanced features and is almost completely unreliable. Cisco ended up putting a lot of their resources into kgetting and keeping Beth Israel operation.

Patient-Centric Medical Systems

Julian Goldman, director of the Medical Device Plug and Play lab in CIMIT presented next. With everything that's going on in clinical engineering these days, he does not envy AAMI members, but he does admire them. His talk was titled, "can patient-centric medical systems integration improve safety at the "sharp edge" of health care delivery?" He reviewed CIMIT's Operating Room of the Future (ORF) program, describing the workflow and how devices are integrated to support that workflow.

He talked about systems integration and medical device interoperability to create safety-interlocks and high reliability systems for care. The identification of "exception conditions" across a broad care delivery effort like surgery is perhaps more valuable than automating normal tasks and procedures. After numerous examples of interoperability that exist in our daily lives, he contrasted that with the almost total absence of interoperability in health care. Finally Julian described numerous interoperability projects and experiments - none of which are available commercially. The reason for the absence of these interoperable safety-interlocks was laid at the feet of vendors - and at the same time, Goldman appealed to hospitals to work together to "motivate" vendors to commercialize these kinds of capabilities. Be sure to check out his site for lots more information.

Connectivity Case Study - Kaiser

Bridget Moorman, Clincal Systems Engineer at Kaiser, was up next to talk about her project at Kaiser. They're attempting to integrate medical devices with their Epic EMR on an enterprise scale - a daunting task. Bridget laid out the key requirements medical device connectivity, describing things like, "want[ing] seamless interconnection and data flow from biomedical devices to clinical information systems." The means to effectively manage connectivity deployments was also discussed. She also presented a nice model for considering infrastructure hardening requirements for medical device connectivity.

Bridget next delved into standards: 11073, HL7, DICOM, CANopen, Continua Health Alliance, and XML. She reviewed numerous device vendor solutions (GE, Philips, Welch Allyn, Capsule Technologie, Sensitron, HCTSi iSirona, LiveData, iMetrikus) she has in her lab.

Perhaps the most important topic presented was a description of the "device interoperability" contract language that Kaiser has recently specified in their purchase contracts:

  • Supliers will warrant that their products will interwork or interoperate with KP's Epic systems and with other designated third party products
  • Supplier will finalize any integration with third party products before delivery to kaiser and will do independent testing of the interoperatbility at CIMIT or the Sidney Garfield Center
  • If unsuccessful interoperation, will reimburse Kaiser for product cost
  • Do not specify interface standard due to current volatility in standards definition and development

This is radical stuff that places the systems integration role firmly on the shoulders of the medical device vendor.

After presenting an enterprise connectivity architecture, Bridget offered some great observations about connectivity pitfalls and lessons learned:

  • IT folks frequently don't understand clinical variable context, e.g., temp versus core temp
  • Need for dual systems operation and limited HL7 message availability
  • Limited or no availability of "test" devices - connectivity test systems rather than the actual device
  • The duplication and complexity of interfaces and components to make medical devices with serial ports network-aware - creates problem-identification challenges
  • Brittle interfaces where problems can ripple on either side of the interface when changes occur in either the device, interface system or CIS/EMR
  • Prevalence of proprietary end-to-end solutions from device vendors
  • The paucity of connectivity monitoring and management tools to help identify and fix signal propagation problems (due to limitations in devices and connectivity systems)
  • Very limited interface configuration capabilities - scalability, message modification, number of ports, etc.
  • Insufficient wireless capabilities - health care delivery is inherently mobile, connectivity must be too
  • Establishing and maintaining patient context - older technology associates data to patient using port numbers or bed locations, and not actual patient name and ID

A sample device connectivity architecture was presented, highlighting the complexity and additional steps and vendors necessary to get device data into the EMR. Many device vendors have dragged their feet in adding network connectivity to their devices. The reliance on dongles or warts (modules that connect to the device's serial output and convert data to network connection) is suboptimal, resulting in another unnecessary component to be configured, and maintained - when they get knocked off or banged against the wall or door jam. The best solution is an embedded radio and/or Ethernet port. Many device vendors need to redesign products with more microprocessing horsepower to enable better interfaces.

Bridget described their experience with Nuvon for remote monitoring of the device - connectivity system - EMR chain, including network connections. Kaiser is looking at this to help simplify the connectivity service tree (a sample of which was presented). She closed her presentation reporting that hospitals can expect to pay $10,500 per bed to export device data to HIT systems via HL7. This cost includes hardware, software and biomedical engineering labor costs. Any costs to purchase new medical devices to facilitate connectivity (like new Dynamaps with IrDA capability) is not included.

Medical Device Interoperability

Rich Schrenker, Systems Engineering Manager at Mass General, presented an very thought provoking look at interoperability - what it is and what it can be. After reviewing various interoperability definitions from the IEEE, HIMSS, the MD PnP lab, and the USB Implementers Forum Personal Healthcare Device Class - all different - Rick noted that connectivity remains a largely unsettled market.

In thinking about connectivity, Rick considered systems engineering and creating resilient systems. He noted a challenge in the following quote from S Dekker, Resilience Engineering:

"One marker of resilience... is the distance between operations as management imagines they go on and how they actually go on... Understand the gap between the system-as-imagined and the system as actually operated requires investment not only in understanding how the system really works bu also how it is imagined to work. The latter can sometimes even be more difficult."

And from "To Err Is Human,"

People... become accustomed to design defects and learn to work around them, so often they are not recognized... Accidents are more likely to happen in certain types of systems. When they do occur, they represent failures i the way systems are designed. The primary objective of systems design ought to be to make it difficult for accidents and errors to occur and minimize damage if they do occur."

The point of care is rife with users who are accustomed to bad design - too many rounded corners, too little consideration of the other things clinicians do that is beyond your own device. Sadly, this accommodation becomes requirements and sales objections for newer products that do not include those design defects.

Rick notes a major shortcoming of our health care delivery system: "No substantial perspective on the entire system of health care or training in the use and implications of systems tools and information/communications technologies for managing and improving the system is included in medical education... [and] engineering careers in medical care insitutions are nearly non-existent..."

In a market dominated by proprietary medical devices, Rich suggested open engineering and leveraging commons-based peer production. Like the open source software business model, why can't more providers actively collaborate to encourage vendors to develop better products and evolve widely held best practices.

In considering connectivity and interoperability, Rick wrapped up with the following:

"When health care providers begin leveraging interoperability to construct systems of components in configurations not specifically intended by manufacturers and approved by FDA, they will be engaging in design and integration activities the likes of which are currently under regulatory control. That will be addressed, and ultimately somebody will be doing the necessary point-of-care engineering, whether experienced, familiar, informed by history and safety-conscious, or otherwise."

 

Pictured right is presenter Bridget Moorman with Manny Furst, who presented on Monday.