What is Conformance?
Conformance in FHIR is the formal process of declaring and verifying what a system supports. A FHIR server declares its capabilities in a CapabilityStatement. Profiles declare constraints on resources. Validation checks that resources meet those constraints. Together, these form the FHIR conformance framework.
Conformance vs validation vs compliance
These three terms are related but distinct:
| Term | Meaning |
|---|---|
| Conformance | A system's ability to support a defined set of FHIR capabilities — declared via CapabilityStatement and verified by testing. |
| Validation | Checking that a specific resource instance conforms to the base spec or a profile. Returns an OperationOutcome. |
| Compliance | A system meets the requirements of a specific regulation or IG (e.g. EHDS, US Core). Requires conformance + testing + certification. |
CapabilityStatement — what a server declares
Every FHIR server exposes a CapabilityStatement at GET [base]/metadata. It declares:
- Resources supported: which resource types the server can store and return
- Interactions: read, search-type, create, update, delete — per resource type
- Search parameters: which parameters are supported and with which modifiers
- Operations: which
$operationsare available (e.g.$validate,$export) - Profiles supported: which StructureDefinitions the server validates against
- Security: whether SMART on FHIR authentication is required
HAPI FHIR — check CapabilityStatement locally
curl http://localhost:8080/fhir/metadata | jq '.rest[0].resource[] | {type, interaction: [.interaction[].code]}'Conformance resources
FHIR defines a set of resources whose purpose is to describe other resources and system behaviour — collectively called conformance resources:
| Resource | Purpose |
|---|---|
| CapabilityStatement | Declares what a server or client supports — the system contract |
| StructureDefinition | Defines the structure of resources, profiles, extensions, data types |
| ValueSet | Selects codes valid in a specific context |
| CodeSystem | Defines codes and their meanings |
| SearchParameter | Defines a search parameter — what element it searches, what type |
| OperationDefinition | Defines a custom operation ($validate, $export, $expand) |
| ImplementationGuide | Bundles all conformance resources for a specific use case into a publishable specification |
Testing conformance
Declaring conformance in a CapabilityStatement is only a claim. Verification requires testing. FHIR defines a TestScript resource to write machine-executable test scenarios, and tools like the Touchstone platform run them against live servers.
For our lab, conformance testing is done through:
- Postman collection: manual verification of each endpoint and search parameter
- $validate operation: per-resource validation against HAPI FHIR
- Validator Lab: structural validation against our profiles in the browser
Governance resources and conformance
Three resource types support clinical governance and GDPR compliance — not strictly part of conformance, but part of a production FHIR system:
Consent
Records patient consent decisions — who can access what data, for what purpose, for how long. Structured as a provision tree: root permit/deny with nested overrides. GDPR requires explicit consent for health data processing in most contexts.
AuditEvent
Records who accessed or modified which resource, when, from where, and for what purpose. Maps to the DICOM/IHE audit event vocabulary. GDPR Article 30 (records of processing) and Article 32 (security) require audit trails for health data systems.
Provenance
Records where a resource came from — who authored it, who assembled it, what source data it was derived from. Supports data lineage and trust — particularly important for IPS documents that aggregate data from multiple sources.