How to produce a DCB 0129 clinical safety case

An NHS Trust has agreed to buy your health IT product. Before go-live, the Trust's clinical safety team asks for your DCB 0129 evidence: the name of your Clinical Safety Officer, the Hazard Log, the Clinical Safety Case Report. If the clinical safety section of a DTAC submission is open, the procurement behind it sits and waits. NHS England is explicit that a digital technology which cannot meet DCB 0129 cannot be placed on the market or used in the NHS.

This guide covers the practical route to producing and maintaining that safety case as a health IT manufacturer. DCB 0129 is a mandatory information standard with self-assessed conformance, so there is no certificate to collect. You produce the evidence and keep it live. For what the standard is, how it differs from DCB 0160 and who it applies to, read the what is DCB 0129 explainer. Here the focus is the how.

What DCB 0129 asks of you

DCB 0129 requires a manufacturer of health IT to apply clinical risk management across the product lifecycle and to evidence it. The standard sits on a defined set of documents from NHS England Digital, including the Specification, the Implementation Guidance and the Compliance Assessment Template you self-assess against.

In practice, conformance comes down to five outputs you produce and hold:

• A competent, named Clinical Safety Officer accountable for the product's clinical safety.
• A Clinical Risk Management System, or Plan, covering scope, roles, process and governance across the lifecycle.
• Clinical risk analysis that traces each hazard to its causes and clinical effects.
• A Hazard Log recording every hazard, its rating, its controls and its residual position.
• A Clinical Safety Case Report, the structured argument that the system is safe to release.

DCB 0129 is the manufacturer's obligation, and it stops at the product. The deploying Trust or ICB carries out DCB 0160 on how the software is used in its own setting. Your outputs become the inputs to theirs.

How to produce a DCB 0129 clinical safety case, step by step

The work runs in sequence, and the last step never closes.

1. Appoint a competent Clinical Safety Officer

The Clinical Safety Officer is a clinician with current professional registration, for example with the GMC, NMC or GPhC, trained in clinical risk management. They own the clinical safety of the product and sign off the safety case. The role can be filled by an employee or a named third party, and most early healthtech companies outsource it, because they rarely employ a registered clinician. Nothing downstream is valid without this appointment, so it comes first.

2. Establish the Clinical Risk Management System

Set out how clinical risk is managed for this product: the scope, the roles, the process, the risk acceptance criteria and the governance that holds it together across the lifecycle. This is the Clinical Risk Management Plan the DTAC clinical safety section later asks you to name. It defines how you will do the analysis in step three, so agreeing it up front stops the analysis being reworked.

3. Carry out clinical risk analysis

With the CSO leading, identify the hazards your software could introduce into care. For each hazard, record its causes, the initiating events, and its clinical effects, the harm that could reach a patient. Assess each on likelihood and severity, define the controls that reduce it, then record the residual risk once those controls are in place. This is the analytical core of the whole exercise, and shallow analysis here is what fails clinical review later.

4. Build and maintain the Hazard Log

The Hazard Log is the register that holds the output of step three: each hazard, its causes, its initial rating, the controls applied, the residual rating and its ALARP position. ALARP stands for As Low As Reasonably Practicable, the point at which further risk reduction is no longer reasonable against the effort involved. The log is a working record that changes as the product does.

5. Produce the Clinical Safety Case Report

The Clinical Safety Case Report is the structured, evidenced argument that the system is safe to release, drawing on the Hazard Log and the controls behind it. The CSO reviews and signs it. This is the single document an NHS buyer and a DTAC assessor look for as proof that clinical safety has been managed, so it has to stand on its own evidence.

6. Keep the safety case live

Conformance is not a point in time. You maintain the safety case for the deployed life of the product and reassess when things change: a new release, a functionality change, a reported incident, a new deployment. A major release is an explicit trigger for the CSO to review and update the safety case. Treat this as a standing process that runs for as long as the product is deployed.

From there, your Clinical Safety Case Report, Hazard Log and named CSO become the evidence for the clinical safety section of a DTAC submission, and the input to each Trust's own DCB 0160 work. You produce the safety case once and it does duty across every NHS conversation that follows.

