Note: This is a draft version of the GP Connect PFS Appointments capability. The current version can be found using this link.
FHIR Capability Statement
Prerequisites
Consumer
The consumer system:
- SHALL have previously resolved the organisation's FHIR endpoint base URL.
API usage
Request operation
FHIR relative request
GET /metadata
FHIR absolute request
GET https://[proxy_server]/https://[provider_server]/[fhir_base]/metadata
Payload request body
N/A
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
200OK HTTP status code on successful retrieval of the capability statement - SHALL return a capability statement which conforms to the standard FHIR CapabilityStatement
An example GP Connect CapabilityStatement is shown below ready for customisation and embedding into GP Connect assured provider systems. Providers should use this CapabilityStatement as a base for their own CapabilityStatement, 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 specification version which the FHIR server implements.
Consumer systems:
- SHOULD request the capability statement from the FHIR server endpoint in order to ascertain details of the implementation of GP Connect capabilities delivered by the FHIR server
- Consumers may also cache the capability statement information retrieved from an endpoint to reduce the number of future calls they make to the target organization's FHIR server.
Error handling
Provider systems are expected to always be able to return a valid capability statement.
Examples
Get the capability statement
Request
{% include foundations/get-capability-statement-request-header-1.txt %}
Response
{% include foundations/get-capability-statement-response-payload-1.json %}