EMR Interoperability: 3 Things You Need to Know

Want to create a connected medical device that interacts with an electronic medical record? Interoperability is a major challenge. Here are three things you should especially be aware of.

Chris Newmarker

Integration protocols coming out of Oak Brook, IL-based IHE have opened up a new wave of possibilities for medical device designers facing the challenge of getting devices to communicate with the host of electronic medical record systems out there, says Raymond (Ray) Kan, who manages integration of Baxter's infusion pumps with EMRs.

Interoperability has been a major hurdle when it comes to the dream of devices communicating useful patient information to EMRs, making health providers more efficient and improving patient health outcomes in the process. There are still a large number of electronic medical record software providers competing for business, but a standard API (application program interface) does not exist--making it a tough business proposition to design medical devices to feed information into such EMR systems

Overcoming interoperability challenges matters in the infusion pumps space because integration with EMRs could really make a difference, says Kan, group marketing manager at Baxter. It already is, in fact. The most recent versions of Baxter's Sigma Spectrum infusion systems have included autodocumentation, which can greatly increase efficiency by doing away with the need for nurses to manually record everything they do with an infusion pump into an EMR.

"Autodocumentation helps because the infusion pump is sending the data directly into the patient record. It has to be confirmed by the nurse, but it's automatically there," Kan says. "They don't have to write it down or remember it. There's much less risk of misdocumentation. That's a huge benefit. It saves the nurses time. The data is sent to the system immediately. That enables quite a bit of improvement. And the documentation is more likely to be correct and comprehensive.

EMR integration, however, has been a challenge. Around 2009, Baxter engaged in a total custom integration at Intermountain Healthcare in Utah. "That was very time consuming," Kan recalls. And it was for just one health system, albeit one with nearly two dozen hospitals.

Later, the major EMR vendor Cerner came out with its own IBus specifications. "It was considerably better because it applied to all Cerner customers, but not ideal for the industry because it was proprietary and thus excluded other vendors."

The "information profiles" coming out of IHE, however, are much better, Kan says. What the IHE protocols do is list from A to Z all the XML- and HL7-based information fields a particular type of medical device, such as an infusion pump, needs to feed into a health provider's EMR system. It doesn't guide how the communication is done, but it does define what needs to be communicated.

"IHE protocol defines how that gateway, which is receiving the information, will receive that information and communicate it on," Kan says. "There is no need to integrate an API into your system. You just have to be able to receive and send these messages. It's much easier for vendors to support."

The protocols are created through a process that is public, well-defined, and with participation from all of the vendors. Two major EMR software providers, Epic and Cerner, have demonstrated compliance with the IHE profiles for pump integration, and Epic has implemented this in the field.

"It is much, much better," Kan says of the IHE information profiles. "Our hope is that we can transition just toward this one standard. And because it is a standard, if other EMR vendors, other types of systems want to integrate with our systems, we'll be able to use those same standards to do so. It will make our lives much easier."

So if IHE is opening up all kinds of new possibilities, what should medical device designers be especially aware of when it comes to connecting with EMRs? Here are three important things device designers need to consider around interoperability, courtesy of Kan:

1. Being Aware of What Is Going on at IHE

Does IHE already have protocols around the type of device being designed? If they don't, it's a whole new level of work--because you're likely going to have to work with IHE to get integration protocols written that the major EMR software providers are willing to accept.

"They don't have all of the devices. So probably one of the first steps is to make sure whatever device you have, they support the communication with them, they have a profile for them, because otherwise you would have to work with IHE to create a working group to define that protocol," Kan says.

2. The Need to Design Backwards

If there are information profiles available for your type of device at IHE, you need to "design backwards" to make sure your device provides all the specific pieces of information required in the protocols.

Kan offers an example: IHE protocols might require listing volume infused for a secondary infusion, but what if your device in the past didn't send that information. "Maybe all you sent previously was total volume infused. So now you have to change the design of your internal protocol and your system to be able to have this field--volume infused in secondary--and then pass that to the gateway so they can pass it to the EMR."

If medical data communication needs to be near "real time," does the device support it?

"Some devices are not set up to be real-near time devices. That might require a change in design of the system," Kan says.

3. Being Aware of the Doors You Are Opening

When connecting a medical device with an EMR, it is important to recognize the doors to the system you are opening, because they need to be well-protected against hackers, Kan says.

Baxter has a major goal for next-generation Sigma Spectrum infusion systems: autoprogramming that could reduce chances of error even more. But Kan says the company is taking its time on development, especially after older infusion pumps at competitor Hospira proved themselves vulnerable to hacking because of autoprogramming features.

"When you do support autoprogramming, you create a door," Kan says. "You create a door that can be opened because now there are messages to the pump and from the pump that support sending that pump programs. ... It's one of the reasons why we were very pro-autodocumentation but are taking a more cautious approach to get autoprogramming right."

Chris Newmarker is senior editor of Qmed. Follow him on Twitter at @newmarker.

Like what you're reading? Subscribe to our daily e-newsletter.

[Image courtesy of Baxter]