Definitions and notes about this data

Definitions

Registrations that triggered GP2GP transfer

Total number of registrations that triggered a GP2GP transfer between the 1st and the last day of the month.

Not Included

This does not include registrations that did not trigger a GP2GP transfer. This could be for one of the following reasons

registrations that are not eligible for GP2GP. For example:

the previous practice was in Wales or Scotland
registrations to and from the armed forces
there is no previous practice registered, for any reason

registrations that had a technical issue before GP2GP was triggered. For example, if there was a technical issue during PDS trace or update.
transfers between SystmOne practices that do not go via GP2GP.

This list is not exhaustive and there may be other scenarios in which a GP2GP transfer is not triggered. For more information about how the data is calculated see the ‘Notes about this data’ section.

GP2GP transfers received

Total number of GP2GP transfers between the 1st and last day of the month that were successfully received by the registering practice.

This includes transfers that have not been integrated.

This does not include GP2GP transfers that

failed to transfer, or
were rejected by the receiving practice

For information about how the data is calculated see the 'Notes about this data' section.

GP2GP technical failures (paper copy requested)

Percentage of GP2GP transfers requested between the 1st and last day of the month that failed for a technical reason.

Reasons for technical failures

Technical failures can happen from the point the GP2GP transfer is triggered until the point of integration. Technical failures are not caused by user actions and should be reported to the system supplier.

Example reasons for technical failures

Large message failures
Spine errors
Timeouts

This list is not exhaustive and there are other scenarios in which a technical failure happens.

Not included

Technical issues that happened before GP2GP was triggered. For example, if there was a technical issue during PDS trace or update.

For information about how the data is calculated see the 'Notes about this data' section.

Integrated within 3 days

The percentage of transfers received that were integrated (filed or suppressed) within 3 days of the record being sent.

3 days is considered best practice for integrating or suppressing records transferred via GP2GP.

Time to integrate

The time to integrate is calculated from the time the GP2GP transfer starts to the time the record is integrated by the registering practice.

For example, the GP2GP transfer for a record takes 10 minutes. The practice integrates the record 2 hours after receiving it. The time to integrate would be 2 hours 10 minutes (within 3 days).

For information about how the data is calculated see the 'Notes about this data' section.

Integrated within 8 days

The percentage of transfers received that were integrated (filed or suppressed) within 8 days of the record being sent.

Integrating within 8 days means that a paper copy of the record is not unnecessarily requested.

Time to integrate

The time to integrate is calculated from the time the GP2GP transfer starts to the time the record is integrated by the registering practice.

For example, the GP2GP transfer for a record takes 10 minutes. The practice integrates the record 2 hours after receiving it. The time to integrate would be 2 hours 10 minutes (within 3 days).

For information about how the data is calculated see the 'Notes about this data' section.

Not integrated within 8 days (paper copy requested)

The percentage of transfers received that were not integrated within 8 days.

This includes transfers that were:

integrated after 8 days, or
not integrated when the transfer was categorised.

Not integrating transfers within 8 days increases the amount of paper records that your practice will need to process and store.

Time to integrate

The time to integrate is calculated from the time the GP2GP transfer starts to the time the record is integrated by the registering practice.

For example, the GP2GP transfer for a record takes 10 minutes. The practice integrates the record 2 hours after receiving it. The time to integrate would be 2 hours 10 minutes (within 3 days).

For information about how the data is calculated see the 'Notes about this data' section.

About this data

How we calculate the data

This site is updated 15 days after the end of each month. This is to identify whether transfers started at the end of the month were integrated within 8 days.
Every transfer shown on the platform is categorised 14 days after it started.
- For example, a transfer started on the 2nd February would be categorised based on its status on the 16th February.
The time to integrate is calculated from the time the GP2GP transfer starts to the time the record is integrated by the registering practice.
- For example, the GP2GP transfer for a record takes 10 minutes. The practice integrates the record 2 hours after receiving it. The time to integrate would be 2 hours 10 minutes (within 3 days).
In a small number of cases the data may be different to what is expected because the GP2GP transfer took longer to complete. If the GP2GP transfer takes longer, the practice has less time to integrate before the paper process is triggered on day 8.
- For example, if the GP2GP transfer takes 3 days, the practice has 5 days to integrate before the paper process is triggered.
There may be other scenarios which mean the data is different from what is expected. If you have concerns about the data for a specific practice, please contact us at gp-registrations-data@nhs.net.

Not included in the data

The following are not included in the data on this site.

GP2GP transfers for deducting practices
registrations that are not eligible for GP2GP. For example:
- the previous practice was in Wales or Scotland
- registrations to and from the armed forces
- there is no previous practice registered, for any reason
registrations that had a technical issue before GP2GP was triggered
transfers between SystmOne practices that do not go via GP2GP