The HL7 Interface: The Point-to-Point Interface and Interface Engine

Whenever we talk about healthcare IT marketplace, the term “HL7 interface” always comes to our minds. And, other terms that include point-to-point interface and interface engine are similarly popular.

So, it is very important to learn about these terms in detail. In this guide, we will learn about the HL7 interface, a point-to-point interface, and the interface engine.

However, before ahead with the HL7 interface further, we must know about HL7 as well. Let’s begin with a brief introduction on HL7 for better understanding.

The HL7

HL7 stands for Health Level Seven. An organization of volunteers who define the data specifications for various message types (e.g., ORM, ADT, ORU, etc.) is known as HL7. These specification documents offer the framework in which to communicate patient information between healthcare organizations.

HL7 has various versions 2.x and version 3. Nowadays, the different versions under the HL7 version 2.x family are the most commonly used.

No wonder, HL7 is the most widely used standard to facilitate communication between two or more clinical applications. The basic advantage HL7 offers is that it simplifies the implementation of interfaces and reduces the need for custom interfaces.

It evolved as a flexible healthcare standard with a documented framework for negotiation between applications because of its inception in the late 1980s. Though, this inherent flexibility makes deploying of HL7 interfaces quite challenging at times.

The HL7 Interface

In HL7 Interface, the term “interface” refers to an “interaction,” “communication,” or “interconnection” between the systems. It was essential for healthcare application vendors to offer means within their application for this interaction purpose.

These HL7 interfaces are configured in a way that one system serves as the "demographic master" and preserves all patient information that can flow automatically into another system. This configuration releases the need to key data into multiple systems. Also, by ensuring all work is captured, it eliminates the need for staff to re-enter data into the system and can help prevent data loss of paper.

Besides, the typical interface setup will permit staff to input patient information, make appointments, and then also transfer information to the EHR. Then to document the visit while treating the patient, clinical staff can use the EHR system. Therefore, HL7 interfaces can be well-suited to the task of importing data cleanly into EHRs because EHRs were developed after billing systems.

Moreover, healthcare vendors will use the HL7 interface specifications for the various message types as a starting point. Also, these vendors have exposed an input and/or output interface for their application.

Who Uses an HL7 Interface?

Some of the roles involved with HL7 interfaces are:

Clinical application analysts
Integration specialists
Application programmers
Systems analysts

How Should You Approach an HL7 Interface?

A modest HL7 interface includes several ways to facilitate communication between two healthcare applications:

An export endpoint for the sending application
An import endpoint for the receiving application
The method of moving data between the two endpoints
The method for handling the queuing messages
The method for logging the flow of messages

However, it is believed that each healthcare application must grant access to accept and send patient data and have rules of what it will accept and send. Though, the granted access will be hard-and-fast rules instead of flexible ones which offer easy methods for exchanging data.

And, to ensure data integrity within their application, his access to data is usually tightly controlled by each application vendor. The possible ways to implement an HL7 interface between two or applications are:

1. A point-to-point interfacing approach

2. An interface engine

The Point-to-Point Interface Approach

The interface in which the receiving vendor offers a specification on what data it can receive and in what format it needs to be in is a point-to-point approach.

Afterward, the sending application builds an interface to that specification for that application. It is a one-to-one relationship.

Moreover, a new request and point-to-point interface are developed for each application requiring an interface.

We can say that the point-to-point communications model has each pair of applications which are communicating independently of the other applications in the environment via export and import endpoints.

What are export and import endpoints?

There are export and import endpoints attached to an application that permits it to send as well as receive HL7 messages. Usage of export and import endpoints are:

1. Filter data being sent or received.

2. Match the receiving application’s needs, change the format of data.

3. Write the data into the receiving application’s database.

How many export and import endpoints are required?

Applications that are going to communicate in a point-to-point model must have an export and import endpoint designed specifically to interface with the other application. Based on communication required between the applications, the number of export and import endpoints varies.

Bidirectional communication: Total no. of endpoints needed is 2 (Each application has One export endpoint and one import endpoint). No. of endpoints required for each application is 4.

Unidirectional communication: Total no. of endpoints needed is 2 (Sending application- One export endpoint and Receiving application- One import endpoint). No. of endpoints required for each application is 2.

Replacing or adding interfaces in the point-to-point mode

In a point-to-point interfaced environment, adding, changing, or replacing applications affects the entire system.

So, all the applications interfacing with the updated application, get affected when a changed or updated application is introduced in an interfaced environment. All the endpoints for the updated application must be created or changed to continue communication. Moreover, those software vendors who have interfaces attached to the application must modify or replace their endpoints.

