Mirth Connect Integration Engine: Connecting 15 Hospital Systems with Zero Lost Messages

A 300-bed regional hospital had an integration problem that kept getting worse. Fifteen clinical and administrative systems needed to share data: EHR, lab, pharmacy, radiology, billing, scheduling, dietary, blood bank, and the rest. They had wired them together point-to-point, which meant 105 separate interfaces, and any one of them could break the moment a vendor pushed an upgrade.

We replaced that tangle with Mirth Connect running as a central integration engine in a hub-and-spoke setup. We built 52 channels covering HL7 v2, FHIR R4, X12 EDI, CDA, and flat file formats, with dead-letter queuing, automated retry, real-time monitoring, and zero-downtime deployments.

The result: interfaces dropped from 105 to 15, message delivery reliability at 99.7%, an 87% cut in integration maintenance, and the foundation the hospital needs for its HL7-to-FHIR migration.

The problem: too many point-to-point connections

When a hospital runs 15 systems that all need to talk to each other, the obvious approach is point-to-point: System A connects to System B, System C, System D, and so on. The arithmetic gets ugly fast: N × (N-1) / 2 = 105 unique connections for 15 systems.

What this looked like in practice

• 105 custom interfaces, each with its own connection logic, message format, error handling, and monitoring.
   
• Every upgrade broke something. When the EHR vendor pushed a patch, 14 interfaces needed retesting. When the lab system was upgraded, 14 more. The integration team spent about 80% of its time fixing things that had broken.
   
• No visibility. When a lab result didn't appear in the EHR, nobody could tell whether the lab never sent it, the interface dropped it, or the EHR rejected it. Every troubleshoot started from scratch.
   
• No retry, no dead-letter handling. Failed messages just vanished. A network blip at 3 AM meant patient results sat undelivered until someone noticed and reprocessed them by hand.
   
• Too many formats. Some systems spoke HL7 v2.3, others v2.5.1, the billing system wanted X12, the HIE expected CDA, and the new patient portal needed FHIR R4. Translation code for all of it was scattered across the 105 interfaces.

Channel management dashboard

The channel dashboard is the integration team's home screen. In one view they see every active channel with its status, message throughput, error count, and last activity. Channels are grouped by what they do:

• ADT feeds (8 channels): admission, discharge, transfer, and registration events flowing to bed management, nursing, dietary, and billing
   
• Lab results (6 channels): inbound results from the LIS, transformed and routed to the EHR, patient portal, and referring providers
   
• Orders (7 channels): physician orders flowing to lab, pharmacy, radiology, and procedure scheduling
   
• Billing (5 channels): charge capture, claim generation, eligibility verification, and remittance processing
   
• Clinical documents (4 channels): CDA/CCDA exchange with the state HIE, plus discharge summaries and referral letters
   
• Custom (22 channels): the specialized workflows, including blood bank, dietary, OR scheduling, public health reporting, and quality measures

System architecture

Hub-and-spoke design

Every system connects to Mirth Connect once. Mirth handles the routing, transformation, filtering, and delivery. Adding a new system means one new connection instead of 14.

Internal components

• Channel router: a rules engine that decides where each message goes based on type, content, source system, and business rules
   
• Message transformer: converts between any supported format, including HL7 v2 ↔ FHIR R4, HL7 → CDA, X12 → JSON, and CSV → HL7
   
• Filter engine: drops messages that don't qualify, like test patients, duplicates, or event types nobody downstream cares about
   
• Dead letter queue: failed messages are kept with full context, including error type, source message, attempted transformation, and retry count. Nothing is lost.
   
• Alert manager: configurable alerts over email, Slack, and PagerDuty for channel failures, queue-depth thresholds, and latency spikes
   
• Audit logger: every message is logged with a timestamp, source, destination, processing time, and outcome, which covers HIPAA audit-trail requirements.

Message transformation: HL7 v2 to FHIR R4

