Cameleering
CameleerCameleering / Cameleer / Healthcare / Mirth Connect alternatives
Healthcare integration ยท researched 2026-11-12
Mirth Connect alternatives: the open-source forks, the commercial engines, and interfaces as code
From version 4.6, Mirth Connect is sold only under a commercial, closed-source licence. If your interfaces ran on the open-source edition, you can stay on 4.5.2, buy a licence, move to an open-source fork, move to another commercial engine, or rewrite the interfaces as code. Here is what each option is, with every fact linked to its source.
Cameleer is one of the options on this page, so read it as a vendor's comparison. Each fact about another product is cited to that product's own page or repository, and numbered links go to the sources at the end. Corrections are welcome as a GitHub issue.
What changed with Mirth Connect 4.6
- On 19 March 2025 NextGen Healthcare announced a move from a dual licence (open source and commercial) to a single commercial, proprietary licence, starting with Mirth Connect 4.6 [1].
- NextGen's downloads page says the source code for new releases is no longer public, and that upgrading to 4.6 or later needs a licence. It lists Enterprise, Gold and Platinum tiers, with no prices [2].
- NextGen gave open-source users three choices: stay on their current version, upgrade to 4.5.2 (the last open-source release), or buy a licence and upgrade to 4.6 [1]. The last tagged release in the public repository is 4.5.2, from 23 September 2024 [3].
- There is a free "Mirth Connect for Research" licence for approved research studies affiliated with a non-profit institution [1].
The short answer
| if you want | look at |
|---|---|
| Mirth as it is, with updates and vendor support | Mirth Connect 4.6+ under a NextGen licence [2] |
| Mirth's open-source code base and channel model, still open source | Open Integration Engine (community, Eclipse incubating) [4][5] or BridgeLink (Innovar Healthcare, paid plugins and support available) [6] |
| a commercial interface engine with a vendor behind it | Rhapsody [7], Infor Cloverleaf [8], InterSystems Health Connect [9], Qvera Interface Engine [10] |
| interfaces as code on the JVM | Apache Camel with its HL7, MLLP and FHIR components [11] |
| interfaces as code without a JVM, with HL7, FHIR and DICOM in one small binary | Cameleer with the health pack (Apache-2.0) |
The options side by side
| option | licence | what it is | standards and deployment, as its source states them |
|---|---|---|---|
| Mirth Connect 4.6+ (NextGen) | commercial, closed source from 4.6 [1][2] | the original engine: channels, a desktop administrator, licensed tiers | a licence is required to upgrade past 4.5.2 [2] |
| Open Integration Engine | MPL-2.0 [4][5] | "an open source fork of the now closed-source Mirth Connect", community governed, with vendor neutrality as a stated value; an incubating Eclipse project [4][5] | releases v4.6.0 (9 July 2026) and v4.7.0 (21 October 2026) [4] |
| BridgeLink (Innovar Healthcare) | server MPL-2.0; the WebAdmin is under the Business Source License 1.1 [6] | began as a fork of Mirth Connect 4.5.2, first release March 2025; paid plugins (SSO, MFA, SIEM logging and others), support plans with SLAs, and migration services [6] | Java 17 or later for 26.x; latest release v26.9.0 (1 October 2026) [6] |
| Rhapsody | commercial [7] | healthcare integration engine | HL7 v2, FHIR, CDA, X12/EDI and others; SaaS, your own infrastructure, or iPaaS [7] |
| Infor Cloverleaf | commercial [8] | healthcare integration engine | HL7 v2, FHIR, CDA, X12; cloud, on premises or hybrid with Docker [8] |
| InterSystems Health Connect | commercial [9] | healthcare integration engine | HL7 v2, FHIR, DICOM and IHE profiles; offered as a cloud-first managed service [9] |
| Qvera Interface Engine | commercial [10] | healthcare integration engine, also licensed to software vendors to embed | HL7, FHIR, DICOM (including DIMSE), X12; on premises, in containers or in your cloud [10] |
| Apache Camel | Apache-2.0 | a Java integration framework; interfaces are routes in Java, YAML or XML | camel-hl7, camel-mllp and camel-fhir components [11]; no DICOM component in its component index [12] |
| Cameleer + health pack | Apache-2.0 | Apache Camel's model rewritten in Rust: the same YAML routes, run by one native binary | HL7 v2 over MLLP, FHIR (R4, R4B, R5, DSTU3), DICOM DIMSE and DICOMweb, PS3.15 de-identification; tested against DCMTK, Orthanc, python-hl7 and HAPI FHIR [13]; since 0.6.0 |
iNTERFACEWARE Iguana is often listed as well; its product page could not be fetched on 2026-11-12, so it is left out rather than described from memory.
How to choose
Stay close to Mirth
If your team lives in the Mirth Administrator and has many channels with JavaScript transformers, the least work is to stay on Mirth's code base: a licence for 4.6+, or one of the forks, which both start from the 4.5.2 code [4][6]. Check each fork's notes for how it handles your channels, plugins and Java version before you move.
Move to interfaces as code
If you would rather review interfaces in pull requests, test them in CI and deploy them like any other service, a framework fits better: Apache Camel on the JVM, or Cameleer as one native binary. The cost is a rewrite: there is no channel importer, and Mirth's JavaScript transformers do not run.
From Mirth channels to Cameleer routes
| in Mirth Connect | in Cameleer |
|---|---|
| a channel | a route in a YAML file, kept in Git |
| a TCP listener source with MLLP | from: mllp://0.0.0.0:2575, with automatic AA, AE or AR acknowledgements |
| a destination (HTTP, database, file, another MLLP system) | to: an endpoint: http, sql, file, mllp, fhir, kafka and about 230 others |
| a filter | the filter or choice step with a predicate, such as ${header.CamelMllpEventType} == 'ADT' |
| a JavaScript transformer | steps such as setHeader with hl7terser: PID-3-1, setBody with Simple or jq, and the hl7 and fhirJson data formats |
| code templates shared by channels | route templates and Kamelets |
| queuing and retries on a destination | redelivery policies and a dead letter channel |
| deploying a channel | cameleer validate and cameleer test in CI, then cameleer run or the cameleering/cameleer:health image |
| the message browser | no equivalent; logs, tracing, metrics and the audit log instead |
A tested example: HL7 v2 over MLLP to the EHR, acknowledging after delivery.
Where Cameleer fits, and where it does not
A good fit when
- you want an Apache-2.0 engine whose licence will not change under you;
- you want interfaces reviewed, tested and deployed as code;
- the engine must be small: one native binary, no JVM and no database, for a gateway or a container;
- you need HL7, FHIR and DICOM in one engine, alongside Kafka, databases, cloud services or AI tools.
Not a fit (yet) when
- your team needs a visual channel editor or a message browser;
- you want to import Mirth channels or keep their JavaScript;
- you need cloud healthcare services tested today (Azure, Google, AWS), or Storage Commitment, MPPS and pixel transcoding for DICOM;
- you need throughput figures against Mirth before you choose: none have been measured yet.
Common questions
Is Mirth Connect still open source?
Not from version 4.6. NextGen moved to a single commercial, proprietary licence with 4.6 (announced on 19 March 2025), and the source code for new releases is no longer public. Version 4.5.2 is the last open-source release.
What are the open-source alternatives to Mirth Connect?
Two forks of Mirth's code: Open Integration Engine (MPL-2.0, community governed, an incubating Eclipse project) and BridgeLink (MPL-2.0 server, from Innovar Healthcare, with paid plugins and support available). Outside Mirth's code base, Apache Camel (Java) and Cameleer (Rust, with the health pack) are Apache-2.0 frameworks for interfaces as code.
Can I keep using Mirth Connect 4.5.2?
NextGen listed staying on the current version or upgrading to 4.5.2 as options for open-source users. New releases from 4.6 need a licence.
Which commercial engines replace Mirth Connect?
Rhapsody, Infor Cloverleaf, InterSystems Health Connect and Qvera Interface Engine are healthcare integration engines sold by their vendors; each vendor's page lists HL7 v2 and FHIR, and some list DICOM and X12.
Can Cameleer import Mirth channels?
No. Channels are rewritten as Apache Camel YAML routes: an MLLP listener becomes from: mllp:..., destinations become endpoints, filters and transformers become steps. Mirth's JavaScript transformers do not run.
Sources
Fetched on 2026-11-12 unless noted.
- NextGen Healthcare, "A new era for Mirth Connect by NextGen Healthcare", 19 March 2025: the licence change, the options for open-source users, Mirth Connect for Research.
- NextGen Healthcare, Mirth Connect downloads: closed source from 4.6, a licence to upgrade, Enterprise, Gold and Platinum tiers.
- nextgenhealthcare/connect releases on GitHub: 4.5.2 published on 23 September 2024 is the latest tag.
- OpenIntegrationEngine/engine on GitHub: description, mission and values, MPL-2.0, releases v4.6.0 and v4.7.0.
- Eclipse Foundation, Eclipse Open Integration Engine: state Incubating, MPL-2.0 (proposal: projects.eclipse.org/node/35849).
- Innovar-Healthcare/BridgeLink on GitHub: fork of Mirth Connect 4.5.2, first release March 2025, MPL-2.0 server, Business Source License 1.1 WebAdmin, plugins and support plans, Java 17+, release v26.9.0.
- Rhapsody, Rhapsody Integration Engine: standards and deployment options.
- Infor, Infor Cloverleaf: standards and deployment options.
- InterSystems, InterSystems Health Connect: standards and the managed service.
- Qvera, Qvera Interface Engine: standards, embedding and deployment options.
- apache/camel components on GitHub:
camel-hl7,camel-mllpandcamel-fhir. - Apache Camel, component index: no DICOM component (checked 2026-11-11).
- Cameleer, the health pack and INTEROP: the live tier of 2026-11-11, 10 of 10 against DCMTK 3.6.7, Orthanc 1.12.2, python-hl7 0.4.5 and HAPI FHIR 8.12.0.