Replacing Mirth Connect with Cloud-Native Integration

Why the legacy interface engine model is breaking

For years, tools like Mirth Connect and Rhapsody were the right answer. They handled HL7v2, out-of-band transforms, and point-to-point interfaces well enough that most hospital IT teams could keep the lights on. The problem now is not that these engines stopped working. The problem is that the operating model around them is failing.

When a hospital relies on a few senior integration analysts to manage hundreds of channels, every change becomes fragile. A single vendor upgrade can break a custom transformer. A minor certificate issue can stall lab results. And when support is limited or end-of-life is near, the risk is no longer technical debt in the abstract — it is delayed patient workflows, broken downstream billing, and late-night escalation calls.

This is why the decision has reached the board level. Integration is no longer a plumbing problem. It touches clinical operations, revenue cycle, cybersecurity, merger integration, and every program that depends on real-time data movement.

What hospital buyers are actually trying to fix

Most buyers are not asking for “cloud-native” because it sounds modern. They are trying to solve very specific failure modes:

• Too much manual deployment work for every interface change
• Poor visibility into message failures, queue depth, and latency
• Hard-to-audit custom scripts and transformer logic
• Security controls that depend on local server assumptions
• Slow onboarding for new facilities, acquisitions, and ambulatory sites
• Unclear upgrade paths as legacy platforms age out

In other words, the real problem is not data exchange itself. It is the cost of operating an integration estate that was built for a different era.

Legacy vs. cloud-native integration approaches

There are a few realistic paths hospitals take. Some are better than others. The right answer depends on how much change the organization can absorb, how many interfaces are in play, and whether the team needs to preserve HL7v2 behavior while modernizing the infrastructure around it.

From an architecture perspective, the big shift is from server-centric integration to service-centric integration. That means separating transport, routing, transformation, and monitoring so each layer can scale and fail independently. In practice, that often means running integration workloads on AWS or Azure, using managed secrets, centralized logging, infrastructure-as-code, and strict environment promotion rules. For healthcare teams, it also means building around HIPAA controls from the start instead of bolting them on later.

AST’s view: migration is an engineering program, not a tooling purchase

We see the same pattern across hospital IT teams and vendor-side product groups: the organization buys the new platform first, then discovers that the hard part is re-implementing edge cases, failover behavior, and downstream dependencies. The interfaces that matter most are usually the least documented. They were built by someone who left two years ago, patched by someone else, and only understood by three people in the hospital.

When our team has helped modernize integration-heavy products, the successful programs were the ones that treated interfaces as product surfaces. That means versioning, test harnesses, replayable messages, synthetic monitoring, and release processes that don’t require heroics on a Friday night.

AST’s pod teams typically handle this by embedding engineering, QA, DevOps, and delivery leadership together. That lets us migrate interfaces while building the deployment, rollback, and observability layers in parallel — which is the only way to keep pace when operations cannot afford downtime.

Technical decisions that matter in cloud-native integration

There are four technical choices that decide whether the migration succeeds.

1. Preserve canonical behavior first. Before changing the platform, capture current routing rules, transformation logic, message retry behavior, and downstream contracts. Hospitals cannot afford surprise behavior in lab, ADT, or billing flows.
2. Separate transport from transformation. Don’t lock business logic inside a single interface engine worker. Use queue-based intake, stateless transforms where possible, and explicit routing services so scaling is predictable.
3. Design for observability. Build dashboards for latency, queue depth, error classes, retry counts, and interface-level SLA breaches. If support teams cannot see it, they cannot operate it.
4. Cut over in slices. Move low-risk interfaces first, then high-volume but low-complexity channels, then mission-critical clinical and revenue workflows. Keep rollback plans simple and tested.

In many projects, the cloud-native target is not a single tool. It is a platform pattern: managed message brokers, containerized integration workers, infrastructure-as-code, centralized secrets management, and environment promotion through CI/CD. The goal is not novelty. The goal is repeatable operations.

What boards and CIOs care about most

Board-level interest is driving this shift because the risk profile is obvious. A legacy engine nearing end-of-life creates concentration risk, vendor dependency, and operational fragility. Cloud-native integration reduces those risks only if it improves the organization’s ability to deploy, observe, and recover.

For hospital systems, the business case usually includes:

• Lower infrastructure and support overhead
• Faster onboarding for new sites and acquisitions
• Reduced outage risk through better deployment controls
• Better cybersecurity posture with modern identity and secrets management
• Shorter time to implement new clinical and revenue workflows

That is why leaders increasingly treat integration as strategic infrastructure. It is the connective tissue between EHRs, ancillary systems, revenue tools, and patient-facing applications. If it fails, the whole stack feels it.

AST’s approach to EMR platform engineering migrations

We have spent more than eight years inside healthcare technology, and the same lesson keeps showing up: the hardest part of integration modernization is not the code rewrite. It is coordinating the business, clinical, and operational constraints that sit around the code.

When our team works on platform engineering for healthcare products, we build with the migration path in mind. That means dual-run support, explicit validation, failure-mode testing, and release practices that account for regulated environments. On one recent clinical software program serving 160+ respiratory care facilities, the key win was not just platform stability — it was making it easier for operations teams to trust every release.

That is why AST’s pod model works here. The team owns delivery end-to-end, so there is no handoff gap between integration logic, QA, deployment, and incident response. Healthcare systems do not need more specialists passing work around. They need a team that can ship, verify, and support the migration as one unit.

FAQ: replacing legacy interface engines