DRAFT FOR REVIEW BY APPOINTED CLINICAL SAFETY OFFICER — MUST BE REVIEWED, AMENDED AND SIGNED BY A GMC/NMC/HCPC-REGISTERED CLINICIAN WITH FORMAL DCB0129 CLINICAL SAFETY OFFICER TRAINING BEFORE USE.
CSO01 — BritiAI Clinical Safety Management System (CSMS)
Document reference: BRITI-CSMS-001 Version: 0.9 (Draft for CSO review) Manufacturer: BritiAI Limited Applicable standard: DCB0129:2018 — Clinical Risk Management: its Application in the Manufacture of Health IT Systems Related standard (deploying organisations): DCB0160:2018 — Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems Status: Draft pending CSO sign-off
1. Purpose and Scope
This Clinical Safety Management System (CSMS) defines how BritiAI Limited (“BritiAI”, “the Manufacturer”) discharges its responsibilities under DCB0129:2018 as the manufacturer of Health IT systems intended for deployment within NHS organisations under the NHS Shared Business Services Healthcare AI Solutions Open Framework (SBS10523).
The CSMS applies to all five solutions submitted under Lots 5, 6 and 7 of the framework:
- Scribe-On-Site — on-premises ambient clinical documentation.
- WardFlow Copilot — agentic discharge orchestration support.
- Atlas for Trusts — retrieval and reasoning layer over institutional knowledge.
- MAGIC-NHS — sovereign clinical LLM fine-tuning pipeline.
- Trial Concierge — clinical trial recruitment and protocol Q&A support.
All five solutions are deliberately scoped outside the definition of a medical device under the UK MDR 2002 (as amended) and MHRA guidance on software as a medical device. None of the solutions provide autonomous diagnosis, treatment recommendation or direct clinical decision-making. Each requires a registered healthcare professional to interpret, validate and act upon any output before it influences patient care. This scoping decision has been documented in the BritiAI Regulatory Determination Record (BRITI-REG-001) and is subject to ongoing review.
This CSMS does not replace the deploying organisation’s DCB0160 obligations. Section 11 describes the boundary and how BritiAI supports trusts in discharging their own assurance role.
Mandatory Pass/Fail standards (all lots). Per Section 3 “Project Required Standards” of the framework, the clinical-safety and interoperability standards — including DCB0129, DTAC, SNOMED CT, CE Marking, and the NHS AI Assurance Classification Framework — are mandatory Pass/Fail across all lots, including Lots 5, 6 and 7 under which these solutions are submitted. Answering “No” to any of these questions renders the bid non-compliant. (Lot 7-only bidders may select the “Solution is not classed as a medical device” option for the CE Marking question; BritiAI’s medical-device scoping is set out above and in BRITI-REG-001.) This clinical-safety pack — the DCB0129 CSMS, the per-solution Clinical Safety Case Reports (CSO02–CSO06), and the Hazard Log (CSO07) — is therefore an essential compliance deliverable, not a supporting nicety: it directly evidences the DCB0129 Pass and underpins the DTAC and AI Assurance Classification responses.
2. Governance and Roles
2.1 Executive accountability
The BritiAI Chief Executive Officer holds ultimate accountability for clinical safety. The CEO ensures the CSMS is adequately resourced, that the Clinical Safety Officer (CSO) has unimpeded authority to halt a release on safety grounds, and that clinical safety is a standing agenda item at the BritiAI Board.
2.2 The Clinical Safety Officer (CSO)
BritiAI appoints a contracted, suitably qualified Clinical Safety Officer in accordance with DCB0129 §4.2. The CSO is a clinician registered with the GMC, NMC or HCPC, who holds current registration and revalidation, has completed formal Clinical Safety Officer training (NHS Digital / NHS England recognised), and has demonstrable post-qualification experience in NHS settings.
The CSO’s responsibilities include:
- Approval of the Clinical Risk Management Plan (CRMP) for each solution.
- Chairing or co-chairing hazard identification workshops.
- Approving the Hazard Log and Clinical Safety Case Report (CSCR) for each release.
- Authorising release to deployment (release sign-off).
- Acting as the primary clinical safety contact for deploying trust CSOs.
- Reviewing post-deployment safety incidents and triggering re-assessment.
The CSO has authority to veto release of any solution, version, or configuration on clinical safety grounds. This veto is recorded and may only be overridden by a formal documented decision of the BritiAI Board with an accompanying mitigated risk acceptance — a route reserved for exceptional circumstances and never used to override an unresolved hazard with residual risk above the acceptable threshold (see §5).
2.3 Clinical Safety Group (CSG)
The CSG meets at least monthly and on demand for incident review. Standing members:
- Clinical Safety Officer (chair).
- Head of Product (or delegate per solution).
- Head of Engineering (or technical lead per solution).
- Quality and Information Governance Lead.
- Subcontractor clinical leads (Votee AI for V-Note; Beever AI for Atlas) by standing invitation.
- Representation from at least one deploying trust CSO where practicable.
2.4 Subcontractor clinical safety obligations
Named subcontractors Votee AI (V-Note ambient capture, MAGIC training pipeline) and Beever AI (Beever Atlas neural memory) are bound by clinical safety flow-down clauses in their subcontract agreements. They are required to:
- Operate a documented internal clinical risk management process compatible with DCB0129.
- Notify BritiAI of any safety-relevant defect, near-miss or behaviour change within agreed timeframes (see §9).
- Participate in joint hazard workshops and CSG incident reviews as requested.
3. CSO Appointment and Continuity
The CSO is appointed via a written contract specifying scope, time commitment, indemnity, professional indemnity insurance, and conflict of interest declarations. Continuity is maintained by:
- A named deputy CSO with equivalent qualifications, briefed on all active hazard logs.
- A documented handover protocol triggered by absence or change.
- Retention of all signed safety artefacts in the BritiAI Quality Management System under formal document control (§13).
4. Hazard Identification Methodology
BritiAI applies a structured, multi-method hazard identification approach for each solution and for each material change:
- Functional decomposition. The solution is decomposed into clinical workflow steps and information flows. Each step is examined for failure modes (omission, commission, timing, sequence, value, intent).
- HAZOP-style guideword analysis. Applied to each information flow using guidewords adapted for AI-mediated systems: missing, incorrect, fabricated, stale, biased, ambiguous, delayed, mis-attributed.
- AI-specific hazard catalogue. A standing internal catalogue of known LLM and agentic-system hazards (hallucination, prompt injection, distributional drift, retrieval staleness, tool-call misuse, anchoring bias in human-in-the-loop review, automation complacency).
- Clinical scenario walkthroughs. Co-facilitated with the CSO and, where available, deploying trust clinicians; uses realistic clinical vignettes to surface latent hazards.
- Post-deployment learning. Incidents, near-misses and user feedback feed back into the hazard catalogue (§9).
Every identified hazard is captured in the Hazard Log (CSO07) with traceability from hazard → hazardous situation → harm → controls → residual risk.
5. Risk Evaluation Criteria
BritiAI uses a 5×5 risk matrix consistent with DCB0129 Annex A guidance.
Severity:
| Level | Definition |
|---|---|
| Catastrophic | Death or permanent severe disability of one or more patients. |
| Major | Permanent lesser disability or life-threatening event requiring intervention. |
| Considerable | Reversible but significant harm requiring additional clinical management. |
| Minor | Short-term harm not requiring escalation; recoverable. |
| Negligible | No clinically meaningful harm; inconvenience only. |
Likelihood:
| Level | Definition (over deployed user-population time) |
|---|---|
| Very High | Certain or near-certain to occur frequently. |
| High | Will probably occur in most deployments. |
| Medium | Occasional occurrence expected. |
| Low | Possible but not expected in normal operation. |
| Very Low | Rare; would require unusual concurrent failures. |
Risk acceptability:
- Unacceptable (red): release blocked until controls reduce residual risk.
- ALARP (amber): release only with explicit CSO sign-off and documented justification that risk is As Low As Reasonably Practicable.
- Acceptable (green): release permitted under standard process.
No hazard with residual severity Catastrophic is permitted to remain in the High or Very High likelihood bands; such hazards must be re-engineered, not merely accepted.
6. Risk Control Hierarchy
Controls are applied in the following order of preference, per DCB0129 §5:
- Eliminate the hazard by design. Example: restricting Atlas for Trusts to read-only retrieval over institutional knowledge prevents an entire class of write-back hazards.
- Reduce by design. Example: constraining WardFlow Copilot to drafting discharge summaries with mandatory clinician sign-off rather than auto-submitting.
- Protective measures. Example: confidence indicators on transcription segments in Scribe-On-Site; provenance citations on every Atlas response.
- Information for safety. Example: user training, on-screen warnings, release notes describing known limitations.
Information-for-safety controls alone are not accepted as the sole mitigation for any hazard with severity Considerable or above.
7. Human Factors and Automation Bias
AI-mediated tools carry a specific risk of automation bias — clinicians under cognitive load may rubber-stamp plausible-looking AI output. The CSMS treats this as a first-class hazard category. Mitigations include:
- UI designs that surface uncertainty and require active confirmation of safety-critical fields.
- Mandatory training modules covering the limits of each tool.
- Audit logging of edit-distance between AI draft and final clinician-signed artefact, used as a quality signal not as a performance management tool.
8. Release Sign-off Process
No release (initial deployment, version upgrade, or material configuration change) proceeds without:
- An updated Hazard Log reflecting the change.
- An updated Clinical Safety Case Report (CSCR) per affected solution.
- Evidence that all unacceptable and ALARP-justified residual risks have been reviewed.
- Written CSO sign-off recorded in the QMS.
- Notification to deploying trust CSOs in accordance with §11 and the change-notification SLA.
Emergency hotfixes follow an abbreviated process with mandatory retrospective CSG review within five working days.
9. Post-Deployment Monitoring and Incident Management
BritiAI operates a continuous post-market clinical safety surveillance process:
- Telemetry-based monitors (where contractually permitted by the deploying trust) for indicators such as transcription confidence distributions, retrieval staleness signals, abnormal tool-call patterns, and clinician override rates.
- Incident intake channel available 24/7 to deploying trust CSOs.
- Triage SLA: initial triage within one working day; severity classification within three working days.
- Root cause analysis for any incident classified Considerable or above, using a structured framework (e.g. SEIPS or AcciMap adapted for AI-mediated workflows).
- Field Safety Notices issued to all affected deploying organisations where a hazard’s risk profile has materially changed.
- Annual safety review per solution, signed by the CSO.
10. Subcontractor Safety Interface
Votee AI and Beever AI participate in the CSG and are subject to:
- Quarterly joint safety reviews.
- Mandatory disclosure of model updates, training data changes, and known limitations.
- Joint incident handling for hazards spanning the integration boundary.
11. Boundary with Deploying Trust DCB0160 Processes
DCB0160 places clinical risk management obligations on the deploying organisation. BritiAI explicitly supports — but does not substitute for — those obligations. The detailed engagement model is set out in CSO08_DCB0160_Engagement.md. Key principles:
- BritiAI supplies a complete Clinical Safety Case package per solution: CSCR, Hazard Log, intended use statement, known limitations, configuration guidance, and training materials.
- Deploying trust CSOs are expected to perform their own contextual hazard assessment reflecting local workflows, patient mix, and integration points.
- BritiAI offers joint workshops and a named clinical safety liaison.
12. Competence and Training
All BritiAI staff whose work materially affects clinical safety complete:
- Induction training in DCB0129, the BritiAI CSMS, and human factors in AI-mediated clinical workflows.
- Annual refresher with assessed knowledge check.
- Role-specific training for product, engineering, and customer-facing staff.
Records of training completion are held in the QMS and reviewed by the CSO annually.
13. Document Control
All clinical safety documents are version-controlled within the BritiAI QMS. Each document carries: unique identifier, version, status, author, reviewer, approver (CSO for safety artefacts), date of approval, and next review date. Superseded versions are retained for the lifetime of any deployed solution plus seven years, consistent with NHS records management guidance.
14. CSMS Review
This CSMS is reviewed at minimum annually, and on any of the following triggers: regulatory change affecting DCB0129 or the medical device boundary, material change to any solution’s architecture or intended use, a Considerable-or-above incident, or onboarding of a new subcontractor with safety-relevant responsibilities.
Prepared by: BritiAI Quality and Clinical Safety function. To be reviewed, amended and signed by: Appointed Clinical Safety Officer. Signature block:
CSO name: _________________________ Registration body and number: _________________________ Date of CSO training: _________________________ Signature: _________________________ Date: _________________________