Most UK telehealth platforms have never heard of DCB0129 until an NHS commissioner or enterprise partner asks for it. By then it is usually a procurement blocker rather than a design choice, which is the wrong way round: clinical risk management is meant to shape how a platform is built, not get bolted on afterwards to pass a checklist.
What DCB0129 and DCB0160 actually are
DCB0129 and DCB0160 are NHS England clinical risk management standards, successors to the safety framework built after early NHS IT programmes ran into trouble. They exist because software used in a clinical pathway can cause harm in ways that have nothing to do with data breaches or downtime: a dosing calculator with a rounding error, a triage flow that lets a red-flag symptom slip through, a referral that silently fails to send.
DCB0129 applies to the manufacturer, the organisation building and supplying the health IT system. DCB0160 applies to the deploying organisation, the clinic or service actually putting that system in front of patients. A telehealth brand that both builds its own platform and runs the clinical service sits under both standards at once, which is common in this market and often missed.
The DTAC and where it sits in NHS commissioning
The Digital Technology Assessment Criteria, DTAC, is the baseline gate NHS commissioners use before adopting a digital health product, whether that is an ICB, a GP practice, or an NHS trust. It checks five areas: clinical safety, data protection, technical security, interoperability, and usability and accessibility. A completed DCB0129 clinical safety case is one of the documents a supplier submits under the clinical safety criterion.
DTAC is a gate, not a full assurance programme in its own right. Passing it gets a product onto a shortlist; it does not replace the ongoing obligations under DCB0129 and DCB0160 once the system is live. Operators who treat DTAC as a one-time form to complete for a single NHS deal tend to find the underlying safety case has gone stale by the next review.
The Clinical Safety Officer: a role most platforms haven't filled
Both standards require a named Clinical Safety Officer, a registered clinician (commonly a doctor, nurse or pharmacist) who has completed recognised training in clinical risk management and formally signs off the safety case and hazard log. It cannot be an unnamed committee or a general reference to "clinical governance", and it is a specific accountability, distinct from the superintendent pharmacist's responsibilities under GPhC rules.
In practice, many platforms either leave the role unfilled, assign it to someone without the training, or hand it to a clinician who has no real authority to block a release on safety grounds. All three fail the standard in the same way: on paper the box is ticked, but nobody with the right knowledge and leverage is actually reviewing changes before they ship.
A clinical safety case that was accurate on the day it was written and has not been touched since is not a safety case, it is a historical document. The standard requires a live hazard log tied to every material change, reviewed by a named, trained Clinical Safety Officer with real authority to block a release.
Building and maintaining a hazard log
A hazard log is a living register of everything that could plausibly go wrong clinically because of the software, scored for likelihood and severity, with a documented mitigation for each entry. It is built once at the start, then updated with every material change: a new triage question, an altered dosing display, a changed referral trigger, a new integration with an external system.
The mistake that causes the most trouble later is treating the hazard log as an annual paperwork exercise rather than a release gate. Good practice looks like:
- A hazard review before any change that touches a clinical pathway, not just before major releases
- Each hazard mapped to a specific mitigation, not a general statement of intent
- The Clinical Safety Officer's sign-off recorded against the specific version being released
- Incidents and near-misses fed back into the log, closing the loop between what happens in production and what the paperwork says could happen
Who actually needs this: NHS-facing platforms vs purely private ones
A purely private-pay telehealth service with no NHS commissioning relationship is not legally required to hold a DCB0129 or DCB0160 safety case; these are NHS England standards, not a general statutory requirement enforced across every private digital health product. Many private operators run without one and are not in breach of anything by doing so.
The requirement becomes real the moment a platform touches an NHS-adjacent pathway: supplying into Pharmacy First referral routes, integrating with the NHS App or GP Connect, or entering an NHS partnership of any kind. It is also increasingly expected informally: enterprise white-label partners, insurers and investors doing due diligence now ask for a clinical safety case even where nothing legally compels one, treating it as a proxy for how seriously the platform takes clinical risk generally.
DTAC gets a product onto the shortlist. DCB0129 and DCB0160 are what keep it safe to use after that, and they do not stop being relevant once the deal is signed.
Where this goes wrong
The most common failure is a safety case written once for a DTAC submission and never touched again, while the underlying software keeps changing. The document describes a version of the platform that no longer exists, which defeats the entire purpose: the whole point is that the paperwork tracks the live risk, not a historical snapshot.
The second common failure sits next to API and integration work: a new third-party connection is treated purely as a technical and data protection question, run through a DPIA and an information governance checklist, with nobody asking whether the integration itself introduces a new clinical hazard, such as a referral that can silently fail to arrive. Clinical risk and information risk are related but not the same review, and one is not a substitute for the other. This sits alongside, rather than inside, questions about whether a given feature counts as a medical device under the MHRA's software rules, which is a separate assessment with its own trigger points.
How PExpo supports this
PExpo's role is the regulated dispensing and telehealth infrastructure layer, not the clinical safety case itself; that accountability sits with whichever organisation is building and deploying the patient-facing software. What PExpo does is keep the parts it controls, dispensing workflows, prescription handling, and the operational data that feeds a brand's clinical pathway, built on processes that are already documented, auditable and reviewed as they change.
For a brand assembling its own DCB0129 or DCB0160 case, or working through a DTAC submission ahead of an NHS-adjacent partnership, that means the infrastructure underneath the clinical software is not the unknown variable in the hazard log. Brands considering that kind of partnership can see how the pieces fit on the brands page, and clinics evaluating dispensing partners on the clinics page.
Most private UK telehealth platforms will never need a formal DCB0129 or DCB0160 safety case, because they never touch an NHS-commissioned pathway. The ones that do, or that want to be ready for enterprise and investor due diligence that increasingly assumes one exists, are better placed treating it as a design discipline from the start rather than a document produced under deadline for a single procurement. See how CQC's own inspection framework handles governance for the parallel regulatory angle, and PExpo's pricing for how the infrastructure layer fits into a launch budget.
Frequently asked questions
Do all UK telehealth platforms need a DCB0129 clinical safety case?
No. DCB0129 and DCB0160 are NHS England standards that apply when a platform builds or deploys health IT connected to NHS-commissioned pathways. A purely private-pay service with no NHS integration is not legally required to hold one, though some adopt the discipline voluntarily as good practice.
Who can be a Clinical Safety Officer?
A registered clinician, commonly a doctor, nurse or pharmacist, who has completed recognised training in clinical risk management for health IT. The role carries formal accountability for reviewing and signing off the safety case and hazard log, and it cannot be assigned to an unnamed team or a clinician without that training.
What is the difference between DTAC and DCB0129?
DTAC is the baseline assessment NHS commissioners use to evaluate a digital health product before adopting it, covering clinical safety, data protection, security, interoperability and usability. DCB0129 is one of the underlying standards a supplier's clinical safety case must satisfy to meet DTAC's clinical safety criterion; DTAC is the gate, DCB0129 is part of what gets you through it.
