Foundations FHIR - NHS England Digital

Purpose

The Foundations capability covers the basic API requirements and prerequisites needed to use the GP Connect APIs.

Prerequisites

PDS

You need to be able to provide a verified NHS number to use an API. You can do this using a Spine accredited system, a Demographics Batch Service (DBS) batch-traced record (CSV), or using a Spine Mini Services Provider (HL7v3).

SDS / ODS

To resolve a given GP Practice organisation to its URI you need to be able to do a Spine SDS query (LDAP) using the practice’s ODS code to perform an SDS End Point Lookup.

FHIR

In order to be a compliant FHIR server, provider systems need to expose a valid FHIR CapabilityStatement profile.

Refer to Development Guidance - FHIR API Guidance - Common API Guidance for full details on the common FHIR API patterns used throughout all the GP Connect APIs.

Scenarios

Search for a patient by NHS Number
Search for an organisation by ODS Code
Search for a practitioner by SDS UserID

API definition

The following individual API calls make up the Foundations capability and support the other capability packs:

Spine interactions

The Foundations capability message set includes the following set of Spine interactions:

Operation	InteractionID
Read Metadata	urn:nhs:names:services:gpconnect:fhir:rest:read:metadata-1
Read Patient	urn:nhs:names:services:gpconnect:fhir:rest:read:patient-1
Patient Search	urn:nhs:names:services:gpconnect:fhir:rest:search:patient-1
Read Practitioner	urn:nhs:names:services:gpconnect:fhir:rest:read:practitioner-1
Practitioner Search	urn:nhs:names:services:gpconnect:fhir:rest:search:practitioner-1
Read Organisation	urn:nhs:names:services:gpconnect:fhir:rest:read:organization-1
Organisation Search	urn:nhs:names:services:gpconnect:fhir:rest:search:organization-1
Read Location	urn:nhs:names:services:gpconnect:fhir:rest:read:location-1
Register Patient	urn:nhs:names:services:gpconnect:fhir:operation:gpc.registerpatient-1

Implementation and testing

Below is the suggested order in which the Foundations capabilities should be implemented by provider suppliers. The specified order has been recommended around the functionality of the GP Connect Automated Test Suite and any internal dependencies between the test scenarios for the different foundation endpoints.

It is advisable to develop against the Automated Test Suite as this will assist with creating a GP Connect compliant product. By implementing the endpoints in the order below, this means that the automated test suite set of tests for that endpoint can be run during development without the developer seeing errors due to pre-test API calls or post-test validation API calls relevant to the test being run and failing as they have not been developed yet.

Foundation endpoints

Order	API Endpoint	Test Suite Endpoint Dependencies	Reason For Dependency
#1	Find an organization	-	The find an organization capability is not dependent on any other capability within the automated test suite.
#2	Read an Organization	Find an organization	Find an organization is a dependency for Read an organization as it is used to lookup the local identifier from the organization code which is setup in the test suite organization mapping csv file.
#3	Find a practitioner	Read an Organization	The Read an organization endpoint is required to validate the “managingOrganization” reference returned within the practitioner resource.
#4	Read a practitioner	Find a practitioner / Read an organization	Find a practitioner is required to lookup the logical identifier, from the practitioner user id setup in the test suite practitioner mapping csv file, to use for the read. The Read an organization endpoint is required to validate the “managingOrganization” reference returned within the practitioner resource.
#5	Find a patient	Read and organization / Read a practitioner	The Read an organization endpoint is required to validate the “managingOrganization” reference returned within the practitioner resource. The Read a practitioner endpoint is required to validate the “careProvider” reference if returned within the patient resource.
#6	Read a patient	Find a patient / Read an organization / Read a practitioner	Find a patient is required to lookup logical identifier from the patient from the NHS number set up in the test suite nhsNoMap csv file. The Read an organization endpoint is required to validate the “managingOrganization” reference returned within the patient resource. The Read a practitioner endpoint is required to validate the “careProvider” reference if returned within the patient resource.
#7	Read a location	Read an organization	The Read an organization endpoint is required to validate the “managingOrganization” reference returned within the location resource.
#8	Register a patient	Find a patient / Read a patient / Read an organization	The register patient endpoint tests require a number of the foundation search and read endpoints to be implemented and therefore it is advised that this is done as the last foundation capability. The foundation endpoints are used to create rich register patient requests as well as validating the registered patient resource is valid and retrievable on the providers system.

Information governance

Patient dissent to share flag

When Foundations APIs are used to support the Appointment Management capability, the above flag SHALL NOT be applied by provider systems.

PDS S-flagged patients

Consumer systems SHALL NOT send GP Connect requests for S-flagged patients.

In cases where a request for an S-flagged patient is sent, provider systems SHALL return a ‘Patient Not Found’ error.

Foundation resources

Get the FHIR® conformance profile

Request

N/A - No FHIR resource is sent within the request

Response

Conformance

Errors

If there is a problem with the request or an error occurs during processing of the request then the provider should return a http error along with an “OperationOutcome” Resource within the response payload.

Response

gpconnect-operationoutcome-1 (based on FHIR OperationOutcome)