Chapter 01 · The brief
Fourteen scripts. Fourteen ways to fail.
Thirty percent of engineering capacity spent on integrations that generated no new revenue.
A mid-size healthcare software company had built 14 separate integration scripts over six years — one for each hospital partner. Each script was owned by a different developer, deployed in a different way, and failed in a different way. When a hospital updated their EHR version, the corresponding integration broke and stayed broken until someone had time to look at it.
The company was spending roughly 30% of engineering capacity maintaining integrations that didn't generate new revenue. When they signed a contract with their fifteenth hospital partner, the existing approach stopped being viable.
Chapter 02 · What we found
The same structure. Diverged implementations. No integration layer.
The 14 scripts shared a common structure — receive an HL7 v2 message, transform it into the product's internal format, write to the database — but had diverged in their implementation of that structure over time.
Several scripts used blocking I/O with no timeout handling. Two used deprecated libraries. One had a hardcoded hospital-specific transformation that had been copy-pasted into three other scripts as later hospitals had similar requirements.
The core problem was architectural: each hospital had a point-to-point connection directly to the product's application layer. There was no integration layer with its own operational characteristics.
Chapter 03 · Build
Hub-and-spoke architecture. Hospital-specific variation as configuration, not code.
We designed a hub-and-spoke integration architecture using Mirth Connect as the hub.
The key decision was to build shared transformation channels in Mirth and route hospital-specific variations as configuration, not code. A hospital that sends HL7 v2.3 gets a preprocessing step that normalizes the message structure before it hits the shared transformation channel. The shared channel doesn't know which hospital it's serving.
The architecture shipped in four layers:
- Inbound listeners. One TCP/MLLP listener per hospital, each running as a separate Mirth channel. Hospitals connect to their listener; a single listener can be restarted without affecting others.
- Normalization channels. Hospital-specific preprocessing applied before messages enter the shared pipeline. Handles version differences, encoding quirks, and vendor-specific extensions.
- Shared transformation channel. Converts normalized HL7 v2 to the product's internal format. Single implementation, tested once.
- Outbound writer. Writes to the product database. Buffered with configurable retry and dead-letter queue.
The dead-letter queue was the most important operational addition. Previously, a failed message was lost. Now, failed messages queue automatically, operators can inspect them in the Mirth dashboard, and reprocessing is a button click.
Chapter 04 · Migration
Eleven weeks. No hospital experienced a cutover with data loss.
We migrated hospitals in three batches, starting with the three lowest-volume partners. Each migration involved standing up the Mirth channel for the hospital, running both old script and new channel in parallel for two weeks comparing output, cutting over on a Tuesday morning (lowest volume day for most clinical environments), and decommissioning the old script after 30 days of clean operation.
The parallel-run period caught three edge cases — unusual message structures that the old scripts handled silently but incorrectly. Fixing them before cutover improved data quality compared to the old system.
Chapter 05 · Outcomes
Integration maintenance became a small fraction of engineering capacity.
New hospital partners now onboard by adding a Mirth channel and, in most cases, applying an existing normalization template. The fifteenth hospital partner was live in nine days, compared to a typical six-week timeline previously.
Message processing latency dropped from up to four hours (due to polling intervals in the old scripts) to under twelve minutes on average. Engineering time redirected from integration maintenance to product features added up to roughly 1.2 FTE annually.
Chapter 06 · Stack
Technology stack.
- Integration hubMirth Connect — hub-and-spoke architecture, channel-per-hospital listener model
- ProtocolTCP/MLLP inbound listeners; HL7 v2.x normalization channels per hospital
- TransformationShared channel — normalized HL7 v2 to product internal format; single implementation
- ReliabilityDead-letter queue, configurable retry, Mirth dashboard for operator inspection and reprocessing
- DeploymentPer-hospital channel isolation; individual restarts without affecting other connections