A 3-Step Approach for Optimal EHR Interoperability

Find out how this effective three-step approach can achieve optimal EHR interoperability.

By Luis Sayago

We are often asked if we can “integrate” our Medical Diagnosis Accuracy Reporting (MDAR) software with a customer’s electronic healthcare record (EHR) system. Our MDAR solution is already capable of ingesting, analyzing and displaying data from the EHR, but at what point can we say we have reached optimal EHR integration or interoperability? 

Technical capabilities aside, we first need to evaluate what the customer’s definition of integration means and then try to split that up into manageable conversation points. There are three main definitions, or integration goals, that we focus on:

Interface 

Interconnecting two separate systems to exchange data, can be one way or bidirectional. For example, sending the treatment summary from a radiation oncology system to the EHR. This can trigger a follow-up process via the patient’s referring physician inbox and facilitate collaboration with the patient’s radiation oncologist to evaluate further treatment options.

Integrate

Ability to launch and gain context from a system to a third-party application. This can be a link in the EHR to launch a picture archiving and communication system (cloud PACS) or enterprise imaging viewer to review a patient’s imaging studies. Launching best of breed applications to visualize clinical data, within the context of the EHR workflow, allows clinicians to quickly interpret information that’s relevant to a patient’s condition.

Embed 

Ability to display and/or visualize third-party application content inside another system. The simplest form can be displaying a patient’s document in the EHR chart view that’s stored in an enterprise content management system. A more complex example could be displaying decision support alerts from a third-party application that tracks opioid prescription abuse based on an EHR user’s medication order action using that same EHR’s notifications widget. With so much information to review in the patient’s chart, providing real-time feedback to clinicians on things like opioid over-utilization or abuse is critical.

As you can see, we can narrow down integration to a smaller subset of capabilities, under the umbrella of interoperability. Not surprisingly, the concept of interoperability in healthcare stems from the same need of bringing all these different goals and capabilities under a single term.

What Does ‘Interoperability’ Mean?

Although the term interoperability was first used in healthcare back in 2005, many of the standards and technology required to make this happen were either in their infancy or non-existent. And, with the Health Information Technology for Economic and Clinical Health (HITECH) Act still far on the horizon, the EHRs that would facilitate the process were still not widely deployed. Today, we have many more tools to achieve interoperability such as HL7 Fast Healthcare Interoperability Resources (FHIR) with the initial Draft Standard for Trial Use version 1 (DSTU 1) released in 2014 and the even newer CDS Hooks specification version 1 (1.0 STU) released this year for card-based clinical decision support feedback. 

With technology and standards maturing, interoperability is possible, but we have to closely consider use cases and how well the EHR is optimized to determine what level of interoperability we want to achieve. Each step towards interoperability builds on the previous one. Without interfacing, you can’t achieve integration. And, to embed an application, you need some form of interfacing and integration. We already gave some examples of each of the interoperability steps, but now consider the following optimal EHR interoperability scenario: 

The EHR sends an HL7 ADT interface message to a third-party system so it knows the patient exists. The third-party application acknowledges and, in return, sends another message via a similar interface with important link information to be displayed in the EHR. At the same time, the third-party application initiates FHIR diagnosis and medication resource requests to the EHR and an external Health Information Exchange (HIE). The EHR user then clicks on the link and an embedded view of the third-party app is displayed on an iFrame. Also, the EHR sends a CDS Hook event to the same third-party application when the user goes into the documentation section of the patient chart, and the third-party application now provides real-time feedback based on the patient data and documentation role of the user via the same EHR’s notification system.

Summary

The above is a great example of the level of interoperability we can achieve today, all made possible using standards and EHRs that implement those standards. At Dacarba, we continue to invest in our MDAR solution by working with our customers on interoperability use cases and development. Our most current example includes working with Rush Medical Center in Chicago to develop a CDI Query/Response HL7 interface.

Luis Sayago is a Manager with Dacarba LLC, a subsidiary of Opportune LLP, specializing in the field of healthcare technical systems architecture. Luis has over 14 years of professional IT, network administration and applications development experience with an extensive background and knowledge in the healthcare industry. He has proven ability to lead seamless implementations, manage complex systems and gather business requirements to deliver next-generational technical solutions. Luis earned his BBA in Computer Information Systems from the University of Texas El Paso and an MS degree in Computer Information Systems from the Florida Institute of Technology. He is also fluent in Spanish.