The objective of GP2GP record transfer mechanism is to support the exchange of a GP’s (General Practitioner who is the patient primary care service provider in the context of UK) patient record electronically to a new practice when a patient registers with a new GP. In England an estimated 10% of patients change their practice each year and if the average list size of a practice is 1500 then there will be average of 150 transfers each year per practice. Most practices handle this transfer using the standard Lloyd George envelope or Medical Record envelope method for the transfer of the patient’s past care paper record.
The most common process of transfer of the electronic component of the patient record using Lloyd George envelope method is to produce a printout of the content of the medical record and to put it in the Lloyd George MRE at de-registration. Factually few doctors study such printouts and fewer practices re-enter any salient information and this information is unavailable to assist future care. Thus, an effective method which is aimed at the increased use of electronic records by GPs to improve the care of the patients is reducing the data quality of the patient record when passed to other GPs.
Currently England under CFH with history of pilot implementation of GP2GP using HL7 V3.0 by HIRI (Health Informatics Research International Ltd) consortium in 2003 is now trying to provide this transfer electronically using the national infrastructure and methodology developed under the National Programme for IT-CFH. The GP2GP messages, designed form part of the CFH Message Implementation Manual to support an automated request, acknowledgement and send of the electronic component of the record to assist in the continuation quality electronic records when a patient moves practice.
The objectives and benefits of GP2GP as per CFH website (http://www.connectingforhealth.nhs.uk/systemsandservices/gpsupport/gp2gp) are twofold – benefits the patients and benefits to the practice administration. The benefits of using GP2GP to the patients as perceived under GP2GP are
Ø The patient health record being available to the new GP a lot sooner (e.g. within 24 hours)
Ø The new GP will have knowledge of the patient’s:
o Current medication
o Drug interactions
o Current problems
o Key past medical history
o An improvement in patient safety
Ø Increase patient confidence that they will get good continuing care
Ø Prevent patients being asked information that they have previously reported
The benefits to the practice administrative support teams as perceived under GP2GP are
Ø Reduction in administrative time at the previous GP practice to find and forward on patient records to the new GP practice
Ø Reduction in administrative and clinical time at the new GP practice to review and summarize or re-key the patient record received from the previous GP practice
Ø Reduction in the time taken for the practice to receive the patient record
Ø Reduction in administrative time to chase up patient records from Health Authorities
Exchange Mechanism under CFH GP2GP
The GP2GP process under CFH starts with the registration of a new patient with a GP practice. The GP2GP explicit flows are triggered by the NHAIS Registration links acceptance message flow and the update of the GP registration on a national MPI database called PDS (Personal Demographic Services) which is a part of the national EHR called Spine.
The GP2GP process covers the electronic transfer of the patient record between primary care systems through the MHS (Message Handling Service) of the Spine supplied by the NHS Care Record (NCRS) National Application Service Provider (NASP). There is no interaction with the on-going paper process of transferring Lloyd George envelopes.
The Expected basic functionality provided as part of GP2GP by CFH is as follows
Ø Construct and process EHR Request & Acknowledgement messages
Ø Construct and transfer EHR Extract and integrate into receiving system
Figure below the GP Exchange under CFH GP2GP when a patient shifts from Practice A to Practice B. The exchange is based on intermediary ebXML exchange where the infrastructure of the national EHR called Spine is used as the intermediary MHS.
A1- patient requests a registration with a GP/ GP practice. The GP/GP practice decides to either accept or reject a request for registration
A2- patient requests a registration with a GP/ GP practice. The GP/GP practice decides to either accept or reject a request for registration
A3- As part of the local registration process, the PDS is queried for the patient’s up to date details e.g. demographics, NHS number and current registration details
A4-The Spine Integration infrastructure will route the query to PDS which will populate a response message with the available patient details. If no record of the patient exists on PDS then a new entry will be created and appropriate PDS update messages sent
A5- The patient demographics and NHS number content of the PDS query response is integrated in the local system.
A6- The GP system will interrogate a national directory called SDS to find out if the practice system with which the patient was previously registered is compliant for GP2GP record transfer messages. The SDS keeps a list of all compliant systems.
A7-If the SDS response is negative e.g. the practice system is unable to send/receive GP2GP record transfer messages then the GP system will alert the user to the fact that no electronic transfer of the existing patient record is available
A8- A positive SDS response will trigger a record transfer request to be sent to Spine to route it to the GP practice system.
A9 - The Spine will route it to the GP practice system with which the patient was previously registered
A10- GP system will receive the request and alert appropriate users to the request.
A11- The EHR Request will be considered by the requested GP Practice
A12- The GP system will send an acknowledgement of receipt of the request to the spine which acts as intermediary to be sent to the requesting GP system.
A13- The Spine will forward the acknowledgement of receipt of the request to the requesting GP system.
A14- The GP system will receive the acknowledgement.
A15- The GP system will alert appropriate users to the receipt of the acknowledgement.
A16- If the request can be fulfilled the GP system will send the patient’s Primary care record as an EHR extract message to the Spine
A17- The Spine will forward the EHR extract to the requesting system by acting as intermediary.
A18- The GP system will receive an EHR extract
A19- The GP system will notify appropriate users to the receipt of EHR extract
A20- The EHR extract will be considered by the requested GP Practice
A21- The EHR extract will be integrated with the appropriate patients record
PS: Iam not sure why they are called EHR messages though but again everyone have their own definitions
