Not for emergencies. If someone is seriously unwell or in immediate danger, call 999. For urgent medical help use NHS 111 or your local urgent-care route.
Display: Accessibility statement

Healing Process policy suite

Business Continuity, Disaster Recovery and Downtime Policy

StatusWorking draft
Version1.0-draft
OwnerTechnical Service Owner
Review date23 July 2027 or earlier
Approval status: this is a substantive governance draft for review. It is not evidence that a production control has been implemented, audited or approved. Each live NHS or care deployment must align it with the provider’s policies, law, contract and configured service.

1. Purpose

To maintain safe and proportionate continuity when Healing Process or a dependency is degraded, unavailable or recovering, and to prevent users from relying on the product as the sole route for urgent care.

2. Scope and status

This policy covers website, app, portal, image processing, messaging, identity, integrations, hosting, support, suppliers, cyber incidents, data restoration and provider continuity arrangements.

Core supplier and product policy

3. Policy principles

  • Continuity planning addresses clinical and operational consequences, not only technical uptime.
  • The live service must display alternative contact and urgent routes before an outage occurs.
  • Recovery objectives are based on risk, service hours and provider pathway, and must be tested rather than assumed.
  • Queued or offline information is not treated as received by a care team until confirmed by the service.

4. Mandatory requirements

  • Complete business-impact analysis for critical functions and dependencies and approve recovery-time and recovery-point objectives.
  • Maintain resilient architecture, capacity thresholds, monitoring, backup, tested restoration and documented manual workarounds.
  • Define outage severity, command roles, provider and user notification, status-page content, escalation and decision authority.
  • Make message and image states explicit: draft, queued on device, upload failed, received, in review and actioned.
  • Provide providers with downtime instructions covering enrolment, urgent contact, review queue, documentation, later reconciliation and unresolved actions.
  • Test loss of hosting, identity, network, database, storage, image processing, notification, integration and key supplier services.
  • Prevent automated retries from creating duplicate records or misleading timestamps and preserve provenance when delayed data arrives.
  • Maintain secure backups and recovery keys separated from the primary environment and protect them from ransomware or unauthorised access.
  • Plan orderly service exit or supplier failure, including data export, read-only access where appropriate and communication.

5. Procedure and escalation

  • Monitoring alerts the on-call owner, who classifies impact and activates the incident/continuity plan.
  • For a clinically material outage, the provider is informed through the contractual route and public/service messaging directs users to alternatives without making unverified restoration promises.
  • Recovery includes integrity checks, queue reconciliation, duplicate prevention, review of delayed concerns and explicit confirmation before ordinary service resumes.
  • After each exercise or event, actions are documented, prioritised and tested to closure.

6. Roles and responsibilities

Technical Service Owner

owns resilience, monitoring and recovery execution.

Clinical Safety Officer

assesses clinical impact, workaround and restart safety.

Communications/Support

provides accurate, accessible status and alternatives.

Providers

maintain local continuity, staffing and patient contact routes.

Suppliers

meet contractual continuity and incident obligations.

7. Records, confidentiality and retention

Keep business-impact assessments, continuity and recovery plans, dependency maps, backups, restore tests, exercises, incidents, communications, reconciliation and lessons.

Records created under this policy must be accurate, attributable, access-controlled and linked to the applicable retention schedule. Where a provider is the controller or authoritative record holder, its documented instructions and legal duties apply.

8. Monitoring, assurance and review

Review at least annually and after major architecture, dependency or pathway change. Exercise critical scenarios on a risk-based schedule and monitor availability, recovery, backup success, queue age and continuity-action closure.

Material non-compliance is reported through the relevant clinical-safety, patient-safety, data, security, safeguarding, HR, contractual or whistleblowing route. Corrective actions receive an owner, target date and effectiveness check.

9. Training and communication

The policy owner identifies which roles require awareness, operational or specialist training. Training is accessible, version-controlled, role-specific and refreshed after material change or evidence that understanding is inadequate. Providers communicate local procedures and contact routes before users are granted access.

10. Related documents

11. Approval record

RoleNameDecision/date
Policy ownerTo be completedDraft pending approval
Clinical/technical specialistTo be completedDraft pending approval
Board or delegated committeeTo be completedDraft pending approval
Return to policy centre