5 HL7 Integration Challenges (and How to Solve Them)

Understanding HL7 Interfaces

HL7 interface specifications include data specifications for various messaging types, such as ADT, ORM, or ORU (among others). An HL7 interface consists of a few key components:

• An export endpoint (for the application sending the message)
• An import endpoint (for the application receiving the message)
• A data transfer method (for moving data between the two endpoints)

There are a few concerns with HL7 interfaces that make this setup far more problematic than it appears on the surface. First, the sending and receiving modules are created by software vendors during the application development process. Because HL7 allows for extensive customization, applications often use different HL7 formats. In fact, there are many variances and adaptations of HL7 interface standards, so there is no single standard for how these systems are implemented or how the data is handled. And that means that in order for applications to send and receive data they can understand, translation and data mapping is necessary.

There are a few options for addressing these concerns:

• Modifying the sending and receiving modules
• Using an interface engine to translate the messages
• Implementing an API solution

Let’s take a closer look at HL7 integration challenges and how to overcome them.

HL7 Integration Challenges

1. Integration is essential for an application to be viable.

Clinicians won’t leave the EHR platform, login to an unrelated system, and duplicate data that’s already in the EHR. It’s simply not practical or efficient, and clinicians are already under pressure to do more in less time. It doesn’t matter how useful the application may be, if it requires them to duplicate their efforts, they simply won’t use it if it doesn’t fit into their workflow. So, applications must be readily accessible to clinicians and eliminate the need for data duplication. They should also have closed-loop integration, with data being both pulled from and fed into the EHR. IT teams typically have significant backlogs, meaning organizations could be waiting months (or years) for IT to build the necessary interfaces for these integrations.

2. There’s significant variance in how vendors implement HL7 standards.

The substantial variance in HL7 implementation slows cycles and makes integration both time-consuming and costly. Essentially, it requires maintaining a different code base and integration points for each EHR. Plus, it requires significant resources dedicated to integration development, meaning fewer resources are available for other needs, such as improvements to features and functionality. What’s more, replacing or adding interfaces impacts every application that interfaces with the updated app – potentially impacting the entire system. Every endpoint for the updated app must be either created or changed to facilitate communication, and every software vendor with interfaces attached to the app must replace or modify their endpoints, as well.

3. Better integration is needed to create better apps.

A lack of centralized monitoring means more time and money must be dedicated to monitoring. Problems may go unnoticed until they’ve become a full-blown crisis, and even then, it’s difficult to pinpoint the source of the problem. There’s a lack of meaningful, system-wide information available in a timely manner, so there’s no effective way to gauge the overall stress on a system. In turn, that makes it difficult to estimate resource needs such as server size, network communications, and support staff. More real-time data and read-write capabilities are desperately needed.

4. Poor HL7 data semantics leaves the door open to misinterpretation.

In today’s complex healthcare landscape, it’s imperative that applications not only understand the data values, but what those values actually mean. To avoid misinterpretation, HL7 interfaces must communicate their interpretation of the HL7 interface standard being used. For instance, does a value of “NA” mean “No Allergies” or “Not Applicable”? A value of “3” may indicate that a patient is a current smoker in one system, but in another, that same value could mean that the patient is a former smoker or has never smoked at all. These misinterpretations, and the overall quality of data, have serious implications for patient care delivery. As today’s healthcare systems are increasingly regional, with multiple patient touchpoints, proper data interpretation is even more critical.

5. Migrating to a new EHR may result in a loss of legacy data.

Migrating to a new EHR poses a challenge for healthcare organizations, as well. Some healthcare organizations simply opt to maintain multiple EHRs, requiring clinicians to login to multiple platforms, or worse, request paper records. Others decide to move existing data over to the new system. However, they must prioritize data for migration. (What data is most important? What data should be moved first?) The basic essentials, such as medications, allergies, and diagnoses, are typically prioritized for transfer, meaning that other data, such as older lab results, images, and other data may be left behind. Plus, it might not be possible to convert certain types of data (such as images), or there may be errors in data after conversion. In general, migration incurs substantial resource and technology costs, and migration timelines are often lengthy.

How to Solve HL7 Integration Challenges

Interface engines are a common HL7 integration solution, but they fall short of overcoming these challenges and meeting interoperability goals. With interface engines, PHI must be stored in a second database, which introduces unnecessary security risks – particularly important in the modern era of data privacy and accountability. Code must be written repeatedly, and implementation overall is slow. They’re also not EHR-agnostic, and they don’t provide the real-time data access that’s so essential for healthcare providers today.

Fortunately, software vendors and healthcare providers can overcome these challenges with the use of APIs. Integrate allows the exchange of health information across any EHR platform without compromising the security of PHI. It supports the seamless exchange of information between EHRs, clinical, and administrative applications and provides real-time access to clinical and administrative data. That means real-time access to patient records across providers and streamlined billing, which translates to reduced costs thanks to reduced demand on staff time.

Integrate features a robust set of REST APIs that read and write to EHRs through EHR vendor-supported software modules, standardizing EHR integration through universal, real-time APIs and a unified data model, plus tools to aid in monitoring and managing the environment. The API manages the interface, so there’s no need to wait in the integration project queue, shortening integration time from months to mere hours. Of course, all of these benefits mean nothing if usability is poor. With Integrate, you’ll get a superior user experience, so you’ll never have to worry about users abandoning your platform.

The road to HL7 integration has many obstacles, but API solutions like Integrate put true interoperability within reach for software vendors and healthcare organizations.