The base FHIR specification describes a set of base 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 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 or vendor that describe how FHIR is adapted to support a certain usecase (or set of usecases). An implementation guide combines a set of conformance resources and supporting narrative into a document for use by implementers.
- A capability statement which uses 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.
The content of an Implementation Guide is described using the ImplementationGuide resource, while the capability statement is represented by the CapabilityStatement. These two resources make use of the complete set of conformance resources to fully capture the set of adaptations they represent. More specifically, the conformance resources are:
- The StructureDefinition defines how a particular structure (Resource, Extension or Data Type) is used:
- Describe how existing elements in resources are used
- Identify existing elements that are not used
- Define extensions that can be used in resources or data types
- Exact rules about constrainment can be found in the section on conformance rules
- The OperationDefinition describes additional operations in addition to those in the base specification.
- 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
- The NameSpace resources names terminologies and identifier systems in use in a domain
- The DataElement resource is a formal description of a single piece of information that can be gathered and reported.
The conformance resources and their relationships are shown below:
Conformance resources may be used independently of both of these resources, to cover uses that do not need the context of a guide or capability statement. Examples of such uses are:
- An instance of a resource may reference one or more
StructureDefinitionsto claim conformance to the rules layed out in those StructureDefinitions - A server may serve
CapabilityStatementresources, effectively functioning as a discovery endpoint for services within an organization - A server may hold a set of DataElement resources to become a Data Dictionary of reuseable datamodels as per ISO 11179.
- A code-generation tool may use
StructureDefinitionsandOperationDefinitionsto 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
NameSpaceresources, so vendors and implementers can quickly look up the urls or oids for a given terminology or identifier system.
The conformance resources do not represent patient-related data, and as such are less susceptible to data breaching. Some caution is required however:
StructureDefinitionsmay contain invariants formulated as structured expressions that are evaluated by external engines (i.e. xpath), which -if unproperly 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 any conformance resource, it should provide read-only access, so dependent systems do not run the risk of being misconfigured.
A subset of the conformance resources have been tested and used in production tooling and as such have reached a maturity level where changes become less likely. These are CapabilityStatement, StructureDefinition, ValueSet, OperationDefinition, SearchParameter, DataElement and NamingSystem.
Other resources are still under development:
- ImplementationGuide: used in the HL7 production tooling, but has not received much use outside of these tools yet.
- CompartmentDefinition: new in STU3, and as such has not undergone much production use
Over the past two years, these resources are mainly used in the tools used to build the FHIR publication, early-adopter implementation guides and the FHIR Foundation conformance resource registry. In the 2016-2018 timeframe we expect to see more widespread use of these resources in validation tooling, code-generators and more extensive model-based guide authoring tools.