Summary
Earlier this year, NHS England ran a national review of the clinical risk management standards DCB0129 and DCB0160: the two standards that govern how health IT systems are assessed for safety before and during use.[1]
In this blog, Clive Flashman, Patient Safety Learning's Chief Digital Officer, summarises his response to that review. His central argument is that the standards are the right instrument and should not be replaced, but that in practice they have been reduced to a documentation exercise completed to satisfy procurement. Three things would change that:
Putting patients inside the framework rather than outside it.
Connecting digital safety incident data to national learning through the Learning from Patient Safety Events (LFPSE).
Giving clinical safety officers the time, authority and protection their role has never had.
Content
Why these two standards matter
DCB0129 applies to the manufacture of health IT systems.[2] DCB0160 applies to their deployment and use. [3] Between them they require a named clinical safety officer (CSO), a hazard log, a clinical safety case and a documented decision about what residual risk an organisation is prepared to accept on behalf of its patients.
They are, in my view, the right instrument. No alternative offers what they uniquely provide: a health and care-specific framework, contextualised to the NHS and to social care, whose organising concept is harm to the patient rather than conformity of a product.
ISO 14971, IEC 62304 and ISO 81001-1 are valuable, and the revised standards should be explicitly mapped to them so that manufacturers are not producing the same evidence twice. But those standards were designed around the manufacture and lifecycle of a product. They do not address local configuration, workflow redesign, training, interoperability with a legacy estate or the organisational decisions that determine whether a technically safe product is used safely. Replacing DCB0129 and DCB0160 now would also destroy 15 years of accumulated infrastructure, including trained CSOs, hazard logs, safety cases and a shared vocabulary, at precisely the moment when patients' dependency on digital systems is greatest.
My concern is not that the standards are the wrong instrument. It is that too often they are treated as paperwork to unblock a go-live. The answer is not a different standard. It is a strengthened, better-enforced and more transparent version of these ones.
Patients appear only as the object of risk
This is the largest single gap, and it is the one I expressed my views on most forcefully.
As drafted, neither standard mentions patients or the public as participants anywhere. Patients appear only as a component of the risk. They are not consulted in hazard identification. They are not represented in risk evaluation. They are not told what risks have been accepted on their behalf. And there is no route for them to report a digital safety concern at all. A framework whose entire purpose is protecting patients has been built without them.
I proposed three changes:
Involvement. Patients, service users and carers should be involved in hazard identification and risk evaluation for higher-risk systems, through Patient Safety Partners, existing patient groups, condition-specific charities and user research. Patients and carers see failure modes that clinicians might not. Patients are the only people present at every stage of their own care, and they are the most under-used source of safety intelligence in the NHS.
Transparency. Clinical Safety Case Reports are currently shared only between supplier and deploying organisation. There is no requirement to publish anything, to any patient, ever. I proposed a published, plain-English Clinical Safety Summary for systems above a defined risk tier: what the system does, the principal hazards identified, the residual risks accepted, who accepted them and how to raise a concern. Commercially sensitive implementation detail and exploitable security information can be excluded. Transparency also improves the underlying work, because safety cases written in the knowledge they may be read externally are better safety cases.
A route to raise a concern. If a patient sees the wrong information in their record, receives an incorrect automated message or is harmed by a failed digital process, there is no obvious reporting channel for them.
Safety incident data that goes nowhere
Every manufacturer and every organisation maintains its own Safety Incident Management Log. There is no requirement to aggregate or share them, and no route into LFPSE. Therefore, there is no national picture of digitally related harm, and the same hazard is rediscovered independently, repeatedly, across hundreds of organisations. This is the single biggest missed opportunity for learning in the current framework.
Digital clinical safety and patient safety have grown up as two separate professions. They use different language: hazard log versus risk register, clinical safety case versus patient safety incident investigation. They use different reporting systems: the Safety Incident Management Log versus LFPSE. They have different governance routes and different professional networks. They are managing the same thing, avoidable harm to patients, and they barely speak to one another.
I suggested that the incident systems be connected in both directions: safety incidents recorded under the standards flowing into LFPSE in a structured, tagged format, and digitally related incidents in LFPSE flowing back to the relevant CSO and supplier. I also proposed that 'digital' becomes a named consideration in the Patient Safety Incident Response Framework (PSIRF) learning responses, and for CSOs to be recognised within the patient safety specialist community rather than sitting solely within IT, where safety gets framed as a delivery risk rather than a harm risk.
Readers of my recent blog on the National Commission into the Regulation of AI in Healthcare will recognise the pattern. [4] That report, too, made no mention of LFPSE. Digital harm keeps being designed out of the systems built to learn from harm.
The CSO role is the best thing these standards promote
I said emphatically that the CSO requirement should remain. It creates a named individual with clinical judgement who is accountable for asking whether a system will harm patients, and who has the standing to say no. Remove it and clinical safety becomes a distributed responsibility, which in practice means it is nobody's.
The problem has never been that the role exists. It is that too many CSOs hold the title without the time, authority, training or organisational backing to discharge it. The current definition runs to four sentences. It gives no statement of authority, no expectation of protected time, no assessable competency framework, no independence requirement, no handover arrangements and no defined relationship with the organisation's patient safety function.
I asked for: protected time proportionate to the organisation's digital estate; a direct route of escalation to the board; explicit protection for a CSO who raises a concern or withholds sign-off; a rule that sign-off cannot be overridden without a recorded board-level decision entered in the safety case; a national competency framework; and a national register of CSOs.
The other things I argued for
The standards should apply to medical devices. UKCA marking and MHRA regulation assure a device as designed and as placed on the market. Neither assures how it behaves once configured, integrated and used in a specific setting by a specific workforce. Patients do not experience the distinction between device regulation and information standards. Any gap between the two regimes is a gap in their protection.
Cyber risk is a clinical hazard. A cyberattack that removes access to clinical records is a patient safety event, not merely an IT event. The 2024 Synnovis ransomware attack was linked by NHS data to almost 600 patient safety incidents, and King's College Hospital confirmed a patient death to which a delayed blood test result caused by the attack was a contributing factor. I am not arguing that these should become cybersecurity standards. I am arguing that the clinical consequence assessment belongs in the safety case.
AI needs to be in the standard, not just the guidance. The current standards were written for deterministic software. They are far less relevant to systems whose behaviour changes over time. The system that was assessed may not be the system in use if the model has 'drifted'. Automation bias means the human-in-the-loop mitigation on which almost every AI safety case relies is far weaker than assumed.
Accessibility should be mandatory, not optional. A system that performs adequately on average can be systematically dangerous for a subgroup. If a system is safe for most people and unsafe for some, it is unsafe. Making this optional guarantees it will be done by organisations that were going to do it anyway, which means the burden falls on the populations already experiencing the worst outcomes.
Compliance is now a choice. Section 95 of the Health and Care Act 2022 changed the duty from "have regard to" to "must comply", and section 121 of the Data (Use and Access) Act 2025 extends the duty to IT providers. In 15 years there has been no systematic assessment of whether organisations comply, no consequence for those that do not and no public visibility of either.
Conclusion
Every issue raised in this consultation ultimately meets the same constraint: CSOs do not have time (and there isn't enough of them). A revised standard that adds requirements without addressing protected time will produce better documentation and no additional safety. I would rather see fewer, well-enforced, properly resourced requirements than a more comprehensive standard that organisations cannot meet.
Shared learning is the first of the six foundations of safer care that Patient Safety Learning sets out in A Blueprint for Action.[5] Its absence from the digital clinical safety framework is conspicuous. Connecting these standards to national learning, and bringing patients inside the process rather than leaving them as its subject, would do more for digital safety than any amount of additional documentation.
Recommended Comments
Create an account or sign in to comment