<!-- Derived Markdown alternate of investigations/gp-registration/process.md; canonical repository sources and registered evidence retain authority. -->


# GP registration and record transfer

**A patient changing GP practice creates three separate assurance questions: is registration complete, is the record usable, and who owns outstanding clinical work?**

This investigation uses selected primary sources checked on **28 October 2026**. It explains the process before the technology. Read the companion [safety review and evidence](https://dsic-clinical-safety.pages.dev/investigations/gp-registration/safety-review/index.md) for assessment questions.

Use [unavailable automation](https://dsic-clinical-safety.pages.dev/investigations/gp-registration/unavailable-automation/index.md) to understand missing automatic functions, dependencies, permitted exceptions and requirement findings. Use [record-transfer fallback](https://dsic-clinical-safety.pages.dev/investigations/gp-registration/fallback/index.md) for recovery duties, digital-document and paper routes, and reconciliation.

## Terms and scope

Use **change of GP registration and transfer of the GP patient record** for this activity. Registration establishes the new practice relationship. **Deduction** removes the patient from the previous practice's registered list. Administrative registration and the record request can proceed in parallel. Deduction does not prove successful record transfer. [SRC-097](https://dsic-clinical-safety.pages.dev/sources/index.md#src-097)

GP2GP supports record transfer between English GP practices. Where both practices use TPP SystmOne, the shared record store avoids this GP2GP exchange. Other routes still need a safe continuity process. [SRC-098](https://dsic-clinical-safety.pages.dev/sources/index.md#src-098)

Confirm the route separately for temporary registration, cross-border moves, Defence care or a patient with no previous retrievable GP record. Do not assume that the ordinary England practice-to-practice workflow applies.

## Explicit DSIC requirements

**C13 Patient Information Maintenance – GP, v10.0.3, effective 13 October 2026**, contains the following MUST Epics. These are supplier capability criteria. Establish the product's adopted baseline before making a contractual finding. [SRC-019](https://dsic-clinical-safety.pages.dev/sources/index.md#src-019)

| Requirement | Process meaning |
|---|---|
| **E00163 — manage Patient Registrations** | Create, amend, end and view registrations. Record registration type, start date, named accountable GP and, on ending registration, end date. |
| **E00176 — Personal Demographics Service** | Trigger a national demographic trace during registration and support reconciliation of differences. |
| **E00175 — NHAIS HA/GP Links** | Create the registration message and make received registration messages available. |
| **E00177 — transfer Electronic Patient Records between GP Practices** | Registration completion triggers electronic transfer and automatic integration. Authorised staff can view the integrated record. |

These selected criteria are in C13. [SRC-019](https://dsic-clinical-safety.pages.dev/sources/index.md#src-019)

The linked **S43 GP2GP standard, v6.0.2, effective 6 October 2026**, defines route-specific obligations. It includes automatic integration for the existing HL7 route and separate adaptor requirements for new/FHIR solutions. For the existing HL7 route, GP2GP02 and GP2GP03 require documentation and support to help receiving suppliers interpret transferred information. [SRC-026](https://dsic-clinical-safety.pages.dev/sources/index.md#src-026)

## What the practice process must resolve

The following sequence combines published guidance with an original assurance model. It is not a verbatim DSIC checklist.

| Stage | Process outcome to establish | Basis |
|---|---|---|
| Identify and register | Confirm the person, registration type and correct previous practice. Resolve demographic uncertainty. | C13 criteria above. |
| Track administrative completion | Track the new registration and previous-practice deduction separately from receipt of the clinical record. | NHS registration guide. [SRC-097](https://dsic-clinical-safety.pages.dev/sources/index.md#src-097) |
| Establish record availability | Confirm that the receiving team can use the transferred record. Investigate incomplete or failed outcomes. | C13 and the applicable transfer route. |
| Review clinical meaning | Review medication and resolve degrades: information that did not translate cleanly. Integration does not complete clinical review. | NHS auto-integration guidance. [SRC-099](https://dsic-clinical-safety.pages.dev/sources/index.md#src-099) |
| Reconcile outstanding information | Track missing attachments, paper records and failed transfers to a documented outcome. | Applicable Sending Adaptor requirements and scenarios. [SRC-096](https://dsic-clinical-safety.pages.dev/sources/index.md#src-096) |
| Maintain ongoing care | Establish ownership of pending results and other time-sensitive work. Do not infer clinical handover from a transfer status. | BMA results guidance, extended here into original safety-review questions. [SRC-100](https://dsic-clinical-safety.pages.dev/sources/index.md#src-100) |

## Automatic integration and fallback

A failed transaction, a record awaiting integration and a product without the required automatic capability are different situations. A manual workaround may protect care while leaving a capability issue unresolved. The [unavailable automation investigation](https://dsic-clinical-safety.pages.dev/investigations/gp-registration/unavailable-automation/index.md#establish-why-automation-is-unavailable) separates these cases and their evidence requirements.

NHS England reports that automatic-integration rollout completed in **September 2026**. Older pages still describe manual filing. Use those pages for their stated workflow distinctions, not as evidence of the current rollout state. [SRC-098](https://dsic-clinical-safety.pages.dev/sources/index.md#src-098)

The automatic-integration guidance retains manual work to review, curate and use the record. Medication review and degrade workflows remain. [SRC-099](https://dsic-clinical-safety.pages.dev/sources/index.md#src-099)

For the **Sending Adaptor route**, the requirements include these safeguards:

- Distinguish complete, complete-with-issues and failed outcomes.
- Create a failed-transfer task for the full record and attachments. A printed summary alone is insufficient.
- Keep the task open until the required printing is recognised.
- On retry, use the latest record and recheck the patient's receiving practice.

These are selected route-specific requirements, including GP2GP_Send-11 to GP2GP_Send-17. They are not universal clause identifiers for every GP supplier. [SRC-096](https://dsic-clinical-safety.pages.dev/sources/index.md#src-096)

The service describes an **eight-day fallback trigger** when integration has not occurred. It also identifies the National Document Repository as a possible digital fallback after failure. This is not a clinical-review deadline. [SRC-098](https://dsic-clinical-safety.pages.dev/sources/index.md#src-098)

For the Sending Adaptor, absence of acknowledgement within eight days triggers a failure and printing task. Do not assume that the service's NDR option supersedes explicit adopted printing requirements. Resolve the applicable route and baseline. [SRC-096](https://dsic-clinical-safety.pages.dev/sources/index.md#src-096)

## Outstanding clinical work

BMA guidance says the ordering clinician should generally receive and act on test results unless responsibility is appropriately transferred. Another clinician's ability to view a result does not establish that they will act. Receiving an urgent result can also create a responsibility to act. [SRC-100](https://dsic-clinical-safety.pages.dev/sources/index.md#src-100)

For this review, registration status alone does not settle responsibility for urgent information received by either practice.

For this investigation, the proposed review also covers pending referrals, monitoring, medication decisions and information received after the move. Define the owner, action, urgency and escalation for each relevant handover. These are original safety-review prompts, not additional quoted DSIC clauses.

## Whole-practice migration is different

Moving many records when a practice changes clinical software is a separate activity. **S26 Data Migration** addresses the source supplier, target supplier and service recipient, within its Catalogue/contracting-vehicle scope. It requires its own migration planning and acceptance evidence. Do not substitute an individual-patient transfer check for a system-migration assessment. [SRC-007](https://dsic-clinical-safety.pages.dev/sources/index.md#src-007)

Continue to [safety review and evidence](https://dsic-clinical-safety.pages.dev/investigations/gp-registration/safety-review/index.md), or return to [specific activity investigations](https://dsic-clinical-safety.pages.dev/investigations/index.md).