# Making systems talk: interoperability with FHIR and HIEs
A patient arrives unconscious in the emergency department at 2 a.m. She was transferred from a smaller hospital 40 miles away. The paramedics hand over a printed summary. It is three pages, partly illegible, and missing her current medication list. The receiving hospital runs a different electronic health record (EHR) than the sending facility. On paper, both hospitals are "digital." At the bedside, the data gap is real and dangerous.
This lesson follows that transfer to show how three things (HL7 FHIR APIs, health information exchanges, and the TEFCA framework) either close or fail to close that gap.
An EHR is the software a hospital uses to store patient records: notes, labs, medications, imaging, billing. In the US market, a handful of vendors dominate large hospitals, with many smaller vendors serving clinics and rural facilities.
The problem: each EHR was built as a closed system. Historically, data was stored in proprietary formats. Getting information out often meant faxing, printing, or a costly custom integration project.
Interoperability is the ability of different systems to exchange data and actually use it. Not just move a PDF, but move structured data a receiving system can read, sort, and act on.
Two failure modes matter for our patient:
HL7 (Health Level Seven) is the standards body that defines how healthcare systems format and exchange data. Older HL7 standards (v2 messages, and the CDA document format) are widely used but clunky and hard to work with.
FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") is HL7's modern standard. It matters because it borrows the same web technology that powers ordinary apps: REST APIs and JSON. If you have ever used an app that pulls your bank balance, that is the same architectural idea.
FHIR breaks health data into "resources," each a standardized unit: Patient, MedicationRequest, AllergyIntolerance, Observation (for a lab result or vital sign), Condition (a diagnosis).
Here is what a single medication looks like as a FHIR resource, simplified:
{
"resourceType": "MedicationRequest",
"status": "active",
"medicationCodeableConcept": {
"text": "Warfarin 5 mg oral tablet"
},
"subject": { "reference": "Patient/12345" },
"dosageInstruction": [
{ "text": "Take 1 tablet once daily" }
]
}That structure is the point. The receiving hospital's system can read status: active and Warfarin as data fields, not as text buried in a scanned page. It can flag a dangerous interaction automatically.
In the US, federal rules now require certified EHRs to offer a standard FHIR APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète →. The 21st Century Cures Act and its "information blocking" rules (enforced from 2021 onward) make it illegal for most healthcare actors to unreasonably interfere with access to electronic health information. In practice this pushed vendors to expose FHIR endpoints. You can browse the specification itself at hl7.org/fhir.
FHIR solves the *language* problem. But a shared language does not mean the two hospitals are connected. Someone still has to run the pipes.
A health information exchange (HIE) is an organization that connects many providers so they can share patient records. Think of it as a switchboard. Instead of every hospital building a direct link to every other hospital (an impossible number of connections), each connects once to the HIE, and the HIE routes requests.
HIEs come in a few flavors:
Back to our patient. If the sending hospital and the receiving hospital both participate in the same regional HIE, the ED physician can query the network and pull her records: an active Warfarin prescription, a recent creatinine lab, a documented penicillin allergy. The data gap closes.
If they do not share a network, the query returns nothing, and we are back to the illegible fax.
For years the US had a patchwork. One hospital might belong to a state HIE and a vendor network; a neighbor might belong to a different national framework. Query one, and you missed the others. The transfer succeeds or fails based on geographic and vendor luck, not on the patient's need.
This fragmentation is exactly what the newest layer was designed to fix.
TEFCA stands for the Trusted Exchange Framework and Common Agreement. It is a US initiative, created under the Cures Act and coordinated by the federal health IT office (ONC), to link the major networks together under one common set of rules.
The key concept: a QHIN (Qualified Health Information Network). A QHIN is a large network that meets TEFCA's requirements and agrees to exchange data with all other QHINs. The first QHINs were designated in late 2023, and the framework has been expanding since.
The idea is elegant. A hospital connects to one QHIN. That QHIN can reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → every other QHIN. So the receiving ED in our story queries its own network, and the request flows across TEFCA to wherever the patient's records live. No more asking "are we both on the same specific HIE?"
🎬 [VIDEO: "What is TEFCA?" — youtube.com — a short explainer from health IT educators on how the Trusted Exchange Framework connects networks nationally]
TEFCA is not magic, and in 2026 it is still maturing. Real gaps remain:
So the pipepipeAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → can exist and still deliver an incomplete or unmatched picture. Interoperability is a chain: standard (FHIR), plus network (HIE or QHIN), plus data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.Voir la définition complète →, plus patient matching, plus consent. The chain is only as strong as its weakest link.
Vérification des acquis
1. A hospital sends a scanned three-page PDF of a patient's records to another facility that can open and display it. Why does this still represent a failure of interoperability?
2. Why were traditional EHRs historically unable to share data easily with other systems?
3. What best describes the relationship between HL7 and FHIR?
4. Select ALL correct answers. Two hospitals both describe themselves as 'digital,' yet a real data gap exists at the bedside during a patient transfer. Which factors explain this apparent contradiction?
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers. Which of the following are genuine failure modes for making systems 'talk' as described in the lesson?
Sélectionnez toutes les réponses correctes.
Let us mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Voir la définition complète → our patient's 2 a.m. transfer onto the stack, because this is how to think about any interoperability problem.
Layer 1, the language (FHIR). Both EHRs are certified and expose FHIR APIs. Good. The medication and allergy data can be represented as structured resources.
Layer 2, the network (HIE / QHIN). The receiving hospital belongs to a QHIN. So does the sending hospital's vendor network. Under TEFCA, the ED's query reaches across and returns the records. This is the layer that decides whether any data moves at all.
Layer 3, the reality checks. The patient was matched correctly (her demographics were clean). Her medication list had been updated at her last visit. Consent rules permitted a treatment query. All three held, so the Warfarin appears on the ED screen before the physician orders a procedure that would have caused a bleed.
Change any one variable and the story ends differently. If the sending hospital never joined a network, layer 2 fails and nothing moves. If her name was misspelled at intake, layer 3 fails and the query returns nothing or, worse, someone else's record.
For a broad, vendor-neutral primer on where US interoperability policy stands, the federal health IT office maintains public resources at healthit.gov.
If you run or advise a provider organization, interoperability is not one purchase. It is a set of questions:
The technology is increasingly standardized. The remaining value, and the remaining risk, sits in participation, data hygiene, and matching.