For communication, the software vendor must create interface endpoints for each application when a new application is introduced in an interfaced environment, with which it will communicate. Moreover, for communicating with the new application, each of those software vendors will have to create an interface endpoint.

Replace applications

If an existing application is replaced, then you:

Need to create the export and import endpoints attached to the replaced application.
Need to modify most of the endpoints for applications that the replaced application interface with.

Add applications

Since existing endpoints cannot be used without modification, the cost to add a new application is inordinately expensive. All applications which communicate with the new application must have additional endpoints, in addition to the expense of a new application’s endpoints.

Monitoring interfaces in point-to-point models

There is no centralized monitoring in point-to-point communication models. Due to the lack of centralized monitoring, the following results occur:

1. More money and time needed to monitor the interfaces

2. The absence of meaningful, system-wide information available on time

Advantages of Point-to-Point Approach

A point to point interface is the most cost-effective approach for one or two static, unchanging Interfaces.

Disadvantages of Point-to-Point Approach

1. Through continuous requests to application vendors to build interfaces, costs rise.

2. To determine connection status, no ability to monitor interface.

3. To determine acknowledgment and report on message transaction history, no ability to review message logs.

4. Due to long implementation times and unresolved interface errors, physician confidence in interface credibility erodes.

5. As the number of interfaces grows, interface complexity increases.

Interface Engine Approach

It is an approach that can transform or map the data to the receiving application’s requirements while the message is in transit. Hence, it can be accepted by the receiving application with Interface Engine Approach.

We can say that to simplify the connecting, maintaining, monitoring, and sharing of data between interfaces, an interface engine is designed. It can filter data or change the format of the data to match each application’s needs after taking data from a sending application.

For communicating between applications, this feature greatly reduces the number of individual endpoints required. As a result, it saves on the price of implementing an integrated system.

Adding or replacing new interfaces in an engine model

Since all messages flow through the engine in the interface engine model, therefore the process of adding or changing an interface is simpler than it is in a point-to-point model.

The Process to Replace Applications

For the replaced application, only endpoints that need to be created are the import and export endpoints to and from the new application. Moreover, it insulates the other applications from many of the changes.

The Process to Add Applications

Adding an application does not require as many endpoints to be created with an interface engine. Also, this engine can take the same data which it is already receiving. And, further, send it on to the new application.

Logging with an interface engine

This engine logs connection activity such as all the received and sent messages, errors, connection states, and alerts.

There is no way to tell what happened to a message, without logging or archiving of messages, once it was sent from an application. There is no doubt that communication problems occur from time to time; hence, logging is the only way to determine the root of the problem and correct it.

Advantages of Logging

Here are some of the advantages that the logging of an interface engine provides:

It helps to track the flow of a message in the entire system.
It carries various information about messages. For example, when a message was sent, acknowledged, and received. Even it tells us about what information the message contained.
Easy to troubleshoot communication problems.
Also, it helps to resend messages in case of loss.

Advantages of the Interface Engine Approach

1. To make changes in the format of messages to be sent or received reduces the dependency on multiple vendors.

2. Distributes interfaces to multiple applications productively and also leverages one import or export module from core applications.

3. Improved physician and client support through proactive interfacing monitoring and message log management

4. Using an interface engine enables flexibility to adapt to different HL7 message standards, XML healthcare standards, and many more.

5. By re-purposing an application’s import/export module to multiple applications, it lowers overall interface cost.

Disadvantages of the Interface Engine Approach

The only disadvantage is it adds an application to manage in the IT environment.

What to Choose- A Point-to-Point Approach or Interface Engine Approach?

This could be one of the challenging decisions for each provider: deciding which interfacing approach is the most productive and cost-effective for their organization. The point-to-point approach may work in case the interfacing environment is limited and focused.

Whereas, the interface engine approach will likely provide the most control as well as the most cost-effective results. That's possible if the interfacing requirements are growing internally to streamline workflow and externally to meet physician EMR requirements.

No doubt that there are costs to both approaches. And, it is essential to understand the cost structure of both. An interface needs to be purchased from the application vendor to open up that application in both cases. Though, the below factors can be the determining factor for the best approach:

Is purchasing the application interface once and then use an interface engine to leverage it more cost-effective?

Or to continue to request new interfaces from the application vendor each time a new request comes in is more cost-effective?

However, the advantage of each approach with the weighed costs will lead a provider to make the best choice for their operations.

Conclusion

Hence, this is all about HL7 Interface in detail. Well, we can see that using the HL7 Interface offers more control and saves time and money in a clinical or healthcare environment. Also, it simplifies the implementation of interfaces and reduces the need for custom interfaces.