Integrate with Spine

GP Connect provider APIs are accessed through the NHS Spine. As such, consumers of GP Connect APIs are required to integrate with the following Spine services as a prerequisite to making API calls to GP Connect provider APIs:

• Personal Demographics Service (PDS)
• Spine Directory Service (SDS)
• Spine Secure Proxy (SSP)

Step 1. Personal Demographics Service

A GP Connect consumer queries PDS for the patient to:

• verify the patient’s NHS number
• retrieve the ODS organisation code of the patient’s registered GP practice

Important: Appointment Management consumer suppliers may want to build workflows that support appointment booking into other GP practices (other than the patient’s registered practice) such as into extended access hubs. For these consumers, an alternate mechanism for discovering the target practice’s ODS organisation code is required. See Appointment Management Service Discovery for more details.

For further details on this step, see Personal Demographics Service.

Step 2. Spine Directory Service

A GP Connect consumer queries SDS using the ODS organisation code retrieved in the previous step to retrieve:

• the GP practice’s GP Connect service root URL (their FHIR endpoint)
• the GP practice’s GP Connect ASID

For further details on this step, see Spine Directory Service - (Overview and Querying SDS).

Step 3 onwards. Spine Secure Proxy

A GP Connect consumer constructs a GP Connect FHIR request (incorporating the two items retrieved in the previous step), and sends it to the SSP.

The SSP then forwards the request on to the GP Connect provider system which returns its response back through to the SSP to the consumer system. A number of GP Connect FHIR requests may be made to satisfy the full workflow of the capability.

For further details on this step, see Spine Secure Proxy (SSP).

See the full worked example below for the steps required to consume the GP Connect Appointment Management capability.

Integrate with Spine to book an appointment at the patient’s registered GP practice

The following sequence diagram illustrates the steps which a GP Connect consumer would be required to undertake to book an appointment at the patient’s registered GP practice.

The steps shown in the diagram are detailed below.

Important: The Spine Secure Proxy (SSP) includes a mechanism to filter out all requests between organisations that are not registered on the proxy as having a mutual data sharing agreement. Without this, then all GP Connect consumers would be able to send requests to all GP Connect providers. For the filtering solution to work each consumer/provider organisation MUST have their own unique Spine ASID configured on the SSP.

Consumer topologies

Consumer system - shared MHS

This image shows several consumer systems connecting to GP Connect through a shared message handling server.

This is a typical deployment for an area-based or regional portal, where a central system or Trust Integration Engine (TIE) acting as the message handling server connects to Spine for multiple organisations.

Notes:

• each consumer system using GP Connect MUST have a unique ASID for each organisation that is using it, so that messages flowing through Spine can be correctly identified back to the originating organisation
• consumer systems in the shared MHS topology have one party key shared amongst connecting organisations

Important: In consumer system topologies where GP Connect consumer applications are provisioned via a portal or middleware hosted by another organisation, it is vital that the ASID sent in the Ssp-From header reflects the organisation from where the request originates, rather than the hosting organisation.

Consumer system - separate MHS

This image shows several consumer systems connecting to GP Connect via their own message handling servers.

This could be different types of consumer systems, or the same type of consumer system deployed as separate instances.

Notes:

• each consumer system using GP Connect MUST have a unique ASID for each organisation that is using it, so that messages flowing through Spine can be correctly identified back to the originating organisation
• consumer systems using the separate MHS topology each have their own party key

Provider topologies

Provider system - shared MHS

Important: In the diagram above, the shared message handling server holds three party keys, one associated with each practice. Party Key 1 is for the practice with ASID 1, Party Key 2 is for the practice with ASID 2, and so on.

Multiple GP practice systems using a shared message handling server.

This is a typical deployment for a multi-tenanted data centre hosted GP system serving multiple organisations.

Notes:

• each provider system using GP Connect MUST have an ASID AND party key for each organisation that is using it, so that messages flowing through Spine can be routed to the correct destination organisation
• each party key/ASID combination MUST be registered in SDS as a CMA endpoint 

Provider system - separate MHS

Discrete instances of GP practice systems each serving a single GP practice, and each with their own message handling server.

Notes:

• each provider system using GP Connect MUST have an ASID AND party key for each organisation that is using it, so that messages flowing through Spine can be routed to the correct destination organisation
• each party key/ASID combination MUST be registered in SDS as a CMA endpoint 

PDS tracing

GP Connect systems SHALL be capable of performing Personal Demographics Service (PDS) tracing of patients to obtain their NHS number, date of birth and current registered GP organisation.

The Personal Demographics Service - FHIR API provides a summary of the role of PDS in the NHS Spine architecture, and describes three options for accessing it. Systems SHALL perform this tracing using one of the three options.

Important: The term 'consuming system' on the PDS page of the Spine Core FHIR API Framework site applies in the GP Connect context to both consumer and provider systems.