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.
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.
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.
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,
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.
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,
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.
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.
Overview – The Concept Of Remote Patient Monitoring Cost Many healthcare professionals turned to remote…
Examples of Remote Patient Monitoring – Overview What is remote patient monitoring and what are…
Overview Of The Benefits Of AI In Healthcare One of the benefits of AI in…
The Rise of Remote Patient Monitoring Devices In the Modern Era In recent years, remote…
Overview Of The Cost Of AI In Healthcare In particular, after the Covid 19 spread,…
An Overview of Machine Learning in Healthcare and its Potential Doctors and healthcare professionals use…