MD PnP Update

Posted by Tim Gee on Jun 26, 2007 in Patient Safety, Standards & Regulatory | 0 comments

After the break, Julian Goldman provided a brief update on the MD PnP program.

First, Goldman presented ways integrated systems can support safety, using examples from non-healthcare applications. The classic example from Goldman’s stump speech is the automotive brake/automatic transmission interlock, an almost universal interoperable safety feature.

Safety Inter-locks

From aviation, the airplane landing gear smart alarm annunciates when a plane is landing if landing gear is not down. This example demonstrates contextual awareness, an important feature needed for health care safety.

Clinical analogs that would improve safety were presented including:

Heart lung machine and ventilator – switching from bypass and back. Ventilators are sometimes not turned on – simple human error that could be eliminated. Citation: Anesthesiology. 87(4):741-748, October 1997

Blood pressure measurement errors can occur if the invasive blood pressure monitor is not manually zero’d when patient’s height and inclination is changed relative to pole mounted patient monitor. Human error occurs when the clinician forgets to recalibrate the pressure transducer after moving the patient.Citation: Acta Anaesthesiol Scand. 2006 May;50(5):600-3

Given the potential patient safety benefits, and the relative simplicity of these initial potential applications, the goals of MD PnP include:

1. Lead adoption of open standards
2. Define a regulatory pathway
3. Elicit clinical requirements
4. Use a vendor neutral lab to test and verify solutions

APSF Endorsement of Interoperability

Awareness of these potential patient safety improvements is growing. From the Anesthesia Patient Safety Foundation’s (APSF) endorsement of interoperability, March 2007:

“APSF believes that intercommunication and interoperability of devices could lead to important advances in patient safety, and that the standards and protocols to allow such seamless intercommunication should be developed fully with these advances in mind.

APSF also recognizes that as in all technologies for patient safety, interoperability poses safety and medicolegal challenges as well. Development of standards and production of interoperable equipment protocols should strike the proper balance to achieve
maximum patient safety and outcome benefit.”

The APSF has also noted Dangers of Postoperative Opioids – PCA pump related patient deaths and the need to automatically terminate PCA infusions when monitoring indicates.

“We advocate widespread acceptance of the goal that no patient shall be harmed by opioid-induced respiratory depression in the postoperative period.

“Thus, immediately, we urge health care professionals to consider the potential safety value of continuous monitoring of oxygenation (pulse oximetry) and ventilation in patients receiving PCA or neuraxial opioids in the postoperative period.”

APSF has also publish recommendations regarding PCA pumps:

“A particularly attractive feature may be the ability to automatically terminate or reduce PCA (or PCEA) infusions when monitoring technology suggests the presence of opioid-induced respiratory depression. To facilitate such capabilities, we strongly endorse the efforts to develop international standards for device interoperability and device-device communication.

It is critical that any monitoring system be linked to a reliable process to summon a competent health care professional to the patient’s bedside in a timely manner.”

Kaiser Purchase Contract Language

Providers are also beginning to make demands on vendors regarding connectivity and integration. Kaiser is the first to include purchase contract language that places systems integration responsibilities unambiguously upon the vendor:

“Supplier agrees to participate with Kaiser in the development of a medical device plug and play integration standard (the “Integration Standard”), and … will make reasonable efforts to conform to the Integration Standard when approved and formulated by the parties in writing. Until the Integration Standard is approved, Supplier intends to continue … to provide open interfacing protocols …”

Other providers are evaluating Kaiser’s position and are expected to follow suit.

New Standards Development

Clinical requirements lie at the heart of medical device connectivity. The MD PnP program is currently working to collect use cases and requirements relating to interoperability.

The MD PnP program is also developing a new standard, the “Integrated Clinical Environment” of networked medical devices. Focused on risk management, the project does not specify technology. For risk management, they are specifying data logging, data security, integration with the hospital network, and plug-and-play device discovery.

Another area of focus is the IEC 60601-1-10, the requirements for the development of physiologic closed loop controllers (the PCLC standard). This standard will support distributed patient connected devices that control a patient variable. Example applications include a patient warming system that controls body temperature, and the infusion of a medication to maintain blood pressure in a target range.

The PCLC standard will permit distributed PCLCs that involves more than one item of equipment of a medical electrical system. Distributed PCLCs can also be widely separated in distance. An example here would be the control of blood pressure by networking a bedside blood pressure monitor and an infusion pump, and the titration of inspired oxygen concentration of a lung ventilator with a stand-alone pulse oximeter.

Read More

AAMI 2007 – Day One, Clinical Engineering Symposium

Posted by Tim Gee on Jun 16, 2007 in Real Time Location Systems | 2 comments

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.

Read More