DCB0160: What It Is, Who’s Accountable, and How to Evidence Compliance

DCB0160 in plain English: the difference between safe go-live and wishful thinking

I once sat in a Trust go-live readiness meeting for a new ePMA system. The project team had done heroic work; environments built, data migrated, super-users trained. Then the Clinical Safety Officer quietly asked, “Where’s the signed Safety Case and the current hazard log?” The room fell still. Everyone cared about safety — but the evidence wasn’t there. That silence delayed go-live by three weeks. Painful? Yes. Necessary? Absolutely.

DCB0160 exists to prevent those awkward — and risky — moments. It’s not red tape; it’s the backbone of safe clinical technology deployment across the NHS and independent providers delivering NHS-funded care. If you’re accountable for digital in a Trust, ICS, GP practice, or a private provider integrating with NHS systems, you need to know this standard inside out.

What is DCB0160?

DCB0160 is the NHS England clinical risk management standard for deploying health IT systems in live care settings. If DCB0129 is the manufacturer’s duty to build safe products, DCB0160 is the deploying organisation’s duty to implement, configure, integrate, and operate those products safely in the real world.

It applies whenever digital technology could impact clinical care — EPR modules, ePMA, decision support, digital triage, remote monitoring platforms, pathology/radiology systems, integrations, major upgrades and configuration changes. The standard requires robust clinical risk management across the full lifecycle: scoping, design, testing, go-live, change, and decommissioning.

How it fits with DCB0129, DTAC and UK regulation

• DCB0129 (supplier) + DCB0160 (deploying organisation) are complementary. You need assurance from the supplier (0129) and assurance within your own environment (0160).
• DTAC (Digital Technology Assessment Criteria) expects evidence of compliance with DCB0129/0160 as part of NHS procurement and assurance.
• CQC Regulation 12 (safe care and treatment) and Regulation 17 (good governance) expect providers to assess, monitor, and mitigate risks — DCB0160 is strong evidence of that.
• UK GDPR requires Data Protection Impact Assessments (DPIAs). A DPIA is about data protection risk; DCB0160 is about clinical safety risk. You usually need both.
• DSPT (Data Security and Protection Toolkit) covers information governance and cyber. Again, separate but complementary.
• If your solution functions as a medical device software under the UK MDR 2002 (as amended), you’ll also look to MHRA guidance — but DCB0160 still applies to deployment.

Who is accountable?

Let’s be clear on roles. Accountability isn’t a mystery; it’s structured.

• Board/Executive – Owns clinical safety. Ensures governance is in place, risk appetite is defined, and resources are available.
• Senior Responsible Owner (SRO) – Accountable for the programme and for ensuring DCB0160 is embedded. Signs off readiness and residual risk.
• Clinical Safety Officer (CSO) – A suitably qualified, registered clinician responsible for the clinical risk management process, safety documentation, hazard review, and safety sign-off. The CSO must be independent enough to challenge timelines.
• Project/Change Leads – Ensure DCB0160 activities are integrated into project plans, testing, and go-live criteria.
• Suppliers – Provide DCB0129 evidence, hazard information, safety notices, and cooperate in joint hazard analysis for your configuration and integrations.
• Operational Clinical Leads – Own safe workflows, local SOPs, and adoption; they help identify and mitigate hazards in practice.

What DCB0160 demands

The standard requires a documented and repeatable clinical risk management system covering:

• Governance – Named roles, responsibilities, escalation routes, and decision rights.
• Clinical Risk Management Plan (CRMP) – The how/when/who of managing risk for the specific project or change.
• Hazard Identification and Analysis – Structured capture of hazards (e.g., wrong-patient selection, truncated results in interfaces, decision support misfires), likelihood/severity scoring, and mitigations.
• Verification and Validation – Evidence that mitigations exist and work in the operational context (configuration reviews, scenario testing, clinical simulations, user acceptance testing with safety scenarios).
• Safety Case – A clear, auditable argument that the system is safe for intended use in your environment, supported by evidence.
• Incident Management and Change Control – Processes for capturing issues, trend analysis, and assessing safety impact of patches, configuration, and releases.

The evidence pack you should be ready to show

Auditors, CQC inspectors, internal assurance, and your own Board will expect to see a coherent set of documents. At minimum:

• Clinical Safety Strategy – How your organisation applies DCB0160 across programmes.
• Roles and Responsibilities (RACI) – Including named CSO and deputies.
• Clinical Risk Management Plan for the project/change.
• Hazard Log – Dated, with owners, mitigations, status, and traceability to tests, SOPs, and training.
• Safety Case Report – The narrative linking evidence to claims of safety.
• Test Protocols and Results – Including negative testing and edge cases (e.g., paediatric dosing limits).
• Operational SOPs and Work Instructions – Safe use, downtime procedures, escalation routes.
• Training and Competency Evidence – Super-user model, competency checklists, sign-off for high-risk tasks.
• Go-Live Readiness and Risk Acceptance – Residual risks documented, accepted by the SRO and CSO.
• Incident and Change Logs – With clinical safety impact assessment.

Practical steps to speed safe go-live (and avoid last-minute panic)

Embed early, not late

• Week 0–2: Nominate your CSO and deputies; draft the CRMP; create a simple hazard log template; agree risk scoring aligned with your Risk Management Policy.
• Week 3–6: Run a cross-functional hazard workshop (clinical, pharmacy, operations, IM&T, supplier). Seed it with known hazards from DCB0129 artefacts, incident reports, and lessons from neighbouring Trusts.
• Week 7–10: Trace each high-risk hazard to a mitigation and a test. Build safety scenarios into UAT and clinical simulations. Don’t leave safety testing to the final sprint.
• Week 11–go-live: Draft the Safety Case as you go; don’t wait until the end. Obtain staged sign-offs at each gate (design freeze, test exit, training completion).

