DCB0160 is the NHS clinical risk management standard for organisations deploying and using health IT systems. For GP practices, that means looking beyond supplier assurances and asking a more practical question: is this system safe in the way we actually use it here?
That is the part many practices miss. A supplier can assess their product in general terms, but they cannot assess your exact setup, your local workflows, your integrations, your staffing model, or the workarounds people use when the day gets busy. DCB0160 sits with the deploying organisation because risk is shaped by real-world use, not just by software design.
Why DCB0160 matters in general practice
Digital systems now sit inside almost every part of practice operations: online consultations, triage, patient messaging, prescribing workflows, results handling, appointment routing, document transfer, and increasingly AI-supported tools. That means digital risk is no longer a niche technical concern. It is part of everyday patient safety.
A tool can be safe in principle and still create risk in practice if it is poorly configured, badly understood, or dropped into a workflow without clear controls. Messages can be routed to the wrong place. Urgent information can sit in the wrong queue. Staff can rely on assumptions that do not match how the system really behaves. None of that is necessarily a software defect, but it is still a clinical safety issue.
That is why DCB0160 is not just another compliance document. Done properly, it is a structured way of identifying where digital processes could create harm and showing what the practice has done to reduce that risk.
Two standards, two responsibilities
DCB0129: the supplier’s responsibility
DCB0129 applies to the organisation developing or supplying the system. It looks at the safety of the product itself, including foreseeable hazards in normal intended use.
- Applies to developers and suppliers
- Focuses on product-level safety
- Should produce supplier safety documentation
DCB0160: your practice’s responsibility
DCB0160 applies to the organisation deploying or using the system. It looks at local implementation risk: how the tool works in your own setting, with your staff, processes, integrations, and governance.
- Applies to provider organisations
- Focuses on deployment and real-world use
- Requires local assessment and sign-off
Why supplier assurance does not cover everything
A supplier does not know what happens in your reception workflow at 8:05 on a Monday morning. They do not know which requests get manually redirected, which staff groups can see which queues, how your urgent access model works, or what happens when a process breaks and someone invents a shortcut to keep the day moving.
That matters because those local details shape the real risk. A system may be designed appropriately, but still become unsafe if the wrong people monitor it, if escalation rules are unclear, if patients misunderstand what happens after submission, or if a change to one system quietly affects another.
The practical test: if a digital tool could delay, misroute, lose, distort, suppress, or wrongly influence patient care, it deserves a clinical safety review in its deployed context.
What DCB0160 usually involves
A Clinical Safety Management System
A documented approach to how the organisation manages digital clinical risk, including governance, responsibilities, incident handling, review, and escalation.
A named Clinical Safety Officer
A suitably qualified clinician with oversight of clinical safety work, able to challenge assumptions and review the safety position properly.
Hazard logs
A live record of potential hazards, possible harms, controls, mitigations, and the residual risk that remains after those controls are in place.
A safety case or safety case report
A structured case, supported by evidence, explaining why the deployment is considered safe enough for use in your organisation.
Who should be the Clinical Safety Officer?
In a GP practice, the Clinical Safety Officer is typically a senior registered clinician such as a GP partner, clinical lead, senior nurse, or pharmacist. The key point is not just job title. The person needs enough authority, understanding, and protected time to challenge risks properly rather than simply being named on a document and forgotten.
Training matters too. Clinical risk management is a formal discipline with its own language, structure, and expectations. A CSO should have appropriate training and should remain connected into the practice’s wider governance and learning processes.
What good looks like
- Named CSO with clear ownership
- Appropriate training completed
- Time and support to do the role properly
- Link into governance, incidents, and review
Warning signs
- No named CSO
- Role assigned without training
- No evidence of local safety review
- Assumption that supplier documents are enough
Which systems are likely to be in scope?
Practices often think first about the obvious systems: the main clinical record, prescribing, online consultations, and triage tools. Those are clearly relevant. But DCB0160 often reaches further than people expect.
If a digital process could influence patient care directly or indirectly, it should be considered. That can include patient messaging platforms, inbound webforms, workflow-routing tools, digital document handling, local automations, and integrations between systems. If information can be delayed, redirected, missed, or misunderstood, there is a clinical safety angle to think through.
| Usually clearly in scope | Often overlooked |
|---|---|
| Clinical systems and EHRs | Patient communication tools |
| Online consultation and triage systems | Website forms collecting symptoms or requests |
| Prescribing and medicines workflows | Workflow automation and queue routing |
| Clinical decision support | Digital document and transfer services |
| AI tools influencing care decisions | Local integrations and workarounds |
A simple example: a website form can still create clinical risk
A practice may think of a website form as an admin tool. But once that form starts collecting symptoms, channelling requests into same-day demand, or feeding into triage decisions, it becomes part of a clinical process.
The risk is not hard to imagine. A submission might land in the wrong queue. A patient may believe they have requested urgent help when they have only submitted a message for later review. Staff may assume somebody else is monitoring the inbox. The wording on the form may not make the limitations clear. None of that is dramatic on paper, but it is exactly the kind of real-world risk DCB0160 is there to bring into the open.
Avoid becoming an accidental developer
Practices are very good at finding clever local fixes. The danger is that a “small workaround” can quietly become a locally developed clinical tool without anyone quite noticing.
Spreadsheet macros, scripts, low-code automations, routing rules, and custom integrations can all introduce risk if they affect clinical prioritisation, results handling, treatment actions, or communication pathways. Once you move from using a product to materially shaping how clinical decisions or flows happen, the governance picture gets more complicated very quickly.
A sensible way to get started
- List the digital systems and workflows that could affect patient care.
- Identify which suppliers already provide safety documentation.
- Confirm who will act as Clinical Safety Officer and what training they need.
- Put in place a practical Clinical Safety Management System.
- Start hazard logging with the highest-risk systems first.
- Complete safety case documentation for relevant deployments.
- Review again when systems change, processes change, or incidents expose new risks.
Final thought
The most common mistake with DCB0160 is assuming it belongs entirely to the supplier. It does not. Supplier assurance matters, but it only answers part of the question.
DCB0160 is about your real-world deployment: your choices, your setup, your workflows, your staff, and your controls. Treated properly, it gives your practice a structured, defensible way to show that digital safety has been considered before problems emerge.