Mirth Connect, what happened? Here's What Comes Next.

Sketch of an integration engine evolving from legacy Java architecture to modern DAG-based workflow

Every platform eventually becomes the thing it was built to replace

It's 11pm. I'm debugging a Mirth channel that stopped routing ADT messages three hours ago. The JavaScript transformer editor has frozen — again — so I'm editing XML directly in a text file, deploying through the GUI, watching the dashboard for messages to flow, and refreshing obsessively. I've done this dozens of times. I know every workaround.

That was 2019. The tooling hasn't changed much since.

I've written about getting Mirth up and running and connecting it with RabbitMQ. Those are how-to articles. This one is different. This is about where Mirth came from, what happened to it, and what the next generation of healthcare integration looks like.

What Mirth Got Right

When Mirth Connect launched, it was genuinely transformative. Before it, healthcare integration meant expensive proprietary engines — Rhapsody, Cloverleaf, HL7Fuse — with six-figure licensing and consultants who billed like surgeons. Mirth was open source, GUI-based, and actually worked. A small hospital IT team could route HL7 messages between their ADT system and their lab without a professional services engagement.

That mattered. Healthcare data was (and still is) a mess of HL7v2 messages, SOAP services, flat files, and vendor-specific formats that predate the internet. Mirth sat in the middle and made them talk to each other. It became the Swiss army knife of the space — not because it was beautiful, but because it was there, it was free, and it handled the edge cases that killed other tools.

The architecture reflected its era. Channels defined as XML. Transformers written in JavaScript-inside-XML. Message routing through regex and filter scripts. A Swing-based desktop client that felt like 2005 because it was built in 2005. It was dense and idiosyncratic, but engineers who learned it could build anything.

The NextGen Era

Mirth Corp was acquired by NextGen Healthcare in 2015. For a few years, not much changed. The open source core kept moving, the community kept building, and NextGen mostly added commercial extensions on top.

Then the pace slowed.

Look at the release history. Mirth Connect 4.5.2 shipped in September 2024 — the most recent release as of this writing. Version 4.5.0 was January 2024. Version 4.4.0 was July 2023. The changelog reads: security improvements, bug fixes, MFA library update, Java version notice. There is no release with a headline feature. The biggest architectural news in two years is that Java 17 will become the minimum version requirement in 2025.

That's not a knock on the engineers maintaining it. Maintaining a 20-year-old Java codebase that powers critical healthcare infrastructure across 40 countries is real work. Security patches matter. But it's telling that the innovation surface has moved almost entirely to the commercial tier while the open source core idles.

The GitHub repo has 400 open issues. The top complaints are the ones I lived: the JavaScript editor freezing during development, setup complexity on fresh installs, feature gaps around operational visibility. These aren't new bugs — they're known friction points that have existed for years and aren't getting fixed because the incentive structure has shifted.

NextGen's enterprise pitch now leads with "1/3 of all public Health Information Exchanges" and "340 million clinical documents annually." That's impressive scale. It's also the product language of a company protecting a legacy revenue base, not one accelerating toward a new architecture.

What the Architecture Can't Do

The deeper problem isn't the open issues count. It's that Mirth's architecture makes certain things structurally difficult.

Modern deployment is painful. Mirth runs as a Java application server with a separate administrator client. Dockerizing it is possible but friction-heavy. Configuration lives in a database that requires migration tooling to move between environments. There's no native Kubernetes story, no clean infrastructure-as-code path. Teams that have modernized their deployment stack around containers find Mirth a persistent exception.

The JavaScript developer experience is hostile. Transformers are JavaScript functions written inside XML channel definitions, edited in a GUI text area with no LSP support, no type checking, no proper debugging. The workaround — edit XML directly, commit to version control, deploy through the API — is functional but alienating for engineers who've been spoiled by TypeScript and modern tooling.

FHIR is bolted on, not native. Mirth predates FHIR by a decade. R4 support exists, but it's built on top of an architecture designed around HL7v2 message flow. The programming model doesn't naturally express the resource-graph thinking that FHIR requires. Teams building FHIR-first products feel the impedance mismatch constantly.

