Modernizing EHR/EMR Integrations: The Interface Mesh

If you ask where the risk in a healthcare modernization actually lives, the honest answer is rarely “the application.” It is the connections. An EHR or EMR is valuable precisely because it is wired into everything — labs send results into it, pharmacy systems reconcile against it, billing reads from it, external partners exchange records with it. Each of those connections is an interface, and the set of them is what this series calls the interface mesh. Part 1 named it as the first of healthcare’s three pressures. This part is about why it is the real obstacle, and how to modernize around it without tearing it.

Three standards, all live at once

The mesh speaks several languages simultaneously, and a real estate runs all of them.

• HL7 v2 is the workhorse of clinical messaging — admissions, lab orders and results, pharmacy, scheduling. It is a text format, decades old, and deliberately flexible: many fields are optional, and the standard explicitly allows local extensions. That flexibility is why it spread, and also why no two HL7 interfaces behave quite alike.
• X12 EDI carries the administrative transactions, above all the claims and eligibility exchanges between providers, clearinghouses, and payers — the 837 claim, the 835 remittance, the 270/271 eligibility pair.
• FHIR is the modern standard: an API-based, resource-oriented model built on ordinary web technologies. New integrations increasingly target it, and regulation has pushed adoption, but it sits alongside the older standards rather than having replaced them.

The practical reality is that you are not modernizing onto one clean standard. You are modernizing inside an estate that runs HL7 v2 and EDI and FHIR at the same time, often bridged by an interface engine that has been accumulating routes and transformations for fifteen years.

Why the mesh is the hard part

Two properties make interfaces the most dangerous thing to touch.

The first is undocumented behavior. HL7 v2’s flexibility means each interface carries a payload of local convention — which optional segments are actually populated, what a particular field really means at this site, which custom Z-segments downstream systems quietly depend on, what ordering and timing assumptions the receiver makes. None of this is written down in a way you can trust. The behavior lives in the running interface, and the only complete specification of it is the interface itself. This is the tribal knowledge problem in its sharpest form: a contract that everyone relies on and no one has fully captured.

The second is blast radius. Because every system reads from and writes to the mesh, a change in one place propagates. Modify how the EHR emits a result message and you have potentially affected every downstream consumer of that message — the lab archive, the billing trigger, the reporting feed — most of which you did not intend to touch and some of which you may not even know exist. In a big-bang replacement, all of these change at once, which is why the cutover so often surfaces interface failures that no amount of pre-launch testing predicted. The behavior that breaks was never in a document to test against.

The principle: keep the contract, isolate the change

The way through is a discipline, not a tool: treat each interface contract as stable, and absorb all the change behind a boundary.

Concretely, when you modernize a system that sits on the mesh — say you are replacing the component that consumes lab results and feeds billing — you do not re-cut its interfaces to match the new system’s internal model. You keep the existing HL7, EDI, or FHIR contract exactly as the rest of the estate expects it, and you place a translation layer between that contract and the new system. The mesh sees no change. The new system sees only its own clean model. The translation in between is where the messiness is deliberately confined.

This is the anti-corruption layer, applied to interfaces. Its job, in both directions:

• Inbound: an incoming HL7 or EDI message — with its optional segments, local field meanings, and quirks — is translated into the new system’s clean, explicit model. The eleven ways a status can be expressed become one enum; the custom Z-segment becomes a named, understood field.
• Outbound: when the new system has to emit a message back onto the mesh, the ACL translates its clean model back into the exact format the legacy consumers expect, preserving every quirk they depend on, so nothing downstream notices a new system is behind the feed.

Inside the boundary, new code speaks its own language. Outside it, the mesh keeps flowing as it always has. The strangler facade handles which system answers a given request; the ACL handles what the messages mean as old and new have to talk. Together they let you rebuild one system on the mesh while every other system keeps running, unaware.

Why this is safer than “rip and replace the interface engine”

The tempting shortcut is to rebuild the interface engine itself in one move — new platform, all routes re-implemented, cut over on a weekend. It fails for the same reason the broader big-bang fails, only more acutely: the interface engine is the single point through which the entire mesh passes, and its behavior is the most undocumented in the estate. Re-implementing all of it at once means re-deriving years of accumulated local convention from scratch and proving it correct all at the same moment, with no way to roll back a single route independently. You are concentrating the estate’s most hidden behavior into its riskiest possible change.

The incremental alternative migrates interfaces the way it migrates everything else: one route, one feed, one transaction type at a time, each behind its own boundary, each provable and reversible on its own.

Proving the translation is right

A translation layer is only as trustworthy as its fidelity, and a subtly wrong translation is exactly the silent-divergence failure the whole approach exists to prevent — a dropped optional segment, a mishandled edge case in a date format, a Z-segment quietly lost. So the translations are held to the same evidence bar as the systems themselves.

The technique that fits the mesh especially well is shadow traffic testing: real production messages are fed through both the legacy path and the new path in parallel, and the outputs are compared message for message. Where they match across the full range of real-world traffic — including the rare and malformed messages that no synthetic test would think to generate — you have evidence the translation is faithful. Where they diverge, you have found a hidden assumption before it reached production rather than after. This is how you prove functional equivalence for an interface whose real specification was never written down: you test against its actual behavior, not against a document that doesn’t exist.

Not every interface needs the full treatment

Not every interface is worth a full anti-corruption layer. Where the legacy format and the new model are already close — a clean, modern FHIR exchange feeding a system with a similar resource model — a thin adapter is the honest choice, and wrapping it in ceremony is waste. The ACL earns its cost where the gap is real: the decades-old HL7 v2 feed thick with local convention, the EDI transaction with site-specific handling, the boundary many systems cross. Translate where meaning actually diverges; adapt where it doesn’t.

And a sequencing caution: interfaces are usually not the first slice to migrate, even though they are the riskiest. Early slices are better chosen where the value is clear and the blast radius is contained, so the team builds the parity and rollback machinery on lower-stakes ground before pointing it at the mesh. The mesh is where this approach proves its worth — not where you should learn it.

Where this leads

The structural method is now in place: keep the interface contracts stable, isolate change behind translation boundaries, and prove each translation against real traffic. But the systems behind the mesh have their own character, and on the payer side that character is specific — high-volume claims and payment engines, frequently written in COBOL and running on mainframes, maintained by a workforce that is leaving on a schedule. Part 3, COBOL in Healthcare Payments, looks at those engines: why they were built the way they were, why the knowledge clock makes them urgent, and how the slice-by-slice approach applies to the code that actually moves the money.