Background
GP2GP allows patients’ electronic health records to be transferred directly, securely, and quickly between their old and new practices, when they change GPs.
There are currently issues within GP2GP that either 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 across via GP2GP. 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 degraded, or lost, potentially impacting the ability of the new 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.
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.
Through the existing GP2GP service, 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 prevents the NHSD team from maintaining a real time view of GP2GP system performance.
- Supplier MI is submitted in CSV format. This 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 makes deduplicating GP2GP transfer conversations time consuming and in some cases, impossible.
- Differences between suppliers in terms of how they have implemented the existing MI specification. This results in difficulties when attempting to accurately interpret the data.
The purpose of this New Work Request (NWR) is to define and consistently implement an uplifted GP2GP MI specification which 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 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 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.
Further details are contained in the technical space on the developer portal. Live version will be made available TBC.