📖 Profiling
From a base resource to agreed local rules
The FHIR specification defines base resources that can be used in many different settings. Real projects usually need more specific rules. For example, a hospital, national programme, or research network may need a particular element to be present or may restrict which codes can be used.
Profiling means defining those additional rules while staying
within the boundaries of the base FHIR resource. The published set of
rules is called a profile. Technically, a profile is published as a
StructureDefinition resource.
A profile can, for example:
- make an optional element required;
- limit the allowed values or data types;
- specify which terminology or value set to use; and
- require or constrain a governed extension.
Cardinality: how often may an element appear?
FHIR expresses the minimum and maximum number of occurrences as cardinality:
0..1means zero or one occurrence, so the element is optional;1..1means exactly one occurrence, so the element is required; and0..*means zero or more occurrences.
In the base Patient resource, birthDate has cardinality 0..1. If a
local workflow cannot operate without a birth date, its Patient profile
can change the minimum to one. The resulting cardinality is 1..1.
The profile has not created a new kind of data; it has made the shared
rule more specific for that use case.
Projects commonly publish related profiles, extensions, terminology rules, examples, and exchange requirements together in an implementation guide. Systems need to agree on that context; saying only that data “uses FHIR” is often not specific enough.