Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Roadmap Item Retired

...

...

Page Properties
id1

ID

RM125

Version

1.0.4

Type

Roadmap Item

Frameworks

Page Properties
id2

Title

GP2GP Enhanced MI Specification

Description

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.

Date Added

 

Standards and Capabilities

GP2GP,

...

 Patient Information Maintenance - GP

Change Route

Managed Capacity - Minor/Patch uplifts

Change Type

Uplift

Status

...

Closed

Publication Date

...

 

Effective Date

...

 

Incentives / Funding

No

Incentive / Funding Dates

N/A

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/postman

  • Follow the Assurance Approach to validate the implementation.

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 specifications

The 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-0171.02 GP2GP SS Harvesting Management Information.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

Status
colourRed
titleMUST

...

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

Status
colourRed
titleMUST

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:

  1. 2xx - Successful event submission

  2. 4xx - Bad request
    The error message will identify the reason for the failed validation of the message content. This should be resolved and then resubmitted

  3. 5xx - Internal Server Error

If a 500 error is encountered, the message should be saved and sent at a later time.

  1. 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:

  1. Confirm the number of events submitted

  2. Confirm the number of EHRs transferred

  3. All expected events received

Review any errors encountered.