DCB 0129, explained
in plain English.

If you are building a digital health product for the NHS, sooner or later someone asks whether you are "DCB 0129 compliant." Sometimes it is a procurement lead, sometimes a trust's clinical safety team, occasionally an investor doing diligence. The honest version of what they are asking is this: have you proven your software will not harm a patient, and is a named clinician willing to put their signature on that claim? That is what DCB 0129 is for. Here is the whole thing in plain English, from someone who writes these for a living.

What DCB 0129 actually is

DCB 0129 is an NHS information standard. Its full name is "Clinical Risk Management: its Application in the Manufacture of Health IT Systems." It is published by NHS England (it began life at NHS Digital) and it is mandatory under section 250 of the Health and Social Care Act 2012. In practice it means that if you make software used in the NHS to support care, you must run a formal clinical risk management process and produce evidence that you did.

It is not a box to tick. It is a discipline borrowed from safety engineering: work out every way your product could contribute to patient harm, decide how likely and how serious each one is, design those risks down to an acceptable level, and document all of it so a clinician can review it and sign off.

DCB 0129 vs DCB 0160, and why people confuse them

There are two standards and they are a pair.

• DCB 0129 is for the manufacturer. If you build the product, this one is yours.
• DCB 0160 is for the deploying organisation. When a trust switches your product on, they run their own DCB 0160 process for how it is used in their setting.

You produce a clinical safety case under 0129; the trust builds on it under 0160. When a trust asks for "your DCB 0160," they usually mean they want your 0129 evidence so they can complete their own 0160. Knowing which side of the line you sit on saves a lot of confused emails.

What you actually have to produce

Three documents do most of the work.

1. A Clinical Risk Management Plan. How you will run the process, who is accountable, and what "acceptable" risk means for your product.
2. A Hazard Log. The heart of it. Every hazard, its causes, the harm it could cause, an initial risk rating (severity and likelihood), the controls you put in place, and the residual risk once those controls are applied.
3. A Clinical Safety Case Report (CSCR). The readable summary that argues, with evidence, that your product is safe to deploy. This is the document a trust's safety team will actually read.

Underneath those sits the thing that makes them credible: a named Clinical Safety Officer.

The Clinical Safety Officer

DCB 0129 requires a Clinical Safety Officer (CSO): a currently registered clinician, suitably trained in clinical risk management, who is accountable for the clinical safety of your product. The CSO runs the hazard analysis, signs the safety case, and is the person whose name is on the line. You can train someone internally or contract one in. What you cannot do is skip it. No CSO, no valid safety case.

Where DCB 0129 fits with everything else

A few relationships are worth getting straight, because teams routinely conflate them.

• DTAC. The Digital Technology Assessment Criteria, used by most NHS buyers, has a clinical safety section that asks for your DCB 0129 evidence. No safety case, no DTAC pass.
• Medical device regulation. If your product is a medical device, you also need UKCA or CE marking under MHRA rules. That is a separate regime about the device itself. DCB 0129 is about clinical safety in NHS use. Many products need both, and one does not substitute for the other.
• Data protection. The DSPT and a DPIA are separate again. Safety is about harm, not privacy. You will likely need all of these, so plan for them as a set rather than discovering them one at a time.

Start earlier than you think

The expensive mistake is treating DCB 0129 as a final step before go-live. By then your design decisions are baked, and if the hazard analysis surfaces something serious you are reworking the product under deadline. Clinical risk management is cheapest when it shapes the design, because you identify hazards while you can still architect them away. Start at design, not at launch.

What it costs you to ignore it

Not the consultancy fee. The real cost is the slipped go-live, the trust pilot paused at the safety gate, the procurement that stalls because you cannot answer the clinical safety question. For an early-stage company, a three-month delay to a pilot is usually worse than the entire cost of doing the safety case properly.

How the process runs

In practice it is four phases: scope the product and its clinical context; run a hazard identification workshop with your clinical and engineering leads; draft the hazard log, safety requirements and CSCR; then review residual risk and sign the release. Done with focus, that is a few weeks rather than a few months, as long as the team turns up to the workshop and the scope stops moving.

Common questions

Do I need DCB 0129 to sell to the NHS? If your product is health IT used in NHS care, yes. It is mandatory, and DTAC will ask for it.

Is DCB 0129 the same as being a medical device? No. Device regulation through the MHRA is separate. You may well need both.

Can I do it myself? You can, if you have a registered clinician trained as a CSO and the time to run the process properly. Many teams contract the role in to move faster and keep it independent.

How long does it take? A focused engagement is typically about four weeks from kickoff to a signed release.

What if we change the product later? Material changes go through change control and the safety case is updated. It is a living process, not a one-off.