DCB0129 and DCB0160: what pharmacy operators need to know

Two standards, two owners

DCB0129 and DCB0160 are the paired clinical risk management standards issued by NHS England (through the Data Coordination Board) under the Health and Social Care Act 2012. They exist to make sure that health IT does not introduce avoidable clinical risk: that a system doesn't, for example, drop a field from a consultation record or present the wrong patient's notes. The two standards divide that duty between the organisation that builds the software and the organisation that puts it to use.

DCB0129 applies to the software manufacturer: the company that designs and supplies the system. DCB0160 applies to the deploying care organisation: in this case, your pharmacy, which takes the software and uses it to deliver care to patients. They are complementary, not alternatives. A safe deployment needs both halves done, and done by the party that is actually in a position to do them.

What DCB0129 asks of the software supplier

Under DCB0129 the manufacturer has to run a structured clinical safety process across the life of the product. In practice that means three things you can point to. First, a named Clinical Safety Officer, a suitably qualified clinician who is accountable for clinical safety and signs off the work. Second, a hazard log: a living register of the ways the software could contribute to patient harm, each with its likelihood, severity and the controls that reduce it. Third, a clinical safety case report that draws the evidence together and states, with justification, that the system is acceptably safe to release.

The point of DCB0129 is that these are ongoing obligations, not a one-off box-tick. Every material change to the software, such as a new pathway or a change to how notes are captured, is expected to be assessed and the hazard log updated. That is why you should never treat it as a certificate or a logo; there is nothing to frame on the wall, and no product can be described as "approved" on the strength of it.

What DCB0160 asks of your pharmacy

DCB0160 sits with you as the deployer because some risks only appear in the way a system is actually used in your consultation room. Think of local factors the manufacturer can't see: how staff are trained, how the on-site team greets a patient and starts the video call, what happens if connectivity drops mid-consultation, and how you assure yourself the record was captured correctly. DCB0160 asks the deploying organisation to identify and manage those risks in its own hazard log and safety documentation.

Larger groups often appoint their own Clinical Safety Officer or share the role across sites; a single independent pharmacy will usually scope this proportionately to the service it runs. Either way, the deployment safety work builds directly on the supplier's DCB0129 evidence, which is exactly why the two standards are linked. Our superintendent remote consultation checklist sets out the operational side of this in more detail.

Why the deployer depends on the supplier

Here is the connection that matters commercially. A deploying organisation cannot properly complete its DCB0160 assessment unless the supplier has met DCB0129 first, because your safety case has to reference theirs. If the manufacturer hasn't identified the hazards designed into the software, you are left guessing at risks you cannot see. The standards are explicit that a deployer must satisfy itself that its supplier has met DCB0129.

That turns DCB0129 evidence into a straightforward procurement question. Before you commit to any clinical software, including a remote consultation platform, ask the supplier to show you the DCB0129 position. You are not being difficult; you are doing the assurance step the standard expects of you.

What to ask a software supplier for

A short, specific set of questions will tell you where a supplier really stands. Ask for the name and clinical background of their Clinical Safety Officer. Ask whether a hazard log exists and is actively maintained as the product changes. Ask to see, or to be walked through, the clinical safety case report. And ask plainly whether DCB0129 is fully established or still in progress. An honest "in progress, and here is our plan" is more useful than a vague claim of compliance.

Then confirm the supplier will support your side: will they give you the documentation and the hazard information you need to complete your own DCB0160 file, rather than leaving you to reconstruct it? A supplier that treats your DCB0160 as their problem too is a supplier that understands how these standards are meant to work together.

Where Remote Pharmacist sits

We describe our assurance position honestly, because getting this wrong would be exactly the kind of overclaim the standards are designed to prevent. Remote Pharmacist is establishing its DCB0129 practice: the Clinical Safety Officer role, the hazard log and the clinical safety case. That work is in progress, shown as in progress rather than asserted as held. As a pre-launch platform onboarding pilot pharmacies, we would rather tell you where we are than dress up a certificate that doesn't exist.

Alongside that, we are built to support your DCB0160. Because we design for clinical safety from the record outwards, with pathway-aligned notes, an append-only hash-chained audit trail, consent capture and role-based access with multi-factor authentication, we can give you the hazard information and documentation your deployment assessment needs. You can read more on our clinical safety and assurance page, which sets out the DCB0129 and DCB0160 position alongside the wider assurance picture.

How this fits your other assurance duties

DCB0129 and DCB0160 cover clinical risk specifically; they sit next to, and don't replace, your information governance obligations. The NHS Data Security and Protection Toolkit (DSPT) is your annual self-assessment against the National Data Guardian's ten standards, due each 30 June. Registering with the Information Commissioner's Office and paying the data protection fee is a legal duty for any organisation that controls personal data. Cyber Essentials covers the technical basics. Our security overview shows how these pieces relate.

Keep the distinction clear when you review a supplier: DCB0129 is about the software being safe to build and release, DSPT and the ICO fee are about how data is governed, and DCB0160 is the deployment-safety work that only you can sign off. Each has a different owner, and a supplier that blurs them is worth a second look.