+150 XP

Making systems talk: interoperability with FHIR and HIEs

# 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.

Why systems do not talk by default

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:

  • No connection at all. The systems have no shared pipe.
  • Connection without usability. Data arrives as an unstructured blob (a scanned document), so a clinician still has to read three pages to find one allergy.

HL7 and FHIR: a shared language

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:

json
{
  "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 API. 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.

Health information exchanges: 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:

  • Regional or state HIEs, often nonprofit, covering a geographic area.
  • Vendor networks, where hospitals on the same EHR share through the vendor's own exchange.
  • National networks that connect the connectors.

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.

The old barrier: too many separate networks

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: a network of networks

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 reach 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]

Why it can still fail at the bedside

TEFCA is not magic, and in 2026 it is still maturing. Real gaps remain:

  • Participation. A network only helps if both hospitals actually joined. Onboarding takes time and money, and smaller rural facilities lag.
  • Data quality. The query might succeed but return a record where the medication list was never updated. Garbage in, garbage out.
  • Matching the patient. Networks must confirm that "Jane Smith, DOB 1975" at hospital A is the same person as at hospital B. The US has no national patient identifier, so matching relies on demographics and can fail or return the wrong record.
  • Purpose and consent. Rules govern *why* data can be requested (treatment, payment, public health). State privacy laws add variation, especially for sensitive data like behavioral health.

So the pipe can exist and still deliver an incomplete or unmatched picture. Interoperability is a chain: standard (FHIR), plus network (HIE or QHIN), plus data quality, plus patient matching, plus consent. The chain is only as strong as its weakest link.

Knowledge check

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?

MULTIPLE CHOICE

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?

Select all the correct answers.

MULTIPLE CHOICE

5. Select ALL correct answers. Which of the following are genuine failure modes for making systems 'talk' as described in the lesson?

Select all the correct answers.

Reading the transfer through the three layers

Let us map 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.

What this means for decision makers

If you run or advise a provider organization, interoperability is not one purchase. It is a set of questions:

  • Which networks do we participate in, and do they reach the partners we actually transfer patients to and from?
  • Do our FHIR endpoints work, and are they tested, or just technically "on"?
  • How good is our patient matching? A high duplicate-record rate is a silent interoperability failure.
  • Is our data current at the point it leaves the building?

The technology is increasingly standardized. The remaining value, and the remaining risk, sits in participation, data hygiene, and matching.

Key Takeaways

  • FHIR is the shared language. It turns health data into standardized, machine-readable resources using ordinary web APIs, so a receiving system can act on data instead of just displaying a document.
  • HIEs and QHINs are the pipes. A shared language is useless if the two systems are not connected to the same network; TEFCA aims to link major networks so a single connection can reach the whole country.
  • The chain has weak links. Even with FHIR and TEFCA, transfers fail because of non-participation, stale data, bad patient matching (no national patient ID), or consent restrictions.
  • Diagnose interoperability in layers. Language, network, and data-quality-plus-matching. When data does not reach the bedside, one specific layer broke, and naming it is the first step to fixing it.