How long a DCB 0129 safety case takes

There is no NHS England timeline for this, and any figure is indicative. Clinical safety consultancies commonly describe a first safety case for a single-product company taking shape over roughly the first three months of an engagement, though that depends heavily on how mature your existing product and design documentation already is. The two real drivers are CSO availability and the state of your documentation. Well-kept design records shorten the analysis; scattered ones lengthen it. Maintenance has no end date, because the obligation runs for the deployed life of the product.

Where teams get stuck

Six blockers account for most stalled safety cases.

• No access to a qualified CSO. This is the commonest wall for early healthtech. It is a gating dependency on a person; the appointment has to be made before anything else moves.
• Hazard analysis too shallow. Generic hazards with no causes, clinical effects or specific controls do not survive clinical review.
• The Hazard Log treated as one-off. A static log goes stale the moment the product changes.
• The safety case not updated on release. A major release is a defined reassessment trigger, and a report that predates the current build undermines the argument.
• Confusing DCB 0129 with DCB 0160 or the MHRA route. These are separate obligations. Meeting one does not satisfy another.
• Evidence scattered across suppliers and spreadsheets. When the CSO, the documentation and the wider compliance evidence sit apart, the pack gets rebuilt by hand for every deal.

How Naq gets you there faster

The gating dependency is the person, so that is where the platform starts. Naq's in-house Clinical Safety Officers build and maintain the Clinical Safety Case Report and the Hazard Log with you, included in the platform rather than hired and invoiced separately.

The Hazards module is aligned to DCB 0129. It uses 5×5 Likelihood by Severity scoring with a Hazard Rating of 1 to 5, holds causes as first-class child records under each hazard, carries an ALARP flag on the residual risk, archives entries instead of deleting them so the audit trail stays intact, and sets the CSO as the default approver. Reassessment is driven by events, so an incident, a control failure, a system or supplier change or a major release prompts a review instead of relying on someone to remember.

Because clinical risk and evidence sit in one connected system, they feed the DTAC clinical safety section without being gathered twice. The AI assistant is read-only by design; it summarises and checks evidence and never edits the formal safety record.

Clinical safety support is a genuine difference from the US compliance platforms such as Vanta and Drata, which do not carry it. UK NHS specialists cover this ground too. The ownable advantage is running clinical safety in the same place as ISO 27001, Cyber Essentials, GDPR and the other NHS standards, so one connected system holds the lot.

Frequently asked questions

Do I get a DCB 0129 certificate?

No. DCB 0129 is a mandatory NHS information standard with self-assessed conformance, so there is no certificate to obtain. You produce and maintain the clinical safety case, the Hazard Log and the named Clinical Safety Officer, and self-assess against the NHS England Compliance Assessment Template as evidence of conformance.

Do I need a Clinical Safety Officer to produce a DCB 0129 safety case?

Yes. DCB 0129 requires a named Clinical Safety Officer: a clinician with current professional registration, for example GMC, NMC or GPhC, trained in clinical risk management and accountable for the product's clinical safety. They sign off the safety case. The role can be an employee or an outsourced named third party.

What is the difference between the Hazard Log and the Clinical Safety Case Report?

The Hazard Log is the living register of every hazard, its causes, its ratings, its controls and its residual ALARP position. The Clinical Safety Case Report is the structured argument, built on that log, that the system is safe to release. The Hazard Log is evidence; the report is the conclusion the CSO signs.

How does DCB 0129 feed into a DTAC submission?

The clinical safety section of DTAC asks a manufacturer to confirm DCB 0129 conformance, name the Clinical Safety Officer and supply the Clinical Risk Management Plan, the Clinical Safety Case Report and the Hazard Log. The outputs you produce for DCB 0129 are the evidence that section requires.

Does the DCB 0129 safety case ever finish?

No. You maintain it for the deployed life of the product. A new release, a functionality change, a reported incident or a new deployment each triggers a reassessment, with a major release prompting a CSO review and an update to the safety case.

‍