Clinical Safety by Design: DCB0129 and DCB0160 in Dental AI
6 min read
How the NHS clinical-risk-management standards apply to AI software in dentistry, and why a named Clinical Safety Officer matters.
When software contributes to clinical decisions, the question is no longer just “does it work?” but “what happens when it doesn’t?” In the UK, the answer is governed by two NHS Digital standards: DCB0129, which places obligations on the manufacturer of health IT, and DCB0160, which places obligations on the organisation deploying it. Together they define a discipline called clinical risk management.
What the standards actually require
DCB0129 is not a checkbox exercise. It requires a manufacturer to appoint a suitably qualified Clinical Safety Officer — a registered clinician — who owns the safety case for the product. That safety case is a living set of documents:
- A hazard log enumerating every way the software could plausibly contribute to patient harm.
- A risk assessment for each hazard, scoring likelihood and severity both before and after mitigations.
- A clinical safety case report that argues, with evidence, that residual risk is acceptable.
Why it matters for AI scribes
An AI clinical-notes tool sits in an unusually sensitive position: it summarises a clinical encounter into the permanent record. The relevant hazards are specific and foreseeable — a mis-heard tooth number, a drug name transposed, an omitted finding, or a confidently worded summary of something the clinician never said. Naming those hazards explicitly is what turns “the AI is usually accurate” into a defensible safety position.
Mitigations that follow from the hazard log
Once hazards are written down, the mitigations become obvious and testable. Every generated note is presented for clinician review before it enters the record. Source audio and transcripts are retained so any entry can be checked against what was actually said. High-risk fields — medical history, medications, diagnoses — are designed to surface uncertainty rather than paper over it.
The point of DCB0129 is cultural as much as documentary: it forces a team to assume their software will fail somewhere, and to design so that failure is caught by a human before it reaches a patient.