Short answer: DCB0129 is the clinical risk management standard for organisations that develop and maintain health IT systems for use in England’s health and care environment — mandated under section 250 of the Health and Social Care Act 2012, where it applies. It requires a governed process, competent clinical safety leadership, hazard management and documented evidence that residual clinical risk is acceptable.
What is DCB0129?
DCB0129 is titled Clinical Risk Management: its Application in the Manufacture of Health IT Systems. NHS England describes it as the standard that helps manufacturers evidence the clinical safety of their products. It is published under section 250 of the Health and Social Care Act 2012, and NHS England states that compliance with DCB0129 and its deployment counterpart DCB0160 is mandatory.
The standard is not a product-quality badge and it is not replaced by DTAC, UK medical-device regulation, cybersecurity assurance or data-protection work. It is the clinical risk management thread that should run through product development, maintenance and release.
When does DCB0129 apply?
It normally applies when an organisation is responsible for developing or maintaining a health IT system intended for use in health or adult social care in England. “Manufacturer” in this context is about responsibility for the product, not whether the organisation owns a factory or sells physical hardware.
The practical first question is therefore not “are we a startup?” but “are we responsible for the design, build, configuration or maintenance of functionality that could affect clinical care?” NHS England publishes a separate applicability guide because the boundary can be nuanced, particularly for platforms, integrations, configurable systems and local modifications.
What evidence does a DCB0129 safety case need?
A credible file usually contains a coherent set of linked artefacts rather than one standalone report:
- Clinical Risk Management Plan: scope, roles, lifecycle, methods, acceptance criteria and planned safety activities.
- Hazard Log: traceable hazards, causes, controls, verification evidence, initial and residual risk, owners and status.
- Clinical Safety Case Report: the structured argument explaining why the available evidence supports release for the defined use and context.
- Clinical Safety Officer approval: named clinical accountability from a suitably competent person. What a CSO does.
- Supporting evidence: intended use, workflow analysis, testing, usability findings, incident processes, release records and known limitations.
The hazard log is not just a spreadsheet of dramatic failures. It should include credible ways the system could contribute to harm: omitted information, misleading prioritisation, delayed action, incorrect identity matching, inaccessible alerts, automation bias and unsafe behaviour during downtime or degraded performance.
A workable DCB0129 process
- Define intended use and boundaries. State users, settings, decisions supported, excluded uses, dependencies and interfaces.
- Appoint the CSO and agree governance. Establish who can accept risk, who owns controls and how unresolved safety issues affect release.
- Map the clinical workflow. Clinical risk lives in the interaction between software, people, policy and environment.
- Run structured hazard identification. Include clinicians, product, engineering, implementation and human-factors perspectives.
- Design and verify controls. A control is not complete because it appears in a requirement; evidence must show that it works.
- Build the safety argument. Link claims to evidence and make assumptions, limitations and residual risks explicit.
- Maintain it after release. Changes, incidents, new integrations and new settings can alter the risk picture.
Common failure modes
Starting at procurement
If the first serious hazard workshop happens when an NHS buyer asks for the safety case, important design decisions may already be expensive to change. Clinical safety works best as a product discipline, not a document sprint.
Confusing a hazard with a software bug
A bug may be a cause. The hazard should describe the unsafe clinical condition or circumstance, with a plausible path to harm and controls across the whole sociotechnical system.
Writing controls that cannot be evidenced
“The clinician will check” is not automatically an effective control. The workflow must make the check possible, understandable and reliable, and the verification record must show what was tested.
Treating sign-off as the end
DCB0129 covers development and maintenance. Material changes need safety impact assessment, and the safety file should remain aligned with the released product.
Current position in 2026
NHS England has begun a review of DCB0129 and DCB0160 so the standards remain practical and aligned with advances in healthcare technology and clinical practice. The current published 2018 release remains the operative source, so teams should use the current documents while monitoring official updates.