What is DCB0129 and why should a pharmacy buyer care?
DCB0129, in full Clinical Risk Management: its Application in the Manufacture of Health IT Systems, is an information standard published under section 250 of the Health and Social Care Act 2012, and it requires organisations that build and maintain health IT systems to run a systematic clinical risk management process across the product's whole life. Its companion, DCB0160, applies the same discipline to the organisations that deploy and use those systems. The current versions were published in 2018, first introduced in 2009, and NHS England describes their purpose plainly: making sure digital health technologies are developed with appropriate safety considerations from design through to delivery.
The reason a pharmacy buyer should care is not procurement bureaucracy; it is the nature of the product. A PMR or clinical platform sits between a prescriber's decision and a patient's medicine: it renders prescriptions into labels, carries dosing directions, queues dispensing, flags duplicates and holds the record clinicians rely on. When software like that fails, wrong data displayed, a direction truncated, a record attached to the wrong patient, the failure is clinical, not technical, and the harm lands on a patient.
"'We test our software' is not the same as 'we have systematically identified how this system could contribute to patient harm'."
DCB0129 exists because of that gap: a supplier who has identified each hazard, mitigated it and documented the residual risk can show you the paperwork. This guide is about asking for it.
The law grew teeth in 2025 and 2026
For most of its life, DCB0129's force was contractual and reputational: NHS procurement demanded it, notably through the Digital Technology Assessment Criteria (DTAC), where it is a core criterion, but the underlying statutory duty on health bodies was only to "have regard to" information standards. That changed in two steps. Section 95 of the Health and Care Act 2022 came into force on 7 July 2025, changing the duty to "must comply" and introducing the Health and Social Care Information Standards (Procedure) Regulations 2025. Then section 121 of the Data (Use and Access) Act 2025 came into force on 5 February 2026, expanding scope so that IT providers themselves can be made subject to a duty of compliance, which moves enforcement beyond contracts and onto suppliers directly, with commencement being phased in.
At the same time, the standards are being revised in the open. NHS England ran eleven focus groups between January and July 2025 with manufacturers, providers, clinical safety officers and industry experts, every one of which supported keeping clinical risk management mandatory, and a public consultation on both standards opened on 29 June 2026 and runs until 11 September 2026, with AI-driven systems and the expanding electronic record estate among the drivers. The buyer's takeaway from all this is simple: clinical safety assurance is moving in one direction, the regulator's own supporting papers say future revisions are likely to leverage the enhanced legal powers, and a supplier who treats DCB0129 as optional is betting your pharmacy against the direction of travel.
What a compliant supplier must actually have
A supplier meeting DCB0129 holds five things, and each is a document or a person you can ask about by name.
- A clinical risk management system with governance arrangements, opened for each product with a clinical risk management plan.
- A named Clinical Safety Officer (CSO): a clinician currently registered with a professional body, trained and competent in clinical safety and risk management, who oversees the process, signs the deliverables and carries personal professional accountability for doing so.
- A hazard log: the structured record of every identified hazard, its clinical impact, the mitigations and controls applied and the residual risk accepted, built using recognised techniques such as structured what-if analysis and functional failure analysis.
- A clinical safety case report: the formal, evidence-backed argument that the system is safe for release, signed off by the CSO.
- A live process after go-live: monitoring, change-triggered reviews when functionality is updated, and clinical incident management feeding back into the hazard log.
NHS England's guidance is explicit that an adopting organisation can request the manufacturer's clinical safety documentation and should be provided with it, so "that's internal" is not a compliant answer to a reasonable request. And compliance is not a certificate issued once: it is maintained for as long as the system is deployed, which is why the questions below ask about updates and incidents, not just documents.
Does this apply to a private pharmacy's software?
The honest answer is: its home territory is NHS and adult social care in England, its reach is growing, and a sensible buyer asks the questions regardless of where the legal line sits today. The standards were written for health IT used across the health and care environment in England, they are enforced hardest through NHS procurement and assurance, and NHS England publishes an applicability flowchart for products where the answer is unclear. The Data (Use and Access) Act extension to IT providers is being phased in through 2026, and the current national review is exactly the kind of moment when scope gets clarified and often widened. A private-only pharmacy operation buying a PMR is therefore in a zone where formal applicability may depend on facts and timing.
But the buyer's practical rule cuts through the scoping debate: DCB0129 is the recognised benchmark of whether a health software supplier takes clinical safety seriously, and the hazards it manages, wrong-patient records, label rendering errors, unsafe defaults, silent data loss, do not check whether the prescription being dispensed is NHS or private before harming someone. The GPhC already expects pharmacies to hold assurance on the third parties their services depend on, and your software is the third party your entire service depends on. Ask the questions. A supplier with good answers will be glad you did, and a supplier without them has told you something more useful than any demo.
The questions to ask your supplier
Put these to any PMR, clinical platform or booking system vendor, in writing, and keep the answers in the procurement file.
| Question | What a good answer contains | Red flag |
|---|---|---|
| Who is your named Clinical Safety Officer, and what is their registration? | A named individual, their professional body and registration number, and their clinical safety training or competence evidence | No named person; "our QA team handles safety"; a CSO nobody can identify |
| Can you provide your clinical safety case report and hazard log summary for the product? | Yes, with the safety case report shared and a hazard log summary relevant to the deployment; NHS England guidance says adopters should be provided with this | Refusal on confidentiality grounds with no summary offered; documents that do not exist yet |
| How do hazards from our workflows appear in your hazard log? | Recognition of pharmacy-specific hazards, labelling, dispensing queues, patient matching, prescriber handoffs, and willingness to discuss how your deployment maps to them | A generic template log with no product-specific hazards; blank looks at "hazard log" |
| What happens to clinical safety when you release updates? | Change-triggered clinical risk review, CSO involvement in release sign-off and a record of safety-relevant changes | "We ship continuously" with no safety review step; updates nobody clinically assesses |
| How do we report a clinical safety incident, and what happens next? | A defined route, triage involving the CSO, feedback into the hazard log and communication to affected customers | Support tickets as the only route; no distinction between a bug and a clinical incident |
| Where does our patient data sit and what happens at exit? | Not strictly DCB0129, but ask alongside: UK data residency, export formats and a portability commitment | Vague hosting answers; no exit route; data ransom by omission |
Red flags in supplier answers
Beyond the table, three patterns should end conversations. The first is the permanently forthcoming compliance: "we are working towards DCB0129" is a reasonable answer from a six-month-old startup and an alarming one from a supplier with live deployments, because the standard applies through the lifecycle, not after traction. The second is the confidentiality wall: a supplier may reasonably protect sensitive technical detail, but NHS England's own guidance establishes that adopting organisations should be provided with clinical safety documentation, so a flat refusal to evidence the safety case is a position taken against the standard's design. The third is the certificate illusion: a supplier waving a document dated three years ago with no change process behind it has a museum piece, not a clinical risk management system, and your five minutes of questions about their last update will expose it.
None of this requires the buyer to become a clinical safety engineer. Every question in this article can be asked by a superintendent in plain English, and the quality of the answers is legible without specialist knowledge, which is precisely why asking them is worth the awkwardness.
Your side of the deal: DCB0160 in proportion
DCB0129 has a mirror, and it faces you: DCB0160 places clinical risk management duties on the organisations that deploy and use health IT, because a safely built system can still be dangerously implemented. For a large trust that means a full deployment safety programme; for a pharmacy it means a proportionate version of the same thinking, and proportionate is the regulator's own word. In practice, a small pharmacy's DCB0160-shaped diligence looks like: naming who is responsible for the safe use of the system, usually the superintendent; risk-assessing the deployment itself, your data migration, your configuration choices, your workflow around the software's gaps; training staff on the system as part of the competence sign-off you already run; and having a route for staff to report anything that looks clinically unsafe, feeding both your incident process and the supplier's.
That list should feel familiar, because it is the same governance discipline the GPhC's standards already demand, applied to the software layer. The inspection question"how do you know this system is safe in your pharmacy" has the same shape as every other inspection question, and the answer lives in the same file.
Putting it in the procurement file
The output of this article is a file, and it belongs next to the third-party due diligence the distance services guidancealready requires for prescribing partners: the supplier's answers to the question set, the CSO's name and registration, the safety case report or its summary, the update and incident processes in writing, and a review date, because supplier assurance decays exactly like every other assurance. Re-ask the questions at contract renewal, after any major product change and whenever the revised standards land, which on current timelines means watching what emerges from the consultation closing 11 September 2026. Ten questions, asked once a year, against the system your entire operation runs on: it is the cheapest clinical risk management your pharmacy will ever do.
Key takeaways
- DCB0129 requires health IT manufacturers to run systematic clinical risk management, with a named registered clinician as Clinical Safety Officer, a hazard log and a clinical safety case report maintained across the product lifecycle.
- The statutory duty hardened from "have regard to" to "must comply" on 7 July 2025, and from 5 February 2026 compliance duties can attach to IT providers directly under the Data (Use and Access) Act 2025.
- Both standards are under live revision, with public consultation open from 29 June to 11 September 2026 and unanimous focus-group support for keeping them mandatory.
- Adopting organisations can request a supplier's clinical safety documentation and, per NHS England guidance, should be provided with it, so refusal is itself an answer.
- The buyer's question set covers the named CSO, the safety case and hazard log, pharmacy-specific hazards, update review and incident handling, and it can be asked in plain English.
- Whether or not a private-only operation sits inside formal scope on a given day, the standard is the benchmark of supplier seriousness, and the hazards do not distinguish NHS from private patients.
- DCB0160 is the buyer's mirror duty: name who owns safe use, risk-assess the deployment, train against the competence matrix and keep a route for reporting unsafe behaviour.
FAQs
Put the questions to us.
We think buyers should interrogate every supplier this way, including us. If you are evaluating Dataforge PMR, bring this article's question set to the demo and put each one to us directly, the CSO question included, and we will answer on the record alongside walking your own service through the platform.
Book a demo