CapabilityStatement

The resource explicitly enumerates which FHIR interactions a server supports for each resource type.

• read: Direct access to a known resource by its logical ID
• vread: Retrieves a specific historical version of a resource
• update: Allows a client to modify an existing resource
• delete: Removes a resource from the server
• history: Fetches the complete change log for a resource type
• create: Enables the submission of a new resource instance
• search: Defines which search parameters are indexed and queryable

This declaration allows a client to programmatically adapt its behavior without manual configuration.

The rest.security element provides a machine-readable contract for authentication and authorization.

• CORS Support: Declares cross-origin resource sharing policies for browser-based apps
• Service Management: Links to the FHIR OAuth 2.0 endpoints for SMART on FHIR workflows
• Certificate Requirements: Specifies mutual TLS or PKI-based authentication needs

This section is critical for automated security negotiation, allowing a client to discover the exact token endpoint and scopes required before attempting a connection.

A CapabilityStatement references specific StructureDefinitions to indicate which constrained profiles a server claims conformance to.

• US Core Profiles: Declares support for USCDI-mandated data elements
• Custom Profiles: Advertises proprietary extensions and slicing rules
• Supported Profiles: Lists canonical URLs for every profile the server validates against

This mechanism transforms a generic FHIR endpoint into a semantically precise interface, ensuring that a client sending a US Core Patient resource will be understood and processed correctly.

Beyond basic CRUD, the resource advertises support for extended FHIR operations.

• $validate: Checks a resource against its stated profile rules
• $expand: Requests a ValueSet to be fully enumerated for a drop-down UI
• $match: Performs patient matching for master person index deduplication
• $everything: Fetches a complete patient record graph in a single bundle

Each operation is bound to a specific resource context, allowing a client to discover that, for example, Patient/$match is available for probabilistic identity resolution.

For event-driven architectures, the CapabilityStatement defines the FHIR messaging events a system can send or receive.

• Event Catalog: Lists specific event codes like patient-link or observation-created
• MessageHeader Profiles: Specifies the exact bundle structure expected for each event
• Endpoint Declarations: Provides the destination URL for message delivery

This section enables loose coupling between clinical systems, where a laboratory system can discover exactly which admission-discharge-transfer events a subscribing EHR supports.

The document element declares the FHIR document bundles a system can produce or consume.

• Clinical Document Architecture (CDA) Replacement: Defines FHIR-based clinical notes
• Composition Profiles: Specifies the exact section structure and coded headings
• Digital Signature Support: Indicates whether documents are cryptographically signed

This allows a document consumer to validate that a received Continuity of Care Document (CCD) conforms to the expected template before attempting to parse it for clinical data.