A vendor's presentation can make a new triage or booking tool look straightforward. Then the Clinical Safety Officer asks for the DCB0129 evidence, the local team starts discussing escalation routes, and the apparent procurement decision becomes a safety governance exercise.
That's the right point at which to slow down. What DCB0129 and DCB0160 mean for GP practice software is not that a supplier needs a certificate. The two standards create a two-stage safety gate. The supplier must evidence that the product is safe by design, while the practice, federation or ICB must show that it's safe in its own workflows and deployment context.
The Procurement Moment Every Practice Now Faces
The familiar meeting has two documents open. On one side is the supplier's assurance pack, with a reassuring statement that the product meets DCB0129. On the other is the practice's governance checklist, which asks a harder question: what does the practice itself need to assess before patients can use the system?
That distinction matters particularly for software that automates triage, routing or booking. A practice isn't only buying functionality. It's introducing new data flows, changing how requests reach staff, and potentially removing a manual decision point from the pathway. Those changes can create local hazards that a supplier cannot fully identify from outside the practice.
NHS England describes DCB0129 as the standard for manufacturers and developers, designed to help them evidence the clinical safety of their products. DCB0160 applies to the health organisation implementing and using the system, requiring assurance that the software is safe in its local deployment context. NHS England's clinical safety assurance guidance sets out this supplier-side and adopter-side split.
Practical rule: A DCB0129 dossier supports procurement. It doesn't replace the practice's DCB0160 work.
The legal position is important. Compliance with both standards is mandatory under the Health and Social Care Act 2012, so the decision isn't equivalent to purchasing ordinary administrative software. The two questions for the meeting are clear: what does the supplier have to provide, and what must the practice produce before and after deployment?
What DCB0129 Requires of a Software Supplier
DCB0129 is the NHS clinical risk management standard for the manufacture of health IT systems. NHS England says it provides requirements for organisations responsible for developing and maintaining health IT systems used in health and care settings, and is designed to help manufacturers evidence the clinical safety of their products. The DCB0129 standard is therefore about the supplier's design, development and maintenance responsibilities.
A serious supplier should be able to provide more than a sentence saying “DCB0129 compliant”. The practice should expect a usable evidence pack that allows its own clinical safety work to begin.
That pack should make the following visible:
- Hazard log: A controlled record of foreseeable clinical hazards, their causes, consequences and mitigations.
- Clinical safety case: A structured argument explaining the safety controls and any residual risks associated with the product's intended use.
- Named clinical safety oversight: Clear identification of the supplier's Clinical Safety Officer and the person responsible for maintaining the safety process.
- Lifecycle controls: A documented approach to safety issues, incidents, releases, maintenance and changes to the product.
The point isn't to collect paperwork for its own sake. The practice needs to understand which controls are built into the product, which controls depend on configuration, and which risks transfer to the deploying organisation. A generic compliance statement can't answer those questions.
DCB0129 and DCB0160 were first introduced in 2009, and the current versions, DCB0129 v4.2 and DCB0160 v3.2, were published in 2018. These details are recorded in NHS England's supporting information for the national review. The standards have therefore been part of NHS digital safety governance for years, rather than being a new procurement hurdle.
What DCB0160 Requires of the Practice Using the Software
DCB0160 is the NHS clinical risk management standard for the deployment and use of health IT systems. The obligation sits with the health organisation using the technology, not with the vendor. NHS England's DCB0160 guidance covers implementation, use, maintenance and decommissioning.
For a practice, that means the supplier's evidence is an input to local assurance. It isn't the local assurance itself.
The practice, federation or ICB needs to own the deployment-side record. That normally means establishing:
- A local hazard assessment that reflects the practice's actual workflow, patient access routes, interfaces and escalation arrangements.
- A local clinical safety case showing that the supplier's controls remain effective in the intended environment.
- Named clinical safety oversight on the adopter side, with clear responsibility for decisions and sign-off.
- Change and monitoring controls covering configuration changes, pathway changes, upgrades, incidents and emerging hazards.
The local context is where otherwise sound product controls can fail. A triage route may work as designed but interact differently with appointment templates, reception processes or escalation arrangements at a particular practice. The practice owns the assessment of those interactions because the supplier can't see every local dependency.
NHS England says an implementing organisation can request, and should be provided with, the supplier's DCB0129 documentation. The NHS clinical risk management standards page also confirms the mandatory status of the standards under the Health and Social Care Act 2012.
The practical burden rises with the system's clinical influence. A tool that automates decisions across reception, triage and booking requires more careful local evidence than a system that merely stores information. DCB0160 is the practice's proof that the deployment is safe in use, not a declaration that the vendor's product is safe everywhere.
How Automated Triage Tightens the Safety Obligations
Automation changes the shape of the safety question. In a manual GP-led triage model, a clinician reviews the request and makes the decision. In an autonomous model, the practice must demonstrate how the system behaves when the presentation is routine, ambiguous, urgent or outside the expected pathway.
The local safety case should address operational behaviour, not just product features:
- Override behaviour: Who can override an automated outcome, under what circumstances, and how is that action recorded?
- Escalation pathways: How are red-flag or high-priority presentations directed to the appropriate human response when no person is reading every incoming request?
- Exception handling: What happens when information is incomplete, contradictory or outside the configured pathway?
- Post-deployment monitoring: How does the practice identify incidents, near misses, unexpected routing or risks introduced by configuration changes?
The contrarian point is simple. Removing a manual triage step doesn't remove the DCB0160 burden. It can increase the need for evidence because the practice must show that the absence of that human step hasn't created a new failure mode.
This is an active area of regulatory attention. NHS England launched a 2026 review of DCB0129 and DCB0160 to assess whether the standards still fit modern digital health technologies and deployment models, as recorded in the published DCB0160 review information. Buyers should treat the standards as live governance requirements, not static procurement language.
A supplier serious about DCB0129 should make the handover practical. Its dossier should give the practice enough detail to identify transferred controls, local assumptions and questions for the DCB0160 assessment.
Who Owns What Across the Two Standards
The distinction is easiest to use when it's written as a meeting checklist.
| Obligation | Owner | Key artefacts | Lifecycle stage |
|---|---|---|---|
| DCB0129 | Supplier or manufacturer | Product hazard log, clinical safety case, named supplier clinical safety oversight and lifecycle safety process | Design, development, maintenance and supplier release activity |
| DCB0160 | Health organisation, such as the practice, federation or ICB | Local hazard assessment, local clinical safety case, named adopter-side oversight and deployment monitoring process | Deployment, use, maintenance, change and decommissioning |
| Joint go-live check | Supplier and health organisation | Review of supplier evidence against local hazards, controls, escalation routes and outstanding residual risks | Before go-live and whenever material changes require reassessment |
The table should be read line by line. If the supplier owns an artefact, the practice should request it. If the health organisation owns it, the practice can't delegate the responsibility just because the vendor has supplied a full dossier.
A Practical Compliance Checklist for a Practice Deployment
Use the following sequence in the procurement and governance meeting:
- Before procurement: Request the DCB0129 dossier, identify the supplier's Clinical Safety Officer and confirm which standard version the evidence addresses.
- During evaluation: Compare the supplier hazard log with the practice's workflow, integration points and escalation routes. Record local risks the supplier can't assess remotely.
- At go-live: Complete the local hazard assessment, approve the practice-side clinical safety case and confirm named clinical safety oversight.
- After deployment: Record overrides and safety concerns, monitor incidents and review the safety case after configuration, pathway or product changes.
The practice should also confirm how the tool interacts with the practice's clinical system and what information is transferred into the booking record. This is a workflow assurance question, not a request for the supplier to claim that it reads full patient records, supports SNOMED coding or creates tasks directly in clinical systems.
Any supplier worth the practice's time will provide its side of the evidence in a form that supports this checklist. The practice still has to apply that evidence locally and retain its own decisions.
What This Means for Choosing Triage Software
The standards don't choose between manual reception triage, manual GP-led triage, form-based online consultation, AI-assisted triage and autonomous AI triage. They do require the organisation and supplier to understand the safety consequences of the chosen model.
For GP practice software, the central distinction is whether a human still makes each triage decision. AI-assisted triage can improve the information presented to staff while leaving the decision with a human. Autonomous AI triage removes the manual triage step, so the local safety case must examine the controls around automated routing, booking, exceptions and escalation.
That doesn't make one model automatically safe and another automatically unsafe. It means the evidence must match the operational reality. A practice adopting an automated pathway needs to test how local overrides work, how urgent presentations reach staff and how safety learning is fed back into monitoring and change control.
GP Triage is an autonomous AI triage and booking platform for NHS primary care, regulated by Infermedica as a Class 2B medical device and built with NHS England and Microsoft. It supports adult and paediatric presentations, integrates with the major UK clinical systems and pushes a triage summary into the booking record. To date, zero recorded clinical safety incidents across approximately two million triages and around 97% concordance with GP decision-making are the stated safety performance figures, not guarantees. The GP Triage service should still be assessed through the practice's own DCB0160 process.
The sensible procurement test is therefore documentary and operational. Ask the supplier to walk through the DCB0129 dossier beside the evidence required for local deployment, rather than treating compliance as a one-off certificate.
GP Triage can walk your practice through its supplier-side DCB0129 documentation and the evidence needed for local DCB0160 assurance. Visit GP Triage to arrange a practical demonstration focused on your workflows, escalation pathways and go-live governance.
