Skip to main content
Spec reference: https://hl7.org/fhir/structuredefinition.html
Profiles tell you “which fields are required, what codes are allowed, and what extensions exist” for a specific use case (usually defined by an IG). Technically, a profile is a StructureDefinition resource that constrains a base resource or datatype.

​
What a profile can constrain

Common profile constraints include:
  • Cardinality: required vs optional fields (e.g. 1..1 instead of 0..1)
  • Fixed values / patterns: e.g. Observation.status must be final
  • Terminology bindings: allowed codes for CodeableConcept and Coding
  • Reference targets: allowed resource types / target profiles
  • Slicing: “this repeating element has named slices with different rules”
  • Invariants: FHIRPath rules that must hold

​
How to spot profiles on an instance

Instances can declare conformance via meta.profile[]: 
{
  "resourceType": "Patient",
  "meta": {
    "profile": ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"]
  }
}
That doesn’t “make it valid” by itself — it’s a claim that a validator or server can verify.

​
Differential vs snapshot

StructureDefinitions often come in two views:
  • Differential: only “what changed” from the base definition
  • Snapshot: the fully expanded structure after applying base + constraints
Validators commonly want snapshots. Many toolchains generate snapshots from a package load step.

​
Where profiles come from

Profiles are almost always distributed via FHIR packages (IG packages). When you install an IG, you install its StructureDefinitions.

​
Next