Deploying organisations
DCB0160 clinical safety support for healthcare organisations
DCB0160 is the clinical risk management standard for health and care organisations deploying and using health IT. It addresses the risks that only appear once a system meets a real service, a real configuration and real staff.
The distinction that matters
Manufacturer responsibilities versus deploying organisation responsibilities
DCB0129 and DCB0160 are complementary standards addressing different parties. Neither one absorbs the other.
| Question | DCB0129 — manufacturer | DCB0160 — deploying organisation |
|---|---|---|
| Who is addressed | The organisation that designs, builds and supplies the health IT system | The health or care organisation that implements and uses it |
| What is assessed | The product as designed, against its stated intended use | The deployment: local workflow, configuration, integration, training and use |
| Typical hazards | Design behaviour, data handling, interface design, model behaviour, defects | Workflow change, local configuration, staff competence, downtime, migration |
| Who owns the safety case | The supplier's Clinical Safety Officer | The deploying organisation's Clinical Safety Officer |
| What it cannot cover | How the system will be configured and used in a specific organisation | Design decisions and internal product behaviour set by the manufacturer |
A supplier who claims their evidence removes the deploying organisation’s obligations is overstating it. Equally, a trust that assumes the supplier has covered everything will find local hazards unaddressed at go-live.
Scope
Who DCB0160 is for
DCB0160 is aimed at health and care organisations that deploy, configure, integrate or significantly change health IT used in the delivery of care. In practice that includes NHS trusts and boards, primary care organisations and PCNs, community and mental health providers, ICBs running shared systems, and independent providers delivering NHS-commissioned care.
It also matters to suppliers, indirectly. The assumptions, constraints and residual risks you hand to a customer determine how much local work they face. A supplier who provides clear deployment guidance makes their customer’s DCB0160 work tractable — and gets through implementation faster as a result.
What good looks like locally
- A named, appropriately competent Clinical Safety Officer with real time allocated.
- A local clinical risk management plan that is actually followed, not filed.
- Hazard assessment done early enough to change the configuration, not after go-live.
- Clinical staff involved in identifying hazards, not only IT and programme staff.
- Change control that reassesses upgrades and configuration changes proportionately.
Where local hazards come from
Local workflow change
The system changes who does what, in what order, and with what information in front of them. The clinical risk sits in the new workflow, not only in the software.
Configuration decisions
Templates, alerts, default values, escalation rules and access permissions are all local choices that can create or remove hazards.
Integration and data flow
How the system exchanges data with your existing estate — and what happens when that exchange is delayed, partial or fails silently.
Training and competence
Who has been trained, on what version, and what happens with bank, agency and rotating staff.
Downtime and fallback
What clinical staff do when the system is unavailable, and how the record is reconciled afterwards.
Decommissioning and migration
Retiring a legacy system, migrating data and running two systems in parallel are each a distinct source of clinical risk.
Documentation
Local clinical safety documentation
The document set mirrors the supplier side, but the content is local. Referencing a supplier's safety case is fine; substituting it is not.
Local clinical risk management plan
How your organisation manages clinical risk for this deployment: scope, roles, risk criteria and approval route.
Local hazard log
Deployment-specific hazards, their causes, controls and residual risk — including hazards inherited from supplier assumptions.
Clinical safety case report
The local argument that the deployment is acceptably safe, referencing the supplier's evidence but not substituting for it.
Deployment and go-live checklist
The clinical safety preconditions for go-live, and who signs them off.
Change control record
How upgrades, configuration changes and workflow changes are reassessed after go-live.
Working together
Your relationship with suppliers
The most productive deployments treat clinical safety as a shared conversation rather than a document exchange. Ask your supplier for their intended-use statement, their clinical safety case report for the version you are deploying, and — most usefully — the assumptions and residual risks they are handing to you.
That last item is the bridge between the two standards. Every supplier control that depends on local behaviour (“users will be trained”, “the system will be configured with X enabled”, “a clinician will review before filing”) becomes a local obligation. If it is not written down and assigned, it will not happen reliably.
Change management
After go-live
Clinical risk does not stop at go-live. Supplier upgrades, new modules, changes to interfacing systems, local configuration changes, new user groups and pathway redesign all warrant a proportionate reassessment.
Set thresholds in advance for what triggers what. A minor cosmetic release does not need the same treatment as a new AI-assisted feature or a change to alerting logic — but the decision should be recorded, with reasons, either way.
How we help
Support for applicable organisations
Our primary focus is supplier-side assurance. Where a deploying organisation needs support, we offer a defined and honest scope.
Local hazard workshops
Facilitated sessions with clinical and operational staff to surface deployment and workflow hazards before go-live.
Documentation support
Structuring your local clinical risk management plan, hazard log and safety case report so they are usable and defensible.
Supplier evidence review
Reading what your supplier has provided and identifying the assumptions and residual risks that land with you.
Accountability for local clinical safety remains with the deploying organisation and cannot be transferred to an adviser. We are not a regulator, certification body or statutory auditor, and nothing here is legal, regulatory or clinical advice.
FAQ
DCB0160 questions we are asked most
Keep going
Related reading
DCB0129 for suppliers
The manufacturer-side standard, and the evidence your supplier should be able to produce.
Clinical Safety Officer support
Competence, authority and resourcing for the role in a deploying organisation.
Safety cases and hazard logs
How the local argument is structured and kept traceable.