Interoperability Between Disparate EHR Systems

The fastest way to fail at interoperability is to treat every EHR like it speaks the same language just because the vendor brochure says “FHIR enabled.” I have seen teams spend months wiring a clean-looking API integration and still ship something useless because the receiving system could not reconcile patient identity, the source system buried important context in free text, or the interface engine silently dropped an edge case nobody tested.

That is the part most people miss. Interoperability is not about moving data. It is about preserving meaning under real clinical pressure. If the chart says a medication was discontinued, the other side needs to know whether that means “stop forever,” “hold for procedure,” or “entered in error.” If you do not carry that nuance through the exchange, you have connected systems but broken care.

At AST, the integrations that survive live traffic are the ones we design from workflow backward. I am not talking about a glossy architecture slide. I mean the gritty stuff: which system is the source of truth for demographics, how duplicate MRNs are handled, whether a referral can be accepted without a final diagnosis, and what happens when Epic sends one version of a patient and Oracle Health stores another. That is where the work lives.

There is a counterintuitive lesson here: the best interoperability strategy is usually not “use FHIR for everything.” I know that is unpopular with vendors who want a single modern answer. But in production, HL7v2 still carries a lot of operational truth, FHIR R4 covers structured access and app workflows well, and vendor-specific APIs often fill the real gaps. The winning move is not ideological purity. It is choosing the right rail for the right job and making the rails agree on meaning.

What has to line up before systems can truly talk

If you are connecting Epic, Oracle Health, athenahealth, PointClickCare, or a homegrown EMR, I start with five questions. They look simple, but they determine whether the integration will be reliable or brittle.

• Identity: How do you match the right patient, encounter, provider, and location across systems?
• Terminology: Are diagnosis, procedure, medication, and lab codes normalized to the same code systems?
• Transport: Are you using HL7v2 feeds, FHIR R4 APIs, webhooks, flat files, or a vendor gateway?
• Workflow state: Which system owns draft, signed, pending, canceled, corrected, and reconciled states?
• Governance: Who approves mapping changes, endpoint changes, and break-glass exceptions?

When any one of those is vague, the integration degrades slowly. It does not usually explode on day one. It fails in small, annoying ways: a duplicate patient appears in the inbox, an order lands without the right encounter, a referral closes but the note never arrives, or a medication status update gets interpreted as a brand-new order. Those are the failures that create distrust.

This is why I prefer integrating through a canonical model inside the platform whenever we can. In practice, that means we normalize incoming data into a stable internal structure, then adapt outward to the destination system’s expectations. On a good day, that keeps the rest of the system from learning every vendor quirk. On a bad day, it gives us one place to debug when a payer-facing, patient-facing, or clinician-facing workflow goes sideways.

AST has learned this the hard way on live interfaces where the sandbox behaved beautifully and production behaved like a different product. We once traced a “missing note” issue to a vendor-side quirk that only appeared when a payload contained a certain combination of optional fields. The fix was not just code. We had to add field-level logging, payload hashing, and a replay path so the integration team could reconstruct exactly what moved and what got dropped.

How I build interoperability at AST

Here is the practical sequence I use when the goal is durable exchange between disparate EHR systems.

1. Define the clinical object, not just the interface. Decide whether you are exchanging a patient, encounter, order, result, document, referral, claim, or something else. Then define the minimum data needed to make that object useful on the receiving side.
2. Pick the system of record for each element. One system owns demographics, another owns scheduling, another owns billing, and another may own the final signed note. If two systems both claim ownership, you need a rule for which source wins.
3. Map identifiers early. Patient identity, provider identity, facility identifiers, and encounter numbers should be resolved before downstream transformation. Do not wait until the message is already formatted; by then, the damage is done.
4. Normalize terminology to a controlled vocabulary. Use the code system the receiving workflow expects. If you skip this, free-text clinical meaning will drift and downstream automation will misfire.
5. Validate against real edge cases. Test canceled orders, duplicate demographics, corrected results, split encounters, late-arriving notes, and merged patients. Happy-path testing is not interoperability testing.
6. Build acknowledgments and replay. Every exchange needs a way to prove receipt and a way to resend safely. Without that, you cannot tell the difference between a temporary transport error and a true data loss event.

That sequence sounds obvious until you try to run it against a live EMR with years of historical baggage. The biggest mistake I see is teams assuming the source system is clean, stable, and complete. It never is. One application may send a native HL7v2 feed with decent structure but weak meaning. Another may expose a tidy FHIR endpoint but omit the business logic that clinicians rely on. A third may only cooperate through a vendor API with rate limits and obscure edge rules. You only discover the truth when the payloads start moving.

If you need a technical shorthand for the architecture, I think in layers: source adapters, canonical normalization, rules and matching, transport mediation, and workflow presentation. FHIR R4 is usually the cleanest internal contract for modern app patterns, but it is not the whole answer. HL7v2 is still the reality at many hospitals. X12 matters when the workflow touches eligibility, claims, or payer-side processing. The right architecture respects each standard instead of pretending one replaces the others.

Where Medexa fits when the problem is documentation and downstream claims

When interoperability is tied to documentation, coding, or claims continuity, the exchange problem becomes even more unforgiving. That is why we built Medexa as a co-pilot on top of the provider’s existing EMR or HIS, not a rip-and-replace system. It captures the visit ambiently, anchors codes to the exact words that support them, and then keeps the documentation chain intact as the data moves toward a payer-ready claim. The point is not novelty. The point is reducing the number of places where meaning can get lost.

In AST delivery, I have seen a common pattern: clinicians document one thing, coders interpret another, and the claim engine tries to reconcile both with whatever the EHR surfaced. If the workflow does not preserve the clinical rationale, you end up depending on manual memory and after-the-fact cleanup. Medexa helps because it makes the source of truth explicit instead of hiding it in a note template or a billing queue.

And yes, we keep the trust model narrow on purpose. For anything that touches a payer or a human chart, I want deterministic rules, human approval, and auditability. The machine can assist. It cannot be the final authority just because it inferred something confidently. That is not interoperability. That is guessing with a nicer user interface.

A practical checklist you can use this week

If I were reviewing an interoperability program this week, I would ask the team to walk through this checklist before touching another endpoint.

• Do we have a written source-of-truth matrix for every exchanged field?
• Can we trace one patient record from source intake to downstream display to audit log?
• Have we tested patient merges, corrections, cancellations, and late amendments?
• Do we know which fields are mandatory by workflow, not just by schema?
• Is every transformation reversible enough to debug a failed exchange?
• Do clinicians or operational staff review exceptions before the data becomes visible?
• Can we replay one failed message without creating duplicates?

If the answer to any of those is no, the integration is not ready. That may sound strict, but it saves time. I would rather delay a go-live than spend the next quarter explaining why a technically successful interface keeps producing operational noise.

The most reliable interoperability programs I have seen are boring in the best possible way. They log aggressively. They publish clear ownership. They treat mapping changes like code changes. They test the ugly cases. And they accept that different EHRs, different vendors, and different care settings will never line up perfectly without a deliberate normalization layer.

The real goal is not to make two systems identical. It is to make them coherent enough that clinicians, coders, and operations teams can trust the exchange. That takes more than an interface engine and more than a standards checklist. It takes a design that respects the messiness of clinical work.