Healing Process policy suite

Clinical Safety and Risk Management Policy

1. Purpose

To apply a documented clinical risk-management system to the design, development, deployment, change and operation of Healing Process so that foreseeable hazards are identified, controlled, monitored and communicated.

2. Scope and status

This policy applies to the supplier product lifecycle and to cooperation with each deploying organisation. Supplier and provider clinical-safety duties are complementary: the supplier addresses risks created or contributed to by the product; the provider addresses risks arising from local configuration, integration, staffing and use.

Core supplier and product policy

3. Policy principles

• Patient safety takes priority over schedule, marketing or commercial pressure.
• Clinical safety is continuous. It begins before requirements are fixed and continues through decommissioning, incidents and post-market learning.
• The safety case must reflect the actual intended purpose, version, environment and workflow; a generic document cannot approve every deployment.
• Controls should follow a hierarchy: eliminate or reduce risk by design, add protective measures, then provide clear information and training for remaining risk.

4. Mandatory requirements

• Appoint a suitably qualified Clinical Safety Officer with authority, competence, time and access to decision makers.
• Maintain a clinical risk-management plan, hazard log, clinical safety case and release/deployment safety documentation appropriate to the applicable standards and contract.
• Analyse hazards including wrong person or wound, poor image quality, misleading alignment, false reassurance, alert overload, missed review, failed message, unsafe automation, out-of-hours use, integration error, unauthorised access and downtime.
• Trace each safety-critical requirement to design, verification, validation, user information and residual-risk acceptance.
• Define severity and likelihood consistently, record rationale and ensure risk acceptance is made by an authorised person rather than inferred from silence.
• Control safety-related content, thresholds, algorithms, prompts, workflows and configuration as versioned product items.
• Require provider-specific deployment hazard review covering workforce, operating hours, inclusion criteria, escalation, clinical record, alternative route and business continuity.
• Monitor incidents, near misses, complaints, model performance, backlog, failed contact and other safety signals and feed learning into corrective action.

5. Procedure and escalation

• No production release proceeds until required safety evidence and unresolved hazards have been reviewed and approved under the release process.
• A proposed change receives clinical impact assessment. High-impact changes trigger renewed hazard analysis, verification, provider notification and deployment review.
• A safety incident is triaged immediately; affected functionality may be disabled, advice issued or service paused while investigation proceeds.
• Before decommissioning, the supplier and provider agree continuity, data export, record preservation, user communication and removal of unsafe dependencies.

6. Roles and responsibilities

Clinical Safety Officer

owns the supplier safety system, hazard log and clinical safety case and advises release decisions.

Board/Product owner

provides resources, accepts business-level residual risk and prevents unsafe release pressure.

Engineering/QA

implements safety requirements and produces objective verification evidence.

Provider CSO and service owner

own local deployment safety, staffing and clinical workflow controls.

All workers

report actual or potential safety issues promptly.

7. Records, confidentiality and retention

Retain safety plans, hazard logs, safety cases, reviews, risk decisions, traceability, verification, training, incidents, corrective actions, release evidence and provider communications under controlled versioning.

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 continuously through safety surveillance and formally at least annually, on each major release and after significant incident or deployment change. Report open hazards, overdue controls, incidents, backlog and safety-performance trends to governance.

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

• AI Image Alignment and Human Oversight Policy
• Medical Device and Intended Purpose Policy
• Patient Safety Incident Policy
• Business Continuity Policy

11. Approval record