An integration engine like Mirth Connect earns its place when you are running many interfaces to many counterparties and need routing, transformation, queuing, retry and monitoring as shared infrastructure rather than rebuilding them per integration. It is overhead when you have one or two connections against a modern FHIR API, because you have added a server to run, patch, monitor and staff for capabilities those integrations were not going to use. The practical dividing line is HL7 v2 message volume: engines exist because v2 interfaces need reliable delivery, acknowledgement handling and replay, and if that is your traffic, an engine is the right answer and building one is a mistake. If your integration is a handful of authenticated FHIR calls in a request-response pattern, the engine adds an operational layer between your application and the API without earning it. One thing has changed recently enough to reshape this whole decision: Mirth Connect is no longer meaningfully open-source, and that fact belongs at the top of any evaluation, not a footnote.

What an Integration Engine Actually Does

An integration engine’s job is routing messages between systems, transforming their format along the way, queuing them reliably, retrying on failure, and giving you monitoring visibility into all of it. Those capabilities exist specifically because HL7 v2’s delivery model demands them — v2 is event-driven, high-volume, and has its own acknowledgement semantics that a naive point-to-point connection doesn’t handle gracefully at scale.

What Mirth Connect Is (and What It Costs Now)

This is the highest-confusion, highest-value part of this post, and it needs a direct, current correction: Mirth Connect is not the free open-source option it’s still widely described as. NextGen Healthcare announced in March 2025 that it was moving Mirth Connect to a fully commercial, closed-source licensing model starting with version 4.6. Version 4.5.2, released in September 2024, was the final open-source release under the Mozilla Public License — and that version is no longer officially supported. You can keep running it, but there are no new updates, bug fixes, or security patches coming for it from NextGen.

That’s a genuinely different proposition from “free, open-source integration engine,” which is how a lot of still-circulating content describes it. If you’re evaluating Mirth Connect today, you’re evaluating a commercial product for any currently-supported version, with the older open-source release available only as an unsupported, unpatched legacy option. Verify NextGen’s current commercial pricing and licensing terms directly before scoping anything around Mirth — this is a fast-moving detail and stale information here will meaningfully mislead a build-vs-buy decision.

The Dividing Line: Message Volume and Counterparty Count

Regardless of the licensing shift, the underlying decision framework still holds: the number of interfaces and counterparties you’re running, crossed against whether that traffic is v2 (event-driven) or FHIR (request-driven), is what actually determines whether an engine earns its place. One or two FHIR connections rarely justify one. Many v2 interfaces across many counterparties almost always do.

When an Engine Is Clearly Right

Many HL7 v2 interfaces across multiple counterparties, a genuine need for message replay and audit history, and a team that will actually operate the thing — patch it, monitor it, staff an on-call rotation for it. If that’s your situation, an engine’s shared infrastructure is worth the now-real licensing cost, because building and maintaining that same reliability tooling yourself, per interface, costs more in the long run.

When Building Direct Is Clearly Right

One or two FHIR integrations in a straightforward request-response pattern, with no dedicated operations team to run a standing server. Be honest about what you’re giving up by not standing up an engine — replay and centralized monitoring, mainly — and confirm your actual integration count doesn’t need them before deciding against one.

The Middle Ground: Libraries Without an Engine

The option most comparisons skip entirely, and worth knowing about now that Mirth’s cost calculus has changed: HL7 parsing libraries, managed message queues, and cloud-native alternatives can cover a meaningful middle ground between “no tooling at all” and “a full standing integration engine.” If your volume doesn’t justify Mirth’s now-commercial licensing but a bare point-to-point connection feels too thin, this middle tier is worth evaluating before defaulting to either extreme.

Operational Cost Nobody Quotes

The honest counterweight to “just use an engine”: running one is a standing operational commitment — patching, monitoring, upgrades, on-call coverage, and now, for Mirth specifically, an ongoing commercial license cost that wasn’t part of the calculation a couple of years ago. Budget for all of that as a real, permanent line item, not a one-time setup cost.

How This Fits Cerner and Epic Work

An integration engine typically sits alongside, not instead of, the vendor-specific FHIR clients I cover in FHIR vs. HL7 v2 on Cerner — handling the v2 event traffic while your FHIR client handles the app-style reads and writes. The same architecture pattern applies whether you’re building against Epic or Oracle Health.

Next Steps

If Mirth Connect is anywhere in your current architecture plan, confirm which version and licensing terms you’re actually scoping against before you budget anything — the open-source assumption a lot of teams still carry into this decision is now genuinely out of date. If you’re weighing an integration engine against building direct, talk to our team about your actual interface count and volume — that’s the number that should drive the decision, not which option used to be free.