Mirth Connect vs Building In-House: Which is best?

It's 11:47 PM on a Tuesday. Somewhere in a US healthcare company, a VP of Engineering is typing variations of the same query into Google:

• "Mirth Connect vs in-house build"
• "should we buy or build an integration engine"
• "alternatives to Mirth Connect for healthcare integration"
• "how long does it take to build an HL7 interface engine from scratch"

The board meeting is in seven days. The product team wants to ship the connected-care module by Q3. The CTO is asking why a single HL7 v2 ADT feed has eaten a quarter of the engineering roadmap. And someone — probably a confident senior engineer with a clean GitHub profile — has put a tempting slide in front of leadership that reads: "We can build this in-house. We don't need Mirth."

This blog is the framework we wish that VP of Engineering had open in another tab.

We are not here to sell you Mirth Connect. We run Mirth Connect deployments for hospitals and digital-health vendors, but we have also been hired to replace Mirth, to fork it, and in two specific cases, to help a team retire their custom integration engine and migrate back. The honest answer is that build-vs-buy depends on volume, differentiation, talent supply, time-to-market, and how much of your roadmap you can afford to spend on plumbing.

By the end of this article you will have a defensible answer for your next steering committee, a 2x2 quadrant you can put on a slide, a 5-year TCO model, and a clear sense of when building from scratch is actually the right call.

What a VP of Engineering Is Actually Trying to Decide

The build-vs-buy question is rarely about engineering. By the time it reaches leadership, it is about four things at once:

1. Capital allocation. Every dollar spent on integration plumbing is a dollar not spent on the product feature that customers actually pay for.
2. Time-to-revenue. The first hospital contract, the first payer go-live, the first FDA submission — most of these are gated by an interface working end-to-end.
3. Talent risk. Whatever you build, someone has to maintain it. The half-life of a senior engineer at a healthcare startup is roughly 26 months. Will the system survive their resignation?
4. Strategic positioning. Is your integration engine a feature, or is it commodity infrastructure that everyone in your category has?

Most "let's build it ourselves" pitches accidentally optimize for point 4 while ignoring 1, 2 and 3. This framework forces all four onto the same page.

The 2x2: Where Your Use Case Lives

The first cut is brutal and clarifying. Two axes:

• X-axis: Volume / complexity. How many messages per day, how many distinct interface types, how exotic the workflows?
• Y-axis: Differentiation value. Does the integration capability itself differentiate your product, or is it commodity infrastructure your customers expect to "just work"?

Drop your use case into one of four quadrants:

Bottom-left — Commodity / Low volume → Use Mirth Connect. A single hospital, a couple of HL7v2 ADT feeds, a lab order interface, and a quarterly FHIR pull. This is what Mirth was built for. Spinning up your own engine here is a vanity project.

Bottom-right — Commodity / High volume → Buy + customize Mirth. Most regional health systems, payers, and mid-stage digital-health companies live here. You have real volume, you need monitoring and high availability, but the integrations themselves are bread-and-butter HL7 v2.x, FHIR R4, and X12 5010. Mirth handles this all day. Spend your engineering energy on monitoring, observability, deployment pipelines, and re-usable channel templates.

Top-left — Strategic / Low volume → Probably Mirth + a thin wrapper. Your differentiator is the clinical workflow on top of the integration. The integration itself is plumbing. Use Mirth, but wrap it with your domain APIs so the rest of your product doesn't know Mirth exists.

Top-right — Strategic / High volume → Build from scratch (carefully). You are processing tens of millions of messages a day, your integration capability is the product, and you have shipped at least one interface engine before. This is rare. This is companies like Redox, Particle Health, Datavant, 1upHealth. If you cannot honestly put yourself in their company, you are not in this quadrant.

Everything that follows is about how to read your position on this quadrant with rigor — and what to do once you know.

Option 1: Commercial Mirth Connect (NextGen)

The original Mirth Connect was open-source under the Mozilla Public License until NextGen Healthcare acquired the project and, in 2025, transitioned the open-source releases to a commercial subscription model. The free community edition is no longer receiving feature releases.

What you get:

