Most Software as a Medical Device (SaMD) teams focus on features. Then an NHS buyer asks: “can you show us your clinical safety case?” and the room goes quiet.
If you want pilots to turn into procurement, you need a credible answer. This week’s Monday Masterclass is a plain-English route from zero to a safety case buyers trust: what DCB0129/0160 are, who does what, the artefacts you need, and how to build them this quarter.
What DCB0129 and DCB0160 are, in practice
Two standards sit behind clinical safety for digital health in the NHS:
- DCB0129: for manufacturers and suppliers. It requires you to set up a clinical risk management system and to produce a safety case before deployment. It is about how you design, build, and assure your product.
- DCB0160: for NHS organisations that deploy, operate, maintain, and decommission digital systems. It is about local clinical risk when your product runs in a real service.
In short: suppliers must evidence DCB0129, NHS providers must evidence DCB0160. Both are expected for any digital system used in care. A Clinical Safety Officer (CSO) is required on both sides. They are a registered clinician with suitable training and they sign the safety case. NHS regions remind teams that this is not optional.
These standards are often checked alongside DTAC during procurement, so treating them as ‘paperwork I can deal with later’ slows you down. Bake clinical safety in from the start and you’ll save yourself headaches later down the line.
Things buyers expect to see
Clinical Safety Officer (CSO). A registered clinician (for example GMC or NMC) who has completed NHS clinical safety training. They own the risk management plan, run hazard identification, sign the safety case, and oversee incident review.
Product and engineering leads. They make sure safety controls are designed, implemented, tested, and traced to hazards. They keep artefacts up to date across releases.
Clinical champion or site lead. They can keep an eye on real world processes and watch out for any issues which occur. Sanity checking whether the controls work in practice.
Governance cadence. A predictable rhythm: pre-release safety review, post-release incident review, documented decisions, and updates to the hazard log and safety case. Real examples show incident intake to the CSO, recording in issue trackers, and escalation to senior management.
Training. NHS England’s Digital Clinical Safety Programme provides tiered training: Essentials for awareness, Intermediate for process activities and deliverables, and Practitioner for those acting as CSOs. It is available via e-learning or workshop delivery.
The core artefacts: what “good” looks like
1) Clinical Risk Management Plan (CRMP).
Scope, responsibilities, methods, scoring, toolchain, and sign-off points. This plan anchors the whole system and tells reviewers how you will manage risk.
2) Hazard log.
Your single source of truth for hazards, causes, consequences, controls, and residual risks. It is a controlled document and must be maintained across the lifecycle. Real project plans state this explicitly and treat the log as a living record.
3) Clinical Safety Case and Safety Case Report.
The narrative that your risks are ALARP: As Low As Reasonably Practicable. It justifies why risks are low enough given benefits and available controls. Safety case reports are issued at deployment and refreshed when things change.
4) Change and incident records.
How you triage issues that could affect patient safety, how you investigate, and how you feed learning back into the hazard log and safety case. NHS-facing examples show a clean loop from incident report to CSO action.
How to do it this quarter: Now → Next → Later
Now (week 0–2): set foundations
- Appoint or contract your CSO. They must be a registered clinician and should complete Practitioner-level training if they will sign off documents. If you need help here drop us an email here, we have clinical safety experts amongst our mentors who will be able to assist you.
- Draft a light CRMP. Define scope, roles, severity/likelihood scales, and how you will record hazards.
- Schedule a one-day hazard workshop. Include engineering, product, clinical, and UX. Real plans call for CSO-led sessions that walk the system, identify failure modes, and capture hazards systematically.
- Cross-check against a practical list. A seven-step approach used by teams covers: appoint CSO, define process, write the plan, identify hazards, maintain the log, produce the safety case, and set up monitoring.
Next (week 3–8): identify, score, control
- Run the workshop and fill the log. Capture hazards across normal, edge, and failure scenarios. Include patient-entered data paths: we have found this is a common blind spot that triggers false alerts if not designed well.
- Score risks and define specific controls. Avoid vague mitigations. Use clear language, keep control statements standalone and testable, and aim for the right level of granularity. Practical guidance warns against short or ambiguous hazard descriptions and generic controls.
- Draft the safety case report. State claims, summarise evidence, present residual risks with an ALARP argument. The safety case explains why further mitigation would be grossly disproportionate compared with the remaining risk.
- Stand up incident routes. Define how safety-related issues reach the CSO, how you record them, and how the log and case will be updated. Ideally use real project examples to show this loop in action.
Later (week 9+): prove and maintain
- Exercise your controls in a live setting. Small pilot, single ward, or one GP practice. Update hazards and evidence based on what happens.
- Bake safety into releases. Pre-release review, post-release incident review, versioned artefacts, CSO sign-off. Keep the hazard log and safety case under document control.
- Map outputs to procurement packs. Index the safety plan, log snapshot, case report, incident process, and training records so they slot into DTAC checks without rework.
- If you already use ISO 14971. Reuse your risk management plan and analyses, but add DCB-specific pieces: the CSO role, clinical safety case, and local deployment considerations that sites will check under DCB0160.
Your evidence pack for NHS due diligence
Making yourself easy to buy is one of the key bits of advice we give to our mentees. Here are some things you can have ready to keep procurement running smoothly.
- CRMP: scope, roles, scoring, methods, sign-offs.
- Hazard log (snapshot): with links to detailed evidence. The working log stays internal, the snapshot goes to buyers.
- Clinical Safety Case Report: with CSO signature and ALARP argument.
- Change and incident process: intake, triage, investigation, update loop to hazards and case.
- Training records: CSO training and team awareness modules.
Map the pack to the clinical safety items in DTAC, and to the site’s DCB0160 checks. Buyers move faster when they can tick boxes with confidence. If you get this right it can actually become a key trust building asset as your buyer sees that you take clinical risk seriously.
Common pitfalls and how to avoid them
- No CSO, or an untrained one. Fix: contract a registered clinician and book Practitioner training. Do not wait until the week before a governance board.
- Thin or messy hazard logs. Fix: write clear hazard statements, use specific controls, and keep the level of detail consistent. Update the log whenever hazards, controls, or evidence change.
- No plan for incidents. Fix: define routes to the CSO, recording in your issue tracker, escalation to senior management for safety-related items, and feedback into the log and case.
- Assuming ISO 14971 alone is enough. Fix: add DCB0129 specifics: the CSO, a clinical safety case report, and explicit governance around deployment and decommissioning that your NHS customers cover under DCB0160.
- Ignoring local context. Fix: work with sites to identify local hazards, integrations, data workflows, and change management. That is the heart of DCB0160.
Toolkit: getting started
We are putting together some toolkits and templates that people can use to kick start their compliance process. If you’d like a copy of or DCB starter kit then drop us an email here and we’ll send over the current version.
Compliance watch: what is changing
There is ongoing work to modernise DCB standards for AI and data-driven technologies. Expect more clarity on adaptive models, monitoring, and transparency. Keep an eye on NHS updates and reputable explainers, and plan to refresh your documents when the guidance shifts. We’ll be doing the same and try to release an update when we hear more.
How this fits your roadmap
If you’ve been following our posts you should already have a ‘Now → Next → Later Plan’. Why not update it with key clinical safety tasks:
- Now: appoint your CSO, write a simple CRMP, schedule the workshop.
- Next: run the workshop, score and control hazards, write the safety case, stand up incident routes.
- Later: prove it in a live setting, bake safety into releases, keep your evidence pack current.
Done well, clinical safety stops being a blocker. It becomes part of how you build trust with clinicians and IT, and it shortens procurement conversations.
Want more like this?
Want the Safety Case Starter Kit (hazard log template, safety case skeleton, release checklist) drop us an email here.
For weekly posts, tools, tips and advice subscribe to Monday Masterclass below. You’ll also get our highly rated free Medtech Founder’s Starter pack, our mentees have found this super useful, and its free… What’s not to love!!
Educational only. This is not legal or regulatory advice. Always check current NHS guidance and your local governance for your product and pathway.