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


# Record-transfer fallback

**Fallback is the alternative process used to recover missing or unusable patient information and maintain care when the normal record-transfer route cannot complete.**

This page covers recovery: identifying missing information, selecting an authorised route, making the record usable and reconciling later arrivals. For a function that is absent, disabled or unable to operate, read the separate [unavailable automation](https://dsic-clinical-safety.pages.dev/investigations/gp-registration/unavailable-automation/index.md) investigation.

Read [process and requirements](https://dsic-clinical-safety.pages.dev/investigations/gp-registration/process/index.md) for the overall patient journey and [safety review and evidence](https://dsic-clinical-safety.pages.dev/investigations/gp-registration/safety-review/index.md) for assessment questions. Selected sources were checked on **28 October 2026**. The local workflow below is original review synthesis. No product, contract or actual workbook has been assessed.

<span id="identify-what-is-unavailable"></span>

## When record transfer needs recovery

| Position | Recovery need |
|---|---|
| No usable record arrived | Establish which patient and source practice are involved, what was requested and what is still needed. |
| Some information or attachments are missing | Recover the missing components and keep their status separate from the received record. |
| The record arrived but cannot be integrated or used | Follow the supported recovery process and provide approved interim access for care. |
| A defined exception requires another route | Follow that route's identity, access, transfer and completion rules. |
| Automation will remain unavailable | Establish a continuing manual operating model as well as the recovery action for each patient. See [unavailable automation](https://dsic-clinical-safety.pages.dev/investigations/gp-registration/unavailable-automation/index.md#what-changes-when-manual-handling-becomes-the-normal-process). |

This table is a proposed recovery classification. It does not establish why the normal route failed or whether an applicable requirement was breached. A recovered patient record and a resolved supplier defect are separate outcomes.

<span id="explicit-exceptions-and-recovery-duties"></span>

## Recovery duties

For the Sending Adaptor route, S95 **GP2GP_Send-11–18** governs failure status, full-record recovery tasks, retry and destination checks. Its eight-day no-acknowledgement rule triggers failure handling. The [process page](https://dsic-clinical-safety.pages.dev/investigations/gp-registration/process/index.md#automatic-integration-and-fallback) summarises the selected obligations. [SRC-096](https://dsic-clinical-safety.pages.dev/sources/index.md#src-096)

The eight-day rule is not a safe waiting period for urgent clinical information or a universal incident-resolution target. Other integration clocks and explicit requesting-adaptor exceptions are explained on the [unavailable automation page](https://dsic-clinical-safety.pages.dev/investigations/gp-registration/unavailable-automation/index.md#keep-the-process-clocks-separate).

## Requirements that remain relevant or become triggered

Fallback usually activates existing recovery obligations and changes the evidence needed. It does not replace the entire DSIC baseline with a separate manual standard.

| Area | Verified requirement anchor | What the fallback review should establish |
|---|---|---|
| **Registration and identity** | C13 E00163, E00175 and E00176 remain separate from record transfer. [SRC-019](https://dsic-clinical-safety.pages.dev/sources/index.md#src-019) | Registration status, demographic matching and national messages remain controlled. Use the applicable exception when a dependency is unavailable. |
| **Business continuity** | S24 **BC-DR-1** requires continuity arrangements; **BC-DR-16** and **BC-DR-16A** require annual continuity and disaster-recovery testing; **BC-DR-20** addresses recovery/update of data collected, or which should have been collected, during disruption. [SRC-008](https://dsic-clinical-safety.pages.dev/sources/index.md#src-008) | The applicable plan covers interim work, recovery objectives and reconciliation after restoration. Use its activation criteria; not every individual transfer failure is a disaster. |
| **Incident and service management** | S65 **SM005** links incident and change obligations; **SM006** requires performance measurement against applicable service levels. [SRC-010](https://dsic-clinical-safety.pages.dev/sources/index.md#src-010) | Record impact, cause, escalation, ownership and corrective work. Establish the actual SLA before alleging a missed deadline. |
| **Clinical safety** | S25 **GP-08.4.3.01** requires DCB0129 work and documentation enabling DCB0160 assessment. [SRC-004](https://dsic-clinical-safety.pages.dev/sources/index.md#src-004) | Supplier and deployer assess risks introduced by missing records, delay, manual entry, duplicate work and restoration. Local risk acceptance does not establish supplier capability conformance. |
| **Information governance** | S30 **GP-IG-3-2** covers role-based access; **GP-IG-18-6** covers encryption for relevant supplier-provided transfers; **GP-IG-14.3-4** covers auditable physical data movement. [SRC-005](https://dsic-clinical-safety.pages.dev/sources/index.md#src-005) | The alternative route preserves authorised access, secure transfer, provenance and tracking. Fallback is not permission to use an unapproved sharing channel. |
| **Training** | S28 **TR-3.1** requires a training plan; **TR-6.1** requires relevant, controlled materials; **TR-12.4** addresses further support when evaluation identifies problems. [SRC-012](https://dsic-clinical-safety.pages.dev/sources/index.md#src-012) | Staff can perform the additional recovery and reconciliation actions. These clauses do not prescribe a specifically named GP2GP fallback course. |

The right-hand column is original review synthesis. Apply each clause's contracting vehicle, solution type and other conditions. Detailed linked SLAs and all underlying implementation specifications were not audited here. A numeric response, recovery or data-loss limit must come from the applicable controlled source.

S26 Data Migration does not become applicable merely because an individual patient's record uses manual fallback. Reassess S26 separately if the activity is a whole-practice system migration. [SRC-007](https://dsic-clinical-safety.pages.dev/sources/index.md#src-007)

## Digital documents and paper are distinct fallback routes

### National Document Repository

The NHS National Document Repository (NDR) identifies GP2GP failure as a supported use case. Confirm that both practices can use the service. Do not assume that a closed network, a cross-border destination or a Defence deployment has access. The service describes MoD/MoJ participation as a pilot and paperless cross-border transfer as future development. Its published bronze service window is 08:00–18:00 on weekdays, excluding bank holidays. Account for that window when planning urgent or out-of-hours recovery. [SRC-102](https://dsic-clinical-safety.pages.dev/sources/index.md#src-102)

In the upload guidance, **full EHR summary** means the full notes or journal, not a brief clinical synopsis. Attachments need separate export, including documents held in external document systems. Partial-transfer recovery can involve only the missing attachments. Track upload failures and retry them. [SRC-103](https://dsic-clinical-safety.pages.dev/sources/index.md#src-103)

The receiving practice checks patient details before accepting or rejecting documents. EHR attachments cannot be viewed within NDR; staff must download them for these checks before acceptance. The NDR guidance explicitly states that the service is not linked to clinical systems. Accepted documents must be downloaded and summarised into the clinical system through the usual new-patient process. The stored EHR is a snapshot and may be out of date. [SRC-104](https://dsic-clinical-safety.pages.dev/sources/index.md#src-104)

Therefore, **uploaded**, **accepted for storage**, **available to the clinician** and **clinically reconciled** need separate evidence. A document attachment does not prove that its allergies, medicines or pending tasks affect the receiving system's clinical functions. Test the relevant local behaviour.

### PCSE movement and urgent information

PCSE provides tracked paper-record movement and enquiries about missing records. A “No Paper Record” status means GP2GP is expected; it does not prove that the transfer succeeded. Its published cross-border route from England to the other UK nations requires a full electronic-record printout through PCSE. [SRC-105](https://dsic-clinical-safety.pages.dev/sources/index.md#src-105)

PCSE also describes a qualifying urgent/safeguarding information-request route for registered contacts. It arranges a full summary and attachments through its specified NHS.net email process. This does not necessarily accelerate the physical record movement. Follow the actual PCSE instructions and eligibility criteria. [SRC-105](https://dsic-clinical-safety.pages.dev/sources/index.md#src-105)

### Resolve the route before claiming completion

Current NHS NDR guidance supports a digital fallback, while the selected S95 clauses and PCSE guidance still describe printing. The inspected sources do not establish a universal supersession rule. Record the supplier route, adopted specification and relevant service/commissioner instructions. Do not declare either “paper always unnecessary” or “NDR alone fulfils every transfer duty”. [SRC-096](https://dsic-clinical-safety.pages.dev/sources/index.md#src-096) [SRC-103](https://dsic-clinical-safety.pages.dev/sources/index.md#src-103) [SRC-105](https://dsic-clinical-safety.pages.dev/sources/index.md#src-105)

## A practical local recovery workflow

This is a proposed workflow for local clinical-safety review, not an additional national specification.

1. **Identify the affected patients and information.** Separate total failure, missing attachments and failed integration. Name an owner for each unresolved case.
2. **Assess clinical urgency.** Identify medication, allergy, pending-result and other time-sensitive needs. Obtain approved interim information without waiting for an administrative timer.
3. **Record the incident and choose the applicable route.** Document supplier advice, access constraints, escalation and the reason for the chosen fallback.
4. **Assemble and check the package.** Verify patient identity, date, source, expected content, attachments and acknowledged omissions. Preserve a transfer trail.
5. **Make information usable.** The receiving team checks and summarises the material according to local policy. Assign clinical review and outstanding actions explicitly.
6. **Reconcile after restoration.** Compare the eventual electronic record with interim entries and actions. Resolve duplicates, differences, later additions and unresolved tasks.
7. **Close each outcome separately.** Record evidence for successful recovery, clinical task completion and any remaining supplier defect. Preserve the escalation or acceptance decision for unresolved risks.

## What would support a finding

| Evidence available | Appropriate conclusion |
|---|---|
| A failed transfer followed the applicable fallback process, with recovery evidenced | A managed exception. Assess any separate service or functional breach; do not infer blanket noncompliance. |
| An applicable automatic capability is demonstrably absent | A potential **REQUIREMENT-NONCONFORMANCE** against the identified criterion. A manual risk control is a separate safety measure. |
| An applicable required recovery task was demonstrably omitted | A potential **REQUIREMENT-NONCONFORMANCE** against that recovery obligation, with the contradictory evidence. |
| No procedure, training, test or completion evidence was supplied | **EVIDENCE-GAP**. The absence of supplied evidence does not prove the activity was not performed. |
| Route, contract, permitted exception or adopted version is unknown | **APPLICABILITY-UNRESOLVED**; request the missing baseline. |
| The required detail is in an uninspected attachment or service-level schedule | **SOURCE-DETAIL-REQUIRED**; obtain the controlled material before a definitive clause-level finding. |

Use the [safety review](https://dsic-clinical-safety.pages.dev/investigations/gp-registration/safety-review/index.md) to record the hazard, owner, control and evidence separately. The actual workbook stays in its approved environment. This investigation remains a wiki supplement to the unchanged [version 1.1 offline reference](https://dsic-clinical-safety.pages.dev/offline-reference/index.md).
