For integration teams still running Mirth Connect 4.5.2 or older. This guide lays out the five realistic routes after NextGen closed the source, what each one costs in security exposure and rework, and how we move your channels to the route you pick.
On March 19, 2025, NextGen Healthcare announced that Mirth Connect 4.6 would ship under a single commercial, proprietary license, ending the old dual model. Version 4.5.2, tagged on GitHub in September 2024 under the Mozilla Public License 2.0, is the last open-source release, and source for 4.6 onward is not published.
NextGen offered open-source users three choices: stay where they are, move to 4.5.2, or buy a license and upgrade.
Attackers do target Mirth servers. CVE-2023-43208, an unauthenticated remote code execution flaw in releases before 4.4.1, scored 9.8 and entered CISA's Known Exploited Vulnerabilities catalog on May 20, 2024.
On September 10, 2026, CISA advisory ICSMA-26-253-01 listed three further high-severity flaws in Mirth Connect 4.7.1 and earlier: SQL injection through the Database Connector API and two XML external entity issues. NextGen's fix is 4.7.2, a licensed build. Release 4.5.2 falls inside that range, and no open-source patch for it will come from NextGen.
None of this forces you to sign the first license quote. It does mean the decision needs an owner and a date. Our Mirth Connect support engineers begin with an inventory of what your channels really do, because the right alternative follows from that, not from a feature grid.
Each of these routes is in use today, and a larger estate can combine two while its channels move in phases.
MPL 2.0 lets you keep running, and even modifying, 4.5.2 indefinitely. What you lose is upstream fixes. Treat it as a fixed-term plan: put the administrator port and REST API on a management network, keep Java and the operating system patched, watch the logs, and set the exit date now.
Channels upgrade with the least rework and you receive NextGen's fixes, such as the 4.7.2 release named by CISA. In exchange you pay an annual fee for each production server. Our Mirth Connect license cost guide covers the tiers and the one public price.
Open Integration Engine (OIE) forked 4.5.2 in March 2025, passed its Eclipse Foundation creation review in July 2026, and is now an incubating Eclipse project. Its 4.7.0 release of October 21, 2026 closes SQL injection and XXE issues in the same components CISA flagged. BridgeLink, maintained by Innovar Healthcare, is a second MPL 2.0 fork on its own release line.
Rhapsody runs a Migration Fast Track program aimed at Mirth users. Qvera QIE can import a Mirth channel export, translate its JavaScript and report what did not convert. Iguana scripts in Lua, so transformers are rewritten. InterSystems Health Connect is sold as a fully managed cloud service or self-managed, and Infor Cloverleaf runs in the cloud, on premises or hybrid.
AWS HealthLake, the Azure Health Data Services FHIR service and Google Cloud Healthcare API store and serve FHIR data, and Google's HL7v2 store ingests feeds through an MLLP adapter. They suit new API and analytics work but do not run your filters and routing. Microsoft deprecated the older Azure API for FHIR on September 30, 2026.
| Aspect | Open Integration Engine | Mirth Connect 4.6+ (licensed) |
|---|---|---|
| License | MPL 2.0, source on GitHub | Proprietary; billed yearly for each production server |
| Who steers it | Community maintainers under Eclipse Foundation incubation | NextGen Healthcare and its authorized resellers |
| September 2026 CISA flaws | 4.7.0 notes close matching SQL injection and XXE issues | Fixed in 4.7.2 and later |
| Extensions | Free third-party plugins from the community | Bundled by tier, not sold one by one |
| Runtime | Java 17 minimum since OIE 4.6.0 | Per NextGen's upgrade notes for your target release |
| Support | Optional, bought from independent firms | Included, with 24x7 phone support on Gold and Platinum |
| Main cost | Engineering and any support contract | License fee plus engineering |
Version numbers do not line up between the two. OIE 4.6.0 and 4.7.0 are the fork's own releases, not rebuilds of NextGen's 4.6 and 4.7, so compare release notes rather than labels.
The method holds whichever engine you choose. Only the rework in step two changes.
We export every channel, code template library, global script and alert, then build a register of connectors, listening ports, senders, receivers, volumes and owners. Disabled or orphaned channels are marked for retirement rather than migration.
Filters and transformers are read line by line. We list custom Java libraries, direct Xerces imports (OIE 4.6.0 dropped Xerces), shared templates and global map use. For Qvera this feeds the converter report; for Iguana it becomes a Lua rewrite plan.
For each Database Reader and Writer we record the JDBC driver, SQL, stored procedures and polling interval, move credentials into a secrets store, and confirm write-backs stay idempotent if a message is replayed.
A sample of production traffic, de-identified where the test environment requires it, runs through old and new channels side by side. Outputs and ACK codes are diffed field by field, and every difference is explained before sign-off.
The new engine receives live copies of traffic while the old one stays authoritative. Queue depth, error counts and downstream acknowledgments are compared until each receiving system's owner accepts them.
Senders are repointed in an agreed order, lowest clinical risk first. The old channel stays deployed but stopped, with a tested route back, until hypercare ends.
Where the waiting happens: rarely inside the engine. Firewall changes, sender reconfiguration by EHR or lab vendors, and their test windows take longest, so the inventory lists those requests early.
Data-flow diagrams, transformation summaries and a risk register for inherited or undocumented Mirth estates, so the engine decision rests on evidence.
Network restrictions, TLS, credential protection, OS and Java patching, audit logging and backup checks while the exit is planned, ideally confirmed by a penetration test of the integration server.
We work across Mirth Connect, BridgeLink and Open Integration Engine, and move channels with the replay and parallel-run method above.
If you buy from NextGen, we run compatibility testing, Java updates, backups and rollback planning for the jump from 4.5.2.
Moving to a different commercial engine? We hand over the inventory, mapping specifications and replay test sets your new platform team builds against.
Queue, error-rate and certificate-expiry monitoring, with coverage from business hours to 24/7. A BAA is available when the support work involves PHI.
Sometimes the engine is not the real problem. Our healthcare interoperability consultants can review the wider design, including point-to-point feeds that should be retired, and our HL7 and FHIR integration team builds the FHIR layer if you add one.
Our healthcare integration team writes and maintains HL7 v2 and FHIR interfaces, so our advice reflects how migrations actually fail.
One solution architect owns the inventory and cutover plan from first export to final sign-off.
A new Mirth advisory is a security matter, and those get a same-day response; other enquiries are answered inside one business day.
Founded in 2008, Xcodefix Global is a brand of Xcodefix Inc (Delaware). Our delivery teams sit in Coimbatore and Chennai, and we have shipped 250+ projects in 10+ countries.
Send a channel export, or just a count of channels and connector types. We will return the route we would take for your estate, the risks we see in it, and the outside dependencies to start requesting now.
Prefer email? info@xcodefixglobal.com
Talk to the specialist who would scope the work — not a call-centre script.
Ask us directlyOnly up to version 4.5.2. NextGen moved Mirth Connect to a single commercial license from version 4.6, announced on March 19, 2025. Older releases remain under the Mozilla Public License 2.0, so running them costs nothing in license fees. Newer releases, including the security fixes in 4.7.2, require a paid license from NextGen or an authorized reseller.
Two actively maintained open-source forks are Open Integration Engine, now an incubating Eclipse Foundation project, and BridgeLink from Innovar Healthcare. Both use MPL 2.0 and keep Mirth's channel model, so channels carry over with little rework. Test custom Java code and any direct Xerces imports before cutover, because the forks have changed some dependencies.
Open Integration Engine is a community fork of Mirth Connect, started in March 2025 from the last open-source release. It is licensed under MPL 2.0, became an incubating Eclipse Foundation project in July 2026, and shipped version 4.7.0 on October 21, 2026. The project states that it is compatible with Mirth Connect, and several independent firms sell support for it.
Legally, yes, because the open-source license does not expire. The concern is security. CISA's September 2026 advisory covers Mirth Connect 4.7.1 and earlier, which includes 4.5.2, and NextGen ships fixes only in licensed builds. If you stay for now, isolate the admin interface, patch Java and the OS, monitor the server, and fix a date to move.
BridgeLink is Innovar Healthcare's fork of Mirth Connect, published on GitHub under MPL 2.0, so the source is free to use. Innovar also sells hourly-billed images and support plans for it on AWS Marketplace. It follows its own version scheme, such as 26.9.0, so map features through its release notes rather than Mirth version numbers.
That depends on channel count, in-house skills and who you want accountable for patches. For a large estate with heavy JavaScript, a fork or a Mirth license usually means the least rework, because channels move almost unchanged. Teams that want one vendor for engine, hosting and support often shortlist commercial engines. We recommend a route after the inventory, not before it.
Into the forks, generally yes, since they share Mirth's channel format. Qvera QIE includes a converter for Mirth exports that reports anything it could not translate cleanly. Engines with a different scripting model, such as Iguana and its Lua, need transformers rewritten. Whatever the target, replay real messages through old and new channels and compare the outputs before cutover.
Rarely on its own. AWS HealthLake, Azure Health Data Services and Google Cloud Healthcare API store and expose FHIR data, and Google can take in HL7 v2 through an MLLP adapter. Your filtering, routing, code mapping and acknowledgment logic still has to run somewhere, so plan for an engine, or equivalent code, in front of the FHIR service.
