— By Dean Mawson, NHS nurse, Clinical Director and Clinical Safety Officer at DPM Digital Health Consultancy
Digital health technologies are increasingly working as part of complex environments rather than standalone products. A piece of software might exchange information with an EPR through an API, rely on a third-party service or data source, or belong within a wider infrastructure of cloud services, local networks and other clinical systems. Remote monitoring, AI-enabled decision support and other technologies introduce further dependencies as they become integrated into existing pathways.
This creates a challenge for clinical risk management because the technology itself is only one part of the environment in which care is delivered.
A system may have been assessed as safe as a standalone, but the way it interacts with other systems, suppliers, or pieces of infrastructure can introduce risks that weren’t considered as part of that assessment.
I believe the next version of the NHS clinical safety standards, DCB0129 and DCB0160, need to address this much more directly.
Until now, the standards have provided an important framework for managing clinical risk in digital health. But, the digital health environment has changed considerably since they were introduced. We now have more complex integrations, greater reliance on third-party suppliers, greater InfoSec and Cyber Security concerns, connected infrastructure and rapidly developing AI technologies.
Our approach to clinical safety needs to recognise this change, and reflect the environment in which these technologies are being used.
Clinical risk is about so much more than a standalone product
Clinical risk management can become very product-focused. The difficulty is that clinical risk can emerge from the relationship between these different components.
The current standards do recognise interoperability and integration, but I believe the next version needs to place much greater emphasis on them. Risk analysis should explicitly consider the points where systems and middleware interact, including third-party systems.
The same principle applies to cybersecurity, rather than being treated as a separate compliance activity running alongside.
Going forward, I’d like to see refreshed DCB standards taking a broader view of what we mean by the system being assessed.
Accountability as systems become more connected
As digital health environments become more interconnected, responsibility for clinical risk can involve several different organisations.
A supplier may be responsible for its product while the healthcare organisation is responsible for how that product is deployed. Another organisation may own the system it connects to, while a third party provides infrastructure or another service on which the technology depends.
The revised standards need to provide much clearer expectations around those relationships.
In my response to the national consultation on DCB0129 and DCB0160, I recommended that organisations such as ICBs, PCNs, Trusts, and community trusts should be able to define accountability and ownership for risks that transfer across systems. There also need to be clearer boundaries and processes for the handover and acceptance of risk.
This becomes particularly important when the same technology is deployed across several organisations.
There is little value in every organisation repeatedly recreating the same safety evidence when the underlying technology and associated risks are substantially the same. A regional safety case could provide a baseline for a common technology or deployment, with individual organisations then assessing the differences in their own environment and addressing those additional risks locally.
That approach could reduce duplicated work while giving clinical safety teams more capacity to focus on the risks that are specific to their own environment.
Clinical safety should follow technology throughout its lifecycle
The digital health ecosystem also extends beyond implementation.
Clinical safety can be influenced by decisions made during procurement, the way a technology is configured and integrated, changes made after deployment, ongoing maintenance, and eventually any decision to replace or decommission it.
In my view, the current standards do not provide enough detail across all of these stages.
Procurement deserves much greater attention. Organisations have different routes for acquiring digital health technologies, and procurement teams do not always have enough awareness of the clinical safety requirements associated with them. By the time a technology reaches implementation, important decisions about the product, supplier, and deployment may already have been made without proper assurance.
Decommissioning also needs a much clearer process, including defined responsibilities for both the health organisation and manufacturer and appropriate safety documentation.
Cybersecurity provides a third example of why the lifecycle needs to be considered as a whole. Clinical assurance may need to consider the security of data throughout the lifecycle, ongoing supplier and system assurance, maintenance that requires downtime, access and administration, and plans for decommissioning or replacement when a supplier stops supporting a system.
A clinical safety assessment should therefore be treated as part of an ongoing process rather than a document produced before deployment and then filed away to gather dust
The standards need to reflect the digital health environment we have now
There is a need to update the language and structure of the standards.
DCB0129 uses the term “Health IT System”, but the technologies being deployed now extend well beyond the information systems and records that term traditionally describes.
I recommend the refreshed standards use “digital health technology” as the broader term, with clear tiers for digital health infrastructure and digital health software or systems.
Clearer definitions would also support a more proportionate approach to clinical risk management. Not every digital health technology presents the same level or type of risk, so the requirements should reflect the risk profile of the technology and its intended use.
That assessment should involve clinical and operational expertise rather than being determined centrally without sufficient input from people with experience of deploying and managing these technologies in practice.
AI makes this particularly important. Internationally, regulators are converging on one answer to the problem that AI models don’t stay fixed after approval: building lifecycle change-management into the regulation itself, rather than treating every update as a fresh standalone safety case. The revised standards need to address AI and machine learning technologies directly, and should align with relevant national and international AI standards, including DTAC, ISO 42001 (AI Management Systems), ISO 38507 (AI Governance, principles for responsible AI at board level) and BS 30440 (Validation of AI in a Healthcare Setting).
The clearest model is the US FDA’s Predetermined Change Control Plan, which lets manufacturers pre-specify how a model is allowed to change after approval so it doesn’t need full resubmission every time it’s updated — an approach the EU has now mirrored in its December 2025 MDR/IVDR amendment, alongside regulatory sandboxes and clarified guidance on how the AI Act overlaps with MDR/IVDR.
We need to understand the system around the technology
The next generation of DCB standards has an opportunity to bring clinical safety closer to the reality of modern digital health.
That means looking beyond each individual product to consider its integrations, dependencies, infrastructure, suppliers, data flows, and the organisations involved in delivering care. It means recognising that regulatory frameworks elsewhere have already accepted a technology’s risk profile isn’t fixed at the point of approval — and building that same lifecycle thinking into DCB0129 and DCB0160 is overdue.
Additionally, they must find better ways to reuse appropriate safety evidence when technologies are deployed across multiple organisations, rather than requiring each organisation to recreate the same work.
None of this will get easier. The NHS will keep adopting more connected technologies, more AI, and more complex infrastructure. The clinical safety framework has to keep pace, or the gap between what’s regulated and what’s actually deployed will keep widening.
The next DCB standards should give organisations the structure, accountability and practical tools they need to assess that wider environment and manage the clinical risks that arise from it.
That is how we can build a clinical safety approach that reflects the digital health ecosystem as it exists today, rather than the one we had when the standards were first written.
