Comparisons

When you are integrating HL7v2, there are three categories of tools to choose from:

• Interface engines are standalone applications for HL7v2 that you can install on your own servers or host in the cloud. InterSystems IRIS (opens in a new tab), Mirth Connect / NextGen Connect (opens in a new tab), Rhapsody (opens in a new tab), Iguana (opens in a new tab), Cloverleaf (opens in a new tab) are among the most widely used in the industry. They typically provide a graphical UI for building interfaces, with built-in support for managing and operating HL7v2 endpoints. They are often used in hospital integration layers, where the team has limited engineering capacity and many interfaces to manage.
• Cloud HL7v2 services are managed offerings like Google Cloud Healthcare API (opens in a new tab) and Azure Health Data Services (opens in a new tab). They ingest HL7v2 over MLLP at a managed endpoint and deliver the messages — parsed, optionally translated to FHIR — into a cloud destination.
• Language-native libraries are code libraries that you use to develop your own HL7v2 applications and services. HAPI HL7 (opens in a new tab) (Java), nHAPI (opens in a new tab) (.NET), python-hl7 (opens in a new tab), node-hl7-complete (opens in a new tab), and Glion are libraries built to support developing HL7v2 applications. They are often used by teams building a product that requires HL7v2 support — a clinical SaaS that ingests ADT, a billing system that consumes ORM, etc. — and that want to build and operate their own HL7v2 endpoints as part of that product.

Versus interface engines

Interface engines like Mirth Connect (opens in a new tab) (now NextGen Connect) and its commercial siblings are standalone solutions that run as the integration layer of a hospital. They are installed as software on a server and usually configured through a graphical UI. They are designed to manage many interfaces at once, with features for monitoring, logging, message replay, and visual mapping. They are a good fit for teams with existing operational expertise in these engines, many interfaces to manage, and limited engineering capacity.

An organization building a software product that contains one or more HL7v2 endpoints — a clinical SaaS that ingests ADT, a billing system that consumes ORM — is not well-served by an interface engine and usually chooses to build its own HL7v2 services using a language-native library. This approach allows the team to use the same code review, deployment, and monitoring tools for the integration layer as for the rest of the product.

Glion provides the application framework for building HL7v2 services using the language-native library approach. It is not a managed solution, and it does not provide a graphical UI for building interfaces. Instead, it provides the pieces to build those things in whatever way makes sense for your team. If you want to build a custom UI for managing your HL7v2 endpoints, Glion's plugin system allows you to do that. If you want to integrate with your existing monitoring and logging tools, Glion's design allows you to do that as well.

Versus HAPI HL7 and nHAPI

HAPI HL7 (opens in a new tab) is the most-used HL7v2 library; nHAPI is its .NET port. Both are mature, comprehensive, and conformant. Either is the right answer for a JVM or .NET application that needs HL7v2 support without a particular pipeline shape.

HAPI tends to be stronger:

• HAPI has decades of accumulated profile data, community plugins, and real-world testing in every corner of the standard. Glion is newer and has fewer profiles and plugins, though it is growing.

Glion tends to be stronger:

• TypeScript-native types and ergonomics for a TypeScript or Node project, without bridging through a JVM.
• A pipeline model — unified — that composes plugins rather than subclassing parser objects.

In most scenarios, the choice between HAPI and Glion tends to be driven by the team's existing expertise and the language of the rest of the application. A Java team building an integration product uses HAPI. A TypeScript team building an integration product uses Glion.

Versus other Node libraries

Several HL7v2 packages exist on npm, such as node-hl7-complete (opens in a new tab), hl7v2 (opens in a new tab), simple-hl7 (opens in a new tab), and mllp-node (opens in a new tab).

Most of those libraries are either unmaintained or only provide a subset of the features needed to build a complete HL7v2 application. For instance, some libraries only provide parsing and serialization, without support for MLLP or validation. Others may provide an MLLP server but lack a plugin system for customization.

Glion is an application framework for HL7v2 in TypeScript. It provides a parser, an MLLP server, a validation engine, and a plugin system in one TypeScript-native package.

Where Glion does not fit

A team that wants a managed application. Glion is not a SaaS that handles the entire HL7v2 lifecycle — ingestion, parsing, validation, monitoring, alerting — for you. It is a library you build your own application with. Teams that prefer not to operate the integration layer should look at the cloud HL7v2 services or a hosted interface engine.

A team that needs FHIR, not HL7v2. Glion does not support FHIR (yet) — it is focused on HL7v2. A team that needs FHIR support today should look at a library or service that provides that.

Trade-offs of choosing Glion

The library is younger than HAPI. There will be HL7v2 corners — older versions, obscure segments, partner-specific quirks — where Glion does not yet ship a profile or a plugin, and a HAPI deployment would. The plugin system lets teams build their own plugins for those corners and share them with the community. The ecosystem is growing, and the core framework is designed to make it easy to add new features and optimizations over time.