What is FHIR? The standard quietly rewiring healthcare

In 2011, an Australian health-IT veteran named Grahame Grieve published a proposal that amounted to a polite act of rebellion. He had spent years inside HL7 — the standards body whose message formats carried most of the world's clinical data — watching its flagship next-generation standard go almost nowhere. His sketch made an unfashionable argument: stop trying to model all of medicine up front, and start copying the web.

That sketch grew into FHIR. A decade and a half later, it sits underneath hospital integrations, national exchange networks, regulatory mandates, and the app on your phone that can pull your own lab results.

What FHIR actually is

FHIR — Fast Healthcare Interoperability Resources, pronounced "fire" — is HL7's standard for exchanging health data as small, predictable packages called resources, served over ordinary web APIs in JSON or XML. If you have ever used an API for payments or maps, you already understand the architecture; FHIR's bet was that health data deserved the same one.

A resource is the unit of exchange. A Patient resource holds demographics. An Observation holds a lab value or a blood-pressure reading. A MedicationRequest holds a prescription. R4, the current workhorse version, defines roughly 145 of these shapes, and they reference each other the way web pages link: the Observation points to the Patient it describes, the MedicationRequest points to the prescriber. Each resource lives at its own URL and answers to the same HTTP verbs that fetch any web page.

That is most of the trick. A developer who has built an ordinary web application already knows the transport, the formats, and the security model — OAuth, the same protocol that lets one app post to another on your behalf. Integration work that used to consume months of bespoke interface engineering can be prototyped in a weekend, and FHIR connectathons exist precisely to prove that, repeatedly, in public.

Why the old standards failed — and what FHIR copied instead

FHIR won by being implementable, which sounds modest until you meet its predecessors. HL7 v2, born in the late 1980s, is terse, pipe-delimited, and still running inside most hospitals. It works, but it is flexible to a fault: every installation is a local dialect, so every new interface becomes a small consulting project. HL7 v3, the intended successor from the early 2000s, made the opposite mistake. It began from a grand unified Reference Information Model and asked implementers to absorb the theory before sending a single message. After a decade of effort, it found little adoption outside the CDA document format.

FHIR's winning choices were cultural as much as technical. The specification is free to use and reads like web documentation rather than a treaty. Public test servers run continuously. The 80/20 rule is explicit policy: the core covers what most systems need most of the time, and everything unusual is handled through extensions instead of making the core heavier. HL7 v3 asked implementers to be patient. FHIR asked the standard to be useful.

R4, the workhorse version

When someone says FHIR in production, they almost always mean R4. Published at the end of 2018, R4 was the first release to carry normative content — core pieces frozen and guaranteed backward-compatible, which is the property regulators and procurement officers wait for before committing. US certification rules pinned to it, Apple's Health Records feature consumed it, and the SMART on FHIR model standardized how third-party apps plug into it. Newer releases exist, but regulation plus installed-base inertia means R4 will anchor real systems for years.

One caveat belongs here, because it surprises nearly everyone: the base specification is deliberately permissive. Almost every field is optional, because the same standard has to serve dozens of countries with different clinical practices. Two systems can both speak flawless FHIR and still fail to understand each other — which is why implementation guides exist, and why the American one matters enough to get its own field note on FHIR R4 and US Core.

The regulatory tailwind

FHIR's path to being mandatory in the United States began in 2016. The 21st Century Cures Act ordered an end to information blocking and required that patients be able to reach their electronic health information through APIs "without special effort" — the statute's own phrase. The 2020 federal rule implementing it chose FHIR R4 as the API standard, and by the end of 2022, certified EHR systems had to expose a conforming patient-access API.

The practical consequence: the ability to download your own records as structured, machine-readable data is now a regulatory floor, not a premium feature. We walk through how to actually exercise it in how to download your own health data as FHIR, and the broader plumbing story — TEFCA, penalties, what still lags — in the interoperability state of play.

What FHIR does not solve

FHIR moves data; it does not guarantee meaning, fitness for research, or permission. Three gaps matter.

Meaning lives in vocabularies. A FHIR Observation can carry any code; whether two hospitals call the same lab test the same thing depends on terminologies like LOINC and SNOMED CT, distributed in the US through the National Library of Medicine, not on FHIR itself.

Research needs a different shape. FHIR is transactional — built to record and exchange care as it happens, one patient at a time. Population-scale analysis wants flat, uniform, query-shaped tables, which is why serious research platforms pair FHIR with the OMOP Common Data Model; we compare the two in FHIR vs. OMOP.

And an API is not consent. A pipe that can hand your record to an app says nothing about who may use that record, for what purpose, for how long, or whether you can change your mind.

That third gap is where Mithras Health builds. The platform keeps FHIR R4 as its system of record, validates every record against pinned US Core 6.1.0 profiles on ingest, and projects OMOP views for research — but nothing is released except under a per-study, revocable, scope-limited consent, behind a hard k ≥ 5 cohort floor, with every event written to an append-only audit trail. FHIR supplies the rails. The covenant has to be built on top of them.

Grieve's 2011 wager — that healthcare's data problem was an implementability problem — has aged remarkably well. The fax machine outlived two generations of health-data standards. It is finally meeting one that ships.