Uplifts to GP2GP Adaptor
ID | RM261 |
|---|---|
Version | 1.0.1 |
Type | Roadmap Item |
Contracting Vehicle(s) |
Title | Uplifts to GP2GP Adaptor |
|---|---|
Description | Uplift to GP2GP Requesting and Sending Adaptor to support resend of GP2GP transfer and the preservation of original codes. |
Date Added | Apr 10, 2025 |
Standards and Capabilities | GP2GP Requesting Adaptor, GP2GP Sending Adaptor |
Change Route | Patch |
Change Type | New/Uplift |
Status | Closed |
Publication Date | May 8, 2025 |
Effective Date | May 22, 2025 |
Incentives / Funding | No |
Incentive / Funding Dates | N/A |
Background
The GP2GP Adaptor(Requesting/Sending) is required to be uplifted with new Requirements along with updates on existing Requirements. The main areas that will be introduced as a part of this Roadmap item is as follows:
Resends: If a GP2GP transfer fails, the ability for the Sending System and/or Sending System User to resend the transfer attempt. This will allow for the resend of the transfer when the error has been caused by intermittent network or system issues rather than using an off system solution. This mimics current GP2GP HL7 behaviour.
Preservation of original codes: When an Incumbent system sends a record they will send the original code used (Read v2, CTv3 or local code) and the mapped SNOMED CT code. Currently there is no requirement to preserve or send the original code used on Suppliers of new services or applications. This change is to ensure legacy codes are available for audit purposes and these codes are made available again for any future GP2GP transfer back to the original system.
Outline Plan
Supplier Solutions must be fully compliant with these changes by the Effective Date.
Summary of Change
GP2GP Requesting Adaptor : Requirement Updated | ||
Requirement ID | Requirement | Level |
Step 6 | ||
GP2GP_Req_25 | If the lookup to SDS fails or no ASID exists for any reason (e.g. the previous practice was a Defence Medical Services that does not support GP2GP) then the GP2GP process cannot proceed as the Sending Site end point has not been identified. The GP2GP status for this transfer in the workflow will be marked as ‘failed’ and will indicate that the user must contact the Sending Site as no GP2GP request was made. | MUST |
GP2GP Requesting Adaptor : New Requirements added | ||
Requirement ID | Requirement | Level |
Step 14 | ||
GP2GP_Req_101 | Where a GP2GP transfer has failed, the Sending Site may attempt a re-send of the EHR. The Requesting System will need to allow receipt of a re-sent EHR that has the same Conversation ID of the EHR that previously failed. The Requesting System will also update its GP2GP workflow associated with the outcome of the resend (if it fails again or is successful). | must |
Step 17 | ||
GP2GP_Req_102 | When the Requesting System is integrating a re-send of an EHR, it must not overwrite any data that has been entered since the Patient has been registered. | must |
Step 18 | ||
GP2GP_Req_103 | The Requesting System must preserve any legacy codes it receives from the Sending System (i.e. Read v2/CTv3 or local codes that have been mapped to SNOMED CT). This is to ensure they are available for audit purposes and these codes are made available again for any future GP2GP transfer back to the original system. Example below, the SNOMED CT code will be used by the Requesting System to populate the record, but the original ctv3 code must also be stored, but does not need to be made available to the user.  | must |
GP2GP Sending Adaptor : New Requirements added | ||
|---|---|---|
Requirement ID | Requirement | Level |
Step 15c | ||
GP2GP_Send-15 | The Sending System must provide a function for the user to trigger a re-send of the GP Connect structured record (EHR) for any GP2GP failed transfer. This is because:
In both cases a re-send should now result in a successful transfer and is preferable to an off-system paper process. | must |
GP2GP_Send-16
| The Sending System, when attempting a retry must create the structured GP Connect structured record (EHR) using the latest copy of the record held on their database (so that any additions since the first attempt at sending are included). | must |
GP2GP_Send-17 | Prior to re-sending the GP Connect structured record (EHR) the Sending System shall perform the usual PDS checks, as listed in Step 2, to ensure that the Patient is still registered at the requesting practice. | must |
GP2GP_Send-18 | If the re-send is successful, and a positive acknowledgment received, the Sending System will update its workflow as per GP2GP_Send-10. If a negative acknowledgement is received the user can still trigger a re-try but the Sending System may wish to place some restrictions (e.g. only one re-send per failed record every 24 hours). | must |
Step 4 | ||
GP2GP_Send-19 | GP Connect migrate structured provides the data model for the sending of an Electronic Health Record (EHR), however, for the avoidance of doubt the following are requirements that are to be followed when providing an EHR for a GP2GP transfer using GP Connect:
The original SNOMED code and descriptive text is made available along with the legacy Read v2 code and the original term text. | must |
Full Specification
GP2GP Requesting Adaptor v1.0.1
GP2GP Sending Adaptor v1.0.1
Assurance Approach
Not applicable as the Roadmap Item is a Patch change and no work is required by Suppliers.