Health Data Standards, Explained Plainly

FHIR — Fast Healthcare Interoperability Resources, almost always just said as “fire” — breaks a patient's record into small, named pieces called resources: a Patient resource, a Condition resource, a MedicationRequest resource. Every vendor that supports FHIR agrees on the same field names and the same coding systems inside each one, which is exactly the agreement the last chapter's two hospitals were missing.

FHIR is not the first attempt at this. It is the fourth major generation of a standard published by the same organisation, HL7, and it only makes sense once you have seen what it replaced — a format that is, remarkably, still running underneath most of American healthcare today.

Before FHIR, the standard almost every hospital system spoke was HL7 version 2, first published in 1987. Its job was narrower than FHIR's: get a lab result, an admission notice, or an order from one hospital system to another in real time, without a courier walking a printout down a hallway. For that job it worked, and it is the reason a message typed at a nurse's station can update a pharmacy system seconds later.

MSH|^~\&|REGISTRATION|GENHOSP|LAB|GENHOSP|202603140930||ADT^A01|4821|P|2.3PID|1||482||DOE^JANE||19910604|FPV1|1|I|MED^204^1||||1234^SMITH^ROBERT|||MED

Read it as a stack of segments, each one starting with a three-letter code and each field inside it separated by a pipe: MSH is the message header, PID is patient identity, PV1 is the visit. There is no field name anywhere in the message — position is the only thing telling a receiving system that the fourth pipe-separated value in PID is a birth date. Miscount a pipe and you have silently shifted every field after it.

That positional format was fast to parse and cheap to implement in 1987, which is exactly why it spread. What it did not solve is the problem from the last chapter: v2 lets a message get from one system to another, but it never forced two hospitals to fill those positions with the same codes. Each hospital's interface team also had licence to bolt on custom Z segments — locally invented fields with no shared meaning outside that one building — so two “standard” v2 feeds could still be incompatible in practice.

Here is a simplified Condition resource — the FHIR shape for exactly the diabetes diagnosis from the last chapter, written one single way instead of two competing ways.

{  "resourceType": "Condition",  "code": {    "coding": [{      "system": "http://hl7.org/fhir/sid/icd-10-cm",      "code": "E11.9",      "display": "Type 2 diabetes mellitus without complications"    }]  },  "subject": { "reference": "Patient/482" },  "recordedDate": "2026-03-14",  "clinicalStatus": "active"}

Reading each field in plain English:

The part that actually changed the economics is not the JSON — plenty of older formats were structured too. It is that FHIR resources are fetched over ordinary REST: a plain GET /Patient/482/Condition over HTTPS, the same pattern a web developer already uses against any other API. Reading a v2 feed instead means standing up a dedicated interface engine and paying an analyst to hand-map every field position for every hospital you connect to.

FHIR and HL7 v2 are both just envelopes — shapes for carrying data from one place to another. Neither one tells you what code to put inside the envelope for “Hemoglobin A1c” or “metformin.” That job belongs to a separate layer of terminologies, each covering a different kind of fact:

Here is why the distinction matters in practice, not just in theory. The same lab result — a patient's A1c reading — looks completely different depending on which system carries it. Under the old approach, a lab result travelling in an HL7 v2 message often carried whatever short code that specific lab invented:

OBX|1|NM|A1C^Hemoglobin A1c^GENHOSP-LAB||7.2|%|4.0-5.6|H|||F

A1C means something only inside that one lab's own system — GENHOSP-LAB is even named directly in the segment, because there is no shared registry to point to instead. The same result, expressed as a FHIR Observation using the correct terminology, looks like this:

{  "resourceType": "Observation",  "code": {    "coding": [{      "system": "http://loinc.org",      "code": "4548-4",      "display": "Hemoglobin A1c/Hemoglobin.total in Blood"    }]  },  "subject": { "reference": "Patient/482" },  "valueQuantity": { "value": 7.2, "unit": "%" }}

4548-4 means the exact same test at every hospital on earth that uses LOINC, which is nearly all of them. A receiving system does not need to know which lab drew the blood to know what was measured — it just needs to recognise one code, once. That is the practical benefit of a shared terminology: the envelope carries the data, the terminology makes the data legible to a stranger.

Standards like this existed in earlier forms decades before most hospitals adopted them. The delay was never really about the technology. Every hospital that had already built its own record system had years of data locked into its own format, and rewriting that system to speak a new standard cost real money with no obvious short-term payoff for that specific hospital — the benefit mostly accrued to other hospitals trying to read its data.

The terminologies had their own slower path. SNOMED CT alone runs to more than 350,000 concepts, and mapping a hospital's existing home-grown codes onto it — rather than just adopting it for new records going forward — is years of unglamorous clinical review work that no product roadmap prioritises on its own.

What finally moved the needle was regulation, not persuasion: government rules requiring certified systems to support FHIR gave every vendor the same deadline at the same time, which is the only way an industry-wide standard actually spreads — nobody wants to be first, and nobody wants to be last once everyone else has moved.