...
...
Page Properties | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
|
Page Properties | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
|
...
|
...
|
...
|
...
|
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/postmanFollow 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:
...
GP2GP: Link Removed from Supplementary Specifications |
Supplementary specificationsThe following supplemental specifications contain additional requirements and guidance for GP2GP implementation: NPFIT-FNT-TO-TIN-1087.02 GP2GP Supplementary Specification on Handling Medication Discontinuation.pdf NPFIT-PC-BLD-0069 24 GP2GP Spine Technical Design v7.1.pdf NPFIT-PC-BLD-0083.08 GP2GP Response Codes.pdf NPFIT-PC-BLD-0099.04 GP2GP Handling Missing Attachments.pdf NPFIT-PC-BLD-0132.03 GP2GP Supplementary Specification on Structured Degrade Handling.pdf NPFIT-PC-BLD-0133.02 GP2GP Supplementary Spec - Handling and Propagation of Non Consultation Data.pdf NPFIT-PC-BLD-0134.05 GP2GP Supplementary Specification Representing PMIP Data in GP2GP Messages.pdf NPFIT-PC-BLD-0158 GP2GP Supplementary Specification Attachment References.pdf NPFIT-PC-BLD-0163.02 Topic and Category Handling in GP2GP.pdf NPFIT-PC-BLD-0170.03 GP2GP SS Handling Large Messages.pdf
NPFIT-PC-BLD-0172.02 GP2GP UC1 Transfer Electronic Health Record.pdf NPFIT-PC-BLD-0173.01 GP2GP UC 2 Harvest and Prepare Management Information.pdf NPFIT-PC-BLD-0175.03 GP2GP SS Handling A-B-A Transfers v1. |
...
3.pdf NPFIT-PC-BLD-0177.01 GP2GP SS User Experience.pdf NPFIT-PC-BLD-0178 02 GP2GP Coding Scheme Translation v1.1.pdf NPFIT-PC-BLD-0180.02 GP2GP Transfer of Patient Facing Service Settings 04.pdf NPFIT-PC-BLD-181.02 GP2GP Handling the SCR indicator v03.pdf NPFIT-FNT-TO-IG-DES-0115.01 Statement on Data Retention v1.0.pdf NPFIT-FNT-TO-TAR-0017.07 Compliance Requirements for Patient Registration.pdf NPFIT-FNT-TO-TIN-0289.08 GP2GP Supplementary Specification on Handling Attachment Types.pdf |
GP2GP: Requirement GP2GP05 added |
ID | Description | Level |
---|---|---|
GP2GP05 | Suppliers must implement and maintain the GP Registrations Management Information |
...
API inline with the latest specification version |
|
...
GP2GP: Requirement GP2GP03 updated |
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:
2xx - Successful event submission
4xx - Bad request
The error message will identify the reason for the failed validation of the message content. This should be resolved and then resubmitted5xx - Internal Server Error
If a 500 error is encountered, the message should be saved and sent at a later time.
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.
Endpoint | 2xx | 4xx | 5xx | No Response | No Pll |
---|---|---|---|---|---|
registrations | |||||
transfer-compatibility-statuses | |||||
ehr-requests | |||||
ehr-responses | |||||
document-responses | |||||
ready-to-integrate-statuses | |||||
ehr-degrades | |||||
ehr-integrations | |||||
errors |
Post-Live Verification
Once the service is live, after 1 day and 1 week, the following verifications should be completed:
Confirm the number of events submitted
Confirm the number of EHRs transferred
All expected events received
Review any errors encountered.