Conformance Publication Service

A Conformance Publication Service is a subset of the FHIR specification aimed at publishing conformance resources. Systems implementing this subset are typically registries or repositories providing the user with search capabilities and display of StructureDefinitions (and thus extensions), OperationDefinitions, SearchParameters and other conformance resources. Systems implementing the capabilities described in this subset enable seamless integration between repositories and consuming applications like authoring and validation tools. For example:

  • Validators could use this API subset to retrieve extensions and StructureDefinition to be able to fully validate FHIR instances
  • Repositories can use the subset to synchronize their content with other repositories
  • Authoring tools can enable the user to browse a repository based on resource types and status and find extensions the user may wish to use in an instance.

Note that this API subset is targeted at retrieval and searching only and so does not include capabilities for storing or updating conformance resources.

Indicating conformance to this service

A server that supports the functionality described here can declare that they provide conformance services in their capability statement:

<CapabilityStatement xmlns="http://hl7.org/fhir">
  <!-- snip -->
  <instantiates value="http://hl7.org/fhir/CapabilityStatement/conformance-publication-service"/>
  <!-- snip -->
</CapabilityStatement>

This page is meant as an informal introduction to the features of the Conformance Publication Service, the full formal description of the subset can be found in the conformance-publication-service capability statement.

Looking up conformance resources by canonical

As shown in the module on conformance resources, many conformance resources refer to each other, and do so by use of their canonical url, which is the url element found on most conformance resources. Servers implementing this service will support searching on the url:

	GET http://registry-api.fhir.org/open/StructureDefinition?url=http://hl7.org/fhir/StructureDefinition/Patient

Searching conformance resources by keyword

Applications can allow their user to search for resources by any word appearing anywhere in the resource, by calling the service like so:

	GET http://registry-api.fhir.org/open/StructureDefinition?_content=medication

Or, to search across a set of conformance types:

	GET http://registry-api.fhir.org/open?_content=medication&_type=StructureDefinition,ValueSet

Limiting the search results

The API subset contains a number of search parameters that can be used to limit the result set of searches, to for example by jurisdiction, to limit the search results to contain only resources that are relevant for a certain country:

	GET http://registry-api.fhir.org/open/StructureDefinition?jurisdiction=us

Implementers of the service should also provide other search parameters like:

  • jurisdiction
  • status
  • identifier
  • publisher

Staying in sync

A registry may query another registry for recent changes, as to be able to stay up-to-date with new changes in that registry using the _history capabilities described in the subset:

	GET http://registry-api.fhir.org/open?_history&_since=2018-01-01

This will return a Bundle with all changes to the service, as described for the _history operation.

Validating instances against profiles

Systems implementing this service like registries will normally contain sets of StructureDefinitions that can be used to validate FHIR instances against. A Conformance Publication Service includes functionality to invoke the $validate operation as defined by FHIR. Since these services would not normally store instances, only the type-level variant of the $validate operation needs to be supported:

	POST http://registry-api.fhir.org/open/Patient/$validate
	(body will contain a Parameters resource with resource to validate + profile urls to validate against)

Generating snapshots

Conformance services may be asked to generate a snapshot for a given StructureDefinition using the $generate operation. To be compliant to this service specification the service only needs to implement the instance-based overload of this operation:

	GET http://registry-api.fhir.org/open/StructureDefinition/patient-mothersMaidenName/$generate

This call will return response with a single StructureDefinition containing both the original differential and the newly generated snapshot.

[TODO: why does the spec say this is not idempotent?]

Getting a subset of a CapabilityStatement

CapabilityStatements for systems implementing most of the FHIR specification can be huge, so the FHIR specification offers the $subset operation to retrieve just a limited subset of any CapabilityStatement. Since systems implementing the Conformance Publication Service may act as a registry for the CapabilityStatements of other systems, they should also implement at least the instance-based overload of this operation:

	GET http://registry-api.fhir.org/open/CapabilityStatement/fhir-full/$subset?resource=Patient&resource=Observation

[TODO: Or would this be .....?resource=Patient,Observation]

Which would return a trimmed-down version of the CapabilityStatement with just the <rest> parts about the Patient and Observation resources included.

Extensions found in the search results

[TODO: Something about the link/extensions found in the result Bundle for base url and authors]

Last updated on