Data flow diagram

Below is a diagram (Figure 1) that depicts an overview of the technical architecture of the Direct Care API service. The diagram can be summarised in the following points: 

• Direct Care API service enables information about a patient to be accessed by a clinician in a GP practice or other setting from the clinical system in their registered GP practice (see the three capabilities above). 
• Direct Care API service enables information about appointment availability within a GP practice (depending on the structure of the primary care setting – this may not be the patient’s registered practice) to be assessed by clinical admin staff from other GP practices and care settings (for example, a 111 call centre or an urgent care centre). GP Connect allows appointments to be booked, amended, or cancelled for a patient, and a list of future appointments can also be viewed.
• The patient information passes through NHS England infrastructure but is not stored. 
• NHS England stores audit information on the message flows to enable service support. A subset of this audit information includes a patient’s NHS Number.
• NHS England (SSP) validates that the message only flows between (GP or other) organisations

Figure 1 – Technical Architecture of the Service using the SSP (HTML, Structured and Appointment Management capabilities)

The diagram (Figure 1) and description above relate the Direct Care API service specific data flows. However, in addition to these flows, the Direct Care API service requires a consuming system to have conducted two additional requests for data on Spine before making a request for Direct Care API service data:

1. The first is a request to the Patient Demographics Service (PDS) on Spine to confirm the identity of the patient. This involves the consuming system providing demographics (NHS Number and/or patient name, address, date of birth and gender) to Spine, and receiving in response a complete PDS demographic record for the patient, as well as details of the patient’s registered GP practice.

2.. The second is a request to the Spine Directory Service (SDS) to determine the technical interface address of the target GP practice. This involves the consuming system providing the practice’s ODS code and, in response, receiving the technical interface address.

The programme has worked with the GP principal system suppliers, other NHS programmes, clinicians and subject matter expert (SME) groups to define (i) the standard dataset structures (FHIR profiles) used as part of the Direct Care API service capabilities to carry the required information, and (ii) the business rules determining population of the profiles. This work has involved several steps.

The programme conducted analysis on the use cases gathered for the Direct Care API service capabilities. A logical model was created from this analysis that contained detailed records of the data items that the business required.

Figure 3 - NHS Health Developer Network

The team then analysed what information currently exists within the principal clinical systems and how this is exported to support other NHS England projects such as: GP2GP, Summary Care Record (SCR) and Electronic Prescription Service (EPS). The programme also considered future needs of ongoing NHS England projects to ensure we are as in line with these ongoing efforts as possible.

This analysis was used to create draft profiles that were then discussed in detail with the foundation clinical system suppliers to ensure their feasibility. Once this was complete, the profiles were taken through a curation process by a multi-disciplinary team that involved representatives from many organisations. These included: primary and secondary care clinicians, pharmacists, terminologists, data standards, clinical informaticians that had been involved in creating the base FHIR profiles, clinical safety representatives and representatives from primary and secondary care clinical systems suppliers, and PRSB.

Curated specifications are subject to internal review and will be published as Beta for GP suppliers to develop. However, consumer suppliers will be required to support a first of type for GP provider system suppliers, which will be planned and supported by implementation leads, project managers and consumers, and monitored until the deployment verification criteria (DVC) have been met. Continued monitoring and analysis will support requirements for live services to grant Full Rollout Approval (FRA).

The following sections of this document differentiate between data items that are held by NHS England and data that flows through NHS England infrastructure and does not reside nationally. Read the data specifications.

GP Connect data model

The initial implementation for GP Connect PFS connectivity is to provide the NHS App with a patient facing service to support GPIT Futures’ new market entrants (NME), and subsequently to reuse this for incumbent foundation suppliers, allowing further development for the app.

The goal of Direct Care (GP Connect) APIs is to improve interoperability across the health economy, reusing and improving existing APIs to benefit users and reduce the number of interfaces suppliers must maintain. PFS APIs are therefore based on the current clinical facing APIs, where possible (Access Record: Structured, Appointment Management and Send Document).

The solution includes creating standardised specifications for the following five GP Connect PFS APIs:

GP Connect (Patient Facing) User Permissions

• this API enables patients (via a consumer application, eg the NHS App) to view and request updates to their permissions to their medical record and to a selection of services provided at their GP practice. The permissions and access a patient has are set and maintained by the GP practice via their GP supplier system.
• when getting a patient’s permissions, this API enables a patient’s access by setting their default permissions, if they do not already have online access enabled
• Capability for PFS consumer supplier software application to request user permissions available and status (granted/denied) within a GP practice system for a given NHS Number and ODS code via API

GP Connect (Patient Facing) Access Record – FHIR API

This API enables patients (via a consumer application, for example the NHS App) to view their GP medical record.

Exclusions from View Record

Provision of each clinical area of the medical record is controlled by the GP practice. These restrictions can either be applied at practice level (for all patients or to an individual patient). Restriction applied on individual patient takes precedence. Read more information about restrictions or redactions, IG Requirements GP-IG-11-1, 2B and 3¹

Requesting clinical areas or data items inside clinical areas will depend on configuration set by the practice. In the case where the requested data item is restricted by the practice, either for all patients or current patient, no data will be retrieved.

This API enables patients to manage their prescriptions as held by their GP practice. They can:

• request a new instance of a repeat prescription
• view all medications, acute or repeat, past or present
• cancel an unactioned repeat prescription request
• request a new instance of a repeat prescription to a one-off nomination pharmacy

This API enables patients to book and manage appointments at their GP practice. They can:

• search for free slots
• book an appointment
• view appointments and their details
• cancel an appointment

The PFS API specifications are published on the NHS England API catalogue. They have been created centrally by NHS England in collaboration with internal stakeholders, NMEs, incumbent suppliers and consumer applications. (These web pages are available to system developers on request. If you would like a copy, please ask the NHS England Contact Centre directly. 

Consumers will access the API via the centrally hosted API Management (APIM) platform rather than Spine Secure Proxy (SSP). APIM provides all the required functionality for cross-cutting concerns that SSP does, including auditing, monitoring, and proxying. It does not have the ability to perform lookups against the Data Sharing Agreement Repository (DSAR). However, this is not required for PFS since the data sharing is between the GP and the patient, rather than other organisations. APIM is the strategic choice for API hosting and this approach for PFS will set the precedent for the clinical APIs within GP Connect.

The Prescriptions API will use FHIR R4, but Access Record and Appointment Management APIs will use FHIR STU3 and be migrated to R4 in future. The User Permissions API does not use FHIR since it does not handle any clinical data.

Patient authentication uses NHS login end-to-end process. A patient facing application (eg the NHS App) uses NHS login as the identity provider for a patient. It communicates with the foundation system’s PFS APIs via the API Management (APIM) platform. APIM is responsible for endpoint lookup and authentication token exchange between consumer applications and GP foundation systems.

patient facing services for GP Connect - system interactions  

Figure 1: This diagram shows how a patient uses their NHS App account and, in the background, can authenticate and interact with their GP patient record using both the Authorisation and Patient Facing Service APIs

API documentation is hosted on the NHS England API catalogue for the main information including OAS specifications:

• GP Connect (Patient Facing) Access Record - FHIR API
• GP Connect (Patient Facing) User Permissions API
• GP Connect (Patient Facing) Prescriptions – FHIR API

Details on the FHIR profiles and additional information is available on Simplifier:

• GP Connect (Patient Facing) Access Record
• GP Connect (Patient Facing) User Management
• GP Connect (Patient Facing) Prescriptions

These web pages are available to system developers on request. If you would like a copy please ask the NHS England Contact Centre directly.