Unavailable automation
Identify the missing automatic step before deciding whether there is a capability gap, an operational failure or an allowed exception. A manual recovery process does not settle that question.
This page concerns GP registration and record transfer in England. It covers a system that never had the required automation, a deployment that cannot use it, and automation that fails for an individual record. It also explains the human work that remains after successful automation.
Use record-transfer fallback for the practical recovery routes when information is missing or unusable. This page explains the underlying automation issue and its consequences. Both pages stand independently within the registration investigation.
Selected sources were inspected on 28 October 2026. Requirement summaries are identified by clause and route. The diagnostic model, operating-model questions and examples are original review synthesis. No actual product, contract or workbook has been assessed.
What is meant to happen automatically
Automation here means that the software performs specified steps after an authorised registration action. It does not mean that the whole registration and clinical-review process proceeds without people.
| Step | Expected division of work |
|---|---|
| Identify the patient and complete registration | Staff select the patient and complete the registration. |
| Request and transfer the electronic health record | The registration action initiates the electronic exchange. |
| Integrate the received record | The receiving system incorporates it without requiring a routine manual filing action. |
| Create subsequent review work | The system creates the expected medication and degrade tasks for staff to resolve. A degrade is information that did not translate cleanly. |
| Review and use the record | Staff review, curate and act on the information. Automation does not complete those clinical decisions. |
This division follows NHS automatic-integration guidance. Its historical rollout language is qualified below. 099
Received, integrated, available to the clinician, reviewed and outstanding work completed describe different outcomes. An inbox item proves neither integration nor clinical review. A document visible in a separate repository does not establish that its content populates the clinical system.
Establish why automation is unavailable
The following is a diagnostic framework, not a list of automatic compliance findings.
| Situation | What it means | Evidence that distinguishes it |
|---|---|---|
| Capability absent | The product does not implement the required automatic step. Manual handling is its normal design. | Supplier capability declaration, adopted requirements, supported version and a demonstration of the actual workflow. |
| Capability disabled or misconfigured | The function exists but is not active in this deployment. | Configuration, change approval, reason, affected users and expected restoration or enabling decision. Do not assume who disabled it. |
| Deployment dependency unavailable | Connectivity, onboarding, endpoint identity or another required service prevents operation. | Dependency and access records, supplier diagnosis and scope of the affected practice or counterpart. |
| Temporary service incident | An otherwise functioning route is interrupted. | Last known successful operation, incident times, affected patients and supplier recovery evidence. |
| Record-specific failure | One record cannot progress, although other transfers work. | That patient's transfer states, validation or integration error, attachments and retry outcome. |
| Automation completed; human work pending | Integration succeeded, but clinical review or summarisation remains. | Integrated record and review-task evidence. This is not itself missing automation. |
| Permitted exception or different route | The ordinary transfer is inapplicable or must stop under a defined condition. | The precise exception, patient/registration circumstances and alternative process. |
Several conditions can coexist. For example, a deployment problem may cause a backlog that remains after connectivity returns. Record the cause, patient impact and unfinished work separately.
NHS England reports completion of the automatic-integration rollout in September 2026. That national statement does not prove a particular installation works. The service also identifies the shared SystmOne record store as a different route between practices using that system. Absence of a GP2GP message there is not, by itself, a defect. 098
Which DSIC requirement applies
Start with the product's declared capabilities, contract, adopted versions, implementation route and any documented assurance conditions.
C13 E00177 requires electronic transfer and automatic integration following registration completion, and display of the transferred, integrated record. Its implementation details require compliance with S43. Other C13 Epics separately govern registration, national registration messages and demographic matching. A manual transfer does not demonstrate the automatic-integration criterion. 019
S43 distinguishes routes. GP2GP04 applies to existing deployed HL7 implementations and incorporates the Automatic Integration Specification v1.0. GP2GP07/08 apply to the new/FHIR route through the Sending and Requesting Adaptors. Do not apply every identifier from both routes as one universal checklist. 026
Where an automatic function is demonstrably absent and an applicable requirement demands it, there is evidence for a requirement nonconformance. If applicability or actual behaviour remains unknown, keep the finding conditional. A deploying organisation's acceptance of clinical risk does not establish supplier conformance or waive an applicable requirement.
What the detailed integration rules add
For the existing HL7 route, the inspected specification requires system-triggered integration, full integration, continued system use and protection of concurrent updates. Failures require reporting and later retry. Optional downstream workflow configuration does not make integration itself optional. It also provides wrong-patient correction requirements; a user rejection option is not a substitute. AI5.1 preserves manual integration for records received before automation implementation. That legacy backlog differs from a current capability gap. 107
For the adaptor route, selected S94 requirements cover automatic integration, concurrent-use protection, acknowledgement and failure handling. Attachment placeholders can remain after unsuccessful retrieval. Consequently, an integrated record can still have unresolved attachments. Check the exception list as well as the integration status. 101
Conditions and exceptions that affect automation
The ordinary route is conditional. Selected S94 requirements distinguish these cases:
| Requirement | Process consequence |
|---|---|
| Req01–02 | Ordinary GP2GP eligibility is permanent registration; reassess when temporary/private registration becomes permanent. |
| Req07 | Staff must select the PDS result, even if only one match exists. |
| Req04–05 | PDS outage: helpdesk prompting is SHOULD; exceptional critical electronic recording is MUST. |
| Req09 | Sensitive PDS records use the separate National Back Office/PCSE manual route. |
| Req20 | A failed PDS update ends this transfer process. |
| Req25 | Failed endpoint lookup or no application identifier: report failure and contact the sender; no request was made. |
| Req17 | Missing practice contact details alone must not stop transfer. |
These are selected adaptor rules. They do not provide a blanket exemption from supplying an applicable capability. 101
For a closed-network or Defence deployment, establish the actual service entitlement and connection path. The absence of connectivity can explain why an exchange cannot run. It does not establish which contractual duties apply, or whether the product meets them. Document both decisions.
Keep the process clocks separate
| Clock | Source and meaning | Review boundary |
|---|---|---|
| Immediate integration; 20-minute measure from EHR receipt | HL7 AI1.1 and adaptor Req64. 107, 101 | This is not a promise of a complete clinically reviewed record within 20 minutes of registration. |
| Later retry after integration cannot start or complete | HL7 AI1.7. 107 | The inspected clause does not specify a numerical retry deadline. |
| 72-hour integration-failure recovery window | Adaptor Req70–72 use SHOULD for support/alert/reintegration actions; Req73–74 use MUST for unresolved-failure acknowledgement and status. 101 | Do not apply this adaptor rule to every HL7 implementation or call it 72 hours after registration. |
| Eight days without acknowledgement | The selected Sending Adaptor route triggers failure and printing tasks. 096 | This is a transfer-recovery rule, not permission to delay urgent clinical information. |
S94 does not precisely define the starting timestamp for its 72-hour window in the inspected wording. Its attachment-retrieval allowance and receipt-based integration measure also need a controlled interpretation for affected cases. Obtain the supplier's assured definitions and event timestamps. Do not invent a clock reset or silently combine these measures.
None of these clocks establishes a safe waiting period for an individual patient. Clinical urgency needs its own assessment and escalation.
What changes when manual handling becomes the normal process
If no automation is available and no restoration is planned, the practice has a continuing manual workload. Calling it fallback does not make it temporary. Its staffing, queue management and clinical dependencies need an explicit operating model.
NHS role guidance describes administrative task monitoring, summariser work, clinician review of medicines and allergies, and cover for absences. Its 2022 manual-filing instruction is historical. Use current supplier instructions for the installed system. 106
The following are proposed operating-model questions, rather than additional national clauses:
| Process area | What the deployment should make explicit |
|---|---|
| Intake and ownership | Who identifies every new patient needing records, requests the information, monitors ageing and provides cover? |
| Capacity | Can trained staff sustain the expected arrivals, complex records and absences without an unobserved backlog? |
| Interim care | How do treating staff find available information and see what is missing, uncertain or awaiting review? |
| Record preparation | Who checks identity, provenance, dates, content and attachments, then summarises or transcribes into the clinical system? |
| Clinical meaning | Who checks medicines, allergies and clinically important degrades, and decides which information needs structured entry? |
| Outstanding work | Who accepts pending results, referrals, monitoring and other time-sensitive tasks? Receipt of a record does not allocate these automatically. |
| Later changes | How are late documents, interim consultations and subsequent amendments reconciled without losing or duplicating information? |
| Another practice move | How is unfinished work and the available record handed onward if the patient moves again before processing finishes? |
The NHS automation guidance identifies broken continuity in an A-to-B-to-C move, and records unavailable to treating staff while awaiting integration, as risks of manual integration. These risks should be tested in the local workflow. 099
A written procedure alone does not demonstrate that this model works at the required volume or during staff absence. Seek representative completed cases and backlog evidence. A workable manual model still does not prove that a required automatic capability exists.
What clinicians can actually use
Distinguish readable information from information used by the receiving system's clinical functions. The following are original safety-review questions:
- Are allergies and medication visible only in a document, or also in the fields used by prescribing and alerts?
- Does the system generate the expected review tasks, and can staff identify records needing attention?
- Can missing attachments, coding differences and unresolved degrades be seen without opening every document?
- Are the source, date and limits of interim information clear to the treating clinician?
- Can authorised staff use the record while reconciliation continues, with appropriate safeguards?
Require current supplier evidence for prescribing restrictions, alerts, medication authorisation and degrade handling. Their behaviour cannot be inferred from an old guide or the fact that a PDF opens successfully. NDR storage is separate from clinical-system integration; its receiving guidance requires local download and summarisation. 104
Responsibilities and continuing requirements
The allocation below is a proposed review map. Confirm the actual service agreements and local responsibilities.
| Party or function | Decision and evidence needed |
|---|---|
| Supplier / manufacturer | State the supported function and limitations; diagnose product behaviour; provide configuration, failure/retry instructions, test evidence and updated DCB0129 safety information. |
| Deploying organisation | Verify local dependencies and configuration; assess the real manual workload and patient risks under DCB0160; implement and test local controls. |
| Practice operational and clinical leads | Assign queues, deputies and clinical reviews; manage affected patients and unresolved information; retain evidence of completion. |
| Buyer / commissioner / assurance authority | Establish the adopted baseline, service entitlement and any permitted variation. Distinguish an exception decision from an unsupported local assumption. |
S25 requires supplier safety documentation that enables the deployment assessment. 004 S24 continuity and reconciliation duties, S65 incident/service obligations, S28 training and S30 information governance remain relevant within their applicable scope. 008, 010, 012, 005
A long-term manual design is not automatically a disaster-recovery event. Equally, a supplier release or local risk decision does not close every affected patient case. The fallback page maps the selected continuing clauses.
Evidence for a decision or a return to automation
Record the missing step, affected population, start date, cause, owner and whether the position is temporary or continuing. Separate an unverified explanation from a confirmed cause.
For an automation issue, request the adopted requirement, product/version, configuration, incident history, representative event trace and supplier explanation. For the manual process, request the operating procedure, staffing/cover, queue records, clinical controls and completed examples. Use these as evidence requests; do not assume the artefacts exist.
Before declaring normal operation restored, the proposed review should establish that:
- New eligible registrations follow the required automatic path without an unnoticed manual filing dependency.
- Authorised clinicians can use the resulting record, and expected review tasks reach responsible staff.
- Failures, retries, concurrent updates and missing attachments follow the applicable supplier rules.
- Interim entries and later information are reconciled for previously affected patients.
- Each old case has completion or a documented outstanding exception, separate from the new service status.
- An onward move preserves the necessary record and unresolved work.
These are proposed acceptance questions, not a replacement for formal supplier assurance. If automation will remain unavailable, record the decision, continuing limits and ownership instead of claiming restoration.
Examples and finding classification
All examples below are hypothetical. They are not observations about any product or practice.
| Evidence | Appropriate interpretation |
|---|---|
| Current eligible transfers always require manual filing; the adopted baseline requires automatic integration | Evidence for REQUIREMENT-NONCONFORMANCE against the identified function. Investigate whether the limitation is product or deployment specific. |
| A record received before automation implementation requires manual integration | A permitted legacy workflow under the inspected HL7 specification, subject to its scope. It is not evidence that current eligible transfers lack automation. |
| A PDS outage invokes the documented exceptional recording process | Assess execution of that exception and subsequent recovery. Do not infer blanket product nonconformance. |
| Integration succeeds and a clinician still needs to review medication | Expected clinical work. Establish its completion separately. |
| No tests, configuration or queue evidence was supplied | EVIDENCE-GAP, not proof of failed automation. |
| Contract, route or exception applicability is uncertain | APPLICABILITY-UNRESOLVED. Obtain the missing baseline. |
| A numerical deadline depends on an unclear clock definition or uninspected schedule | SOURCE-DETAIL-REQUIRED before a definitive timing finding. |
A useful Hazard Log entry distinguishes the failure, resulting information gap, possible harm, control, responsible party and verification evidence. Do not invent a risk rating or acceptance decision. Use safety review and evidence for that assessment structure and record-transfer fallback for recovery.
This page is a wiki supplement. It is not yet included in the unchanged version 1.1 offline reference. The actual workbook remains in the approved closed-network environment.