The hospital's goal is to move from HL7 v2 to FHIR R4. Mirth Connect is the translation bridge: it takes HL7 v2 from the legacy systems and emits FHIR R4 for the modern ones, so no legacy system has to change.

Transformation examples

ADT message flow

When a patient arrives at the ER, one event sets off a chain:

1. The registration system sends ADT-A01 (admission) to Mirth over TCP/MLLP
    
2. Mirth validates the message structure and fills in missing fields (attending physician lookup, insurance verification)
    
3. Mirth routes the A01 to five downstream systems at once: bed management (room assignment), nursing station (care team notification), dietary (meal planning), lab (standing order activation), and billing (account creation)
    
4. Each destination sends an ACK back to Mirth to confirm receipt
    
5. When the patient transfers (A02) or is discharged (A03), the same fan-out runs again with updated information

This runs 400+ times a day, across every admission, transfer, discharge, registration update, and merge.

Dead letter queue and error handling

Before Mirth, a failed message was just gone. Now every failure gets captured, sorted, and acted on:

• Transient failures (connection timeouts, a system that's briefly down): auto-retry with exponential backoff, 1s, 5s, 30s, 2min, 10min, 1hr. About 95% clear within the first three retries.
   
• Validation failures (malformed HL7, missing required segments): routed to the dead-letter queue with the parse error attached, so the team can fix the source system's configuration.
   
• Business rule violations (unknown patient ID, invalid code): flagged with enough context for clinical staff to review.
   
• Resolution tracking: every dead-letter message carries a status, either Pending Review, Auto-Retried, Manually Resolved, or Escalated. The SLA is 95% resolved within four hours.

Monitoring and alerting

The monitoring dashboard gives the team round-the-clock visibility into integration health:

• 12,847 messages/hour at peak, on a live throughput gauge
• 99.7% success rate, tracked per channel and overall
• 23ms average latency, from message receipt to destination delivery
• Channel health matrix: green/yellow/red status for all 52 channels at a glance
• Alerting: PagerDuty when a channel goes down, Slack for queue-depth warnings, email for routine notices like scheduled maintenance

Before and after

Message format support

Results

Cost impact

• Integration team efficiency: 2 FTEs freed from maintenance and reassigned to new projects (worth ~$280K/year)
• Less downtime: automated retry closes the data gaps that used to cost an estimated $150K/year in clinical and billing impact
• Faster onboarding: new system integrations now land in days instead of weeks
• Total annual value: ~$430K/year in efficiency gains and reduced risk

Technology stack

Timeline

Total: 3.5 months with 2 integration engineers + 1 Mirth specialist. All 105 point-to-point interfaces will be retired by the end of Phase 4.

Lessons learned

• Start with ADT, because everything depends on it. ADT events are the backbone of hospital data flow. Get those channels right first, and lab, orders, and billing follow naturally. Every downstream system needs to know when patients arrive, move, and leave.
   
• Dead letter queues aren't optional. Before Mirth, lost messages were invisible. After Mirth, every failure is captured and recoverable. If I had to name the single most important operational feature, it's the DLQ.
   
• The monitoring dashboard sells the project. Hospital IT leadership went from "integration is a black box" to "I can see every message flowing in real time." That visibility builds trust and justifies the spend.
   
• HL7 v2 isn't going away, but FHIR is coming. The Mirth translation layer lets the hospital keep taking HL7 v2 from legacy systems while handing FHIR R4 to modern consumers. Mirth is the bridge.
   
• Channel naming matters. With 52 channels, "ADT-A01-to-BedMgmt" beats "Channel_47" every time. Five minutes spent naming saves hours of troubleshooting.

Related guides

This case study is part of our complete guide to Mirth Connect: What Is Mirth Connect? Complete 2026 Guide for Healthcare Leaders. Related deep-dives:

• Mirth Connect HL7 Interface Engine: Production Deployment Guide
• Healthcare Integration Architecture with Mirth Connect and Apache Kafka

Need production-grade Mirth Connect help? See our Mirth Connect integration services.