What is DCB0160?
DCB0160 is the information standard titled Clinical Risk Management, its Application in the Deployment and Use of Health IT Systems. It is currently at amendment 25/2018, published on 7 June 2018, and was established under section 250 of the Health and Social Care Act 2012. It applies to organisations responsible for deploying, using, maintaining or decommissioning health IT systems in health and care settings.
A health IT system is defined broadly: a product used to provide electronic information for health or social care purposes, whether hardware, software or a combination. A patient medication record system, a clinical decision support tool, a consultation platform and a dispensing system all fall comfortably within that description.
The standard's premise is that software safe in one setting may be unsafe in another. The same system deployed into two pharmacies — different workflows, staffing, training and downtime arrangements — presents different hazards. Only the deploying organisation is positioned to identify them. DCB0160 therefore puts the obligation on the deployer: assess clinical risk in your own environment, implement controls, and keep that assessment current as circumstances change.
Not every digital tool attracts formal clinical safety assurance. NHS England's own material distinguishes cases where assurance is suggested or advised from cases where it is mandated. The following sections take that distinction seriously rather than glossing over it.
What is the difference between DCB0129 and DCB0160?
This is the misconception the whole subject turns on. A pharmacy asks whether its software is clinically safe, the supplier produces DCB0129 documentation, and everybody proceeds as if safety has been established. It has not, because the two standards address different risks. DCB0129 binds the manufacturer and covers hazards in how the system is designed and built. DCB0160 binds the deploying organisation and covers hazards in how that system meets a particular workplace: the workflow it is dropped into, the staff who use it, the training they received, the other systems it connects to, and what happens when it stops working on a Friday afternoon. A manufacturer cannot foresee those. That is the entire reason the second standard exists. The supplier's documentation is a primary input to the deployer's assessment, not a replacement for it. A pharmacy holding a supplier's hazard log and nothing else has evidence about the product and none about its own use of it. The two are parallel obligations. Neither discharges the other.
Does DCB0160 apply to community pharmacy?
This deserves an honest answer rather than a confident one. The honest answer has two parts.
The standard is expressed to apply to organisations deploying and using health IT within health and care settings, and the mandate flows from section 250 of the 2012 Act. The organisation types usually listed in guidance are NHS trusts, integrated care boards, GP practices, primary care networks and federations. Community pharmacy contractors are not usually named among them, even though they provide NHS-funded care under contract.
Whether a particular pharmacy is bound is therefore a question for specific advice, not for general assurance in either direction. This article does not claim to resolve it. What can be said with more confidence is that the answer matters less than it appears, for three reasons.
First, the clinical risk exists whichever standard names the deployer. A dispensing error caused by a misconfigured system harms a patient whether or not a hazard log was mandated. Second, the GPhC standards separately require that risks associated with providing pharmacy services are identified and managed. That is standard 1.1 and, as our analysis of inspection outcomes shows, among the most commonly failed. Third, where a pharmacy contracts for NHS services or connects to national systems, clinical safety assurance is increasingly requested as part of wider assurance frameworks, whatever the underlying mandate.
The practical position for most pharmacies is therefore to follow the process proportionately. Do it because it is good practice and because the GPhC standards point the same way — not because a definitive answer about the mandate has been obtained.
Who can be a Clinical Safety Officer?
NHS England defines the Clinical Safety Officer as a clinician with current professional registration, trained in clinical risk management and accountable for clinical safety. Three requirements follow.
Current registration with an appropriate body: the GMC for doctors, the NMC for nurses and midwives, the HCPC for allied health professionals and, directly relevant here, the GPhC for pharmacists. A superintendent pharmacist is therefore eligible to hold the role. That materially cuts the cost and awkwardness of compliance compared with organisations that must recruit externally.
Training through the recognised clinical safety pathway. The practitioner-level course is the operative qualification, delivered as a workshop. Reported prices are around £475 for NHS staff and £625 for commercial organisations — treat these as indicative and confirm them at booking.
Authority — the requirement most often reduced to a formality, and it should not be. The CSO holds authority to pause or halt a deployment judged unsafe. An organisation that appoints a CSO while reserving go-live decisions to a commercial timetable has appointed a signature, not a safety officer.
What documents does DCB0160 require?
| Artefact | What it contains | When |
|---|---|---|
| Clinical Risk Management Plan | Scope of the deployment, the clinical environment, governance arrangements and the CSO appointment | Before hazard work begins |
| Hazard Log | Each identified hazard with likelihood, severity, initial rating, controls and residual risk | Built during assessment, maintained thereafter |
| Clinical Safety Case Report | The evidenced argument that the system is acceptably safe in its intended context, with rationale for accepting residual risk | Signed by the CSO before go-live, approved by senior management |
| Incident and near-miss monitoring | Clinical incidents arising from the system, feeding back into the log and report | Continuous after deployment |
The process that produces them runs in a recognisable sequence. Scope and plan. Identify hazards through structured review, including the supplier's DCB0129 material. Assess likelihood and severity. Implement controls. Write the safety case report. Then monitor on an ongoing basis.
The element most often mishandled is the last. A hazard log completed for go-live and never revisited describes a system that no longer exists — software updates, workflows change and staff turn over. The log is a living document. Treating it as a launch deliverable rather than a maintained record is the same failure our SOP guide identifies in procedures that no longer reflect practice.
What hazards should a pharmacy actually assess?
Generic hazard lists are of limited use. A pharmacy assessing its own deployment should reason from where its clinical risk genuinely sits. Five categories cover most of it.
Identification and matching. Whether the system can attach the wrong record to the wrong patient, how similar names and dates of birth are handled, and what happens when a patient exists twice.
Clinical decision support behaviour. What alerts fire, what they do not cover, and how alert fatigue is managed. A system generating many low-value warnings produces staff who dismiss them all — including the one that mattered.
Data transfer and integration. What crosses between systems, what does not, and whether a gap is visible to the user or silent. Silent failure is the hazard, because staff cannot compensate for something they cannot see.
Downtime and degradation. What happens when the system is unavailable, whether the fallback is documented and practised, and how records created during downtime re-enter afterwards. This is consistently the least prepared area and the one most likely to be tested in reality.
Training and competence at the point of use. Were the people using the system trained on the version they are using? What happens when a locum encounters it for the first time on a Saturday? This hazard belongs entirely to the deployer, and no supplier can address it.
What should you ask a software supplier?
Six questions. The answers to the first two quickly establish whether the supplier has done the work.
Does DCB0129 documentation exist for this product, and may we see it? Who is your Clinical Safety Officer, and is their professional registration current? What residual hazards have you recorded and explicitly passed to the deploying organisation? Those become ours to control. How does the system behave when it fails, and what degraded modes exist? What support do you provide to our own DCB0160 assessment, and is it included or chargeable? And how are clinical safety implications of updates communicated to us before they are deployed?
The last question repays particular attention. A supplier that pushes updates without flagging their clinical safety implications has transferred an unassessed change into the deploying organisation's environment. The hazard log the pharmacy maintains then describes the previous version.
This site's publisher builds pharmacy software and maintains its own DCB0129 documentation — disclosed here rather than left implicit. A pharmacy should put these six questions to this publisher on precisely the same terms as to any other supplier. A supplier that finds them unwelcome has answered a different, more useful question.
What does compliance cost?
Less than the subject's reputation suggests, provided it is scaled proportionately.
The direct costs are the CSO training, reported around £625 for a commercial organisation, and the time to produce the three artefacts. For a single pharmacy deploying one system, that time is measured in days rather than weeks where the supplier's DCB0129 material is available to work from. Engaging an external clinical safety consultancy raises the cost substantially. For most community pharmacy deployments it is not necessary, if a registered pharmacist within the business undertakes the training.
The standard itself allows for proportionality: the scale and complexity of the documentation should reflect the size and risk profile of what is being deployed. A pharmacy deploying a booking module is not doing the same exercise as a trust deploying a hospital-wide electronic patient record. Producing documentation as though it were is a misallocation, not a virtue.
What happens if you skip it?
Most organisations do skip it — worth stating plainly rather than pretending otherwise. Research cited in this field has found that only a small minority of digital health technologies in use across NHS England carry documented assurance against the clinical safety standards. Many thousands are in use without it. Commentators have identified the resulting exposure in terms of patient risk, organisational capacity and legal consequence where harm occurs.
For a pharmacy the exposure takes three forms. Patient safety exposure — the reason the standards exist. Regulatory exposure, through the GPhC's requirement to identify and manage risks associated with pharmacy services, which does not mention DCB0160 and asks the same question. And evidential exposure: an organisation investigating an incident caused by a system will ask what assessment was performed before deployment, and an absence of documentation is answered by memory.
The asymmetry is familiar from elsewhere in this library. The work is modest and predictable, while its absence becomes apparent at the least convenient moment.
Where should a pharmacy start?
Five steps, in order, none requiring external assistance for a typical deployment.
Establish which systems in the pharmacy are health IT systems within the definition — usually more of them than expected. Identify who will hold the CSO role; a GPhC-registered pharmacist within the business qualifies, subject to training. Obtain the DCB0129 documentation from each supplier, and record where it does not exist, because that is itself a finding. Run a hazard identification session covering the five categories above with the people who actually use the system, not management alone. And produce the three artefacts proportionately, then schedule the review that keeps them current alongside the other dates in the compliance calendar.
Key takeaways
- DCB0160 governs organisations deploying and using health IT, under section 250 of the Health and Social Care Act 2012. It addresses risks arising in the local environment, not in the product.
- A supplier's DCB0129 documentation is an input to the deployer's assessment, not a substitute. Neither standard discharges the other.
- Whether the standard binds a community pharmacy contractor warrants specific advice. Either way, the GPhC's requirement to identify and manage service risks asks materially the same question.
- A GPhC-registered pharmacist may hold the Clinical Safety Officer role, subject to recognised training. That officer must genuinely hold authority to halt an unsafe deployment.
- Three artefacts are required: a risk management plan, a hazard log and a clinical safety case report. The log is maintained after go-live, not closed.
- Assess hazards where pharmacy risk actually sits: patient identification, alerting behaviour, silent integration failures, downtime arrangements and competence at the point of use.
- Ask suppliers six questions, including who their Clinical Safety Officer is and how the safety implications of updates are communicated. Apply them to this site's publisher on the same terms.
Sources and further reading
FAQs
Safe in your pharmacy.
Disclosure repeated: our publisher builds Dataforge PMR and maintains its own DCB0129 documentation. We share it with deploying pharmacies as an input to their DCB0160 assessment, not as a replacement for it. Put the six questions above to us on the same terms as to anyone else.
See Dataforge PMR