The FHIR data model has specific concepts that shape how you think about healthcare data. Five that matter most for practitioners working with FHIR:
1. Resources are semantic units. Patient, Encounter, Observation are complete, meaningful units. Unlike relational rows, resources encapsulate related data.
2. References are typed. Observation.subject.reference points at a resource of specific type. Not just any URL; type-checked.
3. Profiles constrain, not replace. US Core Patient is a Patient with additional constraints. Base Patient is still valid; profiled Patient is more specific.
4. Extensions add without breaking. Custom fields via Extension reference StructureDefinitions. Downstream that doesn't know the extension ignores it safely.
5. Bundles group with intent. Bundle type dictates semantics — transaction (atomic writes), batch (independent), searchset (query response), collection (grouping).
Implications for data handling
1. Resource-centric queries. Query by resource type + search parameters; not by generic JSON paths. 2. Reference resolution. Following references means fetching linked resources; batched via _include. 3. Terminology awareness. Coded fields need terminology server integration. 4. Version awareness. ETag/If-Match for optimistic concurrency. 5. Profile awareness. Validate against target profile, not just base spec.
Common data model mistakes
1. Treating FHIR resources as generic JSON objects. 2. Ignoring reference type constraints. 3. Custom fields without extensions. 4. Skipping profile constraints. 5. Bundle type confusion.
Tools for exploring the data model
1. HL7 FHIR spec — reference. 2. Server CapabilityStatement — what your server supports. 3. $validate — verify data against profile. 4. Inferno — automated conformance testing.
FHIR data model is well-designed for healthcare complexity. Grasping the five concepts above unlocks everything else.
