Healthcare Interoperability Solutions: 4 Architectures (2026)
Quick answer. Healthcare interoperability solutions fall into four architectures: vendor-anchored Health Information Exchanges (HIE) such as Epic Care Everywhere, Office of the National Coordinator (ONC) and Fast Healthcare Interoperability Resources (FHIR) R4 based regional exchanges, central data warehouses that physically pool records, and federated Trusted Research Environments (TRE) where compute moves to the data and data never leaves the source.
Healthcare interoperability solutions are the technical and governance systems that let clinical, genomic and claims data move — or be queried in place — across organisations, regions and national borders. In 2026 the credible options collapse to four architectures: vendor-anchored HIEs like Epic Care Everywhere, FHIR R4 regional exchanges built on the ONC stack, centralised data warehouses that pool records, and federated TREs in which compute travels to the data. The choice is no longer about file formats — it is about who holds the data, who carries the legal risk, and whether the architecture survives a hostile audit.
Why interoperability looks different in 2026
Two events reset the conversation. In May 2026, approved researchers at UK Biobank walked derived data out of a centralised software-as-a-service (SaaS) TRE through its normal workflow — a reminder that even tightly governed central platforms inherit copy-out risk by design. In parallel, the European Health Data Space (EHDS) Regulation reached its Article 50 secondary-use timeline, the United States Office of the National Coordinator for Health Information Technology (ONC) finalised onboarding of major Qualified Health Information Networks (QHIN) under the Trusted Exchange Framework and Common Agreement (TEFCA), and the United Kingdom’s NHS Federated Data Platform (FDP) moved into its second deployment wave.
The combined effect is regulatory: data custodians can no longer treat interoperability as a clinical messaging problem solved by a Health Level Seven (HL7) feed. They must show that secondary use — research, artificial intelligence (AI) training, population analytics — is auditable to the row level and that derived outputs cannot leave without inspection.
The four interoperability architectures
1. Vendor-anchored HIEs (Epic Care Everywhere, Oracle Health, MEDITECH Traverse)
Vendor HIEs solve clinical care continuity. Epic’s Care Everywhere now exchanges records across roughly 80% of US hospitals through the Epic Nexus QHIN designation under TEFCA, and Oracle Health (formerly Cerner) operates an equivalent network with CommonWell. These exchanges are FHIR R4 capable at the resource level but optimised for point-of-care queries — a clinician pulling a patient summary, not a population epidemiologist pulling a five-million-row cohort. They are excellent for treatment and operations under the United States Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule. They are weak for cross-jurisdictional research because they require a treating relationship or a permitted purpose under TEFCA’s narrow exchange purposes.
2. ONC/FHIR-based regional exchanges
Regional Health Information Organisations (RHIO) and state-level HIEs — the Sequoia Project’s eHealth Exchange, CRISP in Maryland, Manifest MedEx in California — built their next generation on the ONC United States Core Data for Interoperability (USCDI) v4 and FHIR R4 standards. These non-vendor exchanges broker records between providers, payers and public health agencies, and are the rails for TEFCA’s Public Health and Government Benefits Determination purposes. Their architectural limit mirrors vendor HIEs: data is replicated into the exchange’s repository, so every consumer that needs analytical depth becomes another copy of the cohort — the residual identification risk that the EHDS and the UK Information Commissioner’s Office (ICO) Anonymisation Code of Practice now flag explicitly.
3. Centralised data warehouses and SaaS TREs
The dominant pattern for secondary use today: custodians extract records, harmonise them against the Observational Medical Outcomes Partnership Common Data Model (OMOP CDM) v5.4 or Sentinel CDM, and load them into a single cloud warehouse. The Observational Health Data Sciences and Informatics (OHDSI) consortium, the US Food and Drug Administration’s Sentinel Initiative, and several national biobanks run versions of this model. Centralisation buys speed — every analyst sees the same schema — but concentrates legal, cyber and reputational risk in one tenancy. The UK Biobank incident showed that even with row-level access control, the workflow itself can permit derived data to exit. Central warehouses are right when the data is already de-identified to a public-use standard, and wrong when the source remains identifiable.
Comparison of the four architectures
| Dimension | Vendor HIE (Epic, Oracle) | Regional FHIR exchange | Central warehouse / SaaS TRE | Federated TRE (Lifebit, NHS FDP, NIH NLM) |
|---|---|---|---|---|
| Primary use case | Clinical care continuity | Public health, payer-provider exchange | Secondary use research, AI training | Secondary use research, sovereign AI, population analytics |
| Standards | FHIR R4, USCDI v4, HL7 v2 | FHIR R4, USCDI v4, IHE profiles | OMOP CDM v5.4, FHIR R4 ingestion | OMOP CDM v5.4, FHIR R4, GA4GH Data Connect |
| Where data physically lives | Replicated into exchange directory | Replicated into HIE repository | Centralised cloud tenancy | Stays at custodian — data never leaves the source |
| Copy-out risk | High (multiple cached copies) | High (each consumer copies) | High (workflow permits derived export) | Low (automated airlock on every output) |
| Audit granularity | Query-level | Query-level | Project-level | Row-level, code-level, output-level |
| Cross-jurisdiction fit | Weak — TEFCA permitted purposes only | Weak — state or national scope | Constrained by data residency | Native — each node respects its own sovereignty |
| Representative deployments | Epic Nexus, CommonWell | eHealth Exchange, CRISP, Manifest MedEx | Sentinel, OHDSI network studies | Genomics England, NHS FDP, Synapxe, NIH NLM, CanPath |
FHIR R4 is necessary but not sufficient
Every architecture above speaks FHIR R4 — the floor, not the ceiling. FHIR resolves the syntactic problem of how a Condition or Observation is serialised, but not the semantic problem of harmonising SNOMED CT, International Classification of Diseases Tenth Revision Clinical Modification (ICD-10-CM), Logical Observation Identifiers Names and Codes (LOINC), RxNorm and Anatomical Therapeutic Chemical (ATC) across cohorts never collected with research in mind. Data Harmonisation is where interoperability pays off: AI-automated mapping to OMOP CDM v5.4, with provenance preserved back to the source vocabulary, is what lets a federated query against five biobanks return a single coherent answer. The Global Alliance for Genomics and Health (GA4GH) Phenopackets and Data Connect standards extend the same logic to genomic phenotypes.
Three deployments anchor the federated pattern. The NHS Federated Data Platform connects English trusts so elective recovery, population health and vaccine programmes can run without aggregating records into a central NHS England warehouse. Singapore’s Synapxe — the national health technology agency — operates the country’s federated research substrate across public hospitals and polyclinics, supporting the Ministry of Health’s HealthierSG longitudinal programme. The NIH NLM unified discovery service (FedRAMP authorised) federates query across NIH data commons so researchers can locate cohorts without each commons exporting its metadata. Each is operating at national scale and shows that federation is the production substrate for sovereign health AI.
How to choose, in practice
Three questions decide the architecture. First: who carries the legal liability if a record is re-identified downstream? If the answer is the data custodian, a federated TRE bounds that liability because the custodian never relinquishes physical control. Second: how many jurisdictions does the cohort span? Single-state scopes fit a regional FHIR exchange or vendor HIE; anything cross-border collapses to federation. Third: is the workload secondary use? Care continuity belongs in vendor HIEs; research, AI training and population analytics belong in a federated TRE — and regulators (EHDS Article 50, NHS England Data Saves Lives, US HHS Office for Civil Rights) increasingly expect that pattern.
A defensible 2026 stack layers all four: a vendor HIE for treatment, a regional FHIR exchange for public health reporting, a harmonised OMOP CDM layer for internal analytics, and a federated TRE for anything touching identifiable data or crossing an organisational boundary. The federated layer closes the audit.
Frequently asked questions
What is the difference between an HIE and a TRE?
A Health Information Exchange (HIE) is built for clinical care continuity — a clinician pulling a patient summary at the point of care. A Trusted Research Environment (TRE) is built for secondary use — research, AI training, population analytics — with row-level audit, output airlocks and reproducible queries. The two are complementary, not interchangeable.
Is FHIR R4 enough on its own for interoperability?
No. FHIR R4 solves the syntactic problem of how clinical resources are serialised, but does not solve semantic harmonisation across SNOMED CT, ICD-10-CM, LOINC and local vocabularies. Production interoperability requires a harmonisation layer — typically OMOP CDM v5.4 — on top of FHIR R4.
Why do federated TREs avoid the UK Biobank-style incident?
Because data never leaves the source. There is no central copy to export, every output passes an automated airlock, and the researcher only ever sees inspected results — not the underlying record-level data. The exfiltration workflow that compromised the centralised platform is architecturally absent.
Does TEFCA make central warehouses safer?
TEFCA improves clinical exchange interoperability between QHINs under defined permitted purposes, but it does not address secondary-use copy risk. A QHIN connection feeds a downstream warehouse with the same governance debt as any other extract-transform-load pipeline.
Can a federated TRE work across countries with different data protection laws?
Yes — that is its core property. Each node respects its own jurisdiction: General Data Protection Regulation (GDPR) in the European Union, HIPAA in the United States, Personal Data Protection Act (PDPA) in Singapore. Compute travels to the data, so no record crosses a border. Federated deployments at Genomics England, CanPath, Synapxe and the Danish National Genome Center operate on this principle.
What standards should a 2026 interoperability stack support?
FHIR R4 with USCDI v4 at the exchange layer, OMOP CDM v5.4 for analytical harmonisation, GA4GH Phenopackets and Data Connect for genomic phenotypes, and Health Level Seven Version 2 (HL7 v2) where legacy clinical feeds persist. Federated query protocols such as GA4GH Data Connect sit above all of these.