Use simple, visible tools

• One living hazard log in a shared location. No scattered spreadsheets.
• Risk burndown on the weekly agenda. If risk isn’t reducing, pause and address the blockage.
• Clear change impact checks in your CAB: “Does this affect any DCB0160 hazards, mitigations, or SOPs?”

Examples across UK settings

• Acute Trust ePMA: High-risk hazards include weight-based dosing, look‑alike/sound‑alike medicines, and duplicate therapy. Mitigations include configuration controls, clinical decision support, pharmacist verification, and training with competency checks. Evidence: test scripts showing dose checks firing correctly and being actioned.
• Primary care digital triage: Hazards include delayed escalation of red-flag symptoms. Mitigations: clear triage rules, safety netting communications, time-based alerts, and rota cover SOPs. Evidence: audits of response times and escalation outcomes.
• ICS remote monitoring: Hazards include device connectivity loss and misinterpreted data. Mitigations: automated alerts, patient education, agreed response thresholds, and on-call clinical oversight. Evidence: simulated drop-outs and documented clinical responses.
• Independent provider integrating with NHS Spine: Hazards include identity mismatch. Mitigations: mandated NHS number tracing workflows, staff training, and audit. Evidence: identity matching test results and SOP adherence checks.

Common pitfalls (and how to avoid them)

• Leaving the CSO to “do the paperwork”. Fix: make safety a team sport. The CSO leads; everyone contributes evidence.
• Confusing DPIA with DCB0160. Fix: run them in parallel; cross-refer where risks overlap but keep purposes distinct.
• Hazard logs without closure evidence. Fix: link each mitigation to a test, SOP, or training artefact. No link, no closure.
• Uncontrolled local configuration. Fix: change control with clinical safety impact checks and rollback plans.
• Silence from frontline users. Fix: involve clinicians early, run simulations on real pathways, and schedule “mop‑up” clinics in week one.

Mapping to wider UK governance

• CQC: DCB0160 artefacts demonstrate you’ve identified and mitigated risks (Reg 12) and maintain effective governance (Reg 17).
• HSE principles: The ALARP concept (as low as reasonably practicable) mirrors what we aim for in clinical digital risk; document why residual risk is tolerable.
• UK GDPR and ICO DPIA: Cross-reference risks (e.g., incorrect data flows causing clinical error). Keep the risk registers connected but not conflated.
• FCA-regulated providers offering digital health benefits: Whilst outside core NHS scope, the accountability mindset mirrors SM&CR. Clear ownership, documented decisions, and evidence trails matter.
• Education and public sector: School nursing and community services using digital tools should still apply DCB0160 where clinical impact exists, aligning with DSPT and safeguarding policies.

What “good” looks like on go-live day

• Signed Safety Case and risk acceptance by the CSO and SRO, with residual risks understood and owned.
• Operational SOPs live, staff briefed, escalation lines tested.
• Back‑out and downtime plans rehearsed, not theoretical.
• Real-time monitoring of key safety indicators (e.g., order turnaround times, alert overrides, response SLAs).
• Hypercare staffed with clinical and digital leads; issues triaged with a safety lens.

Templates you can stand up quickly

You don’t need ornate documents; you need clarity and traceability. Start with:

• Two-page CRMP – scope, roles, methods, thresholds, sign-off points.
• Hazard log columns – ID, description, cause, consequence, severity, likelihood, risk rating, mitigation, owner, evidence link, status, review date.
• Safety Case skeleton – claims (what’s safe), arguments (why), evidence (tests/SOPs/training/incidents/assurance).
• Test traceability matrix – hazard → mitigation → test case → result → defect/ret test.
• Risk acceptance form – residual risks, rationale (ALARP), controls, SRO/CSO signatures, review date.

Building capability without derailing delivery

• Appoint a deputy CSO and create cross-cover to avoid single points of failure.
• Shadowing and peer review – Pair new project teams with a Trust/ICB that’s recently delivered a similar system; borrow their hazard seeds and test packs.
• Communities of practice – Join regional digital safety forums, ICS clinical safety groups, and national NHS networks to share patterns and pitfalls.
• After-action reviews – Treat early incidents and near-misses as learning opportunities; feed them straight back into hazard logs and SOPs.

FAQs I’m asked most

Is DCB0160 mandated?

Yes. NHS organisations and those delivering NHS-funded care are expected to comply. It is referenced in NHS England’s standards library and underpins DTAC assessments.

Do we need DCB0160 for minor configuration changes?

Apply a proportionate approach. Use change impact checks to determine whether hazards or mitigations are affected. If yes, update evidence and, where needed, seek CSO review.

Can the supplier’s DCB0129 cover us?

No. 0129 is necessary, not sufficient. You must evidence safety in your local workflows, integrations, data, and training.

Who can be a CSO?

A suitably qualified, registered clinician with appropriate clinical safety training and experience. They must be empowered to challenge delivery timelines where safety is at risk.

Your next move

If you have a digital go-live within the next three months, pull your leads together this week. Nominate the CSO, initiate the Clinical Risk Management Plan, open the hazard log, and schedule the first safety workshop. If your programme is already in flight, baseline your evidence against the list above and close the gaps now — before your readiness meeting does it for you.

If you’d like a rapid, pragmatic review of your DCB0160 posture — or simple templates you can adopt this month — get in touch. Let’s make safe go-live the default, not the exception.