← All articles

Mirth Connect in 2026: When to Keep It and When to Move On

Last updated: November 2026

If your organization has HL7v2 interfaces, there is a better-than-even chance Mirth Connect is running them. It has been the default since the mid-2000s, it is open-source (MPL 2.0 for the community edition), and there is a generation of interface analysts who learned integration on Mirth's channel model. That installed base matters.

But the landscape has changed. NextGen acquired Mirth in 2015 and rebranded it NextGen Connect. FHIR adoption is accelerating under ONC mandates. AI-assisted tooling is reducing the manual transform work that Mirth requires. And the licensing picture has gotten murkier with each release. If you are evaluating whether to stay on Mirth, expand your Mirth investment, or start looking elsewhere, here is what we see after years of building on both sides of the decision.

Where Mirth still wins

The community is unmatched

No other healthcare integration engine has a community this large. Forums, Slack channels, Stack Overflow answers, YouTube tutorials, consulting shops — if you run into a problem with Mirth, someone has hit it before. That matters when your interface analyst is troubleshooting a production HL7v2 feed at 2 AM.

Zero licensing cost (community edition)

The open-source Mirth Connect community edition costs nothing. For an organization that has the staff to configure, deploy, and maintain it, total cost of ownership can be remarkably low. You pay in engineer time, not vendor invoices. Plenty of hospitals run Mirth on a single Linux VM with no commercial support contract and have for a decade.

HL7v2 is solved

Mirth's HL7v2 support is mature and battle-tested. MLLP listener, message parsing, segment manipulation via JavaScript, acknowledgment handling, routing rules — it all works. If your integration needs are primarily HL7v2-to-HL7v2 with no FHIR migration on the horizon, Mirth is hard to argue against.

Where Mirth shows its age

FHIR was bolted on, not built in

Mirth predates FHIR by over a decade. FHIR support exists, but it is implemented through channel configuration — you set up HTTP listeners, write JavaScript to parse FHIR JSON, and manually construct FHIR responses. Compare that to engines built around FHIR from the start, where FHIR resources are first-class objects with typed parsing, validation, and native Subscription support.

In practice this means: a Mirth channel that accepts an HL7v2 ADT and produces a FHIR Patient resource requires a developer who knows both HL7v2 segment structure and FHIR resource modeling, plus enough JavaScript to write the transform. That developer is expensive, and the transform is brittle — one Z-segment change at the sending site breaks it.

Mapping is manual and repetitive

Every Mirth channel transform is hand-written JavaScript or XSLT. There is a template library, but the field-by-field mapping work is on the developer. This is where AI-assisted mapping tools (available in newer engines like MedHook) have an edge: they suggest the PID-to-Patient or OBX-to-Observation mapping from the message structure, and you correct the suggestions rather than writing from scratch.

We have seen this cut initial transform development from 2-3 days to a few hours on a typical ADT interface. The improvement is largest for teams without deep HL7 expertise.

The licensing story is complicated

Mirth Connect started fully open-source. After NextGen's acquisition, newer versions introduced commercial licensing for certain features (enhanced monitoring, HA, dedicated support). The community edition remains free, but you need to check exactly which version and feature set you are using. Some organizations have been surprised by licensing requirements when upgrading.

No pre-built EHR adapters

Connecting to Epic's FHIR API requires writing OAuth 2.0 token management, handling Epic's 5-minute token expiration, managing per-site credentials, and dealing with Epic-specific FHIR extensions. Same for Cerner, athenahealth, and every other EHR. In Mirth, that is all custom channel code. Engines with pre-built EHR adapters handle the vendor-specific quirks out of the box.

The evaluation framework

If you are deciding whether to stay on Mirth, here are the questions that actually matter:

1. Is FHIR in your near-term roadmap?

If your interfaces are stable HL7v2 and you have no FHIR requirement within 18 months, stay on Mirth. There is no reason to migrate a working system.

If you are building new FHIR interfaces (because of ONC mandates, a hospital partner's requirement, or a product decision), evaluate whether Mirth's bolted-on FHIR support meets your needs or whether a FHIR-native engine would be more productive.

2. How much HL7 expertise does your team have?

Mirth assumes deep knowledge of HL7v2 segment structure and JavaScript/XSLT transforms. If your team has that expertise, Mirth's learning curve is negligible. If your team is primarily web/API developers encountering HL7v2 for the first time, the ramp is steep, and AI-assisted tooling in newer engines can flatten it significantly.

3. What does your interface volume look like?

Mirth handles high message volumes well. We have seen Mirth deployments processing millions of messages per day. The question is not whether Mirth can handle the volume — it can — but whether the operational overhead of managing Mirth at scale (HA configuration, monitoring, channel management) is justified compared to alternatives that include these features out of the box.

4. How many EHR vendors do you need to connect to?

If you connect to one or two EHRs, the custom connection code in Mirth is manageable. If you are building a product that needs to connect to Epic, Cerner, athenahealth, MEDITECH, and NextGen, the per-vendor connection work in Mirth adds up. This is where pre-built adapters in engines like MedHook or managed platforms like Redox provide leverage.

5. What does your team cost?

An experienced Mirth developer in the US bills $150-250/hour or earns $130-180K/year salary. That is the real cost of Mirth's "free" license. If your team is building and maintaining 20+ Mirth channels, calculate whether the all-in cost (salary + time + opportunity cost) exceeds what you would pay for a commercial engine that reduces the per-interface effort.

What "moving on" actually involves

Migrating off Mirth is not a weekend project. Here is what it looks like:

  1. Inventory your channels. Document every Mirth channel: source, destination, message type, transform logic, volume, and dependencies. We have seen organizations with 50+ channels that no one has a complete inventory of.

  2. Prioritize by risk and value. Migrate new interfaces first on the new engine. Move stable, low-change legacy interfaces last (or leave them on Mirth indefinitely — there is no rule that says you cannot run two engines).

  3. Parallel run. For each migrated interface, run the old Mirth channel and the new engine in parallel. Compare outputs at the message level. This is the step that catches transform differences.

  4. Budget 1-2 weeks per complex interface. A simple point-to-point HL7v2 route migrates quickly. A channel with custom JavaScript transforms, multiple destinations, and Z-segment handling takes longer. Plan accordingly.

The pragmatic approach is hybrid: keep Mirth for existing stable interfaces, use the new engine for new work, and migrate legacy interfaces opportunistically when they need changes anyway.

Our take

Mirth Connect is not dying. It remains the right choice for organizations with deep HL7v2 expertise, stable interfaces, and no near-term FHIR requirement. The community is real, the cost is real (zero), and the track record is real.

It is the wrong choice if you are building FHIR-native integrations from scratch, if your team lacks HL7 expertise and needs AI-assisted tooling, or if you are connecting to multiple EHR vendors and writing custom connection code for each one is eating your sprint capacity.

We have deployed both Mirth and MedHook in production, and we have helped teams migrate from one to the other. The answer is almost never "rip and replace everything." It is usually "use the right tool for the next interface, and migrate the rest when the cost-benefit makes sense."

If you are evaluating your integration stack, we are happy to look at your current Mirth deployment and give you an honest assessment of what is worth migrating and what should stay. Get in touch — 30 minutes, no pitch.