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
Use Cases
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 |
The Register Patient API use case, which is included in the Foundations capability, has a separate “Register Patient” message set:
Operation | InteractionID |
---|---|
Register Patient | urn:nhs:names:services:gpconnect:fhir:operation:gpc.registerpatient-1 |
Implementation And Testing
Below is the suggested order in which the foundation capabilities should be implemented. The specified order has been recomended around the functionality of the GP Connect Automated Test Suite and any internal dependancies 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.
1. 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 capablitiy within the automated test suite. |
#2 | Read an Organization | Find an organization | Find an organization is a dependancy 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. |