Clinical risk management
DCB0129 compliance and clinical safety support for digital health suppliers
DCB0129 is the NHS clinical risk management standard that applies to manufacturers of health IT systems. This page explains what it asks for, the evidence it produces, and where suppliers most often get stuck — then how we help you close it.
The basics
What DCB0129 is
DCB0129 is a clinical risk management standard published under the remit of NHS England’s data and information standards process. It sets out a clinical risk management process that manufacturers of health IT systems are expected to follow so that clinical risk is identified, analysed, controlled and monitored across the product lifecycle.
It is a process standard, not a checklist of technical features. It does not tell you how to build software. It asks you to demonstrate, with evidence, that you understand how your product could contribute to patient harm, that you have done something proportionate about it, and that you keep doing so as the product changes.
The visible outputs are a clinical risk management plan, a hazard log and a clinical safety case report, produced under the oversight of a named Clinical Safety Officer. The credibility of those documents — not their existence — is what determines how a review goes.
What it is not
- It is not a certification you pass once and display as a badge.
- It is not a determination of whether your software is a medical device; that is a separate regulatory question.
- It is not a substitute for information governance, security testing or accessibility work.
- It is not something your NHS customer can complete on your behalf.
Who it applies to
- Manufacturers of software used in the delivery of NHS care in England
- Suppliers whose product informs, prompts or automates part of a clinical decision or workflow
- Products that create, transmit, transform or display clinical data
- Digital therapeutics, triage, remote monitoring and patient-facing clinical tools
- AI-enabled products supporting clinical documentation, summarisation or prioritisation
- Organisations bringing an existing product to the NHS from another market
Applicability should be assessed and recorded for your specific product and intended use. If DCB0129 genuinely does not apply, the reasoning for that conclusion is itself useful evidence to hold.
Deploying rather than supplying?
If you are an NHS or care organisation implementing someone else’s system, the standard that applies locally is DCB0160.
Read about DCB0160 →Common triggers
Why manufacturers meet DCB0129 during NHS procurement
Most suppliers do not go looking for this standard. It arrives attached to a deal, usually at the point where a deadline already exists.
An NHS procurement or framework question
A buyer asks for your clinical risk management plan, hazard log and clinical safety case report, often at short notice and usually with a submission deadline.
A DTAC request
The clinical safety section of DTAC asks directly about DCB0129 compliance and your Clinical Safety Officer arrangements.
An information governance or security review
Reviewers notice the product touches clinical workflow and escalate to the trust's clinical safety team.
A pilot converting to a contract
What was tolerated as a small pilot now needs formal assurance before wider rollout.
A significant product change
A new module, a new integration or a new AI feature changes the clinical risk picture and triggers reassessment.
An incident or near miss
Something happened in the field and the customer asks how the hazard was identified and controlled.
The pattern is consistent: clinical safety evidence is requested late, treated as paperwork, and then becomes the thing that delays a signature. Doing it earlier is cheaper and produces a better product, because the hazard workshop usually surfaces design issues nobody had articulated.
The lifecycle
Clinical risk management, step by step
DCB0129 describes a cycle rather than a document set. Each step produces evidence, and each product change re-enters the cycle.
Define intended use
Everything downstream depends on this. The intended-use statement sets out what the product does, for which users and patient groups, in which settings, and what it is explicitly not for. A vague intended use produces a hazard log that cannot be judged complete, because nobody can say what 'complete' would mean.
Establish the clinical risk management plan
The plan describes how clinical risk will be managed across the lifecycle: who is accountable, how hazards are identified and scored, the risk acceptability criteria you will apply, how decisions are recorded, and how the process reconnects at each release.
Identify clinical hazards
Structured hazard identification, ideally in a workshop with clinical and engineering input, walking the real clinical workflow. The useful question is not 'can the software crash' but 'what could a user reasonably do, or be led to believe, that results in a patient being harmed'.
Analyse and evaluate risk
For each hazard: causes, the clinical consequence, existing controls, an initial risk rating, then a residual rating after additional controls. The judgements matter more than the matrix — a defensible log shows reasoning, not just numbers.
Implement and verify controls
Controls can be design changes, constraints on behaviour, user interface changes, guidance, training or deployment requirements passed to the customer. Each needs to be verified as actually implemented, and traceable back to the hazard it addresses.
Produce the clinical safety case report
The safety case is the argument that the product is acceptably safe in its intended use, supported by the evidence you have generated. It should be readable by a clinical safety officer at the receiving organisation without needing a walkthrough.
Manage change and post-deployment safety
Releases, configuration changes, model or prompt changes, integration changes and field incidents all feed back into the hazard log. Clinical safety is a lifecycle activity, not a document produced once for a bid.
Typical evidence
What NHS reviewers ask to see
These are the artefacts that most often appear in a clinical safety review. They should read as a connected set, not as eight unrelated documents.
Clinical risk management plan
Scope, responsibilities, risk acceptability criteria and process, signed by the Clinical Safety Officer.
Hazard log
A live register of hazards, causes, consequences, controls, initial and residual risk, owners and status.
Clinical safety case report
The structured safety argument with references to supporting evidence, issued per release or major version.
Intended-use statement
What the product is for, who uses it, in what setting — and its explicit limitations and exclusions.
Clinical Safety Officer record
Who holds the role, their registration and competence, their authority and how they are resourced.
Change and release control
How clinical safety is reassessed on change, with a traceable trail of decisions and approvals.
Deployment guidance for the customer
Assumptions, configuration constraints, training expectations and residual risks handed to the deploying organisation.
Incident and post-market process
How field issues are triaged for clinical impact and fed back into the hazard log.
Common mistakes
Where suppliers usually come unstuck
None of these are unusual, and none of them are fatal if they are caught before a buyer finds them.
Treating it as a document exercise
A safety case produced from a template in a weekend reads exactly like one. Reviewers ask follow-up questions and the gaps surface immediately.
An intended use that is deliberately broad
Broad intended use looks commercially attractive and makes the safety argument almost impossible to close. Narrow and precise is easier to defend.
Hazards written as software bugs
'API returns 500' is not a clinical hazard. The hazard is what the user sees, believes and does next, and how a patient could be affected.
No named Clinical Safety Officer, or a nominal one
A CSO who has never seen the hazard log is a governance gap that buyers detect quickly.
Controls with no verification
Every stated control should be traceable to something that demonstrably exists in the product, the documentation or the deployment process.
A safety case frozen at version one
If the product has shipped twelve releases since the safety case was signed, the safety case is no longer evidence of anything.
Assuming DCB0160 is someone else's problem entirely
You cannot complete it for your customer, but the assumptions you hand them materially affect whether they can complete it at all.
How Assurance AI helps
Clinician-led support, structured around SAFE
We work through our own SAFE methodology so the work stays proportionate and every document traces back to a real decision.
Scope
Define intended use, users, clinical context, boundaries and dependencies.
Before anything can be assessed, we pin down what the product is actually for: the clinical question it answers, who uses it, where it sits in the care pathway, what it explicitly does not do, and which systems, data feeds or models it depends on.
Assess
Identify potential clinical, operational, AI and governance risks.
Structured hazard identification with clinical input — including reasonably foreseeable misuse, workflow failure modes, data quality issues and, for AI-enabled products, model behaviour that could mislead a user.
Fortify
Design proportionate controls, oversight, monitoring and mitigations.
Controls that match the severity and likelihood of the hazard: design changes, human oversight, constrained outputs, user guidance, training, fallback behaviour and post-deployment monitoring.
Evidence
Create traceable evidence that demonstrates how risks are being managed.
Documentation that stands up to scrutiny: hazard log, clinical risk management plan, safety case report, DTAC responses and a change-control trail linking each control back to the hazard it addresses.
SAFE is Assurance AI’s own internal assurance methodology. It is not NHS certification, regulatory approval, statutory audit or accreditation, and completing it does not guarantee any procurement or regulatory outcome.
Applicability and gap assessment
A structured read of your product, intended use and existing documentation against what DCB0129 asks for — with a prioritised gap list rather than a generic report.
Hazard identification workshops
Facilitated sessions with your clinical, product and engineering people, walking real workflows to surface plausible failure modes.
Documentation build or rescue
Clinical risk management plan, hazard log and safety case report drafted with you, in language a receiving clinical safety team will accept.
Clinical Safety Officer arrangements
Clarifying the role, its competence requirements and how it is resourced — including coordinating appropriately qualified external support where scope allows.
Change and release integration
Embedding clinical safety review into your release process so the safety case stays current instead of ageing out.
Buyer-facing readiness
Preparing the pack that goes to procurement, and rehearsing the questions a clinical safety reviewer will ask.
We are an assurance and advisory practice. We are not a regulator, certification body or statutory auditor, and we do not approve, certify or accredit products. Nothing on this page is legal, regulatory or clinical advice.
FAQ
DCB0129 questions we are asked most
Keep going
Related reading
DTAC readiness
The clinical safety section of DTAC leans directly on your DCB0129 evidence.
Clinical Safety Officer support
Who can hold the role, what it requires, and external CSO models.
Clinical safety case and hazard log
How the argument is structured and what traceability looks like in practice.
AI clinical safety
What changes in your hazard analysis when the product uses machine learning or LLMs.
DCB0160 for deploying organisations
The local counterpart your NHS customer is responsible for.
NHS readiness check
A structured, deterministic self-assessment of where your assurance currently stands.