FHIR Schema: Practical Notes on the Resource Structure

FHIR resource anatomy — resourceType, id, meta, extension, modifierExtension, type-specific fields — narrowed by profile constraints.

The FHIR schema — the underlying structure of resources — is well-documented but has practical patterns worth internalizing. Understanding schema mechanics prevents integration surprises.

Resource anatomy

Every resource has:

1. resourceType — the resource name. 2. id — server-assigned identifier. 3. meta — versionId, lastUpdated, profile references, tags, security labels. 4. extension[] — custom fields. 5. modifierExtension[] — extensions that change the meaning of adjacent elements. 6. Type-specific fields — Patient has name, gender; Observation has code, value.

Data types

FHIR defines primitive types (string, integer, dateTime), complex types (HumanName, Address, Quantity), and reference types (Reference to another resource).

Extension mechanism

Extensions add fields without changing base spec. Each extension has:

- url — canonical URL identifying the extension StructureDefinition. - value[x] — the extension value. - Optional nested extension[] for complex extensions.

Profile constraints

Profiles narrow the base schema:

1. Required elements. Cardinality bumped to 1..1 or 1..*. 2. Forbidden elements. Cardinality set to 0..0. 3. Terminology bindings. Coded fields bound to specific ValueSets. 4. Fixed values. Elements set to specific values. 5. Slicing. Repeating elements categorized by discriminator.

Common schema mistakes

1. Custom extensions without StructureDefinition. Non-conformant, downstream can't validate. 2. Wrong data type. `$validate` catches this. 3. Missing required elements per profile. Non-conformant. 4. Reference type mismatch. Reference to wrong target resource type.

Tools for schema exploration

1. HL7 FHIR spec — reference documentation. 2. US Core spec — US-specific profiles. 3. Server-provided CapabilityStatement — what your server actually supports. 4. Inferno for validating against profiles.

Extension governance

Organizations creating custom extensions should:

1. Publish StructureDefinitions. 2. Version-control extension changes. 3. Include validation in write path. 4. Document extension purpose and semantics.

FHIR schema is well-designed for extensibility while maintaining conformance. Get the extension governance right and future extensions add cleanly.

Share: Facebook Twitter Linkedin

Comments are closed.