FHIR normative content and version compatibility

Normative and non-normative content

FHIR contains a mix of normative (stable) and non-normative (evolving) content. Where content is declared fully normative, later publications should not introduce breaking changes to that normative behavior.

• Normative: Breaking changes are not expected; changes should be additive or clarifying.
• Non-normative (trial-use/informative): Breaking changes can occur across versions and releases.

Forward compatibility guidance for clients

To minimize disruptions when servers evolve, implement clients defensively:

• Ignore unknown elements in JSON rather than failing parsing (forward-compatible parsing).
• Avoid hard-coding assumptions about response shape beyond the FHIR standard (for example, do not require optional elements to be present).
• Prefer tolerant validation for non-normative areas; reserve strict validation for required fields and server-enforced constraints.
• Follow content negotiation rules: set Accept and Content-Type to supported encodings for this server (see resource pages).

Version-to-version compatibility expectations

• When using FHIR R4 endpoints, expect stability for interactions and patterns that are normative in the R4 standard.
• When using FHIR R6 endpoints, the server may expose newer resources and search parameters aligned to R6.
• Across versions, differences are expected (for example, resource models, supported operations, and search parameters). Design clients to handle version-specific behavior.

Recommended workflow for integrations

Use the capability statement (server metadata) to confirm what a deployment supports before integrating:

• Verify supported resource types and interactions (read/search/create/update/delete/vread).
• Verify supported operations (for example, administrative purge operations).
• Verify supported formats and any deployment-specific limitations.