Skip to content
Assurance AI

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.

Last reviewed: Guidance in this area changes. We re-check the primary sources when we review a page.

The distinction that matters

Manufacturer responsibilities versus deploying organisation responsibilities

DCB0129 and DCB0160 are complementary standards addressing different parties. Neither one absorbs the other.

QuestionDCB0129 — manufacturerDCB0160 — deploying organisation
Who is addressedThe organisation that designs, builds and supplies the health IT systemThe health or care organisation that implements and uses it
What is assessedThe product as designed, against its stated intended useThe deployment: local workflow, configuration, integration, training and use
Typical hazardsDesign behaviour, data handling, interface design, model behaviour, defectsWorkflow change, local configuration, staff competence, downtime, migration
Who owns the safety caseThe supplier's Clinical Safety OfficerThe deploying organisation's Clinical Safety Officer
What it cannot coverHow the system will be configured and used in a specific organisationDesign 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.

What we need from you

  • The supplier's DCB0129 safety case report and hazard log, with any stated assumptions.
  • A description of the deployment: care setting, workflow, user groups and go-live plan.
  • Your existing local clinical risk management plan, if one exists.
  • Named clinical and operational participants for the hazard workshop.
  • The name and availability of your appointed Clinical Safety Officer.

What you receive

  • A drafted local clinical risk management plan, structured to DCB0160.
  • A populated local hazard log from the workshop, with owners and controls identified.
  • A drafted local clinical safety case report for your CSO to review and sign off.
  • A written review of the supplier's evidence, listing residual risks transferred to you.
  • A prioritised action list with the gaps to close before go-live.

We work in support of your organisation's appointed Clinical Safety Officer. We prepare, structure and review documentation; your CSO reviews and signs it off. We do not sign off clinical safety documentation, and we do not act as your CSO unless and until formal competence, appointment and cover arrangements have been established and recorded in writing.

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

Is DCB0160 just DCB0129 for the NHS side?

No, and treating them as interchangeable causes real problems. DCB0129 concerns the manufacturer and the design and build of the health IT system. DCB0160 concerns the health or care organisation that deploys, configures and uses it in a specific local setting. The hazards are genuinely different: a supplier cannot know your staffing model, your local pathway, your interfaces or how the system will be configured in your organisation.

Our supplier has a clinical safety case. Do we still need to do anything?

Almost always yes. A supplier safety case is written against an intended use and a set of assumptions. Deployment introduces local hazards — configuration choices, integration with your other systems, training, workflow changes, who has access to what, and what happens during downtime. DCB0160 exists to address that layer.

Who should hold the Clinical Safety Officer role in a deploying organisation?

It needs to be someone with appropriate current clinical registration, relevant experience of the clinical setting affected, training in clinical risk management, and enough organisational authority to influence deployment decisions. The role also needs to be resourced properly; a nominal appointment with no time allocated is a common weakness.

Does DCB0160 apply to small changes and configuration?

Configuration and workflow changes are frequently where local clinical risk actually arises, so they should be assessed proportionately rather than exempted by default. Most organisations set thresholds in their clinical risk management plan for what triggers a full reassessment versus a lighter review, and record the reasoning either way.

Can Assurance AI act as our Clinical Safety Officer?

We work in support of your organisation's appointed Clinical Safety Officer: we prepare, structure and review documentation, and your CSO reviews and signs it off. We do not hold the CSO role, and we would only ever consider doing so where formal competence for that clinical setting, a written appointment, contractual scope and indemnity cover have first been established and recorded. Until that is in place, the right arrangement is support under your own CSO, and accountability stays with your organisation.

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.

Next step

Speak to Assurance AI about a deployment

Tell us what you are implementing and where you are in the programme. We will be straight with you about whether we are the right support and what a proportionate scope looks like.