Different medical systems in clinics and hospitals including; hospital information system (HIS), electronic health record (EHR), radiology information system (RIS), electronic medical record (EMR), and lab information system (LIS) has different communication languages. To further complicate the system, there are ever-increasing numbers of healthcare applications being used across different functions of the healthcare system. This means that a unified and universal inter-communication language for different systems and applications used across all the functions of the medical system is a necessity to ensure efficient, reliable, and quality healthcare solutions.
That’s where HL7 comes into play.
The language was exclusively developed as a universal communication language between medical systems and applications. The language was introduced in the industry back in 1987. In this digital health blog, we will be looking at everything you would want to know about the language including the HL7 software, HL7 integration, and HL7 integration engine.
What is HL7?
As briefly discussed above, HL7 is an exclusive universal medical language that was developed to ensure easy and consistent communication between different applications and systems used across all the functions of the healthcare industry. Today, the entire communication involved in the healthcare industry is being communicated in one or more HL7 messages.
The development of HL7 needs close collaboration between the application catalyst, system analyst, application programmer, and integration specialist.
What does HL7 stand for?
As can be guessed by the name, the HL7 language comprised of 7 different layers of ISO communication model including;
- Physical – this communication layer is responsible to connect the medical facility to the transmission media
- Datalink: the data link layer in HL7 is responsible to manage and minimize errors between adjacent nodes
- Network: the HL7 network layer is responsible for routing the information across the network
- Transport: the transport layer of the HL7 language is responsible for the end-to-end communication control
- Session: The session layer is responsible to manage the non-communication issues
- Presentation: the presentation layer of the HL7 language is responsible to transform the information
- Application: lastly, the application layer of the language is responsible for delivering services to applications
If we broadly categorized the 7 different layers that together make up the HL7 layers, we can say that the layers 1 to 4 are responsible for communication purposes, whereas, layers 5 to 7 are the functional layers. All of these HL7 layers are important to complete the transfer or retrieval of medical communications between different applications and systems.
What is the Objective of HL7?
The core vision behind the development of HL7 was to offer the healthcare industry with a unified and universal language to promote fasters and secure medical data sharing. Now, in order to achieve the goal of data interoperability, it is important to have a logical and simplified workflow to ensure enhanced quality, superior accuracy, and cost-effectiveness for healthcare providers.
What is HL7 Integration?
Today, all healthcare facilities would typically use more several HL7 enables systems and applications. However, to be able to fully leverage the potential of the language and achieve higher efficiency, reduce cost and ensure superior services, healthcare facilities would require an HL7 integration engine that can assist in HL7 integration between all of the systems and applications.
Here, the HL7 integration can be accomplished by one of the two ways:
The Point-to-Point interface HL7 integration is the simplest approach to ensure data communication between different medical systems and applications. In this approach, dedicated interfaces (point-to-point) are built to send and receive data between two systems or applications. Since, there’s a dedicated link/interface between the two systems/applications, the data format used for communication between them is easily recognized. However, the downside or challenge of this approach is a large number of interfaces/links that have to be generated between the systems/applications. For instance, to connect 4 systems with ADT data, 4 different interfaces/links would have to be built.
2. Interface and HL7 Integration Engine
The HL7 integration engine is a sort of middleware that is meant to connect different systems. The HL7 integration engine is able to convert the data formats as per the requirements of different systems, as well as, orchestrates the message workflow. The benefit of this approach is that it removes any need for individual (point-to-point) interfaces between systems. And while the interfaces (from point-to-point approach) and integration engines can be difficult to differentiate, the main point of differentiation is the range of functionalities supported by each.
When it comes to HL7 integration, the primary consideration should be your integration strategy, irrespective of the HL7 version you choose. For instance, you would need to understand your facility needs; whether you want to go with an HL7 integration engine or you would be better off with the point-to-point interface? What are the integration functionalities you would require at your place? It is of utmost important to nail down a strategy detailing the scope of integration.
Who uses the HL7 Integration Software Engine?
At present over 90% of healthcare facilities including hospitals and private clinics in the United States have integrated the HL7. Across the world, there is over 25 HL7 organization working to make it the global standard in the healthcare industry. Now, if we want to categorize the HL7 users, three border segments may include:
1. Clinical Interface Specialists
This segment includes specialists that are required to move clinical data. These specialists are primarily tasked to create tools or applications that enable easy sharing and recognition of data between medical systems/applications. Such users are responsible for the communication of data between healthcare providers and applications/systems.
2. Government or Regulatory Authorities
Such authorities are mainly interested in sharing the healthcare data to multiple entities for compliance or standardization of healthcare services. There are a few legacy systems available at present as well. such users of HL7 are more interested and have the mandate to communicate/channel the healthcare data in between different healthcare entities, which often isn’t covered by existing interfaces.
3. Medical informaticists
Lastly, we have the medical informaticists which are primarily related to healthcare informatics. The healthcare informatics deals with the logic of healthcare, as well as, studying the creation of clinical knowledge. These HL7 users are primarily interested in creating or adapting clinical ontology.
What are the HL7 Integration Challenges?
Variance in the implementation of HL7 standards
One key challenge in the HL7 software integration is the variation in the implementation of the HL7 standards, which leads to increase time and cost required for the integration. In simple words, the variance in the implementation of standards means programmers/system analysts are required to maintain multiple code base and integration points. Also, the variation in implementation standards means more dedicated resources are required for integration development; leaving with fewer resources for other work processes. To even add to the agony, replacement, or addition of interfaces influences all the related applications; subsequently impacting the entire communication network.
Unreliable HL7 data semantics may lead to misinterpretation
The complexity of today’s healthcare industry means that it is crucial for healthcare applications to identify and understand the data values and their real meaning. To avoid any misinterpretations due to data semantics, the HL7 must integrate/integration engine to communicate their interpretation of the standards being used. To give you an example, the HL7 interface needs to interpret if “NA” means “Not Applicable” or “No Allergies”. Similarly, the value “3” may interpret the patient as “Smoker” or “Former Smoker” in different systems. There can be hundreds and thousands of such cases, which all leads to the importance of communicating the right interpretation for data semantics because this interpretation will eventually lead to the quality of the data, as well as, may have dire consequences for healthcare delivery to patients. And at a time when the healthcare industry is increasingly becoming regional with various patients’ touchpoints, HL7 integrations must offer accurate and comprehensive data interpretation.
Unplanned EHR migration may lead to legacy data loss
There is always a certain degree of challenge and risk involved during the migration of EHR for healthcare institutes. To avoid any loss of data, many healthcare facilities decide to go with multiple EHRs, which require doctors, physicians, and other related staff to maintain login details for multiple platforms. In the worst cases, the healthcare facilities may require medical and paramedic staff to maintain paper records. Alternatively, some institutes may decide to transfer the data into a new system. However, unplanned data migration may lead to loss of legacy data. Before the data migration, healthcare institutes must prioritize the data (which is the most important and which should be migrated at the first stage). Generally, the basic essential medical data including allergies, medications, and others should be the data of choice for initial migration. Another complicacy in this regard arises due to the incompatibility of the data or errors after the conversion of data into other formats.
We can use a commercially available HL7 interface engine hosted in the cloud (let’s say AWS) that connects with the EMR system of each hospital site
Among the most widely used HL7 interface engines include,
- Infor Cloverleaf
- Healthshare Ensemble
- Corehealth Corepoint
- Orion Health Rhapsody
- NextGen Connect (Mirth Connect)
Out of these list, Infor Cloverleaf has tradtionally been the most widely HL7 interface engine, as it’s used by Epic (among others) that has the lion’s share in US healthcare industry. Using Cloverleaf for long-term stability, reliability and scalability may be the best option, but it apparently uses a per-interface pricing model and is way too expensive.
NextGen Connect is the only open source variant available, although their advanced plug-ins and technical support require a commercial license. Using NextGen Connect may require us to use one or more of their plug-ins to speed up our development that would cost $20’000 annually.
- Out of the box HL7 interface engine. Add filtering and transforming capabilities for a “channel” for a connection with each EMR system
- Configure posting REST messages directly from the system to the central aggregation server running a RESTful Web Service.
- Less development time on this front, although making sense of the transformed data will need to be configured
- Less development time but a trade-off with more configuration effort
- Too much system resource consumption, that would require a heavy duty cloud server for a few hundred connections
- Deployment nightmares as many clinics/hospitals are wary of interfacing with another HL7 system over the Internet
- VPN may be required between our system and the EMR to receive MLLP traffic (HL7 communication protocol) securely over TCP for HIPPA compliance
- It may cost $20’000 annually