70% of NHS Digital Health Technologies Lack Safety Assurance: What this means for transformation and equity

I think we can all agree, we want digital technologies used in healthcare to be safe. How do we know a software is safe? Well, we have standards and processes to provide that assurance, right?

A recent study published in JMIR Publications has researched and quantified current compliance with mandatory clinical safety standards across the NHS's digital health technology (DHT) estate. This is the first study to measure both the scale of DHT deployment in NHS organisations and the extent of compliance with safety standards.

The researchers' findings have uncovered a problem that until now wasn't systematically measured or reported: the majority of digital health technologies in use in the NHS today, lack documented safety assurance.

The scale is significant. Across 204 NHS organisations, researchers identified 14,747 digital health technology deployments. Only 17.3% had been fully risk assessed and assured against required standards that have been legally mandated since 2012. That means roughly three-quarters of the digital tools influencing patient care in a typical NHS trust have no documented evidence that anyone has systematically assessed the clinical risks they may pose.

These findings matter because they quantify a problem that has had no central oversight mechanism.

DCB0129 and DCB0160 have been legal requirements under the Health and Social Care Act 2012 for over a decade. They're not new guidance or aspirational frameworks. They're mandated standards that provide assurance of the safety of health IT systems.

DCB0129 applies to manufacturers. It requires documented evidence that clinical risks have been identified, assessed, and mitigated during design and development. The output is a clinical safety case report showing the governance processes used and the residual risks accepted. DCB0160 applies to deploying organisations. It requires each organisation to assess risks specific to their context such as local workflows, staffing models, patient populations and integration with existing systems. Even if a product has strong DCB0129 assurance, every organisation deploying it must conduct its own DCB0160 assessment because implementation context will change risk profiles.

The study contacted 239 NHS organisations under the Freedom of Information Act. The 204 responses (85.4% response rate) covered 14,747 DHT deployments, with provider trusts averaging 107 deployments each. There was substantial variation, some trusts reported 3, while others reported over 1,000. Compliance rates were consistently low across organisations. Average compliance across NHS provider trusts was 24.5% which ranged from 8.1%-50%. Only 13 organisations (6.4%) reported full compliance across their entire technology estate. Sixteen organisations (7.8%) reported zero documented assurance for any deployed technology. 70.1% of organisations were not assured at all.

Lets firstly take a look at why we have clinical safety legislation. Unfortunately we have a plethora of examples to showcase why. These examples all highlight significant harm from IT system failures, which often show consistent patterns, with faults that remain undetected for years, affecting hundreds of thousands of people before they are discovered.

• The national breast screening IT system failure, caused by system incompatibility and failsafe system failure. This went undetected for 9 years between 2009 and 2018, affecting 122,000 women.
• The QRISK2 code-mapping error resulted in incorrect cardiovascular risk stratification for 7 years between 2009 and 2016, affecting 260,000-270,000 individuals.
• Cerner EHR issues with clinical orders being sent to incorrect locations took 2 years to identify (2020-2022) and were still causing problems as of March 2024, resulting in at least 149 documented patient harm events.
• And perhaps the most famous of all was The Horizon IT system, where software bugs compounded by corporate culture led to incorrect accounting which took 20 years to expose resulting in over 700 subpostmasters wrongly convicted of fraud.

These aren't edge cases. They demonstrate that digital systems are particularly prone to hidden and latent failures. Hidden failures occur when individuals, processes, or organisations lack the capability to identify or investigate faults. Harm may be misattributed to other parts of the care pathway that are more easily interrogated. Latent failures remain dormant until specific conditions trigger them, potentially leading to harm that scales rapidly.

The absence of detected harm is not evidence of safety. It may be evidence of inadequate monitoring, or of failures not yet identified. When safety assurance is weak, we may face multiple risks The assumption that "digital is good" may mask underlying risks. Without documented assurance, adoption may implicitly shift risk onto organisations, patients and communities who lack choice or voice.

This gap in assurance is not a purely a patient safety issue it is also an equity issue. Digital tools may fail, mislead or misroute care, disproportionately affecting groups already vulnerable because staff capacity or escalation routes may be weaker in under‑resourced settings.

Vulnerable populations experience disproportionate harm when systems fail, and they have fewer resources and capacity to mitigate that harm. Patients with lower digital literacy are less able to identify when a system has produced an incorrect output or to challenge algorithmic recommendations that don't align with their clinical presentation. Patients with language barriers or cognitive impairments face additional challenges interpreting system outputs or understanding when something has gone wrong. They're less likely to know escalation routes when tools malfunction.

Patients in communities with existing trust deficits, often the same communities we're trying to reach through digital programmes, experience greater impact from failures. One significant incident involving can reverse progress in trust-building.

Organisations that embrace digital services to extend access, personalise care and reduce inequality must also ensure that those services are safe, reliable and trustworthy.

The study didn't explicitly investigate root causes, but qualitative responses from organisations and sector context strongly hint at the systemic causes.

