HL7 and its members provide a framework for electronic health information interchange, integration, sharing, and retrieval. These guidelines specify how information is packed and conveyed from one party to another, as well as the language, structure, and data types that are required for seamless system integration. HL7 standards are the most widely utilized in the world and support clinical practice, as well as the management, delivery, and evaluation of health care. Today, we’ll show you two methods for doing HL7 Integration/Implementation quickly and painlessly. The most popular and known HL7 integration and implementation methods are explained below.

1) Point-to-Point communication:

This is perhaps the most straightforward HL7 integration/implementation method for ensuring secure and uninterrupted data transfer between HL7 interfaces. The integration of dedicated interfaces, which are purpose-built to send and receive data, was required for the point-to-point approach. The inclusion of defined interfaces between two systems/applications, which makes data format recognition considerably easier, makes it a simple and dependable technique. The disadvantage of this strategy is that it requires additional time and resources due to the creation of multiple interfaces and links across systems,

2) HL7 Integration Engine and Interface

The HL7 integration engine, which can be thought of as a form of middleware with the ability to connect numerous systems, is the next prevalent method for HL7 interface integration. The integration engine employed in this approach can change data formats according to different systems’ standards while also managing message workflow. The advantage of this strategy is that it eliminates the need to create multiple interfaces to connect the systems, as is required in point-to-point connections.

Approach 1: We can connect each hospital site’s EMR system with a commercially available HL7 interface engine located in the cloud.

The following are some of the most often utilised HL7 interface engines:

  • Cloverleaf
  • Corepoint
  • Rhapsody
  • NextGen Connect (Mirth Connect)

Out of these, Cloverleaf has long been the most commonly utilised HL7 interface engine, as it is used by Epic (among others), which controls the majority of the US healthcare market. Cloverleaf may be the greatest solution for long-term stability, durability, and scalability, however, it appears to use a per-interface price scheme and is far too expensive.

The advantage of this strategy is that it eliminates the need to create multiple interfaces to connect the systems, as is required in point-to-point connections. The only open-source option is NextGen Connect (Mirth Interface Engine), albeit sophisticated plug-ins and technical assistance require a paid licence. Using NextGen Connect (Mirth Interface Engine) might necessitate us using one or more of their plug-ins to speed up our development, which would cost us $20’000 per year.

Advantages:

  • HL7 interface engine that works right out of the box. Add filtering and transformation features to a “channel” for each EMR system connection.
  • Configure the system to send REST messages straight to the central aggregation server, which is a RESTful Web Service.
  • On this front, there will be less development time, albeit making sense of the altered data will require configuration.

Disadvantages:

  • Less development time, but more configuration effort as a trade-off
  • Too much system resource consumption; a heavy-duty cloud server for a few hundred connections would be required.
  • Many clinics/hospitals are wary about interacting with another HL7 system over the Internet, causing deployment difficulties.
  • To receive MLLP traffic (HL7 communication protocol) securely over TCP for HIPPA compliance, a VPN between our system and the EMR may be required.
  • It might cost up to $20,000 per year.

Approach #2: We can utilise one of the HL7 APIs (libraries) to create a custom service that connects to each hospital’s EMR system. This small, lightweight service will be deployed and run on a local on-premise system, filtering and transmitting the necessary data to us.

We are not looking to process and transform a large number of HL7 messages because of Access2Day’s commercial use case; rather, just a few HL7 messages will be required to be processed, parsed, and changed. The following HL7 messages are most likely to be included in these messages:

  • 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 light of this, a full-fledged HL7 engine may appear to be overkill, because we aren’t really interested in a broad variety of HL7 messages, and most of the additional capabilities that come with the HL7 engine are irrelevant to our needs.

Rather than doing so, we believed that implementing a custom background service that uses an HL7 API could be an alternative worth considering. HAPI (https://hapifhir.github.io/hapi-hl7v2) is one of the most stable open-source HL7 APIs accessible. HAPI is supported by an established community: University Health Network (https://www.uhn.ca)– and is regularly developed and maintained. It also includes a variation for the newer FHIR standard.

While we couldn’t locate any official confirmation, many forum postings have indicated that NextGen Connect (Mirth Connect) uses HAPI as well and that HAPI is Mirth’s HL7 parser.

Advantages:

  • For each hospital site, a small light-weight service that may be deployed on any on-premise system.
  • This approach allows horizontal scaling by design for the HL7 parsing phase, making it infinitely scalable.
  • The service can post the changed data directly to the central aggregation server using a RESTful Web Service, therefore no cloud server is necessary.
  • There will be no need for a VPN because the service will function on the local network and the TCP connection between the service and the EMR for receiving MLLP traffic (HL7 communication protocol) will not be accessible to the Internet.
  • The data will be transmitted over HTTPS, which complies with HIPAA compliance guidelines.
  • There are no $20’000 annual software fees.

Disadvantages:

  • More development time, but less configuration effort as a trade-off.
  • A custom-built software service that does not rely on a pre-packaged solution

Conclusion

While HL7 interface integration/implementation is a technically difficult operation, it can be accomplished effectively with a well-planned strategy and coordinated workflow. The key to the integration/implementation of HL7 is successful is a great collaboration between data issues and interface teams. Hiring Healthcare IT consultants with the experience and expertise to minimize the technical hurdles involved in the integration, as well as building the capacity of the internal team to leverage the full potential of the HL7 integration/implementation, is the best practice for ensuring seamless implementation of HL7 integration at healthcare facilities.

Facebook Comments