Developers aiming to have their digital health solutions adopted by the NHS and the wider healthcare sector must comply with a number of regulatory frameworks to prove their solutions are safe for patient use. One of the most crucial of these is DCB 0129, a framework that sets the standard for the clinical safety of solutions being introduced into the UK healthcare market. 

"DCB0129: Clinical Risk Management in the Deployment and Use of Health IT Systems" is a standard requiring the developers of digital health solutions and IT systems to create a robust clinical risk management system to identify, manage and effectively mitigate any potential clinical hazards and patient harm that could arise through the use of their solutions.

In this blog, we'll dissect what DCB 0129 entails, who it's for, and the actionable steps that you, as a digital health developer, need to take to meet this stringent but essential requirement.

‍

Understanding DCB 0129:

In essence, DCB 0129 requires developers to implement a thorough clinical risk management process, one which must be maintained and regularly reviewed throughout the lifecycle of their solutions. The DCB 0129 standard applies to manufacturers and developers of digital health solutions or IT systems intended for use within the UK healthcare sector; this includes patient-facing apps, wearables and digital IT systems for hospital use. 

While it could be requested independently, the DCB 0129 standard is often required as part of the wider Digital Technology Assessment Criteria (DTAC). The DTAC sets a baseline standard that developers of digital health solutions need to meet before being considered for adoption by the NHS.

What about DCB 0160?

Organisations that purchase or implement these digital health solutions, such as NHS Hospitals and Trusts, must, in turn, comply with the DCB 0160 standard. While DCB 0129 and DCB 0160 are nearly identical, DCB 0160 applies specifically to the organisation implementing the health solution or IT system, whilst DCB 0129 applies specifically to the manufacturer.

‍

Meeting the DCB 0129 standard: Key Steps for Developers

The DCB 0129 specification outlines over 50 requirements that developers must implement to comply with the standard. While you can take a look at the complete specification here, we have summarised several critical actions in the sections below:

‍

Appoint a Clinical Safety Officer (CSO): 

Clinical Safety Officers are trained clinicians responsible for ensuring that the information contained in your solution's Clinical Risk Management Process is accurate and appropriate. CSOs have extensive knowledge of both clinical practices and the development and usage of digital health solutions, which uniquely positions them to understand the potential risks and controls that need to be put in place to ensure your solution is safe. 

While many developers of digital health solutions are clinicians themselves and may assign themselves as CSOs, after all, they likely know their solution better than anyone else; it is strongly recommended that they undergo additional Clinical Safety Officer training to develop a thorough understanding of risk management and safety principles specifically within the NHS setting.

‍

Outline and Develop your Risk Management Process:

An integral step of DCB0129 compliance is developing and implementing a thorough risk management process. Your clinical risk management process encompasses all of your clinical risk management activities and documentation, providing a structured manner to ensure all the necessary risk management activities outlined by the standard are actually carried out. 

If your organisation has an existing governance, quality, or risk management process in place, your risk management process can be linked to the context of your organisation's wider risk management system.

‍

Build a Comprehensive Risk Management Plan: 

In addition to defining what your digital health solution does and the clinical context within which it will be used, your clinical risk management plan will outline the procedures, policies and resources needed for the efficient and effective risk management of your solution. Your risk management plan should cover your solution's entire product lifecycle, ensuring relevant hazards have been identified for every stage of your solution's lifetime, from initial development to post-deployment. 

Your CSO will need to approve your risk management plan, and if there are any changes to your project's nature or significant changes to your solution, you must update your clinical risk management plan accordingly. 

‍

Hazard Identification and Risk Assessment:

This step involves identifying the hazards associated with your solution and its use. This hazard identification process should be carried out by a multidisciplinary group, including your Clinical Safety Officer and any relevant parties involved in developing and deploying your digital health solution. Clinicians using the solution should also be included in the process, allowing a greater chance to identify a broader range of potential hazards.

Before starting the risk assessment process, you must first define its scope. For example, if you are only selling a specific part of your digital health solution to the NHS, such as your app's mental health courses, but not its online therapy services, then it makes sense for the scope to be contained to the mental health courses. If your solution uses a third-party product, you will need to define whether this third-party product needs to be included in the scope. 

There are various techniques for identifying hazards, and your CSO can advise on how to best approach this specifically for your solution. For each of your identified hazards, you must estimate: 

• The severity of the hazard: a qualitative measurement of harm that patients might experience if the hazard were to occur.

• The likelihood of the hazard: a scale of the possibility of the identified hazard occurring. 

• The resulting clinical risk: Clinical risk is the combination of the likelihood of any identified hazards and the severity of harm that could come to patients should the hazard occur.

With clinical risks identified, your organisation can move on to identifying and planning the control measures that your organisation will implement to mitigate any clinical risks your team has deemed unacceptable. Be aware that these risk control measures could introduce new hazards, so it is essential to continuously reassess this risk management process as your digital health solution evolves.

‍

Build your Hazard Log:

A hazard log is a tool used to document and share the identification and resolution of the hazards associated with your solution or IT system. Your hazard log must be regularly updated to include newly identified hazards, record how these hazards will be mitigated, and keep track of the status of your risk management actions. 

Although the hazard log is a dynamic document that must be updated throughout your system's or solution's lifecycle, a baseline version should be issued with each Clinical Safety Case Report. Your CSO must review and approve every version of the Hazard Log to ensure that the clinical safety information recorded is accurate and appropriate.

‍

Create A Clinical Safety Case and Report:

The Clinical Safety Case aims to provide a compelling and valid case that your solution is safe for release, drawing on all the documentation within your Clinical Risk Management Process to argue that your solution is adequately safe. Much like the rest of your clinical safety documentation, your clinical safety case report will evolve to ensure that it continues to provide sufficient confidence in the safety of your solution.

‍

Ongoing Review: 

Post-deployment, your organisation must actively monitor and continue to assess your solution's clinical safety, focusing not only on the system itself but also on any new hazards which have arisen now that it is in use. Suppose your solution's real-world application reveals that your initial clinical risk assumptions do not hold up. In that case, you must review and reassess your hazard log and risk control strategy to ensure new risks are adequately mitigated. 

If your solution undergoes a significant change, such as a system update or the release of a new feature, you must undergo your clinical risk assessment process once again. This will help you determine whether the changes or updates have introduced any new hazards that must be addressed.

Once deployed into the healthcare setting, the DCB 0129 standard outlines implementing a number of measures to ensure your solution continues to operate safely. These include: 

• A clear channel to facilitate the reporting of any incidents by users or the clinical staff that could affect patient safety.

• Establish a communication flow for raising clinical safety incidents for your organisation and the health providers using your solution.

• Implement a clear channel through which your organisation can communicate relevant safety notifications with healthcare providers using your solution.

• Allocating adequate resources for managing and resolving incidents quickly and effectively.

Conclusion

This is just an overview of the activities needed to meet the DCB 0129 standard; for a complete implementation guide, you can take a look at the NHS website here. 

Naq has helped hundreds of healthcare innovators achieve compliance with the frameworks needed to bring their solutions to the NHS, including DCB 0129, DSPT, DTAC, ISO 27001, and more. Our digital platform automates over 80% of the manual work necessary to meet these standards while guiding you through the entire compliance process, simplifying the steps required to ensure your digital health solutions meet NHS standards.

Beyond our digital platform, Naq offers expert assistance through certified Clinical Safety Officers, who can provide comprehensive oversight for your clinical safety documentation, deliver training, and review your materials to ensure your solution meets the clinical safety standards set by DCB 0129.

Speak to one of our experts and simplify your NHS compliance. Click here to learn more.