- Corepoint Health - https://corepointhealth.com -

What is Your Healthcare Interfacing Method?

What is Your Healthcare Interfacing Method?

What is your healthcare interfacing method?

Gain leverage in your clinical interface environment

Hospitals, imaging centers, laboratories, and clinics are all faced with the demand of providing electronic interfaces at unprecedented rates. The rising demand is due to the operational objective of streamlining workflow and the revenue objective of efficiently establishing productive relationships with referring physicians.

Interfacing applications is an essential ingredient to achieving both objectives. Today, there are two primary approaches to interfacing:

  1. Create point-to-point interfaces with different application vendors to connect to internal applications or providers and their applications
  2. Select an interface engine [7] solution that can broker communication of patient data between various internal applications and providers and their applications

Examples of the types of applications requiring interfaces include Electronic Medical Record (EMR [8]), Hospital Information System (HIS [9]), Radiology Information System (RIS [10]), Laboratory Information System (LIS [11]), Dietary, PACS [12], Emergency Department, transcription, and many others.

Providers requiring interfaces depend on an organized workflow to do their jobs effectively and also depend on delivering accurate, timely results to the referring community. With more and more clinics and physicians at the center of most clinical connection requirements, it is increasingly important to have a foundation on which to easily exchange information.

Determining the most effective approach for healthcare integration [13] has a long term impact on an organization’s physician outreach programs, workflow efficiencies, operational costs, and overall client support.

Healthcare interfacing overview

To facilitate communication between two healthcare applications, a modest interface includes:

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

Illustrated in Figure 1 is a simple, sample interface between two healthcare applications. The gray box represents the export endpoint for the sending application (e.g., EMR, HIS, etc.) and the blue box represents the import endpoint for the receiving application (e.g., LIS, EMR, RIS, etc.).

Sample Interface Between Two Healthcare Applications

HL7 [14] is the most widely used standard to facilitate the communication between two or more clinical applications. The prime benefit of HL7 [15] is that it simplifies the implementation of interfaces and reduces the need for custom interfaces.

Since it’s inception in the late 1980s, HL7 has evolved as a very flexible standard with a documented framework for negotiation between applications. The inherent flexibility defined in the HL7 Standard [16] will make the use of an integration technology solution attractive and, most times, a necessity.

Taking this example a step further, illustrated in Figure 2 is the same interaction between two systems but with the added capability in both applications to import and export data.

Sample Interface with Added Capacity to Import and Export Data

Logic tells us that each healthcare application must grant access to accept and send patient data and have rules of what it will accept and what it will send.

Frequently, the access grant will be hard-and-fast rules rather than flexible ones that provide easy methods for exchanging data. This access to data is usually tightly controlled by each application vendor to ensure data integrity within their application.

Both of these examples are simple: one application exchanging data with another. However, the world of healthcare is not that simple. There are multiple applications and multiple providers in a healthcare organization and community. Each additional application and provider added to the network increases the interfacing complexity exponentially.

The complexity increases due to the hard-and-fast rules about how each application and provider will send and receive data. One “gray box” export interface will not meet the requirements of every application. Similarly, one “blue box” import interface will not meet the requirements of every application.

Interfacing approaches

There are two interfacing approaches for healthcare providers to pursue: point-to-point or interface engine. This section will outline briefly the concept behind each with the advantages and disadvantages highlighted.

Point-to-point approach

A point-to-point interface is one in which the receiving vendor provides a specification on what data it can receive and in what format it needs to be in. The sending application then builds an interface to that specification for that application. It is a one-to-one relationship. For each application requiring an interface, there is a new request and point-to-point interface developed.

Advantages and Disadvantages to a Point-to-point Approach Table

Illustrated in Figure 3 is a point-to-point interface environment.

Diagram of a Point-to-point Interface Environment

Interface engine approach

An interface engine can transform or map the data to the receiving application’s requirements while the message is in transit so that it can be accepted by the receiving application.

Essentially, the import and export module from the sending application is built in a very comprehensive manner, capturing all potential data to be used in one interface. The application interface is built with a one-to-many concept in mind. These import/export modules then are connected to an interface engine so that the mapping, routing, and monitoring are managed by this system.

