Ciklum

TL;DR

You do not have to replace the EHR to fix interoperability. A thin architectural layer over the systems already in production (FHIR facades, canonical data models, patient identity resolution, and compliance built into the pipeline) is enough to meet TEFCA, the CMS Interoperability and Prior Authorization Final Rule, and the FHIR R4 mandates. The organizations pulling ahead in 2026 are not the ones with the cleanest stack. They are the ones treating interoperability as a continuous engineering discipline rather than a one-time migration project.

Introduction

Healthcare interoperability is usually framed as a sequencing problem. First, replace the legacy EHR. Then, modernize the data layer. Then, adopt FHIR. Then, build the clinical workflows that depend on it. By the time a hospital finishes step one, the budget for the rest has been redirected somewhere else. That is why so many interoperability programs stall at exactly the same point: the rip-and-replace is too expensive and too disruptive to clear, and nothing else can start until it does.

The premise of this article is that the sequence is wrong. Modern interoperability does not require a full system overhaul. It requires a thin architectural layer over the systems that are already in production, and the discipline to keep building it.

The Adoption Gap Nobody Has Closed With Replacement

The data exchange numbers in 2026 still tell the same uncomfortable story. Roughly 70% of US hospitals participate in some interoperable data exchange, but only 43% do it routinely, per the Office of the National Coordinator for Health IT. Less than 42% of clinicians routinely use the health data they receive when treating patients. In the UK, 93% of NHS trusts have electronic patient records but only 30% have fully integrated bi-directional data flows across the rest of their stack.

FHIR was supposed to be the leveling event. The standard is now widely supported by EHR vendors, and ONC data on hospital API use shows roughly 70% of hospitals offer FHIR-based patient access. But underneath that statistic, the picture changes. The same hospitals still route most of their day-to-day clinical exchange through HL7 version 2 messages and CDA documents. The modern standard exists at the edge. The plumbing inside the building is still mostly legacy.

That gap is exactly why the replacement strategy keeps losing. Hospitals do not need every internal system to speak FHIR. They need every internal system to be reachable through FHIR. Those are different problems with very different price tags.

The FHIR Facade and Why It Changed the Math

The architectural shift that made incremental modernization viable is the FHIR facade. The pattern is straightforward. An API gateway sits in front of the legacy system. When an outside application asks for a patient record, the facade translates the FHIR request into whatever the legacy system natively speaks, retrieves the data, transforms the response into a FHIR resource, and returns it. The legacy system never changes. The outside world sees a clean, standards-compliant API.

Typical implementations combine an OAuth2 authentication layer (typically SMART on FHIR), a translation engine for FHIR-to-HL7v2 conversion, a cache layer, and a connection pool with a circuit breaker for the legacy backend. None of those components require touching the EHR, and they are deployable in months rather than years.

The same pattern is now sufficient to meet the new mandates. The CMS Interoperability and Prior Authorization Final Rule requires impacted payers to begin reporting API use metrics in January 2026, with Patient Access, Provider Directory, and Prior Authorization APIs built on FHIR R4 due in full by January 2027. None of that obligation reaches into the underlying clinical or claims systems. It applies at the API surface, and a well-designed facade gets a payer or provider into compliance without changing a single line of legacy code.

Canonical Data Models and Patient Identity

The FHIR facade solves the format problem. It does not solve the data problem. Two systems that both speak FHIR can still disagree on what a patient looks like, how a diagnosis code is structured, or which medication record is current. Without a layer that resolves those disagreements, the integration delivers fast exchange of unreliable records.

The incremental fix at this layer is a canonical data model. Pick the clinically critical fields, define them once, and normalize the data as it moves through the facade. Patient identity is the single most important field in this set. A USCDI-aligned profile that resolves the same person across the EHR, the lab system, the billing platform, and the patient portal does more for interoperability than any standard adoption decision a CIO will make this year. Once identity is reliable, exchange is reliable. Until it is, every other layer is patching around an underlying inconsistency.

The same principle shows up in non-clinical work. When a global medtech company operating in more than 150 countries rebuilt its order fulfillment and ERP integration, the engineering problem was the same shape as a clinical interoperability problem: multiple systems holding versions of the same record, no canonical identity, and a manual reconciliation layer that absorbed staff time. The fix was not to replace the underlying systems. It was a unified Salesforce-based commerce layer with ERP and payment integration, anchored on a single record per customer interaction. The missing piece in most interoperability programs is not the standard. It is the canonical identity that lets a standard mean the same thing in every system it touches.

Compliance Built In, Not Bolted On

Healthcare runs under HIPAA, HITECH, and a growing patchwork of state privacy regulations. The Information Blocking Rule has already generated about 1,300 complaints, and CMS interoperability penalties reach $1.5 million per violation category per year. Compliance is not a final review. It is a constraint that has to live inside the architecture.

Compliance should be engineered directly into the architectural foundation - encryption in transit and at rest, audit logging for every access, SMART on FHIR-based fine-grained authorization, and formal BAAs with every vendor in the data flow. When a telemedicine platform serving over a million clinicians needed to scale, the engineering team did not begin with new clinical features. They built the foundation first: 100% Infrastructure as Code via Terraform, continuous monitoring through CloudWatch, and HIPAA controls embedded in the deployment pipeline. The features that came after worked because the foundation underneath them was trustworthy.

That ordering applies to interoperability just as cleanly. A FHIR facade without observability is a security audit waiting to happen. A canonical patient identity layer without lineage is a clinical incident waiting to happen. Building HIPAA-secure infrastructure is specialized work, and the engineering capacity for it is the bottleneck in most health systems that have tried to do this in-house.

Where the Network Effects Are Already Showing Up

The federal infrastructure to support all of this has matured faster than most operators have noticed. TEFCA, the Trusted Exchange Framework and Common Agreement, designated its first Qualified Health Information Networks in late 2023. By the end of 2025, 464 million documents had been exchanged across TEFCA, up from roughly 10 million before that year began. That is a 40-times growth curve in a single year, and the trajectory is still steepening as more QHINs go live.

For a hospital, the practical effect is that the network it needs to connect to is already running. The work is to expose its own data into that network reliably, which is again a facade-layer problem, not a platform-replacement problem. The same is true for pharmaceutical and life sciences organizations building ML-powered audit and analytics on top of regulated data. The model only works because the data pipeline underneath it is designed for traceability and explainability. Replace the model and the work continues. Replace the pipeline and the program stops.

The Operating Discipline That Actually Closes the Gap

The organizations making real progress on interoperability in 2026 share three habits. They expose data through a facade rather than replacing the system that holds it. They resolve patient identity at the canonical layer before they worry about everything downstream. And they treat compliance as an architecture decision, not a final approval. None of that requires a new platform. All of it requires sustained engineering discipline.