CapabilityStatement
Introduction
Scope and Usage
The capability statement is a key part of the overall conformance framework in FHIR. It is used as a statement of the features of actual software, or of a set of rules for an application to provide. This statement connects to all the detailed statements of functionality, such as StructureDefinitions and ValueSets. This composite statement of application capability may be used for system compatibility testing, code generation, or as the basis for a conformance assessment. For further information about Conformance testing, see Conformance Rules and Profiling FHIR.
Specifically, capability statements are used in one of three ways:
| Instance | implementation must be present and software may be present |
|---|---|
| Capability | implementation must be absent, software must be present |
| Requirements | implementation and software must be absent |
Instance: Describe an actual implementation
In this scenario, the capability statement describes the capabilities of a deployed and configured solution available at a particular access point or set of access points. The statement describes exactly how to interface with that deployed solution and thus provides for a degree of self-configuration of software solutions.
This is the type of statement that FHIR restful solutions are expected to make available on invocation of the capabilities operation. It is also the type of statement that forms a basis for the testing, certification or commissioning of specific software installations.
Capability: Describe software solution capabilities
In this scenario, the capability statement describes generic capabilities of a software application or component solution. The solution might be available for purchase or other acquisition and might be deployed and configured at any number of independent sites. Because it is not dependent on any particular implementation, the profile cannot provide specific details such as endpoint addresses. It may also need to document various configurations in which the application can be set up or describe the degree of customizability associated with the solution.
This type of statement may be used as a marketing tool by software and system developers to formally describe their capabilities. It can also be used as the basis for conformance testing of software solutions independent of a particular installation.
Requirements: Describe a desired solution
In this scenario, the capability statement describes the capabilities of a desired system. It might be used as part of an architectural design process to document needed system capabilities, or might be used as part of an RFP process to formally document the requirements of a requested solution and to document the criteria by which proposals will be evaluated.
These three types of profiles can be used together. A requirements statement can be compared against the solution statements proffered by respondents to an RFP. A solution statement for a software package forms the starting point for the implementation statement associated with a particular installation of that software package.
CapabilityStatements of type "requirement" describe what capabilities are potentially relevant; additional documentation or extensions (see capabilitystatement-expectation) within the CapabilityStatement are expected to make more explicit statements of degree of expectation associated with each capability.
Background and Context
Capability Statements provide for a degree of automatic configuration and adaptation. However, capturing absolutely every variation that could impact the interoperability of two systems, let alone keeping that detailed information up-to-date as systems evolve through maintenance and upgrades, is rarely practical. Therefore, capability statements should be seen as an interim step. They provide a degree of automation. However, they also provide a great deal of human-readable content that can minimize the need for direct communication between the operators of the systems being configured to interoperate.
Supporting Multiple Versions
Applications may implement multiple versions. If they do, then a CapabilityStatement describes the system's support for a particular version of FHIR, and the system will have multiple statements, one for each version it supports. For further information, see Managing Multiple Versions, and the $versions operation.
Notes
Notes:
- The CapabilityStatement resource provides for an application to describe its use of the RESTful paradigm, messaging events, or FHIR documents. Usually an application would only describe one, but more than one may be described.
- RESTful CapabilityStatement rules:
- RESTful servers are required to provide this resource on demand. Servers SHALL specify what resource types and operations are supported, and SHOULD also specify profiles for each resource type.
- The CapabilityStatement returned in the capabilities interaction may represent the specific capabilities granted to a specific user if retrieved with that specific user's credentials, if one is in context. Servers that require authentication SHOULD still return a CapabilityStatement before authentication/authorization is performed
- RESTful clients SHOULD publish a capability statement
- The search parameters that a server supports (or a client makes use of) are specified in the resource profile that the capability statement references
- Resource Types or operations that are not listed are not supported
- Messaging CapabilityStatement rules:
- The interpretation of request and response depends on the mode. If the mode is sender, then request specifies what the application sends, and response specifies what it accepts. If the mode is "receiver", then this is reversed
- If a request or response is not specified for an event, then no rules are made for it
- Events that are not listed are not supported
- The MessageDefinition resource is newly proposed and is still considered 'draft'. The
supportedMessageelement can be used in place of theeventand the work group believes it may meet implementer needs better, however because the new mechanism has not yet been reviewed by ballot, the older 'event' mechanism has been retained. Implementers may use one or the other to define their capabilities. Feedback is welcome.
- Document CapabilityStatement rules:
- Document profiles should directly constrain the Document.information.class & type elements so that there is no ambiguity concerning which profile any given document conforms to.
- Other service-based use of resources: Due to the variability of these services, the
CapabilityStatementresource does not attempt to describe service-based use of resources. The various service specifications will need to describe this usage in their own way.
Timezone Discovery
If a server has a default timezone, it should be indicated via the timezone code extension on CapabilityStatement.meta.
Supporting Search
One of the most important parts of the CapabilityStatement is indicating what search functionality a server supports or a client uses. The search can specify the following things:
- What resource types search is supported on, or used on
- What search parameters are supported, and what their names are on this server (the server can use alternative names). Note that clients can also choose to use alternative names for search parameters, but there is no expectation that servers will adapt for the client in this regard
- Servers can define their own search parameters that are not sourced from elsewhere, and often to define searches on extensions (see example)
- What include and reverse includes a server supports, or a client uses
- The Capability Statement does not support saying anything about modifiers or chaining directly, but these kind of statements can be made in the referenced search parameter resources (using SearchParameter.derivedFrom to establish traceability to the original definition of the search parameter)
- Systems can also make statements about their use or support for system wide search (not associated with a particular resource type)
[%stu-note reverse%] It is useful to support discovery of which reverse chaining values a server supports. Clients should not assume that servers support reverse chaining everywhere they support forward chaining. This will require a new field somewhere (e.g., in CapabilityStatement or in SearchParameter). Will review with FHIR-I, re: the best place to put this.
The most important use of support for reverse (or forward!) chaining might be in establishing conformance requirements for a server, rather than in supporting "live" discovery of a server's capabilities. (The latter could simply be tested by a client, rather than relying on possibly-incomplete or possibly-incorrect discovery data.)
Open question #1 would we want a way for servers to advertise which specific pairs of (searched resource + reverse chained search params) it support. For example, a server might need to say that the following is supported:
GET [base]/Patient?_has:Observation:subject:code=1234-5
... even though the following is not:
GET [base]/Group?_has:Observation:subject:code=1234-5
Open question #2: concern is that the possibility space is so broad that it might not be worth capturing all of this in such detail. Where to draw the line? [%end-note%] [%stu-note search%] There is no way for a server to communicate how it supports search at this time. FHIR-I plans to address this and other search issues for R6. [%end-note%]
Supporting Profiles
A CapabilityStatement declares two different kinds of profiles for the functionality it describes. For a discussion of the use of these two types of resources, see two uses for profiles.
Using additional resources in CapabilityStatements
CapabilityStatements may represent the use of additional resource. When doing so, CapabilityStatement.rest.resource.type contains the type of the resource as defined in the HL7 registry, along with a reference to the definition of the resource in CapabilityStatement.rest.resource.definition. The definition SHALL contain a version specific reference to the definition. The definition SHALL NOT be present if the resource type is one defined in this specification.
CapabilityStatements using additional resources can refer to these directly; when the additional resource moves to become a part of the core Specification, the search parameter canonical URLs do not change, though the versions might. But there's no change to the codes, whether the server uses the assigned code or it's own.
StructureDefinition
Elements (Simplified)
- CapabilityStatement [0..*]: - A statement of system capabilities
- CapabilityStatement.url [0..1]: uri Canonical identifier for this capability statement, represented as a URI (globally unique)
- CapabilityStatement.identifier [0..*]: Identifier Additional identifier for the CapabilityStatement (business identifier)
- CapabilityStatement.version [0..1]: string Business version of the capability statement
- CapabilityStatement.versionAlgorithm[x] [0..1]: string, Coding extensible:version-algorithm How to compare versions
- CapabilityStatement.name [0..1]: string Name for this capability statement (computer friendly)
- CapabilityStatement.title [0..1]: string Name for this capability statement (human friendly)
- CapabilityStatement.status [1..1]: code required:publication-status draft | active | retired | unknown
- CapabilityStatement.experimental [0..1]: boolean For testing only - never for real usage
- CapabilityStatement.date [1..1]: dateTime Date last changed
- CapabilityStatement.publisher [0..1]: string Name of the publisher/steward (organization or individual)
- CapabilityStatement.contact [0..*]: ContactDetail Contact details for the publisher
- CapabilityStatement.description [0..1]: markdown Natural language description of the capability statement
- CapabilityStatement.useContext [0..*]: UsageContext The context that the content is intended to support
- CapabilityStatement.actorDefinition [0..*]: canonical ActorDefinitions the CapabilityStatement supports
- CapabilityStatement.jurisdiction [0..*]: CodeableConcept extensible:jurisdiction Jurisdiction of the authority that maintains the capability statement (if applicable)
- CapabilityStatement.purpose [0..1]: markdown Why this capability statement is defined
- CapabilityStatement.copyright [0..1]: markdown Notice about intellectual property ownership, can include restrictions on use
- CapabilityStatement.copyrightLabel [0..1]: string Copyright holder and year(s)
- CapabilityStatement.kind [1..1]: code required:capability-statement-kind instance | capability | requirements
- CapabilityStatement.instantiates [0..*]: canonical Canonical URL of another capability statement this implements
- CapabilityStatement.imports [0..*]: canonical Canonical URL of another capability statement this adds to
- CapabilityStatement.software [0..1]: BackboneElement Software that is covered by this capability statement
- CapabilityStatement.software.name [1..1]: string A name the software is known by
- CapabilityStatement.software.version [0..1]: string Version covered by this statement
- CapabilityStatement.software.releaseDate [0..1]: dateTime Date this version was released
- CapabilityStatement.implementation [0..1]: BackboneElement If this describes a specific instance
- CapabilityStatement.implementation.description [1..1]: markdown Describes this specific instance
- CapabilityStatement.implementation.url [0..1]: url Base URL for the installation
- CapabilityStatement.implementation.custodian [0..1]: Reference(Organization) Organization that manages the data
- CapabilityStatement.fhirVersion [1..1]: code required:FHIR-version FHIR Version the system supports
- CapabilityStatement.format [1..*]: code required:supplemented-mimetypes formats supported (xml | json | ttl | mime type)
- CapabilityStatement.patchFormat [0..*]: code required:patchmimetypes Patch formats supported (Mime types for FHIR and JSON And XML Patch)
- CapabilityStatement.acceptLanguage [0..*]: code required:all-languages Languages supported
- CapabilityStatement.implementationGuide [0..*]: canonical Implementation guides supported
- CapabilityStatement.rest [0..*]: BackboneElement If the endpoint is a RESTful one
- CapabilityStatement.rest.mode [1..1]: code required:restful-capability-mode client | server
- CapabilityStatement.rest.documentation [0..1]: markdown General description of implementation
- CapabilityStatement.rest.security [0..1]: BackboneElement Information about security of implementation
- CapabilityStatement.rest.security.cors [0..1]: boolean Adds CORS Headers (http://enable-cors.org/)
- CapabilityStatement.rest.security.service [0..*]: CodeableConcept extensible:restful-security-service OAuth | SMART-on-FHIR | NTLM | Basic | Kerberos | Certificates
- CapabilityStatement.rest.security.description [0..1]: markdown General description of how security works
- CapabilityStatement.rest.resource [0..*]: BackboneElement Resource served on the REST interface
- CapabilityStatement.rest.resource.type [1..1]: uri extensible:extended-resource-types A resource type that is supported
- CapabilityStatement.rest.resource.definition [0..1]: canonical The definition for an additional resource
- CapabilityStatement.rest.resource.profile [0..1]: canonical System-wide profile
- CapabilityStatement.rest.resource.supportedProfile [0..*]: canonical Use-case specific profiles
- CapabilityStatement.rest.resource.documentation [0..1]: markdown Additional information about the use of the resource type
- CapabilityStatement.rest.resource.interaction [0..*]: BackboneElement What interactions are supported?
- CapabilityStatement.rest.resource.interaction.code [1..1]: code required:type-restful-interaction read | vread | update | update-conditional | patch | patch-conditional | delete | delete-conditional-single | delete-conditional-multiple | delete-history | delete-history-version | history-instance | history-type | create | create-conditional | search-type
- CapabilityStatement.rest.resource.interaction.documentation [0..1]: markdown Anything special about interaction behavior
- CapabilityStatement.rest.resource.versioning [0..1]: code required:versioning-policy no-version | versioned | versioned-update
- CapabilityStatement.rest.resource.readHistory [0..1]: boolean Whether vRead can return past versions
- CapabilityStatement.rest.resource.updateCreate [0..1]: boolean If update can commit to a new identity
- CapabilityStatement.rest.resource.conditionalCreate [0..1]: boolean If allows/uses conditional create
- CapabilityStatement.rest.resource.conditionalRead [0..1]: code required:conditional-read-status not-supported | modified-since | not-match | full-support
- CapabilityStatement.rest.resource.conditionalUpdate [0..1]: boolean If allows/uses conditional update
- CapabilityStatement.rest.resource.conditionalPatch [0..1]: boolean If allows/uses conditional patch
- CapabilityStatement.rest.resource.conditionalDelete [0..1]: code required:conditional-delete-status not-supported | single | multiple - how conditional delete is supported
- CapabilityStatement.rest.resource.referencePolicy [0..*]: code required:reference-handling-policy literal | logical | resolves | enforced | local
- CapabilityStatement.rest.resource.searchInclude [0..*]: string _include values supported by the server
- CapabilityStatement.rest.resource.searchRevInclude [0..*]: string _revinclude values supported by the server
- CapabilityStatement.rest.resource.searchParam [0..*]: BackboneElement Search parameters supported by implementation
- CapabilityStatement.rest.resource.searchParam.name [1..1]: string Name for parameter in search url
- CapabilityStatement.rest.resource.searchParam.definition [0..1]: canonical Source of definition for parameter
- CapabilityStatement.rest.resource.searchParam.type [1..1]: code required:search-param-type number | date | string | token | reference | composite | quantity | uri | special | resource
- CapabilityStatement.rest.resource.searchParam.documentation [0..1]: markdown Server-specific usage
- CapabilityStatement.rest.resource.operation [0..*]: BackboneElement Definition of a resource operation
- CapabilityStatement.rest.resource.operation.name [1..1]: string Name by which the operation/query is invoked
- CapabilityStatement.rest.resource.operation.definition [1..1]: canonical The defined operation/query
- CapabilityStatement.rest.resource.operation.documentation [0..1]: markdown Specific details about operation behavior
- CapabilityStatement.rest.interaction [0..*]: BackboneElement What interactions are supported?
- CapabilityStatement.rest.interaction.code [1..1]: code required:system-restful-interaction transaction | batch | search-system | history-system
- CapabilityStatement.rest.interaction.documentation [0..1]: markdown Anything special about interaction behavior
- CapabilityStatement.rest.searchParam [0..*]: - Search parameters for searching all resources
- CapabilityStatement.rest.operation [0..*]: - Definition of a system level operation
- CapabilityStatement.rest.compartment [0..*]: canonical Compartments served/used by system
- CapabilityStatement.messaging [0..*]: BackboneElement If messaging is supported
- CapabilityStatement.messaging.endpoint [0..*]: BackboneElement Where messages should be sent
- CapabilityStatement.messaging.endpoint.protocol [1..1]: Coding extensible:message-transport http | ftp | mllp +
- CapabilityStatement.messaging.endpoint.address [1..1]: url Network address or identifier of the end-point
- CapabilityStatement.messaging.reliableCache [0..1]: unsignedInt Reliable Message Cache Length (min)
- CapabilityStatement.messaging.documentation [0..1]: markdown Messaging interface behavior details
- CapabilityStatement.messaging.supportedMessage [0..*]: BackboneElement Messages supported by this system
- CapabilityStatement.messaging.supportedMessage.mode [1..1]: code required:event-capability-mode sender | receiver
- CapabilityStatement.messaging.supportedMessage.definition [1..1]: canonical Message supported by this system
- CapabilityStatement.document [0..*]: BackboneElement Document definition
- CapabilityStatement.document.mode [1..1]: code required:document-mode producer | consumer
- CapabilityStatement.document.documentation [0..1]: markdown Description of document support
- CapabilityStatement.document.profile [1..1]: canonical Constraint on the resources used in the document
Mappings
- CapabilityStatement Mappings — 12 mapping entries
Implementation Guide
implementationguide-CapabilityStatement-core.xml
<?xml version="1.0" encoding="UTF-8"?>
<ImplementationGuide xmlns="http://hl7.org/fhir">
<id value="CapabilityStatement-core"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:oid:2.16.840.1.113883.4.642.30.4"/>
</identifier>
<name value="CommonCapabilityStatementExtensions"/>
<title value="Common Capability Statement extensions"/>
<status value="draft"/>
<date value="2014-04-12T00:00:00.000"/>
<publisher value="Health Level Seven, Inc. - [WG Name] WG"/>
<description value="Common extensions for use with the CapabilityStatement resource"/>
</ImplementationGuide>
Operations
- versions — Discover what versions a server supports — Using the FHIR Version Mime Type Parameter, a server can support multiple versions on the same end-point.
Resource Packs
list-CapabilityStatement-packs.xml
<?xml version="1.0" encoding="UTF-8"?>
<List xmlns="http://hl7.org/fhir">
<id value="CapabilityStatement-packs"/>
<status value="current"/>
<mode value="working"/>
<entry>
<item>
<reference value="ImplementationGuide/CapabilityStatement-core"/>
</item>
</entry>
</List>
Search Parameters
- context — token — A use context assigned to the capability statement —
(CapabilityStatement.useContext.value.ofType(CodeableConcept)) - context-quantity — quantity — A quantity- or range-valued use context assigned to the capability statement —
(CapabilityStatement.useContext.value.ofType(Quantity)) | (CapabilityStatement.useContext.value.ofType(Range)) - identifier — token — External identifier for the capability statement —
CapabilityStatement.identifier - context-type — token — A type of use context assigned to the capability statement —
CapabilityStatement.useContext.code - context-type-quantity — composite — A use context type and quantity- or range-based value assigned to the capability statement —
CapabilityStatement.useContext - context-type-value — composite — A use context type and value assigned to the capability statement —
CapabilityStatement.useContext - date — date — The capability statement publication date —
CapabilityStatement.date - description — string — The description of the capability statement —
CapabilityStatement.description - fhirversion — token — The version of FHIR —
CapabilityStatement.fhirVersion - format — token — formats supported (xml | json | ttl | mime type) —
CapabilityStatement.format - guide — reference — Implementation guides supported —
CapabilityStatement.implementationGuide - identifier — token — External identifier for the capability statement —
CapabilityStatement.identifier - jurisdiction — token — Jurisdiction of the authority that maintains the the capability statement —
CapabilityStatement.jurisdiction - mode — token — Mode - restful (server/client) or messaging (sender/receiver) —
CapabilityStatement.rest.mode - name — string — Computationally friendly name of the capability statement —
CapabilityStatement.name - publisher — string — Name of the publisher of the capability statement —
CapabilityStatement.publisher - resource — uri — Name of a resource mentioned in a capability statement —
CapabilityStatement.rest.resource.type - resource-profile — reference — A profile id invoked in a capability statement —
CapabilityStatement.rest.resource.profile - security-service — token — OAuth | SMART-on-FHIR | NTLM | Basic | Kerberos | Certificates —
CapabilityStatement.rest.security.service - software — string — Part of the name of a software application —
CapabilityStatement.software.name - status — token — The current status of the capability statement —
CapabilityStatement.status - supported-profile — reference — Profiles for use cases supported —
CapabilityStatement.rest.resource.supportedProfile - title — string — The human-friendly name of the capability statement —
CapabilityStatement.title - url — uri — The uri that identifies the capability statement —
CapabilityStatement.url - version — token — The business version of the capability statement —
CapabilityStatement.version - experimental — token — Whether the CapabilityStatement is experimental —
CapabilityStatement.experimental
Examples
- capabilitystatement-base — capabilitystatement-base — Complete Capability Statement
- capabilitystatement-base2 — capabilitystatement-base2 — EmptyCapabilityStatement
- capabilitystatement-example — capabilitystatement-example
- capabilitystatement-examples-header — capabilitystatement-examples-header
- example — capabilitystatement-example — General Capability Example
- example-terminology-server — capabilitystatement-terminology-server — Terminology Server Base Capability Statement
- knowledge-repository — capabilitystatement-knowledge-repository — Knowledge Repository Base Capability Statement
- measure-processor — capabilitystatement-measure-processor — Measure Processor Base Capability Statement
- messagedefinition — capabilitystatement-messagedefinition — Showing new message definition structure
- phr — capabilitystatement-phr-example — PHR Example
Mapping Exceptions
capabilitystatement-definition-mapping-exceptions.xml
Divergent Elements
- Definition.identifier → CapabilityStatement.identifier
- shortUnmatched | reason=Unknown | pattern=Business identifier for capability statement | resource=Additional identifier for the CapabilityStatement (business identifier)
- definitionUnmatched | reason=Unknown | pattern=A formal identifier that is used to identify this capability statement when it is represented in other formats, or referenced in a specification, model, design or an instance. | resource=A formal identifier that is used to identify this CapabilityStatement when it is represented in other formats, or referenced in a specification, model, design or an instance.
- commentsUnmatched | reason=Unknown | pattern=Typically, this is used for identifiers that can go in an HL7 V3 II (instance identifier) data type, and can then identify this capability statement outside of FHIR, where it is not possible to use the logical URI.
- requirementsUnmatched | reason=Unknown | pattern=Allows externally provided and/or usable business identifiers to be easily associated with the capability statement. | resource=Allows externally provided and/or usable business identifiers to be easily associated with the module.
Unmapped Elements
- Definition.contact — Unknown
- Definition.derivedFromCanonical — Unknown
- Definition.approvalDate — Unknown
- Definition.name — Unknown
- Definition.description — Unknown
- Definition.jurisdiction — Unknown
- Definition.copyrightLabel — Unknown
- Definition.effectivePeriod — Unknown
- Definition.product — Unknown
- Definition.code — Unknown
- Definition.title — Unknown
- Definition.date — Unknown
- Definition.status — Unknown
- Definition.url — Unknown
- Definition.copyright — Unknown
- Definition.lastReviewDate — Unknown
- Definition.subject — Unknown
- Definition.purpose — Unknown
- Definition.derivedFromUri — Unknown
- Definition.versionAlgorithm — Unknown
- Definition.publisher — Unknown
- Definition.performerType — Unknown
- Definition.partOf — Unknown
- Definition.topic — Unknown
- Definition.useContext — Unknown
- Definition.experimental — Unknown
- Definition.version — Unknown
capabilitystatement-fivews-mapping-exceptions.xml
Unmapped Elements
- FiveWs.what — Not relevant for this resource
- FiveWs.author — Not relevant for this resource
- FiveWs.actor — Not relevant for this resource
- FiveWs.cause — Not relevant for this resource
- FiveWs.where — Not relevant for this resource
- FiveWs.context — Unknown
- FiveWs.init — Not relevant for this resource
- FiveWs.source — Not relevant for this resource
- FiveWs.who — Not relevant for this resource
- FiveWs.grade — Not relevant for this resource
- FiveWs.planned — Not relevant for this resource
- FiveWs.done — Not relevant for this resource
- FiveWs.subject — Not relevant for this resource