Resources, profiles & references
FHIR's grammar in three ideas: resources are the nouns, references are the joins, profiles are the local rules.
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.