What is DCB0160?
DCB0160 is the information standard titled Clinical Risk Management, its Application in the Deployment and Use of Health IT Systems, currently at amendment 25/2018 published on 7 June 2018, and 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 within health and care settings.
A health IT system is defined broadly, as a product used to provide electronic information for health or social care purposes, which may be hardware, software or a combination. A patient medication record system, a clinical decision support tool, a consultation platform and a dispensing system each fall comfortably within that description.
The standard's premise is that software which is safe in one setting may be unsafe in another. The same system deployed into two pharmacies with different workflows, different staffing, different training and different downtime arrangements presents different hazards, and only the deploying organisation is positioned to identify them. DCB0160 therefore places the obligation upon the deployer to assess clinical risk in its own environment, implement controls, and maintain that assessment as circumstances change.
It is worth noting that not every digital tool attracts formal clinical safety assurance. NHS England's own material distinguishes between cases where assurance is suggested or advised and cases where it is mandated, which is a distinction the following sections take seriously rather than glossing over.
What is the difference between DCB0129 and DCB0160?
This is the misconception the whole subject turns upon. A pharmacy asks whether its software is clinically safe, the supplier produces DCB0129 documentation, and everybody proceeds on the understanding that safety has been established. It has not, because the two standards address different risks. DCB0129 binds the manufacturer and addresses hazards arising from how the system is designed and built. DCB0160 binds the deploying organisation and addresses hazards arising from how that system meets a particular workplace, comprising 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, which is the entire reason the second standard exists. The supplier's documentation is a primary input to the deployer's assessment rather than a replacement for it, and 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 warrants an honest answer rather than a confident one, and 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 conventionally enumerated in guidance are NHS trusts, integrated care boards, GP practices, primary care networks and federations. Community pharmacy contractors are not usually named among them, notwithstanding that they provide NHS-funded care under contract.
Whether a particular pharmacy is bound is therefore a question upon which an operator should take specific advice rather than accept a general assurance in either direction, and this article does not purport to resolve it. What can be said with more confidence is that the answer matters less than it appears, for three reasons.
The clinical risk exists irrespective of which standard names the deployer, and a dispensing error caused by a misconfigured system harms a patient whether or not a hazard log was mandated. The GPhC standards separately require that risks associated with providing pharmacy services are identified and managed, which is standard 1.1 and, as our analysis of inspection outcomes shows, among the most commonly failed. And where a pharmacy contracts for NHS services or connects to national systems, clinical safety assurance is increasingly requested as part of wider assurance frameworks irrespective of the underlying mandate.
The practical position for most pharmacies is therefore to follow the process proportionately because it is good practice and because the GPhC standards point the same way, rather than because a definitive answer has been obtained about the mandate.
Who can be a Clinical Safety Officer?
NHS England defines the Clinical Safety Officer as a clinician holding current professional registration who has been trained in clinical risk management and is accountable for clinical safety. Three requirements follow.
Current registration with an appropriate body, comprising 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, which materially reduces the cost and awkwardness of compliance for a pharmacy compared with organisations obliged to recruit externally.
Training through the recognised clinical safety pathway, with the practitioner-level course being the operative qualification, delivered as a workshop and priced at figures reported around £475 for NHS staff and £625 for commercial organisations, which should be treated as indicative and confirmed at the point of booking.
Authority, which is the requirement most often reduced to a formality and should not be. The CSO holds authority to pause or halt a deployment judged unsafe, and an organisation which appoints a CSO whilst reserving go-live decisions to a commercial timetable has appointed a signature rather than 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 which produces them runs in a recognisable sequence, comprising scoping and planning, hazard identification through structured review including the supplier's DCB0129 material, risk assessment of likelihood and severity, implementation of controls, the safety case report, and ongoing monitoring.
The element most frequently mishandled is the last. A hazard log completed for go-live and never revisited describes a system which no longer exists, since software updates, workflows change and staff turn over. The log is a living document, and treating it as a launch deliverable rather than a maintained record is the same failure our SOP guide identifies in procedures which no longer reflect practice.
What hazards should a pharmacy actually assess?
Generic hazard lists are of limited use, and 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 where a patient exists twice.
Clinical decision support behaviour. What alerts fire, what they do not cover, and how alert fatigue is managed, since a system generating many low-value warnings produces staff who dismiss them all, including the one which 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, since 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. Whether the people using the system were trained on the version they are using, and what happens when a locum encounters it for the first time on a Saturday. This hazard belongs to the deployer entirely and no supplier can address it.
What should you ask a software supplier?
Six questions, and the answers to the first two establish quickly 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, since 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 which pushes updates without notifying clinical safety implications has transferred an unassessed change into the deploying organisation's environment, and the hazard log the pharmacy maintains describes the previous version.
This site's publisher builds pharmacy software and maintains its own DCB0129 documentation, which is 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, and a supplier which finds them unwelcome has answered a different and more useful question.
What does compliance cost?
Less than the subject's reputation suggests, provided it is scaled proportionately.
The direct costs comprise the CSO training, reported around £625 for a commercial organisation, and the time to produce the three artefacts, which for a single pharmacy deploying one system is measured in days rather than weeks where the supplier's DCB0129 material is available to work from. Where an external clinical safety consultancy is engaged the cost rises substantially, and for most community pharmacy deployments that is not necessary if a registered pharmacist within the business undertakes the training.
The standard itself contemplates proportionality, in that 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 undertaking the same exercise as a trust deploying a hospital-wide electronic patient record, and producing documentation as though it were is a misallocation rather than a virtue.
What happens if you skip it?
Most organisations do skip it, which is 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, with many thousands in use without it, and 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. There is the patient safety exposure, which is the reason the standards exist. There is the 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 there is the evidential exposure, in that 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, whilst 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, which is ordinarily more of them than expected. Identify who will hold the CSO role, recognising that 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, since that is itself a finding. Run a hazard identification session covering the five categories above with the people who actually use the system, rather than with management alone. And produce the three artefacts proportionately, then schedule the review which keeps them current alongside the other dates in the compliance calendar.
Key takeaways
- DCB0160 governs organisations deploying and using health IT, established under section 250 of the Health and Social Care Act 2012, and addresses risks arising in the local environment rather than in the product.
- A supplier's DCB0129 documentation is an input to the deployer's assessment rather than a substitute, since neither standard discharges the other.
- Whether the standard binds a community pharmacy contractor warrants specific advice, though the GPhC's requirement to identify and manage service risks asks materially the same question irrespective of the answer.
- A GPhC-registered pharmacist may hold the Clinical Safety Officer role subject to recognised training, and that officer must genuinely hold authority to halt an unsafe deployment.
- Three artefacts are required, comprising a risk management plan, a hazard log and a clinical safety case report, with the log maintained rather than closed at go-live.
- Assess hazards where pharmacy risk actually sits, comprising 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 clinical safety implications of updates are communicated, and apply them to this site's publisher on the same terms.
FAQs
Safe in your pharmacy.
Disclosure repeated: Our publisher builds Dataforge PMR and maintains its own DCB0129 documentation, which we share with deploying pharmacies as an input to their DCB0160 assessment rather than as a replacement for it. Put the six questions above to us on the same terms as to anyone else.
See Dataforge PMR