Spec references:
Validation |
OperationOutcome |
$validate“Is this resource acceptable according to FHIR (and the profiles it claims to follow)?”In practice, validation is layered.
What gets validated
1) Structural correctness
Basic “is this shaped like a FHIR resource?” checks:resourceTypeis present and known- element names and datatypes match the definition
- required elements and cardinalities are satisfied
2) Profile constraints
If a resource is expected to conform to a profile (or declares one viameta.profile[]), validators can enforce:
- additional required elements
- fixed values and patterns
- slicing rules
- invariants (FHIRPath constraints)
3) Terminology rules
Coded fields (Coding, CodeableConcept, etc.) can be bound to ValueSets.
Validation may check the binding strength (required, extensible, …) and
whether the codes are permitted.
See Terminology.
How validation errors are reported
FHIR usesOperationOutcome. Each
problem is an issue with:
severity:fatal,error,warning,informationcode: a standardized category (e.g.structure,value,invariant)diagnostics: human-readable details (often server/tool specific)expression[]: FHIRPath expressions pointing to the element(s) involved (when available)
When validation happens
Common places you’ll see validation:- Client-side (form/SDK validation before sending)
- Server-side on
create,update,patch,transaction - Explicit validation via the
$validateoperation (if the server supports it)
Discovering server support
Validation capabilities vary by server. The fastest way to check is theCapabilityStatement (GET /fhir/metadata), which can list supported profiles,
terminology capabilities, and operations such as $validate.
TLQ links
- Discover server capabilities: CapabilityStatement
- Error format details: API reference: Errors
- Related learning: Profiles, Terminology, FHIRPath
- TLQ-specific: Server guide: Packages, Server guide: Operations
Next
- Authoring constraints: Profiles
- Understanding coded rules: Terminology