Search loading...


Explore and Make use of Nationally Defined Messaging APIs


Get the FHIR® capability statement

Get the FHIR capability statement from the Access Record Structured FHIR server

Use case

Get the Access Record Structured FHIR capability statement.


  • GP Connect utilises TLS Mutual Authentication for system level authorization
  • GP Connect utilises JSON Web Tokens (JWT) to transmit clinical audit and provenance details



The consumer system:

  • SHALL have previously resolved the organisation’s Access Record Structured FHIR endpoint base URL through the Spine Directory Service

API usage

Interaction diagram

Get the FHIR® capability statement interaction diagram

Request operation

FHIR relative request

GET /metadata

FHIR absolute request

GET https://[proxy_server]/https://[structured_provider_server]/[structured_fhir_base]/metadata

Request headers

Consumers SHALL 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:structured:fhir:rest:read:metadata-1

Payload request body


Error handling

The provider system MUST return a GPConnect-OperationOutcome-1 resource that provides additional detail when one or more data field is corrupt or a specific business rule/constraint is breached.

The table below shown common errors that may be encountered during this API call, and the returned Spine error code. Please see Error handling guidance for additional information needed to create the error response or to determine the response for errors encountered that are not shown below.

Errors returned due to query parameter failure MUST include diagnostic information detailing the invalid query parameter.

Error encountered Spine error code returned
GP Connect is not enabled at the practice (see Enablement) ACCESS_DENIED
The Access Record Structured capability is not enabled at the practice (see Enablement) ACCESS_DENIED

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:

  • SHALL return a 200 OK HTTP status code on successful retrieval of the capability statement
  • SHALL return a capability statement which conforms to the standard FHIR CapabilityStatement

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

  "resourceType": "CapabilityStatement",
  "version": "1.2.6",
  "name": "GP Connect API - Access Record Structured",
  "status": "active",
  "date": "2020-02-10",
  "publisher": "[Provider Software Vendor Name]",
  "contact": [
      "name": "[Provider Software Vendor Contact Name]"
  "description": "This server implements the GP Connect API - Access Record Structured version 1.2.6",
  "copyright": "Copyright NHS Digital 2016-20",
  "kind": "capability",
  "software": {
    "name": "[Provider Software Name]",
    "version": "[Provider Software Version]",
    "releaseDate": "[Provider Software Release Date]"
  "fhirVersion": "3.0.1",
  "acceptUnknown": "both",
  "format": [
  "profile": [
      { "reference": "" },
      { "reference": "" },
      { "reference": "" },
      { "reference": "" },
      { "reference": "" },
      { "reference": "" },
      { "reference": "" },
      { "reference": "" },
      { "reference": "" },
      { "reference": "" },
      { "reference": "" }
  "rest": [
      "mode": "server",
      "security": {
        "cors": true
      "operation": [
          "name": "gpc.getstructuredrecord",
          "definition": {
            "reference": ""

Consumer systems:

  • SHOULD request the capability statement from the Access Record Structured FHIR server endpoint in order to ascertain details of the implementation delivered by the FHIR server, this includes checking the version number specified in CapabilityStatement.version
  • MAY also cache the Access Record Structured capability statement information retrieved from an endpoint to reduce the number of future calls they make to the target organization’s Access Record Structured FHIR server.

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