Last Updated | July 25, 2023
Successful approaches for HL7 integration/implementation involve a deep understanding of healthcare data integration and may require the expertise of healthcare integration services to ensure that data is exchanged accurately and securely between different healthcare systems.
As we talked about the different fundamental aspects related to HL7 in our previous blog. Today we present two approaches through which HL7 Integration/Implementation can be carried out in a hassle-free manner. Let’s have a quick look at two of the most common HL7 integration/implementation approaches.
1) Point-to-Point:
This is perhaps the simplest HL7 integration/implementation approach to ensure secure and unhindered data communication between HL7 interfaces. The point-to-point approach involved the integration of dedicated interfaces, which are purposely built to send and receive data. What makes it an easy and more reliable approach is the presence of dedicated interfaces between two systems/applications, which makes recognition of data formats much easier. However, the downside of this approach is the prerequisite of creating various interfaces and links between systems; which may require additional time and resources.
2) Interface and HL7 Integration Engine
The next common approach for HL7 interface integration is through the HL7 integration engine; which can be seen as a type of middleware with the capacity to connect multiple systems. The integration engine used in this approach comes with the ability to transform data formats as per the standards of different systems, while also coordinating the message workflow.
Not to forget, UX design healthcare is a crucial point to consider because it can optimize the integration engine’s functionality. In addition, a proper UX design eases the data communication and message workflow.
The upside of this approach is that it eliminates the need of creating various interfaces as required in point-to-point interfaces to connect the systems.
Approach-1:
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
- Core health Corepoint
- Orion Health Rhapsody
- NextGen Connect (Mirth Connect)
Out of these lists, Infor Cloverleaf has traditionally been the most widely HL7 interface engine, as it’s used by Epic (among others) which has the lion’s share in the 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 its 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 which would cost $20’000 annually.
Advantages:
- 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
Disadvantages:
- 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
Workflow Diagram
Approach-2:
We can use one of the HL7 APIs (libraries) to implement a service of our own that will connect with the EMR system of each hospital site. This small lightweight service will be installed and run on a local on-premise system and would filter and transmit the required data over to us.
Given Access2Day’s business use case, we are not looking to process and transform a big number of HL7 messages, but rather only a few of the HL7 messages will be required to be processed, parsed, and transformed. Most likely, these messages may include the following HL7 messages, at most,
- ADT – Admit Discharge Transfer
- SIU – Schedule Information Unsolicited
- SRM – Schedule Request Message
- ORU – Observational Report Unsolicited
- ORM – Order Message
- ORU – Unsolicited Result Message
- PV1 – Patient Visit Information
- MDM – Medical Document Management
In the light of this, using a full-blown HL7 engine may seem to be an overkill, because firstly we are not really interested in a large variety of HL7 messages, and secondly, most of the other capabilities that would come with the HL7 engine, are of no use for our requirement.
Therefore, instead of doing that, we thought that another possible option would be to implement a custom background service that utilizes an HL7 API which may be an option that’s worth exploring.
There is one very stable open-source HL7 API available, known as HAPI (https://hapifhir.github.io/hapi-hl7v2). HAPI is backed by a solid well-established community – University Health Network (https://www.uhn.ca) and is actively being developed and maintained, and contains a variant that is for the newer standard – FHIR.
Most interestingly, while I couldn’t find this mentioned officially, lots of forum postings have confirmed that NextGen Connect (Mirth Connect) actually uses HAPI as well and that HAPI is Mirth’s HL7 parser.
Let’s be clear that we are still not going to be implementing the HL7 protocol ourselves, but would use HAPI as the HL7 parser, and build a service on top of that.
Advantages:
- Small lightweight service that can be deployed on any on-premise system for each hospital site.
- Infinitely scalable as this model supports horizontal scaling by design for the HL7 parsing portion
- No cloud server is required at all as the service can post the transformed data directly to the central aggregation server through a RESTful Web Service.
- No VPN is required as the service will run on the local network and the TCP connection between the service and the EMR to receive MLLP traffic (HL7 communication protocol) will not be exposed over the Internet.
- The service will transmit the data over HTTPS that adheres to standards laid down for HIPAA compliance.
- No annual software fees of $20’000
Disadvantages:
- More development time but a trade-off with less configuration effort.
- Custom-built software service not using an out-of-the-box solution
Workflow Diagram
Conclusion
While HL7 interface integration/implementation is technically a complicated task, however, with a well-planned strategy and coordinated workflow it can be achieved successfully. The key to the successful implementation of HL7 lies in excellent coordination amongst the data subject matter specialists and interface teams, as seen in integrated healthcare system examples. The best practice to ensure seamless implementation of HL7 integration at healthcare facilities includes hiring services of professional consultants that bring with them the experience and expertise to minimize the technical hindrances involved in the integration, as well as, build the capacity of the internal team to leverage the full potential of the HL7 integration/implementation.
Want to learn about the HL7 ORU message?
About the Author
