What is FHIR? A 5-minute primer
The mental model behind healthcare's most important data standard — resources, references, and REST.
Why FHIR exists
Healthcare systems have always needed to exchange data — labs to hospitals, hospitals to insurers, apps to EHRs. For decades the workhorse was HL7 v2: pipe-delimited messages that work, but are rigid, ambiguous, and painful to extend.
FHIR (Fast Healthcare Interoperability Resources) is HL7's modern answer: healthcare data modeled as small, composable resources, exchanged over plain REST APIs as JSON.
The three ideas that matter
1. Resources
Everything is a resource: Patient, Observation, Condition, MedicationRequest, Encounter. Each has a defined structure — fields, types, allowed codes. A blood pressure reading is an Observation; the person it belongs to is a Patient.
{
"resourceType": "Patient",
"id": "example",
"name": [{ "family": "Sharma", "given": ["Anita"] }],
"birthDate": "1988-04-12"
}
2. References
Resources point at each other the way web pages link: an Observation has "subject": { "reference": "Patient/example" }. Your clinical record is a graph of small documents, not one giant blob.
3. REST
You read and write resources with ordinary HTTP:
| Action | Request |
|---|---|
| Fetch a patient | GET /Patient/example |
| Search observations | GET /Observation?subject=Patient/example&code=85354-9 |
| Create a condition | POST /Condition |
If you have ever used any web API, you already know how to use a FHIR server.
Versions in the wild
- R4 — the version the world runs on; what India's ABDM profiles (NRCeS) build on
- R4B / R5 — incremental refinements
- R6 — in normative ballot now; aims to make the core resources stable for decades
Where to go next
- HL7 v2 → FHIR: the mental model — how the old world maps to the new
- Resources & profiles — how countries and projects constrain FHIR for their needs