Background

GP2GP allows patients’ electronic health records Patients’ Electronic Patient Records to be transferred directly, securely, and quickly between their old and new practices, Practices when they change GPs.

There are currently issues within GP2GP the electronic transfer that either cause:

• The entire record transfer to fail, in which case the patient record Patient Record must be printed and sent to the patient’s Patient’s new practice Practice via courier.
• Partial failure, where some attachments do not get sent across via GP2GP. In this scenario the failed attachments must be printed and sent to the patient’s Patient’s new practice Practice via a courier.
• Data within the record is being degraded , or lost, potentially impacting the ability of the new patient’s practice Patient’s Practice to optimise their delivery of care to the patient.

NHS Digital (NHSD) has been commissioned by NHS England (NHSE) to determine and monitor the scale of GP2GP transfer failure rates, to diagnose the causes of failures, and to direct and collaborate with suppliers to implement technical measures to address them. The overall aim of the NHSD team, in line with NHSE’s commission, is to reduce the rate of GP2GP transfer failures.

• Patient

The NHSD team is currently using Spine logs to measure the health of the GP2GP service. As these do not cover the end-to-end flow of the registration process (they only provide insight on the Spine elements of the GP2GP journey), they do not provide complete visibility into the causes of all transfer failures, particularly where failures occur within the GP practice Practice system part of the journey. It also only covers transfers using GP2GP. 

Through the existing GP2GP servicespecification, Practice systems Suppliers provide some limited Management Information (MI) is provided by practice systems suppliers, but this has several limitations. These include:

• Suppliers currently submit their GP2GP MI once a week . This which prevents the NHSD team from maintaining a real time view of GP2GP system performance.
• Supplier MI is submitted in CSV format . This which makes its’ further processing time consuming and inflexible (for example, it’s hard to represent structured/nested content, and hard to extend it - if we want to measure new things - such as attachments information or degrades).
• The MI does not provide a way to identify and differentiate between different GP2GP interactions (i.e., there is no unique identifier). This which makes deduplicating GP2GP transfer conversations time consuming and in some cases, impossible.
• Differences between suppliers Suppliers in terms of how they have implemented the existing MI specification . This which results in difficulties when attempting to accurately interpret the data.

The purpose of this New Work Request (NWR) new Registrations Enhanced MI Specification is to define and consistently implement an uplifted GP2GP MI specification which will be will be used by NHSD to drive continuous improvement in the GP2GP service in line with the objectives of NHSE’s commission.

NHSE has commissioned NHSD to deliver this work as part of GP Patient Record Continuity & Digitisation Programme. The objective of this programme is to eradicate paper copies of GP practice patient records in order to reduce costs, reduce operating burden, and increase patient experiences when changing GP practices.

Outline Plan

TBC

Summary of Change

Currently, suppliers electronic transfer of records.

Currently, Suppliers on the 2.2b specification for GP2GP supply MI via a MESH mailbox, in CSV format, on a weekly basis. We are proposing a new MI solution to be implemented by all suppliers. This solution would be for suppliers to send events across the registrations flow This change replaces the previous MI requirement with a new solution that: 

• Captures MI events across the Registrations end-to-end journey in JSON format via a RESTful API

The benefits of this JSON / RESTful API approach:

• The ability to capture near . This will enable the causes of GP2GP transfer failures to be identified, diagnosed, and resolved more efficiently, resulting in GP2GP service performance improvements to be implemented more expeditiously.
• As a result of implementing a more extendable format, as the NHSD team’s knowledge and understanding of the GP2GP service and the cause of its failure develops, we will be able to more flexibly add in new fields to the scope of MI. This will enable future investigations into the causes of transfer failures to be completed more efficiently, without as great a dependency on suppliers.
• It will provide insight into the structured content of GP2GP event payloads which Spine logs are not capable of interpreting / measuring.

Please find our current draft proposal here: https://nhsconnect.github.io/prm-external-developer-website/rfcs/RFC0001_gp2gp_mi/overview/

Further specification details for API changes can be found here: GP Registrations Management Information API - NHS Digital

Full Specification

TBC

Assurance Approach

Risk Assessment call with the Solutions Assurance team who will test areas identified as risk areas. 

Integration test environment. Suppliers will be able to use this environment for testing before applying changes to the live environment. 

• Captures event in near-real time
• Captures additional information about the registration part of the process
• Captures information about placeholders, attachments and degrades
• Is more extendable for the future

Full specification: https://digital.nhs.uk/developer/api-catalogue/gp-registrations-management-information

Getting Started

• Read through the GP Registrations Management Information API
• Login to the NHS developer portal
• Add an application - GP Registrations Management Information API (Integration Testing Environment) to generate an API Key 
• Use the Postman examples to understand the requirements of each endpoint.
  https://github.com/nhsconnect/prm-gp-registrations-mi/tree/main/doc/postman
• Follow the Assurance Approach to validate the implementation.

Useful Links

Postman API Collection https://github.com/nhsconnect/prm-gp-registrations-mi/tree/main/doc/postman

Outline Plan

All Foundation Suppliers must be compliant against this specification by the effective date.

Suppliers should contact the team when they are ready to start development and/or onboarding. The team can be contacted at gp2gp@nhs.net. 

Prior to going live Suppliers must have completed:

• Digital onboarding
• Solution assurance by NHSD

If a Supplier believes that they do not need to meet any of the requirements within this specification within the requested time-period then evidence must be provided to the Patient Record Migration programme, demonstrating why this is the case. It will then be reviewed by the programme and a response will be provided back to the Supplier.

Summary of Change

GP2GP Standard Updates:

• Remove NPFIT-PC-BLD-0171.02 GP2GP SS Harvesting Management Information.pdf from the Supplementary Specifications section of the Standard.
• Add Requirement GP2GP05.

• Add space between "interpreting," and "consuming" in requirement GP2GP03,

Full Specification

GP2GP v.4.0.0

Assurance Approach

The Assurance Approach for this service is to: 

• Confirm the point in the Patient Registration workflow that should be associated with each API endpoint
• Confirm each endpoint call returns a 2xx status code
• Confirm that 4xx, 5xx status codes and No Response scenarios do not impact the otherwise successful completion of the EHR transfer
• Confirm that Personally Identifiable Information (PII) is excluded from the content submitted to the API

The following registration types must be supported:

• New to NHS Patient registration
• Normal registration between England GPs
• Transfer from another home nation
• Temporary to regular
• Temporary to regular from a home nation
• Merged Patient - i.e. created new Patient but later coupled with existing Patient ID on PDS
• New born registration

Each API endpoint should be verified for correct behaviour in the following scenarios:

1. 2xx - Successful event submission
2. 4xx - Bad request
   The error message will identify the reason for the failed validation of the message content. This should be resolved and then resubmitted
3. 5xx - Internal Server Error

If a 500 error is encountered, the message should be saved and sent at a later time.

1. No Response
   If no response is received within the timeout limit, the message should be saved and sent at a later time

Scenario Matrix

This table shows the matrix of API endpoints and the outcome scenarios that should be tested for each of them.

Post-Live Verification

Once the service is live, after 1 day and 1 week, the following verifications should be completed:

1. Confirm the number of events submitted
2. Confirm the number of EHRs transferred
3. All expected events received

Review any errors encountered.