Medical Device Interoperability Lags Behind Technological Capacity

Yours truly was quoted in an article in FDC Reports’ newsletter The Gray Sheet (subscription only) last week about connectivity. The story was inspired by a comment from Bill Crounse, the director of Worldwide Health at Microsoft, during the World Healthcare Innovation and Technology Congress held in Washington, D.C., earlier this month. He said, “”I no longer believe that technology is really the issue that prevents us from getting things done. We have the technology … We’ve cracked the code on things like mobility and wireless devices and broadband. The remaining barriers are really all-around barriers to adoption.”

The story provides an overview of connectivity in both acute care and remote monitoring, from both vendor and customer perspectives. The story closes with this observation:

“The medical device companies are becoming chimeras, where they’re part IT company, and they’re part embedded system company,” Gee noted. But, as long as their mindset remains that of an embedded system company trying to protect the “black box” of proprietary system design, it will be difficult to move forward, he said.

Jason Williams expresses a similar lament about the lack of connectivity in a great post on NeoTool’s blog titled, Bridging the Device Divide. In a comment to the post, standards guru Todd Cooper observes:

Bottom line is that medical device vendors make more money with either proprietary connectivity or strategic partnerships, and end users – provider orgs – do not demand open standards-based connectivity. It is often called out in RFPs – but gets dropped in the decision making process. K-P [Kaiser Permanente] is one of the few org’s drawing a line in the sand on PnP med dev connectivity. “Collaborative partnerships” are the status quo and have been the basis of controlling and limiting device connectivity both at the PoC and to the enterprise.

Todd’s referring to Kaiser’s new purchase contract language that specifies medical device vendor responsibilities for supporting connectivity. You can read an except of the contract language in this post. Rumor has it that Philips has recently declined to meet some of those requirements; it will be interesting see if Kaiser sticks to their guns and drops Philips as their patient monitoring vendor going forward.

In Jason’s blog post he quotes Robert Nadler who says, “…our business is building medical devices, not EMR solutions.” I don’t think medical device vendors will have the luxury of maintaining that point of view for much longer. I spoke with David Freeman and Munesh Makhija of GE Healthcare’s patient monitoring group a few weeks ago. They attended the CMEF and saw an exhibit floor filled with vendors who are doing the same color displays with waveforms that GE is doing – at 30% lower cost. Rather than playing the manufacturing cost game, GE is looking to software to add clinical value and differentiate from low price competitors. Philips seems to be taking a similar approach with their acquisitions of Emergin and VisICU.

The days of staying in that nice familiar embedded device comfort zone are limited. This has always been the case as connectivity transforms medical device product categories. Remember E for M? They were once the market leader in cath lab recorders. They too decided they didn’t want to do software. They contrast nicely with Marquette Electronics who saw connectivity as an opportunity and redefined the product category – driving E for M out of business and capturing a major share of the cath lab market. (Another great example of leveraging connectivity is Alaris.)

You can access both Jason’s and Bob’s excellent blogs from the Blog Roll in the right hand column of this web page.

Read More

MD PnP Update


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