• A mature, JVM-based integration engine with channel-based message routing
• Visual channel editor + JavaScript/Java/SQL transformers
• HL7 v2.x, FHIR, X12, NCPDP, custom delimited / fixed-width support out of the box
• Built-in TCP/MLLP, HTTP, file, JMS, S3, and database connectors
• Vendor support, security patches, log4j-style CVE responses
• Roughly 15+ years of community knowledge, channel examples, and Stack Overflow answers

What you pay:

• Subscription pricing (NextGen does not publish list pricing — typical 2026 deals we see land between \$25K and \$120K per year depending on volume, HA, and support tier)
• Implementation services (yours or a partner's)
• Ongoing engineering for channel maintenance

When this is right: You are in the bottom-left or bottom-right quadrant. You want vendor support. You want SOC 2 / HIPAA language in a contract. You don't want to be the company explaining to a hospital CIO why your "in-house engine" lost a lab result.

When this hurts: You are highly cost-sensitive and process modest volume. The subscription floor can feel disproportionate when you have two interfaces. In that case, look at BridgeLink.

For migration mechanics see our deep-dive on Mirth Connect commercial transition and the 2026 alternatives landscape.

Option 2: BridgeLink / OIE — The Mirth Fork

When NextGen changed the license, the community responded the way open-source communities always do: a fork. BridgeLink (and a few smaller forks under the "Open Integration Engine" / OIE banner) maintain Mirth's MPL-2.0 codebase, accept community PRs, and ship security patches.

What you get:

• Full Mirth API compatibility (channels migrate as-is)
• MPL-2.0 license — no commercial restrictions
• Community-driven roadmap
• Zero license cost

What you give up:

• No phone-a-vendor support contract
• Security patches arrive on community timelines, not enterprise SLAs
• Smaller commercial integration partner ecosystem
• Your hospital procurement team may flag "no vendor of record" in vendor risk reviews

When this is right: You have in-house engineering depth, you contribute back to the project, and your customers are comfortable with OSS. We have a full BridgeLink migration guide for teams making the switch.

Option 3: Cloud-Native Managed Services

Azure Health Data Services (HDS), AWS HealthLake, and Google Cloud Healthcare API are not direct Mirth replacements — they are FHIR-first managed services. But for greenfield products built around FHIR R4, they remove most of the reasons you reached for Mirth in the first place.

What you get:

• Managed FHIR R4 server with audit logging and IAM integration
• DICOMweb endpoints (Azure HDS, GCP)
• De-identification pipelines
• HL7v2 → FHIR converters (Azure FHIR Converter, AWS HL7 → FHIR Lambda templates)
• HIPAA BAA included in the cloud provider's standard agreement

What you give up:

• Visual channel editor and Mirth's mature transformer ecosystem
• Bidirectional and legacy interfaces (X12, NCPDP, custom delimited) need to be glued in via Functions / Lambdas
• Cost can balloon at scale — these are priced per request, per GB ingested, per FHIR resource stored

When this is right: You are a greenfield digital-health product, your customers are FHIR-native (Epic FHIR APIs, Apple Health, etc.), and you do not need to push HL7 v2.x ADT into an aging on-prem ED system.

When this hurts: You sign your first contract with a community hospital running a 2014-vintage Epic or Cerner instance and the only way data leaves the building is MLLP over HL7v2.

Option 4: Build From Scratch

This is the slide that gets shown to the board and the slide that, more than any other, derails healthcare engineering roadmaps.

The pitch is always seductive: "Java 21 + Spring Boot + a Kafka topic + HAPI FHIR + our own DSL = a clean, modern integration engine without Mirth's legacy baggage." Sometimes the team even ships a working proof-of-concept in two weeks.

Then year one happens.

What you actually have to build, in addition to message parsing:

1. Channel lifecycle (create / pause / resume / deploy / version)
2. Message persistence with searchable history
3. Retry / replay with exponential backoff and dead-letter queues
4. ACK / NACK semantics that work across HL7v2, FHIR, X12, NCPDP
5. TLS / mTLS / VPN tunneling for hospital networks
6. Connection pooling for MLLP, JDBC, SFTP, S3
7. Visual or declarative editor for non-Java staff
8. RBAC + audit logging (HIPAA §164.312(b))
9. Monitoring with per-channel throughput, lag, and error dashboards
10. High-availability clustering with leader election
11. Backup / disaster recovery with point-in-time recovery for in-flight messages
12. Versioning and migration tooling for breaking changes
13. Documentation, runbooks, on-call training

Mirth Connect, BridgeLink, and Rhapsody already ship items 1-13. Your differentiation will not be #1 through #13. It will be the clinical workflow on top.

Build-from-scratch makes sense in exactly three scenarios:

• You are a platform company whose product is the integration engine (Redox, Particle Health, Datavant).
• You have message volume that genuinely exceeds what Mirth scales to (~10M+ messages/day per node, sustained, with sub-second SLAs).
• You have a regulatory or clinical safety requirement that none of the engines can meet (rare — we have seen this exactly twice in seven years).

For everything else, building is an act of self-harm dressed up as architecture.

5-Year TCO: Build vs Buy vs Hybrid

Numbers, not narratives, settle most steering committee debates. Here's the model we hand to clients, applied to a representative US digital-health company with 5 hospital integrations going to 25 over five years:

These are not best-case numbers. The build column assumes you actually ship — most teams that start a from-scratch engine quietly pivot back to Mirth in year two and still pay the build cost. The "two engines in production at once" middle period is its own cost line we have left out for clarity.

The hybrid model is the one we recommend most often: Mirth for legacy HL7v2 / X12 / NCPDP and a cloud-native FHIR layer for new product surfaces. It contains lock-in, captures cloud convenience, and keeps the build effort focused on the differentiated parts of your product.

The Talent Question Nobody Wants to Discuss

We pulled 2026 LinkedIn data on Mirth Connect hiring. Three numbers should give every VP of Engineering pause:

• ~1,000 open Mirth Connect listings at any given time across the US, EU, and India
• 4-6 months is the average time to hire an experienced Mirth engineer (vs. ~6 weeks for a senior generalist Java engineer)
• \$96K – \$170K typical US base salary band for Mirth-fluent engineers, with the upper end concentrated in NY, MA, CA

Now compare that to general-purpose Java/Spring engineers, which by every benchmark we use are roughly 10x easier to source. This is the unspoken argument for building in-house: "We can't hire Mirth people, so we'll just write our own engine in plain Spring Boot and any of our engineers can maintain it."

The argument is half right. You can hire generalist Java engineers more easily. But:

1. Your engine is still a healthcare integration engine. It still needs to know HL7v2 quirks, FHIR profiles, X12 segments, and Epic Bridges. Generalist Java engineers do not arrive with this knowledge — they pick it up over 12-18 months.
2. Once they have it, congratulations, you have just trained the most desirable, hardest-to-retain engineers on the open market.
3. Their average tenure on your team after that training will land between 24 and 36 months — typical for senior healthcare-data engineers in 2026.

So you have not actually escaped the talent problem. You have moved it from "we can't find someone who knows Mirth" to "we have to train and retain a hyper-specialized in-house team." For most companies, that is a worse trade.

Time-to-Market: The Number That Actually Decides Most Deals

Engineering hours are abstract. Lost contracts are not.

The same scope — HL7v2 ADT inbound, FHIR R4 patient + observation outbound, retry + replay + monitoring — by approach:

• Mirth Connect off-the-shelf: ~30 days to first production interface (we have done this for clients in 2-3 weeks when channels are well-defined).
• Mirth + customization wrapper: ~60 days.
• Build from scratch on HAPI FHIR + Spring Boot: ~180 days, and that's optimistic.
• Build from scratch with no FHIR library base: 365+ days. We have watched two startups try this and one of them quietly pivoted to Mirth at month nine.

If the next hospital contract closes contingent on a working interface in Q3, the build path almost certainly costs you the deal. The faster path to revenue compounds — earlier revenue funds the next hire, the next certification, the next product surface. Build-from-scratch optimizes for the wrong loop.

The Decision Tree

When we sit with clients, this is the rough sequence of questions we walk:

1. Are your messages standard? HL7v2, FHIR R4, X12 5010, NCPDP SCRIPT — these are commodity. If yes → Mirth or BridgeLink wins.
2. Is your volume under 1M messages/day? Mirth scales comfortably to this and beyond with HA. If yes → buy.
3. Can you wait 6+ months for the first production interface? If no → buy. There is no scenario where build-from-scratch is faster.
4. Has anyone on your team shipped a production integration engine before? Not "built a parser" — shipped, HA, on-call, audited. If no → buy.

Only when all four answers favor build is custom even a candidate. And even then, the right move is usually "build the differentiated 20% on top of Mirth," not "build everything."

Vendor Lock-in: The Risk Most Teams Get Wrong

The argument against Mirth most often centers on lock-in. Let's grade it honestly across the four options:

Two surprises here:

• Custom build has the worst data portability in most cases. Your messages are sitting in your own schema with your own retry semantics. Migrating off your engine is harder than migrating off Mirth.
• Cloud-native has the highest switching cost. Once your FHIR R4 store is in Azure HDS, leaving means re-loading every resource into a new home and rewriting every integration point.

"Building from scratch" feels like the lock-in-free option. In practice, it just shifts lock-in from a vendor to a small group of in-house engineers — and those engineers can resign with two weeks' notice.

When Building From Scratch Is the Right Call

We have been deliberately skeptical, but custom-build is the right answer in real situations. Three patterns we have seen work:

1. Platform companies whose product is the engine. Redox, Particle Health, 1upHealth, Datavant. Their differentiation is the integration capability itself. Mirth is too generic and too slow to evolve for their needs. If your company has "the integration platform for X" in its pitch deck, build.

2. Sustained ultra-high volume. One client of ours pushes 60M+ messages/day from a network of imaging devices into a downstream AI platform. Mirth scales, but at that volume the per-message overhead and JVM tuning became a tax. They build their own ingest layer in Rust and keep Mirth for the regulated FHIR / HL7v2 last-mile delivery to hospitals. Hybrid done right.

3. Regulatory or clinical-safety constraints unique to you. We have seen this twice in seven years. Both were Class II medical devices where the integration path had to be FDA-validated in a way Mirth's general-purpose channel model could not support. Even then, the team didn't build "an integration engine" — they built a narrow, validated message router for one path.

If none of these describe you, you are not building an engine. You are building tech debt.

Innovation Engine vs Commodity Infrastructure

Here is the framing we leave clients with:

Every hour your team spends on commodity infrastructure is an hour your competitors spend on their innovation engine.

Healthcare interoperability plumbing is commodity. Hospitals don't pay for it directly. CIOs do not write checks for the elegance of your message router. They pay for the clinical workflow, the AI co-pilot, the patient experience, the cost reduction — the differentiated layer that sits on top of the plumbing.

The companies that win in healthcare technology are the ones that treat HL7v2, FHIR, X12, and NCPDP as solved problems. They buy the engine, configure it, wrap it, monitor it — and pour their best engineering minds into the part of the product that customers actually pay for.

Mirth Connect is not glamorous. Neither is electricity, and yet every hospital is wired to a grid they did not build. Make the same trade.

How We Help Clients Make This Call

We sit on both sides of this question. We run Mirth deployments for hospital networks and digital-health vendors. We have also helped two clients build small custom routers where the math genuinely supported it. We have never recommended a from-scratch generic integration engine and we don't expect we ever will.

The right next step depends on where you are:

• You think Mirth is right and want help shipping faster: our Healthcare Interoperability Solutions cover channel design, HA setup, monitoring, and EHR integration.
• You're building a healthcare product and the integration layer is in the way: our Healthcare Software Product Development team architects the integration layer so your product team can focus on the differentiated parts.
• You want a second opinion on a build-vs-buy debate happening inside your team: Talk to our team — bring your slides, we'll bring the scars.

Lead Capture: Build vs Buy Scorecard

If you want to take this framework into your next steering meeting, we maintain a structured Build vs Buy Scorecard as an Excel workbook. It walks your team through 24 scoring questions across volume, differentiation, talent, time-to-market, and risk, and outputs a recommendation: Buy, Hybrid, or Build (and which sub-option). It is the same tool we use on day one of every advisory engagement. Talk to our team to receive the scorecard and a 30-minute strategy discovery call with an integration architect.

Further Reading

• Mirth Connect vs Rhapsody vs Iguana — 2026 comparison
• Top 10 Mirth Connect integration failures (and how to avoid them)
• How to set up Mirth Connect for high availability
• Healthcare integration architecture with Mirth and Kafka
• Mirth Connect performance tuning for 10,000 messages/hour

Need a partner who has done this many times? Explore our Healthcare Interoperability Solutions and Healthcare Software Product Development capabilities, or talk to our team to scope a strategy session.