There's no AI integration path. This sounds like a buzzword complaint, but it's practical: mapping between HL7 schemas and FHIR resources is genuinely tedious, repetitive work that AI-assisted tools can accelerate dramatically. Mirth has no story here because the architecture predates the tooling.

What the Next Generation Looks Like

I've been watching the healthcare integration tooling space closely for the last few years, and a pattern is emerging. The teams building new integration infrastructure are converging on a few shared assumptions:

DAGs over channels. Directed acyclic graphs — the same pattern that made Airflow dominant in data pipelines — are a better mental model for integration workflows than Mirth's channel abstraction. Triggers, nodes, edges, parallel branches, sub-workflows. Easier to reason about, easier to test, easier to visualize.

TypeScript over Java. The engineering talent pool has shifted. The engineers building health tech products today are TypeScript-native. An integration engine that speaks their language and fits their tooling is one they'll actually extend rather than work around.

Self-hosted, cloud-native deployment. Runs in Docker. Deploys to your VPC. Configuration is code. No separate admin client, no database migration gymnastics to move between environments. PHI stays inside your infrastructure perimeter, which matters when your security team is asking questions about BAA surface area.

AI-assisted mapping. HL7-to-FHIR field mapping is the kind of structured, repetitive transformation task where AI tools genuinely help. The next generation of integration tooling treats this as a first-class capability, not an afterthought.

This is where MedHook lives. It's a self-hosted integration platform built around visual DAG workflows, TypeScript, and AI-powered field mapping. It ships with native adapters for Epic, Athena, and Oracle Health, handles HL7v2, FHIR R4, and X12 EDI, and runs as an 8-service Docker stack that deploys into your own infrastructure. HIPAA-aligned defaults, AES-256-GCM credential encryption, full audit logging built in.

The design is what you'd get if you built Mirth in 2026 instead of 2006.

This Isn't a Mirth Obituary

Mirth isn't going away. The installed base is massive — it's embedded in hospital systems, state HIEs, and specialty networks that have been running on it for a decade. The switching cost is real. NextGen will maintain the open source core because abandoning it would be a reputational disaster in a community that still trusts it.

But "maintained" is different from "the platform you'd choose today if you were starting from scratch."

The teams I talk to who are building new health tech products — startups, platform companies, new integration projects at existing organizations — are not choosing Mirth for greenfield work. They're choosing it only when they're extending existing Mirth infrastructure, because the cost of context-switching mid-project is too high.

That's the tell. A platform grows through new adopters. When new adopters stop choosing it, the installed base ages in place and the platform eventually becomes what it displaced.

The Practical Transition

If you're maintaining Mirth infrastructure today, you're not throwing it away tomorrow. But there are things worth doing now:

  1. Stop writing new channels. For any new integration work, evaluate whether a modern tool is a better fit. The comparison often surprises people — the ramp-up time on a DAG-based tool is shorter than the ramp-up on Mirth for engineers who don't have Mirth history.

  2. Document your existing channels. The people who understand your Mirth configuration are a bus factor. The XML channel definitions are not self-documenting. Before you consider any migration, you need a clear inventory.

  3. Modernize your deployment first. If you're still running Mirth on bare metal or in a VM with manual configuration, containerizing it is the right first step regardless of what happens next. It makes the eventual migration cleaner.

  4. Build new FHIR integrations outside Mirth. Mirth's FHIR story is the weakest part of the current architecture. Any new FHIR R4 work is better served by purpose-built tooling.

  5. Track the MedHook trajectory. Early-stage products are risky dependencies, but the architecture decisions being made now will determine what the viable alternatives look like in two years. Worth knowing what's coming.

Mirth Connect gave the industry 20 years of reliable, accessible integration infrastructure. That's a real contribution. The engineers who built it and maintained it through multiple acquisitions shipped something that genuinely moved healthcare data when nothing else would.

But the industry has moved. The stack has moved. The engineers have moved.

What comes next will look familiar in the ways that matter — message routing, protocol translation, standards compliance — and completely different in the ways that define the developer experience. DAGs, TypeScript, Docker, AI-assisted mapping, FHIR-native.

I've been doing healthcare integration long enough to know that transitions in this space are slow. Mirth will be in production somewhere in 2030. But the new work is already happening somewhere else.