# HL7 interface engines compared: Mirth Connect, Rhapsody, Iguana, Qvera and cloud options > A vendor-neutral comparison of HL7 interface engines in 2026: Mirth Connect licensing after 4.6 and its open-source forks, Rhapsody, IguanaX, Qvera QIE, InterSystems Health Connect, BizTalk and the Azure, Google and AWS healthcare services, with a selection checklist and migration notes. Author: Ala Ben Aicha Canonical page: https://alabenaicha.me/insights/hl7-interface-engines-compared Updated: 2026-10-06 ## Direct answer An HL7 interface engine receives HL7 v2 traffic (and increasingly FHIR, X12 and DICOM), transforms it, routes it between systems and keeps a durable queue so nothing is lost when a destination goes down. In October 2026 the realistic shortlist is commercial Mirth Connect (proprietary since 4.6), its open-source forks Open Integration Engine and BridgeLink, Rhapsody or Corepoint, IguanaX, Qvera QIE and InterSystems Health Connect. The Azure, Google and AWS healthcare services store and convert data, but none of them terminates and acknowledges an MLLP feed end to end the way an engine does. Choose on team skills, volume, operations tooling and hosting constraints; the feature lists look almost identical. ## What an interface engine actually does Every engine does five things: listen (MLLP over TCP, HTTP, SFTP, database polling), parse, filter and transform, route to one or more destinations, and persist messages with ACK handling and retries. The differences are in how you write transformations, how you promote a change from test to production, and how the engine behaves at 3 a.m. when a lab system stops returning ACKs. For the payloads themselves, [HL7 message types and sample messages](https://alabenaicha.me/insights/hl7-message-types-sample-messages) walks through ADT, ORM/OML, ORU, SIU and MDM. For how a Mirth channel is built internally (source, filters, transformers, destinations, response handling), see [Mirth Connect channel architecture](https://alabenaicha.me/insights/mirth-connect-channel-architecture). Whatever you pick has to parse, acknowledge and survive malformed variants of something like this synthetic admission: ```text MSH|^~\&|ADT_SRC|HOSP_A|ENGINE|HOSP_A|20261006091500||ADT^A01^ADT_A01|MSG00001|P|2.5.1 EVN|A01|20261006091500 PID|1||123456^^^HOSP_A^MR||DOE^JANE^^^^^L||19800101|F PV1|1|I|WARD1^101^A|||||||MED ``` ## Mirth Connect after 4.6 On 19 March 2025, [NextGen Healthcare announced](https://www.nextgen.com/blog/industry-news/a-new-era-for-mirth-connect-by-nextgen-healthcare) that Mirth Connect 4.6 moves from a dual open-source and commercial model to a single commercial, proprietary license. Version 4.5.2, published on GitHub in September 2024 under the Mozilla Public License 2.0, is the last open-source release. NextGen gave open-source users three options: stay on their current version, move to 4.5.2, or buy a license and upgrade to 4.6. The paid tiers named in the announcement are Enterprise, Gold and Platinum, and all of them include Mirth Command Center. The same codebase was also marketed for a period as NextGen Connect, so forum answers and documentation under both names usually apply. Staying on 4.5.2 means no further open-source fixes from NextGen. Security history matters here: [CVE-2023-43208](https://nvd.nist.gov/vuln/detail/CVE-2023-43208), an unauthenticated remote code execution flaw fixed in 4.4.1, was added to the CISA Known Exploited Vulnerabilities catalog in May 2024. An internet-reachable Mirth older than 4.4.1 should be handled as a security incident today. Two forks of 4.5.2 are active: * **Open Integration Engine (OIE)**. A community fork under MPL 2.0, now run as an [Eclipse Foundation project](https://projects.eclipse.org/node/35849). OIE shipped its 4.5.2 release in July 2025 and [4.6.0 on 9 July 2026](https://github.com/OpenIntegrationEngine/engine/releases). OIE 4.6.0 is not NextGen's 4.6; the version numbers collide, so say "OIE 4.6" in tickets and runbooks. * **BridgeLink**. Sponsored by Innovar Healthcare, [BridgeLink](https://github.com/Innovar-Healthcare/BridgeLink) started from Mirth 4.5.2, keeps the core under MPL 2.0 (its WebAdmin module is under the Business Source License 1.1), uses year-based versions (26.9.0 was released on 1 October 2026) and requires Java 17 or later. Innovar sells support plans and add-on plugins. ## The commercial engines ### Rhapsody and Corepoint Both engines belong to Rhapsody. The company [describes itself](https://rhapsody.health/rhapsody-info-for-ai-assistants-and-ai-services/) as formed in 2018 when Hg acquired the Rhapsody business from Orion Health, later adding Corepoint Health; Lyniate is a former name. Rhapsody Integration targets high-volume, multi-standard estates (HL7, FHIR, X12, DICOM) and centres transformation on its Mapper, with JavaScript available where mapping definitions are not enough. Corepoint Integration is the low-code option for in-house teams who would rather configure than script. Rhapsody says its engines have been Best in KLAS since 2009. ### IguanaX (iNTERFACEWARE) iNTERFACEWARE supports two generations, [Iguana 6 and IguanaX](https://www.interfaceware.com/). Both script in Lua 5.1 inside the Translator IDE. In IguanaX every component is Lua code with its own Git repository, and interfaces are promoted between development, test and production through Git and "collections" ([how components use Git](https://interfaceware.atlassian.net/wiki/spaces/IXB/pages/2725609559)). That suits teams that already work with pull requests. The trade-off is a smaller hiring pool for Lua than for JavaScript. ### Qvera QIE QIE scripts in JavaScript, covers HL7, FHIR, DICOM (including DIMSE) and X12, and runs on-premise, in containers or in your own AWS, Azure or Google Cloud account on SQL Server, MySQL or MariaDB. Qvera states that high availability is included in every license. Its [pricing page](https://www.qvera.com/pricing/) lists three commercial models (channel-based, enterprise and OEM) with the full feature set in each. No free edition is listed; a trial is offered. Qvera also advertises conversion of Mirth channels, including their JavaScript, which is worth testing on your own channels before you count on it. ### InterSystems HealthShare Health Connect Health Connect builds interfaces as productions (business services, processes and operations), with a graphical DTL editor for mappings and ObjectScript for custom code. [InterSystems lists](https://www.intersystems.com/resources/healthshare-health-connect/) HL7 v2 and CDA to FHIR transformations, mirroring with automatic failover, and two deployment models: a fully managed cloud service or self-managed on-premises or in a cloud. It fits organisations already running InterSystems products, or estates where durable, long-running orchestration matters more than quick scripting. ### Microsoft BizTalk Server BizTalk Server 2020 is the last version, and Microsoft has published a [lifecycle update](https://techcommunity.microsoft.com/blog/integrationsonazureblog/-/4478559) pointing customers to Azure Logic Apps. Per the [lifecycle page](https://learn.microsoft.com/en-us/lifecycle/products/biztalk-server-2020), mainstream support ends on 11 April 2028 and extended support in April 2030. Do not start new HL7 work on it; plan the exit. ## Cloud services: storage and conversion, not a full engine **Azure Health Data Services** offers managed FHIR and DICOM services. The FHIR service's [`$convert-data` operation](https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/convert-data-overview) converts HL7 v2, C-CDA, JSON and FHIR STU3 into a FHIR R4 batch Bundle using Liquid templates from the open-source FHIR Converter. Microsoft states the default templates are MIT-licensed, unsupported and not intended for production; host your own copy in Azure Container Registry and pin it. Microsoft positions `$convert-data` as one step in an ETL pipeline built on Logic Apps or Data Factory; the service does not listen on MLLP. Also note that [Azure API for FHIR retired on 30 September 2026](https://azure.microsoft.com/updates/azure-api-for-fhir-retirement), so any remaining references to it in architecture documents are out of date. ```json { "resourceType": "Parameters", "parameter": [ { "name": "inputData", "valueString": "MSH|^~\\&|ADT_SRC|HOSP_A|ENGINE|HOSP_A|20261006091500||ADT^A01|MSG00001|P|2.5.1\rPID|1||123456^^^HOSP_A^MR||DOE^JANE||19800101|F\r" }, { "name": "inputDataType", "valueString": "Hl7v2" }, { "name": "templateCollectionReference", "valueString": "myregistry.azurecr.io/hl7v2templates:1.0.0" }, { "name": "rootTemplate", "valueString": "ADT_A01" } ] } ``` **Google Cloud Healthcare API** has a dedicated [HL7v2 store](https://docs.cloud.google.com/healthcare-api/docs/concepts/hl7v2). `messages.ingest` stores a message and returns an HL7 ACK, messages are parsed to JSON, and Pub/Sub notifies subscribers of new messages. An open-source [MLLP adapter](https://github.com/GoogleCloudPlatform/mllp) running on GKE bridges TCP feeds to the API. For HL7 v2 to FHIR, Google's [reference pattern](https://docs.cloud.google.com/healthcare-api/docs/reference-patterns) uses Dataflow and Whistle, and Google flags the published samples as Whistle 1, an unsupported legacy version. **AWS HealthLake** is a FHIR R4 data store. Its [import jobs](https://docs.aws.amazon.com/healthlake/latest/devguide/import-datastore.html) take FHIR R4, and AWS points to partners for converting other formats first. The built-in Data Transformation feature, in preview, covers C-CDA and CSV, not HL7 v2. If your sources are v2, something else must convert them. In practice the cloud pattern is an engine (self-hosted or containerised) that terminates MLLP, returns the ACK and handles retries, then posts FHIR to the managed store. [HL7v2 to FHIR migration strategy](https://alabenaicha.me/insights/hl7v2-to-fhir-migration-strategy) covers the mapping side, and [FHIR servers compared](https://alabenaicha.me/insights/fhir-servers-compared) covers the destination. ## Comparison table | Engine | Licensing (Oct 2026) | Scripting / mapping | FHIR | Deployment | Typical fit | | ------------------------------- | ---------------------------------------------------- | --------------------------------- | ---------------------------------------- | ------------------------------ | -------------------------------------------------- | | **Mirth Connect 4.6+** | Commercial, proprietary (Enterprise, Gold, Platinum) | JavaScript, Java | Via HTTP connectors and scripted mapping | Self-hosted | Existing Mirth shops wanting vendor support | | **Mirth Connect 4.5.2** | MPL 2.0, frozen | JavaScript, Java | Same | Self-hosted | Short-term only, behind strict network controls | | **Open Integration Engine** | MPL 2.0, Eclipse project | JavaScript, Java 17 | Same base as Mirth | Self-hosted, Docker | Teams staying open source with in-house skills | | **BridgeLink** | MPL 2.0 core, paid support | JavaScript, Java 17 | Same base as Mirth | Self-hosted, AWS Marketplace | Open source with a commercial support contract | | **Rhapsody / Corepoint** | Commercial | Mapper plus JavaScript / low-code | Yes | On-prem, hybrid | Large multi-standard estates / lean in-house teams | | **IguanaX** | Commercial | Lua 5.1, Git-native | Via HTTP and Lua components | Self-hosted | Developer-led teams with Git workflows | | **Qvera QIE** | Commercial (channel, enterprise, OEM) | JavaScript | Yes | On-prem, containers, own cloud | Mid-size teams wanting HA in every license | | **InterSystems Health Connect** | Commercial | DTL, ObjectScript | Yes, v2/CDA to FHIR | Managed cloud or self-managed | InterSystems estates, heavy orchestration | | **BizTalk Server 2020** | Commercial, final version | .NET, BizTalk maps | Not built in | Self-hosted | Exit planning only | | **Azure / Google / AWS** | Pay per use | Liquid / Whistle / partners | Native FHIR store | Managed | Destination and conversion, not MLLP routing | ## Selection checklist * **Volume and peaks.** Measure messages per day, peak per minute and the largest message (an ORU carrying a base64 PDF in OBX-5 can be megabytes). Replay your own traffic in a proof of concept instead of trusting vendor throughput figures. * **Team skills.** JavaScript (Mirth family, QIE), Lua (IguanaX), ObjectScript and DTL (InterSystems), mapper or low-code (Rhapsody, Corepoint). Ask who will maintain the interfaces in three years and whether you can hire for that language. * **High availability.** Active/passive or active/active, and what happens to queued and in-flight messages during failover. Ask the vendor to demonstrate it by killing a node during a load test. * **Monitoring and alerting.** Queue depth, ACK latency, error counts, and alerts on silence: no ADT for 15 minutes on a weekday is an incident. Check that metrics and audit logs can reach your existing monitoring and SIEM. * **Version control of channels.** Mirth-family channels export as XML, which is diffable but noisy; IguanaX is Git-native. Define how a change moves from development to production and who approves it. * **EU hosting and regulation.** Message stores hold health data under GDPR Article 9, so set retention and pruning deliberately. A managed engine needs a processor contract, an EU region you can name, and clarity on where support staff access message content from. In France, hosting health data for a third party requires HDS certification; see [HDS health data hosting in France](https://alabenaicha.me/insights/hds-health-data-hosting-france). * **Exit cost.** How you get channels, mappings and historical messages out if you leave. ## Migration notes: moving off Mirth 4.5 open source 1. **Inventory everything.** Channels, code templates, global scripts, the configuration map, alerts, custom JARs, database drivers, certificates and every endpoint with its owner. Take a full configuration backup from the Administrator and commit each channel export to Git. 2. **Pick the path.** License NextGen's 4.6+, move to a fork, or re-platform. A fork keeps your channels close to unchanged; a re-platform means rewriting every transformation, so cost it per channel. 3. **Check fork compatibility.** OIE 4.6.0 requires Java 17, removes the bundled Xerces and xml-apis libraries (code using `org.apache.xerces` must move to `javax.xml.parsers` or SAX), and makes usernames case-insensitive by default. Scan your exports before upgrading: ```bash grep -rl "org.apache.xerces" ./mirth-export/ ``` 4. **Run in parallel.** Replay a representative set of messages through both engines in a controlled environment, normalise volatile fields such as MSH-7 and MSH-10, and diff the outputs. Cut over one interface at a time, starting with low-risk outbound feeds. 5. **Keep history readable.** The old message store is often the only audit trail for past interface disputes. Keep the old engine read-only until your retention period ends, or export what you must keep. Lab and imaging feeds are usually the hardest to move because of result volume and order/result matching; [radiology and lab workflow integration](https://alabenaicha.me/insights/radiology-lab-workflow-integration) covers those flows. If you are weighing these options or planning a move off Mirth 4.5.2, [Mirth Connect consulting](https://alabenaicha.me/services/mirth-connect) covers inventory, fork evaluation and cutover planning.