The FHIR data model is often described as "resources + REST." Five concepts underneath that description are what production systems actually rest on.

Concept 1: Resource identity. Every resource has a stable identifier ({ResourceType}/{id}), a version identifier (meta.versionId), and a meta.lastUpdated timestamp. These three enable versioning, incremental sync, and consistent references.

Concept 2: References vs. contained. Related resources link via reference fields (e.g., Observation.subject.reference: 'Patient/123'). Contained resources embed inline; discouraged for reusable entities.

Concept 3: Profiles as constraints. Profiles narrow the base resource — required elements, cardinality, terminology bindings. US Core is a profile suite that constrains generic FHIR for US healthcare.

Concept 4: Extensions. Custom fields not in the base spec added via Extension. Each extension references its StructureDefinition.

Concept 5: Bundle for grouping. Bundle groups resources for search responses, transactions, or batch operations. Bundle types (transaction, batch, searchset, collection) have distinct semantics.

Model implications

1. Immutability of references. Changing a resource's id breaks references. Systems shouldn't change IDs. 2. Versioning discipline. ETag/If-Match versioning prevents lost updates. 3. Profile enforcement. $validate against target profile ensures conformance. 4. Extension governance. Custom extensions need documented StructureDefinitions. 5. Bundle transaction semantics. Understand transaction vs. batch differences.

Common data model mistakes

1. Custom extensions without StructureDefinition → downstream can't validate. 2. Contained resources for reusable entities → duplication. 3. Reference by id instead of full reference URL → cross-system breakage. 4. Skipping profile constraints → non-conformant data lands in store.

FHIR data model concepts, once understood, make everything else consistent. Get these five right and specific implementations follow naturally.