Search loading...


Explore and Make use of Nationally Defined Messaging APIs


Get the FHIR conformance statement

Use case for getting the GP Connect FHIR server's conformance statement.

API usage

Request operation

FHIR Relative Request

GET /metadata

FHIR absolute request

GET https://[proxy_server]/https://[provider_server]/[fhir_base]/metadata

Request headers

Consumers MUST include the following additional HTTP request headers:

Header Value
Ssp-TraceID Consumer’s TraceID (i.e. GUID/UUID)
Ssp-From Consumer’s ASID
Ssp-To Provider’s ASID
Ssp-InteractionID urn:nhs:names:services:gpconnect:fhir:rest:read:metadata

Payload request body


Error handling

Provider systems are expected to always be able to return a valid conformance statement.

Request response

Response headers

Provider systems are not expected to add any specific headers beyond that described in the HTTP and FHIR® standards.

Payload response body

Provider systems:

  • MUST return a 200 OK HTTP status code on successful retrieval of the conformance statement
  • MUST ensure that the FHIR version number returned by the FHIR server endpoint conformance statement matches the FHIR version stated in the endpoint base URL. Refer to Spine Directory Services for details of the format of the FHIR base URL to be used.

An example GP Connect Conformance Statement of type capability is shown below ready for customisation and embedding into GP Connect assured provider systems. Providers should use this conformance statement as a base for their own conformance statement, replacing the element in square brackets ([ & ]) with specific information of their implementation. The main version at the top of the conformance statement should represent the GP Connect specification version which the FHIR server implements.

<Conformance xmlns="">
	<version value="0.7.1" />
	<name value="GP Connect" />
	<publisher value="[Provider Software Vendor Name]" />
		<name value="[Provider Software Vendor Contact Name]" />
	<date value="2018-02-23" />
	<description value="This server implements the GP Connect API version 0.7.0" />
	<copyright value="Copyright NHS Digital 2016" />
	<kind value="capability" />
		<name value="[Provider Software Name]" />
		<version value="[Provider Software Verson]" />
		<releaseDate value="[Provider Software Release Date]" />
	<fhirVersion value="1.0.2" />
	<acceptUnknown value="both" />
	<format value="application/xml+fhir" />
	<format value="application/json+fhir" />
 		<reference value=""/>
		<reference value=""/>
		<reference value=""/>
		<reference value=""/>
		<reference value=""/>
		<reference value=""/>
		<mode value="server" />
			<name value="gpc.getcarerecord" />
				<reference value="OperationDefinition/gpc.getcarerecord" />

Consumer systems:

  • SHOULD, at run-time, request the conformance statement from the FHIR server endpoint in order to ascertain details of the implementation of GPConnect capabilities delivered by the FHIR server
  • SHOULD cache conformance statement information retrieved from an endpoint at run-time on a per-session basis

C# client request to get the conformance statement

var client = new FhirClient("");
client.PreferredFormat = ResourceFormat.Json;
var resource = client.Conformance();

All content is available under the Open Government Licence v3.0, except where otherwise stated