Advantages and Disadvantages of an Interface Engine Approach Table

Illustrated in Figure 4 is an interface engine environment.

Diagram of an Interface Engine Approach

How does an interface engine leverage your investments?

There are multiple ways in which an interface engine can leverage investments in other applications. Outlined below are several leverage points.

One-payment to application vendors

The sending application (e.g., HIS, RIS, LIS, EMR) needs to be opened up to export and import data. These interfaces can be a one-time fee if they are defined broadly enough so that the interface engine has access to all possible data fields in order to map and transform the data to meet each application’s data specifications.

Independence and control

With an interface engine, new interfaces to applications and providers can be designed and implemented with the provider’s staff. Greater control over interfaces is gained by the providers, decreasing the reliance on application vendors for each and every interface needed.

Shortened cycle time

Implementing interfaces is on the provider’s time schedule, not the vendors. Typically, with an interface engine, interface development and deployment cycle time is shortened from 6–12 months to 1–2 weeks. This gives hospitals, imaging centers, and laboratories a competitive advantage in reaching out to the referring community and delivering quickly to meet their EMR requirements.

Map and route messages for workflow and application requirements

Transformation becomes a key point with an interface engine. Any data format that is sent or received can be transformed into the right format for any application. No modifications are required by each application vendor every time a new data specification is received. Additionally, with an interface engine, business processing rules can be implemented to enhance and streamline workflows within the provider’s organization and with the external referring physician community.

External application and provider integration

Real-world integration takes place between multiple applications in multiple locations. Healthcare interface traffic can be intense so a strong traffic director in the middle is extremely important. The intensity comes from the flexibility defined in how HL7 and other standards are deployed in various healthcare applications.

Ease of monitoring and management

To keep customer support costs low, interface implementations should be easy to monitor and resolution tools for easy fixes should be readily available. This will enable providers to track the uptime of critical interfaces, resolve issues proactively, and quickly fix issues.

The importance of keeping logs of messages sent will become very obvious when a message needs to be re-sent or a history of message exchanges needs to be reviewed. Tools that make searching through the logs easily will be quickly pay for themselves with the growing number of messages and interfaces being implemented.

Flexibility to address varying requirements

Since HL7 is essentially a framework for negotiation, the interface solution must be flexible to deal with HL7 V2.3.1, V2.4, V2.5, etc. and send one message in the differing versions to multiple applications. Part of the flexibility is working with the uniqueness of each application.

Within HL7, Z segments (a method used to hold and transmit clinical patient data the HL7 Standard may not have defined in a particular version) are one way to handle the important data elements that one application may need and another may not. Flexibility is essential.


The number of interfaces will grow over time. With more healthcare providers demanding electronic exchanges of patient data and the growing EMR adoption, an interface solution must be able to grow with the demands of the market.


Each provider should decide which interfacing approach is most productive and cost-effective for their organization. If the interfacing environment is limited and focused, then the point-to-point approach may work. If the interfacing requirements are growing internally to streamline workflow and externally to meet physician EMR requirements, then the interface engine approach will likely provide the most control as well as the most cost-effective results.

There are costs to both approaches, and understanding the cost structure of both is necessary. In both cases, an interface needs to be purchased from the application vendor in order to open up that application. The determining factor for the best approach may be:

  • Is it more cost-effective to purchase the application interface once and use an interface engine to leverage it?
  • Is it more cost-effective to continue to request new interfaces from the application vendor each time a new request comes in?

The costs weighed with the advantage of each approach will lead a provider to making the best choice for their operations.

About Corepoint Health

Corepoint Health solutions deliver interoperability for healthcare organizations and simplify the complexities of healthcare data through practical software applications, consulting and training. Our innovative and proven software solutions leverage clinical data flow efficiently for a diverse group of healthcare entities including hospitals, imaging centers, laboratories, clinics and healthcare vendors. This next generation approach to healthcare data and streamlined workflow is where Corepoint Health specializes in helping customers discover the power of integration.