Resources, profiles & references

The answer in one paragraph

Everything in FHIR reduces to three ideas. Resources are ~145 standardised building blocks (Patient, Observation, Condition, Encounter…), each with defined elements and its own URL. References join them — an Observation points at Patient/p-1042 the way web pages link, making the record a navigable graph. Profiles constrain the deliberately loose base resources for a real use case — "in this country, Patient must have an identifier from this system" — because base FHIR optimises for global flexibility and profiles supply the local strictness that makes data computable.

Resources: broad on purpose

The base spec serves every healthcare system on Earth, so almost everything is optional: a bare {"resourceType": "Patient"} is technically valid. Elements carry defined types (the tricky-but-vital ones: CodeableConcept for coded values, Identifier with its system+value pair, Reference for links), and each resource declares its maturity level — how battle-tested it is across implementations.

References: the joins of healthcare

{ "resourceType": "Observation",
  "subject":   { "reference": "Patient/p-1042" },
  "encounter": { "reference": "Encounter/e-77" } }

Chasing references is how anything real gets assembled — a discharge summary is a walk across the graph. Bundles package resources for transport (search results, documents, transactions); inside a Bundle, entries reference each other before they ever have server URLs, which is its own small art.

Profiles: where interoperability actually happens

A profile (technically a StructureDefinition) tightens the base: forbid elements, make optional things mandatory, fix cardinalities, and — most powerfully — bind coded elements to specific value sets ("Observation.code comes from these LOINC codes"). Profiles travel in Implementation Guides (IGs): published rulebooks like US Core or India's NRCeS profiles. The operational consequence: "we support FHIR" means little; "we conform to IG X version Y" is the sentence that makes systems interoperate. Validation against profiles is how you prove it — and what the future Validation Workbench lab makes hands-on.

Where to go next

US Core & India (NRCeS) profiles — two national rulebooks side by side, and why the same Patient looks different in each.