Increasing scale and complexity of technology deployments, without adequate governance infrastructure. Provider trusts deployed an average of 107 digital health technologies. Multiple organisations told researchers they couldn't provide accurate counts because they don't maintain a central register of clinical systems. You can't assure what you can't inventory.

Inconsistent interpretation of standards scope. Some organisations reported as few as 3 deployed DHTs, interpreting "health IT systems" narrowly as "core EPR systems" only. Others reported over 1,000. The standards define 'health IT' as 'any product providing electronic information for health and care purposes, including software and devices for clinical and non-clinical uses'. However, the variation in reported numbers suggests either genuine differences in digital maturity or more likely, significant differences in how organisations interpret which systems require assurance. Both are problems.

Procurement processes that don't request safety assurance. Several organisations stated explicitly that DCB0129 "is not requested as part of the IT procurement process." This means they're buying systems that influence clinical decisions without verifying the manufacturer has conducted basic safety assessments. Some noted that "suppliers should provide this by default" but acknowledged it's "not recorded." Relying on suppliers to volunteer compliance documentation without contractual requirements is a failure of procurement processes.

Clinical Safety Officer capacity constraints. DCB0160 assessments must be conducted by qualified CSOs, these are clinical staff with specific training in digital safety. Current CSO training typically involves 9-12 hours of largely self-directed online learning. The study authors note this minimal preparation for the scale of the task. These individuals are then expected to assess complex integrated systems and challenge senior decision-makers during procurement or implementation while juggling schedule and budget pressures. The professional infrastructure isn't adequate for the scale of the task across the NHS.

Legacy debt and reactive approaches. Some organisations justified non-compliance by stating their systems "predate DCB0129" or are "reviewed if serious incidents occur."

NHS England is currently reviewing DCB0129/0160 and importantly to address AI, connected devices, and new care models which pose new and unquantifiable risks.

The NHS 10-Year Health Plan positions digital transformation as one of three "big shifts" needed to make the system more sustainable. The plan explicitly references moving from "analogue to digital" care models. That transition requires digital tools that are safe, reliable, and appropriate for scaled deployment. This study shows we can't assume this is the case for the majority of currently deployed technologies.

• Board-level accountability is explicit in the standards. "Top management" holds overall accountability for deployed DHTs. When harm occurs from unassured systems, organisations will need to demonstrate they exercised reasonable care. Without evidence of proper safety assessment, that will be difficult. This represents both a legal and repetitional risk.
• Pace of deployment may be outrunning capacity to assure safely. If organisations are deploying technologies faster than we can conduct proper risk assessments, or if procurement processes don't include a requirement for safety evidence, the compliance gap will widen.
• Legacy technology debt is significant. Many organisations have substantial portfolios of older systems that have never been formally risk-assessed. The study's authors estimate potentially 10,470 NHS technology deployments may be completely unassured based on their 70% finding. Addressing this compliance debt requires dedicated resources and prioritisation, which competes with new transformation initiatives.
• Central oversight mechanisms are absent. There's no central register of DCB0129-assured products, no mechanism for organisations to share assessments of the same tools, and no external accountability for compliance.

For those developing digital strategies, commissioning services, or leading transformation programmes, the following actions need to be prioritised.

1. Start with an accurate inventory

Map every digital technology in clinical or operational use, with deployment dates, responsible teams, and documented assurance status. If your organisation doesn't hold this information "in an easily accessible format", that's the first problem to fix.

2. Stratify by risk, then prioritise

Not all technologies carry equal risks. Basic administrative systems differ from clinical decision support tools, AI-assisted triage, or prescribing systems. Use clinical input to categorise technologies by potential for patient harm, then address high-risk, unassured tools first.

3. Revise procurement requirements

Make DCB0129 compliance a selection criteria. Don't proceed with a purchase if a supplier cannot provide documented evidence of clinical risk management. Include assurance documentation requirements in contracts, with obligations to maintain and update safety cases through product lifecycle.

4. Build assurance into transformation governance

Digital transformation programmes should include CSO input as standard. New deployments must require documented safety assessments before go-live. Make assurance status a standing board-level metric alongside adoption rates and user satisfaction.

5. Invest in CSO capacity

The current model which includes minimal training, often part-time CSO roles juggling technology risk management with clinical responsibilities is insufficient. Organisations need dedicated CSO time, and teams with the seniority to challenge senior decision-makers when safety concerns arise.

6. Treat assurance as a continuous process

System updates, configuration changes, workflow modifications, integration with new tools all alter risk profiles. DCB0160 requires ongoing monitoring requiring infrastructure: hazard logs, incident reporting linked to specific technologies, and regular review cycles.

This study provides the evidence that much more is needed to ensure clinical safety in the technologies and systems we use in health, and is foundational to sustainable and equitable digital health. Digital health maturity requires organisations to demonstrate not just that people can access technology, or that they have skills to use it, but that the technology itself is demonstrably safe and risk-managed for the populations being served.