Skip to content
There has been much debate about the need for Medical Devices to adhere to DCB0129 and NHS Clinical Safety Standards despite the regulatory processes many of them follow. Whilst there remains some ambiguity in the standards, DCB0129 and DCB0160 act as effective clinical risk management mechanisms which support patient safety and successful implementation.
Spurred by significant debate across the Clinical Safety community, alongside a lack of awareness from CSO’s within the NHS of how clinical risk is managed in Medical Devices, this blog has been written by our Head of Clinical Safety, Karen Whitton, to cover:
- What is DCB0129?
- What is Software as a Medical Device (SaMD)?
- Why should SaMD comply with DCB0129?
- How AI and Machine Learning SaMD should comply with DCB0129
- How to define the application of DCB0129 to Medical Devices
By addressing common misconceptions around the applicability of the standards, we hope to help manufacturers, clinical safety officers and healthcare professionals understand and comply with the required regulations.
What is DCB0129?
is a clinical risk management standard issued by NHS Digital and the UK Department of Health & Social Care that requires all Health IT system manufacturers to assess and manage clinical risks throughout the lifecycle of their product(s). It mandates the implementation of a Clinical Risk Management System, including thorough documentation and evidence of risk management activities through a Clinical Safety Case Report (CSCR) and an up to date Hazard Log. This mandate also includes the appointment of a Clinical Safety Officer or CSO to approve the documentation alongside Top Management.
What is Software as a Medical Device (SaMD)?
Software as a Medical Device is software intended to be used for a medical purpose without being part of a hardware medical device. According to the International Medical Device Regulators Forum (IMDRF), SaMD can perform functions such as diagnosis, prevention, monitoring, treatment, or alleviation of disease. Examples of SaMD include:
- Diagnostic software: Applications that analyse medical images or laboratory results to identify potential health issues.
- Monitoring software: Programs that track vital signs or chronic conditions in real-time.
- Therapeutic software: Applications that guide treatment plans or deliver digital therapies.
The MHRA provides guidance with examples and flowcharts to show which standalone software and apps meet the definition of SaMD. This guidance should be the starting point for any digital health manufacturer in the classification assessment of their device.
In the UK, standalone software and apps that meet the definition of a Medical Device are required to be UKCA marked in line with the Medical Device Regulations (MDR) or be CE marked according to EU regulations.
Why does Software as a Medical Device need DCB0129 compliance?
DCB0129 and DCB0160 are standards required to be met by digital health IT manufacturers and deploying organisations and have been set by the UK’s National Health Service (NHS) to ensure the safety, quality, and efficacy of health IT systems. DCB0129 and DCB0160 outline the processes and responsibilities required to manage clinical risks throughout the life cycle of a digital health product.
In its first iteration, the standard excluded the requirement for DCB0129 for SaMD, as it was understood these devices would comply with Medical Device Regulation requirements and the international standard ISO 14971 Application of Risk Management to Medical Devices. The standard was later revised in 2018 to include classified medical devices, to add an additional layer of assurance to healthcare IT systems which were being widely adopted by the NHS as part of national ‘digital-first’ priorities.
We have previously written about ‘How ISO 14971 helps to meet DCB0129 (and vice versa)’ in another blog explaining the key similarities and differences in applying both standards for the purposes of clinical risk management. A notable difference in requirements being the need to designate a Clinical Safety Officer (CSO) to be responsible for the safe manufacture and/or deployment of all digital health systems.
DCB0129 for Artificial Intelligence and Machine Learning SaMD
An Artificial Intelligence (AI) system used in healthcare is likely to be classified as a medical device. The classification is not purely because it is an AI system, it will only require classification if it meets the definition of a medical device by having an intended medical purpose.
There are a number of changes and initiatives currently underway, led by the IMRDF and the local competent authorities such as the MHRA to ensure safety is embedded in AI SaMD. We’ve written about some of these projects already in a recent post by our Head of Quality and Regulatory Affairs, Daniel here.
Regardless of medical device classification or additional controls included as part of certification or compliance, adhering to the NHS clinical risk management standards, DCB0129 and DCB0160, is mandatory for all AI Healthcare IT systems which meet the applicability criteria.
Manufacturers can support the safety assessment of their systems by implementing an assurance framework such as AMLAS into their development process, as previously discussed in a blog by our CSO Haniyah. SaMD must comply with ISO 14971 Risk Management of Medical Devices, and at 8fold, our Clinical Safety Officers apply the approach of BS AAMI 34971 Application of ISO 14971 to machine learning in artificial intelligence, into our DCB0129 work.
Are DCB0129 and DCB0160 required for Software within Hardware Medical Devices (SiMD)?
The NHS Clinical Risk Management Standards DCB0129 and DCB0160 apply to all Digital Medical Devices implemented within the ‘Health IT System’ A Health IT System is defined as: A ‘Product used to provide electronic information for health or social care purposes. The product may be hardware, software or a combination’.
The standards themselves do not fully address the question of when they do and do not apply to software within a device, this information is provided in supporting applicability guidance. This has led to some misunderstanding and confusion around the applicability of the NHS Clinical Safety Standards when software is incorporated into a physical hardware device.
The NHS DCB0129 Applicability Guidance provides the following examples:
- In Scope: The implementation of a QRisk3 calculator in a primary care desktop application
- Out of Scope: software based dosing algorithms that are implemented within a physical infusion pump
The criteria is further muddied by the definitions provided, not quite matching the examples above. The definition of a ‘Health IT System’ clearly states the system may be ‘hardware’, however, the example then used states that software within the physical infusion pump is out of scope. Additionally, NHS England states here that DCB0129 and DCB0160 do not apply in the context of software which is incorporated into a physical ‘Medical device’.
Our interpretation of the standards, applicability guidance and definitions, is that they exclude devices where the software resides solely within a hardware device, and does not integrate or interact with any other systems within the ‘Health IT System. When a Software in a Medical Device integrates with any standalone software application, the DCB0129 and DCB0160 assessments of the software must incorporate the integration as part of the risk process. It is recommended that deploying organisations adhere to IEC 8001-1:2021 Application of risk management for IT-networks incorporating medical devices. Assumptions are made that the hardware device functions in line with its intended use and adheres to all required regulatory standards, and so the assessment focuses largely on the data quality, transmission and digital outputs from the device.
Summary
The NHS Clinical Safety Standards are essential for ensuring the safe manufacture of health IT systems, including Software as a Medical Device and AI as a Medical Device. While the standards aim to provide a robust framework for digital clinical safety, there are ambiguities regarding their applicability to software within hardware medical devices. Confusion arises from inconsistent definitions within supporting guidance.
Our interpretation suggests that DCB0129 and DCB0160 apply primarily in standalone software and/or when software within a hardware device interacts with other systems in the Health IT System or Infrastructure. Clearer guidance is needed to resolve these ambiguities and ensure comprehensive safety assessments and a standardised approach to clinical risk management.
How can 8fold help?
At 8fold, our team of Clinical Safety Officers are experienced in applying the DCB0129 standard to Software as a Medical Devices and can integrate the requirements into existing processes, compliant with ISO 14971 and ISO 13485.
We can also assess and report on the applicability of the NHS Clinical Safety Standards to your product, if it is perceived that they are out of scope. During system procurement, we often see DCB0129 requests for systems that are out of scope which is often due to a misunderstanding of the applicability of the standard.
Whatever the circumstances, our team has your back. Get in touch.
We’re the experts that have your back.
Lets see how we can help you navigate DCB0129 or DCB0160 with market leading Clinical Risk Management
