Why FHIR — Resources as the Unit of Exchange

A different unit of exchange

v2 exchanges messages; CDA exchanges documents. FHIR — Fast Healthcare Interoperability Resources — exchanges resources: small, modular, independently identifiable units of healthcare data, each representing one coherent thing ¹. A Patient, an Observation, a MedicationRequest, an Encounter — each is its own resource type with a defined structure. Instead of packing everything into one large message or document, FHIR breaks the record into modular pieces that can be created, fetched, and linked individually.

This is the design lesson FHIR took from the web. The modern internet is built from addressable resources retrieved over HTTP; FHIR applies the same idea to health data, which is why it feels like a normal web API rather than a bespoke healthcare protocol ².

What a resource is

A FHIR resource has a few defining properties ¹:

• A type — Patient, Observation, and so on, drawn from a fixed set the specification defines.
• An identity — a logical id that, combined with the server’s base URL and the type, gives the resource a unique address (e.g., [base]/Patient/pat-1).
• Common metadata — a meta element (version, last-updated, profiles it claims to conform to).
• A human-readable narrative — an optional text element, echoing CDA’s insistence that a human can always read the content even if software ignores the structured data.
• Structured data elements — the type-specific fields (a Patient’s name and birth date, an Observation’s code and value).

Resources serialize to JSON or XML; JSON is the common choice for new APIs. The same resource can round-trip between the two formats without loss.

Resources connect by reference

Breaking the record into small pieces only works if the pieces can be reassembled. FHIR does this with references: one resource points at another by its address. In the figure, the Observation names its subject as Patient/pat-1, so a glucose result is tied to the patient it belongs to without copying the patient’s data into the observation ¹. Follow the references and the scattered resources form a connected clinical record — the same information CDA would place in one document, here distributed across linked resources.

When resources do need to travel together — a search result, a set of documents, a batch of updates — they are packaged in a Bundle, a resource whose job is to carry other resources ¹. The next lessons open up resource anatomy, references and bundles, and data types in detail.

Why this matters

The resource model is what gives FHIR its two signature strengths. Granular access: a system can fetch exactly one Observation over a plain HTTP request, rather than parsing a whole document to find it. Reuse: the same Patient resource definition serves admissions, lab, pharmacy, and research, instead of each interface re-inventing how a patient is represented ².

One practical note that the rest of this course assumes: this material follows FHIR Release 4 (R4, v4.0.1), the normative base release and the most widely deployed version; R5 (v5.0.0, 2023) is the latest release and refines but does not overturn these fundamentals ¹. With the unit of exchange established, the next lesson dissects a single resource field by field.