Skip to content

Reviewed guide

DCB0129 versus DCB0160: the responsibility split that prevents gaps

Compare manufacturer DCB0129 and deploying-organisation DCB0160 duties, with a practical handover example.

Assurance AI · Published 30 October 2026

Reviewed by Khalid Anwar on 30 October 2026

DCB0129 addresses the manufacturer of a health IT system; DCB0160 addresses the health or care organisation deploying and using it. Both concern clinical risk management, but they examine different decisions and contexts. NHS England describes the split in its clinical risk management standards.

QuestionManufacturer: DCB0129Deploying organisation: DCB0160
What is in scope?Product design, development, maintenance and intended use.Local implementation, configuration, workflow, use, change and decommissioning.
Where do hazards arise?Product behaviour, interfaces, data handling and foreseeable misuse.Local roles, training, integration, downtime and pathway change.
What evidence is needed?Product-specific clinical risk management evidence and safety case.Local clinical risk management evidence and deployment safety case.
Who makes the decision?The manufacturer manages and documents its product risk.The deploying organisation manages and accepts its local deployment risk.

These are working distinctions, not a substitute for applying the standards to a specific contracting or manufacturing arrangement. NHS England's DCB0129 page and DCB0160 page provide the controlled specifications and guidance. NHS England has started a review of both standards, so check those pages for the current release.

Example: a remote monitoring alert

Suppose a supplier's system flags an abnormal reading. The manufacturer assesses whether the algorithm, data transfer and alert display can fail in ways that contribute to harm. It tests controls and tells customers what response time, staffing and connectivity assumptions underpin its safety case.

The deploying service then assesses its own pathway: who receives alerts overnight, what happens during network loss, how staff are trained, and whether escalation is available when the usual clinician is absent. The supplier cannot fully assess that local roster. The deployer cannot simply accept the product's safety case as proof that its own service is safe.

What should the handover contain?

A useful handover identifies the exact product version; the intended use and exclusions; material residual risks; required configuration; alert and downtime assumptions; user training; and the changes that would require reassessment. Name an owner on both sides for questions and incidents. NHS England's BaRS example illustrates how risks can be transferred between supplier and provider records without transferring away each party's responsibility.

If your organisation has developed software in house, or an agency builds it on your behalf, establish who is acting as manufacturer before allocating the work. The label “supplier” alone may not answer that question. For DTAC purposes, NHS England says a care organisation that offers its in-house product to other providers, charged or not, is acting as a manufacturer.

Read our supplier DCB0129 guide and deployment DCB0160 guide. For an assessment of the handover between them, see our supplier and deployment readiness reviews.

Next step

Need to know what this means for your product?

Tell us what you are building or deploying and we will tell you what, if anything, you need to change in your clinical safety evidence.