A FHIR resource definition is not that different from a class definition in a strongly typed language. The names differ, the columns differ, but the pattern is the same: identity fields, then structural fields, then domain-specific fields, each with a type and a cardinality. Once that mapping is in place, reading an unfamiliar resource takes minutes instead of a session. The site's R4 resource atlas surfaces each resource in that shape. For the wider FHIR framing, the FHIR architecture archive collects supporting material.
The Read Order
Every FHIR resource definition has a table with these columns: element, cardinality, type, description. Read them in this order:
- Skim the element list top to bottom for shape
- Note which elements have cardinality lower bound = 1 (required)
- Note which elements have cardinality upper bound = * (repeating)
- Read the type of every reference-shaped element (which resources it points at)
- Read the binding strength on coded elements (required, extensible, preferred, example)
That five-step pass produces enough knowledge to write a valid payload against the resource.
Identity Elements Come First
Every DomainResource carries id, meta, implicitRules, language, text, contained, extension, modifierExtension. These are inherited from the base and behave the same across all resource types. Read them once for the whole spec, not per resource type. For the base pattern, navigating FHIR R4 resources when you know DomainResource but not much else covers them.
Domain Elements Come Next
The elements specific to the resource type are where the meaning lives. Patient has name, identifier, gender, birthDate. Observation has code, subject, value[x], effective[x]. Read the type of each domain element — CodeableConcept, Reference, dateTime, quantity — and the type answers most questions about what the element carries.
The `[x]` Suffix Is a Polymorphism Flag
Elements with [x] in their name accept one of several types at runtime. Observation.value[x] can be Quantity, CodeableConcept, string, boolean, integer, Range, Ratio, SampledData, time, dateTime, Period. The payload uses valueQuantity, valueCodeableConcept, etc., depending on which type was chosen.
Understanding polymorphism is the difference between reading a payload and being surprised by it. Every [x] in the definition is a decision the sender makes.
The Reference Types Are the Foreign Keys
Every Reference element carries a target-type declaration. Those declarations are the equivalent of typed foreign keys in a relational schema. Ignoring them produces payloads that violate the reference contract. For the deeper split of when to reference vs when to contain, reference vs contained: when to embed and when to link is the entry.
Binding Strength Is the Constraint on Coded Values
Coded elements have a binding to a value set with a strength. Required binding means the value has to come from the set. Extensible means it should, but implementers can extend. Preferred and example are advisory. Reading binding strength is what tells you whether a coded value is a hard constraint or a soft suggestion.
Extensions Sit at the End
Every resource can carry extensions. Reading the extensions section tells you which extensions this resource supports and which are common. Profiles add more. For the profile mechanic, profiles and slicing at a glance covers it.
The Short Version
Read cardinality, read type, read binding, note polymorphism, note reference targets. Extensions sit last. That five-check pass turns a FHIR resource definition into something you can code against without guessing. The atlas is the fast lookup; this is the reading pattern.
Sources
- HL7 canonical R4 StructureDefinition resource specification - HL7 canonical R4 StructureDefinition resource specification
