The Conformance Module represents metadata about the datatypes, resources and API features of the FHIR specification and can be used to create derived specifications.
The core FHIR specification describes a set of resources, frameworks and APIs that are
used in many different contexts in healthcare. However, there is wide variability between
jurisdictions and across the healthcare ecosystem around practices, requirements,
regulations, education and what actions are feasible and/or beneficial.
For this reason, the FHIR specification is a "platform specification" - it creates
a common platform or foundation on which a variety of different solutions are implemented.
As a consequence, this specification usually requires further adaptation to particular
contexts of use.
Typically, these adaptations specify:
Rules about which resource elements are or are not used, and what additional elements
are added that are not part of the base specification
Rules about which of FHIR's RESTful API, messaging and document features are used, and how
Rules about which terminologies are used in particular elements
Descriptions of how the Resource elements and API features map to local requirements
and/or implementations
Note that because of the nature of the healthcare ecosystem, there may be multiple
overlapping sets of adaptations - by healthcare domain, by country, by institution, and/or by
vendor/implementation.
FHIR provides a set of resources that can be used to represent and share the adaptations
listed above in a computable fashion. These resources are collectively called the
conformance resources. Although these conformance resources can be used in
isolation they are typically used in the context of an Implementation Guide or a
Capability Statement:
Implementation Guides are documents published by a domain, institution,
vendor, consortium, or other organization that describe how FHIR is adapted to
support a certain use case (or set of
use cases). An implementation guide combines a set of conformance resources and
supporting narrative into a document for use by implementers.
A capability statements use the conformance resources to document how a
client or server has implemented FHIR, i.e. which aspects of the specification and API
are implemented and how.
5.0.2 Contents
The content of an Implementation Guide is described using the ImplementationGuide resource,
while the capability statement is represented by the CapabilityStatement resource. These two resources
make use of the complete set of conformance resources to fully capture the set of
adaptations they represent. Note that the CapabilityStatement resource is one of the conformance resources,
the first just describing the capabilities of a system, while the latter is the set of all conformance resources, including:
The StructureDefinition
defines how a particular structure (Resource, Extension or Datatype) is used to:
Describe how existing elements in resources and/or datatypes are used and identify existing elements that are not used. Exact rules on how to do this can be found in the section on conformance rules
Define extensions that can be used in resources or datatypes.
Reference the Value Sets that specify the content of coded elements, see the terminology module for more details.
The MessageDefinition
describes messages that can be sent and received, including the driving event, contents to be exchanged and responsibilities on receipt.
The SearchParameter describes
additional search capabilities in addition to those in the base specification
The CompartmentDefinition
describes a logical grouping for resources, used in access control or search
Conformance resources may be used independently, not just within the context of an ImplementationGuide resource or capability statement. See the section Common use cases for examples of such uses.
The conformance resources and their relationships are shown below:
Resources shown with a dotted box are described in other sections of the specification:
ValueSet, ConceptMap and StructureMap are from the section on terminology,
TestScript is part of the section on Implementer Support.
5.0.3 Security and Privacy
The conformance resources do not represent patient-related data, and as such are less
susceptible to data breaching. Some caution is required however:
StructureDefinitions may contain invariants formulated as structured
expressions that are evaluated by external engines (i.e. FHIRPath), which -if improperly
sandboxed- could provide low-level access to the system
A server may be implemented in such a way that it will automatically support additional
search parameters or compartments definitions uploaded to that system. This may result
in searches that use large amounts of processing power, expose sensitive patient data,
or both.
If a server acts as a repository of conformance resources, it should tightly control
modifications to its data: updates to conformance resources are usually managed by a review process to ensure
backwards compatibility and stability. Worst case, changes to these resources may result in dependent systems
running the risk of being misconfigured.
5.0.4 Common use Cases
Conformance resources are commonly used as part of an Implementation Guide or
CapabilityStatement resource. There are many ways to use the resources independently however, including:
An instance of a resource may reference one or more StructureDefinitions to
claim conformance to the rules laid out in those StructureDefinitions
A server may serve CapabilityStatement resources, effectively functioning
as a discovery endpoint for services within an organization
A code-generation tool may use StructureDefinitions and
OperationDefinitions to generate code that represents the structures as
classes and operations as remotely callable functions to provide an easier programming
model to a software developer.
A server may act as a repository of NamingSystem resources, so vendors and
implementers can quickly look up the URLs or oids for a given terminology or identifier
system.
OperationDefinition: This resource is normative and stable, though two new features relating to the use of parameters were added in this release. No additional future changes to scope have been discussed or considered
CapabilityStatement: The core of this resource is stable and normative. There are still a few elements on the
resource labelled as 'trial-use'. The FHIR Infrastructure work group intends to develop an
implementation guide for clients to use to ask servers about their capabilities at a much finer granularity than that offered
by the CapabilityStatement, and then those trial use elements will be removed / deprecated or made normative in a future version.
SearchParameter: This resource has been used widely, and is considered stable, but some parts or still undergoing trial use
ImplementationGuide: This resource has been used widely, and is considered stable, but not all tools are fully across all the changes yet
CompartmentDefinition: This resource is in trial-use. HL7 is expected to be the only publisher of this resource
StructureMap: This resource is stable but new feature proposals are welcome; there is a spread of tools but it has not yet been used to it's full potential yet
MessageDefinition: This resource is still undergoing testing; messaging has not been used that widely (though it has been used deeply in a couple of countries)
GraphDefinition: This resource was re-written from ground up and needs considerable testing before the design can be considered proven