Patient Switching Standard
Background
Currently, GP2GP is the standard by which electronic patient records and any associated documents are moved when a patient transfers from one practice to another. GP2GP uses HL7 as the messaging format
The Patient Switching Standard is set to replace the existing GP2GP model
The Patient Switching Standard will use GP Connect 1.6 structured FHIR as the method of transfer of these records instead of HL7 v3
This builds on the strategic standard for the movement of patient records between healthcare organisations as using GP Connect structured data and allows the retirement of the legacy HL7 v3
An extension has been made to GP Connect to facilitate the Patient Switching Standard use case (v1.6). These requirements are published here
- Migrate Patient Record
- Migrate Document
Outline Plan
Following suppliers adopting GP Connect 1.6 this facilitates the ability to move from GP2GP to the Patient Switching Standard (PSS)
It is expected that for a period of time there will be a mixed economy across the supplier estate, where some suppliers have adopted the PSS and others are still using GP2GP and HL7 v3 to transfer records
There are two significant scenarios:
Supplier using PSS winning a patient from a GP2GP site
In this scenario the winning site will make a request for the record and any attachments using GPC 1.6. As the losing site is also GPC 1.6 provider compliant it will return the record and attachments using the GPC API
Supplier using GP2GP winning a patient from a PSS site
In this scenario the winning site will make a request for the record and any attachments using GP2GP HL7 v3. An adaptor has been created by NHS Digital that will deployed at the site using the PSS. This adaptor will take the incoming HL7 v3 request and change it to a GPC request. The PSS site will take this and then retrieve and build the patient record for as GPC payload. At the point of sending the adaptor will transform the GPC message into a HL7 v3 record. This is so it can then be processed by the site using GP2GP
Summary of Change
The Patient Switching Standard over GP Connect 1.6 will bring about a number of changes to the current GP2GP process:
Handling documents
When the winning site receives a patients GP Connect Record Bundle it will parse the file and identify each document required. Therefore, each document is requested separately. The file limit across spine and the estate is being raised from 5mb to 100mb
As each document is requested separately, any failures can be reported to the losing site via the User Dashboard (as below). This means only those documents that fail need to be printed by the losing site
User Dashboard
User research has highlighted issues with identifying patient record transfer status and references to documents that are ambiguous. The PSS will look to improve these by taking on board feedback and setting a standard for providing users with information
Management Information
There will be updated and improved management information that will be delivered to NHS Digital in real time. This will facilitate stakeholders, such as clinical commissioning groups and service management, being able to identify trends and better diagnose potential problems and incidents
Internal Transfers
A standard approach to handling internal patient transfers (i.e. Patient moves from one practice to another on the same clinical system) where they can be accommodated. This is to bring internal transfers in line with clinical safety standards and ensure Management Information and the User Dashboard are also correctly populated
Full Specification
The Patient Switching Standard will comprise of the following requirement bundles:
| High Level Requirements | Overview of the end to end process |
|---|---|
| Management Information | This will detail how Management Information should be captured and provided back to NHS Digital via the Management Information API |
| Patient Switching Dashboard | This will provide requirements on the user interface that provides them with the status of all switches that are in progress, along with the ability to view all historical switches. It will also provide the alerts and workflow for users. This interface will be necessary for both the Requesting and the Sending system |
| Operational Outcomes | This document will detail the process by which the Requesting System determines what information it needs to provide to the Sending System. This is to ensure that a Patient Record or Documents that have not been requested/received are provided. This Operational Outcome message will result in the Sending System notifying the user of the need to print any Electronic Patient Record and/or Documents. [Further work is ongoing to determine other digital methods of transferring this information] |
| Integration of the Record | Will determine logic and rules for integrating the record bundle into the clinical system and any clinical safety aspects around allergies/medications etc. Also provide detail on the handling of codes/values/data items where an appropriate mapping does not exist in the Receiving System |
| Returning Patients | Outlines the requirements for handling the integration of records where it is a returning patient |
| Get Document | Details the process by which documents are to be identified from the GP Connect Record Bundle and the process of determining which documents are to be requested. It also specifies the creation of placeholders by the Requesting System in the Electronic Patient Record |
| Technical Implementation | Provides detailed technical guidance regards PDS and SDS lookup |
The full specification will published here once confirmed
The GP Connect 1.6 is a separate programme and release notes can be found here: GP Connect API 1.6.0-beta release notes
Assurance Approach
TBC