Background

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

There are currently issues within the electronic transfer that cause:

• The entire record transfer to fail, in which case the Patient Record must be printed and sent to the Patient’s new Practice via courier
• Partial failure, where some attachments do not get sent. In this scenario the failed attachments must be printed and sent to the Patient’s new Practice via a courier
• Data within the record is being degraded or lost, potentially impacting the ability of the new Patient’s Practice to optimise their delivery of care to the 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 system part of the journey. It also only covers transfers using GP2GP. 

Through the existing GP2GP specification, Practice systems Suppliers provide some limited Management Information (MI), but this has several limitations. These include:

• Suppliers currently submit their GP2GP MI once a week which prevents the NHSD team from maintaining a real time view of GP2GP system performance
• Supplier MI is submitted in CSV format which makes further processing time consuming and inflexible
• The MI does not provide a way to identify and differentiate between different GP2GP interactions which makes deduplicating GP2GP transfer conversations time consuming and in some cases, impossible
• Differences between Suppliers in how they have implemented the existing MI specification which results in difficulties when attempting to accurately interpret the data

The purpose of this new Registrations Enhanced MI Specification is to define and consistently implement an uplifted MI specification which will be used to drive continuous improvement in 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. 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
• 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.

ID	Description	Level
GP2GP05	Suppliers must implement and maintain the GP Registrations Management Information API inline with the latest specification version

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

ID	Description	Level
GP2GP03	Suppliers must provide support to receivers of GP2GP messages to resolve any issues with interpreting, consuming and processing received messages

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.

All Roadmap items must have the label: roadmap_item. Then add labels from these categories as appropriate. Use one or more 'group' labels depending on the type of Capabilities and Standards impacted by the Roadmap Item: capabilities, context_specific_standards, overarching_standards, interop_standards, tbc. If above label is not "tbc", then use one or more 'ID' labels for each of the Capabilities and Standards that are impacted by the Roadmap Item e.g. s27, c12.