DCB0160 is a non-negotiable part of any new Health IT System deployment. It ensures that the system won’t pose any unnecessary risks to patient care and safety.
Dr Amar Patel
CEO of Bordercross Health
You’ve realised that things need to change—urgently. The staff at your practice are burning out, struggling to keep up with the mounting administrative tasks. You can feel the pressure building, and it’s clear that if you don’t modernise soon, the quality of care will suffer, and your team might not last much longer.
That’s when you come across a robotic process automation tool that everyone is talking about. It promises to transform your core processes, streamline the repetitive tasks, and give your staff the breathing room they need. The marketing material looks great, and after speaking to a few other practices that rave about its impact, you’re sold. You know it’s what your practice needs to survive and thrive.
Determined to make this happen, you write a business case, and it gets approved. You’ve ticked every box, even completing your Data Protection Impact Assessment (DPIA). The vendor assures you the system will be up and running within 30 minutes. It all sounds perfect… But suddenly, you pause.
Have you got your DCB0160 in place?
While it’s tempting to rush ahead, there’s one critical step left. DCB0160 ensures that this shiny new system won’t just make life easier—it also won’t put patient safety at risk. Without it, you’re flying blind, not knowing what hazards could be lurking beneath the surface.
DCB0160 is a regulatory standard that organisations must comply with when deploying digital products in health and social care services. Manufacturers, in turn, are required to complete a DCB0129 to ensure the safety of these systems. Separate guidance applies in specific cases involving medical devices.
DCB0160 ensures systems are deployed safely and remain safe throughout their entire lifecycle. Whether you’re deploying a new system or updating an existing one, DCB0160 covers everything from identifying hazards to ensuring ongoing safety through regular monitoring and feedback.
This person is responsible for overseeing clinical safety in the Health Organisation, ensuring that all safety documentation is complete and risks are managed appropriately.
The CRMP outlines how you’ll manage risks throughout the system's lifecycle, from deployment to decommissioning.
The Hazard Log is a living document where you record all identified hazards, their causes, mitigation measures, and the current status of these hazards.
The CSC is a structured argument backed by evidence that shows the Health IT System is safe for clinical use. It grows and evolves throughout the system’s lifecycle, with updates made at key milestones.
The Clinical Safety Case Report (CSCR) is a summary of all the work done to ensure the system is safe for use.
This log records any incidents that could pose a risk to patient safety, including their causes, the actions taken, and whether they have been resolved.
New software impacts the underlying business processes it aims to improve, as well as the various staff roles previously responsible for those tasks. It is crucial to fully understand existing workflows and to capture both pre-implementation and ongoing post-implementation feedback from staff to effectively monitor changes.
Before you even begin talking about new software, it’s essential to get a clear picture of how things currently work. This means mapping out each step in the relevant business processes—whether it’s managing patient appointments, handling prescription requests, or processing lab results.
Just as important is understanding how your team feels about these workflows. Are they experiencing frustration with certain tasks? Are there points where things frequently go wrong or get delayed? Understanding these pain points allows you to see where the real impact of new software will be felt.
Once you’ve chosen your Health IT system, it’s crucial to gather pre-implementation feedback to understand how it will fit into your current processes and anticipate potential risks. Involving a diverse group of staff—including GPs, nurses, admin personnel, and IT support—helps ensure that every angle is considered. Each of these roles interacts with the system differently, and they’ll likely identify potential hazards or challenges that others might overlook.
In this information gathering, focus on:
Real-world scenarios: How will the system be used day-to-day? What potential hazards can staff foresee? Role-specific impacts: How will it change the workflow for each team member? Will new training be needed, and could there be risks in the transition? Staff concerns: What worries or reservations do your staff have about the new system? Understanding their concerns early on helps address them proactively.
The work doesn’t end once the system goes live. In fact, post-implementation feedback is just as critical as the planning phase. Your staff—whether they’re GPs, nurses, or receptionists—are the first to notice real-world issues that might not have surfaced during testing.
Set up regular, structured feedback loops where staff can share:
New risks or issues: Are there glitches, delays, or usability issues that could impact patient care? System usability: Is the software intuitive, or are there areas where staff are struggling? These can often indicate underlying risks. Process improvements: Sometimes, feedback reveals that the new system has highlighted inefficiencies in the original process. Identifying these allows you to refine workflows further. Having a system to capture this feedback—whether through regular meetings, surveys, or an open forum—ensures that risks are continuously monitored and addressed.
Why Is It Important? Workshops and staff feedback are key to successful risk management. They ensure that the people who use the system every day have a voice in making it safer and more efficient. By listening to your team before and after implementation, you’re not just improving the system—you’re safeguarding patient safety and supporting your staff, ensuring that any risks are identified and resolved quickly.
Introducing a new Health IT system is a transformation that affects every aspect of your practice. By involving your team in every step of the process—from pre-implementation brainstorming to post-implementation feedback—you’re making sure that this change is both positive and safe for everyone involved.
When deploying a new Health IT System, your first step is to establish a Clinical Risk Management File (CRMF). Think of this file as the core of your risk management documentation.
What is the CRMF? The CRMF is a repository where all clinical risk-related documents are stored. It acts as evidence that your organisation is managing clinical risks correctly and adhering to DCB0160.
Key Requirements: Establish at project start: The CRMF must be created at the beginning of the project and maintained throughout the system’s entire lifecycle. Documentation: Include all formal documents related to clinical risk management—compliance evidence, decision-making records, and risk assessments. Why Is It Important? The CRMF ensures you have a centralised record of all decisions and actions regarding clinical safety, which is critical if you ever need to review, audit, or justify your safety management processes.
Once your CRMF is set up, the next document you need is a Clinical Risk Management Plan (CRMP). This is your roadmap to managing risks throughout the system’s lifecycle.
What is the CRMP? The CRMP outlines how your organisation will handle risks during the deployment, maintenance, and decommissioning of a Health IT System.
Key Contents: System description: Details of the Health IT System and its clinical context. Procedures & policies: How risks will be identified, evaluated, and mitigated. Roles & responsibilities: Who is responsible for each part of the risk management process. Triggers for review: When the plan needs to be updated, such as after a major system update or team change. Why Is It Important? Having a clear CRMP ensures that everyone involved knows what their role is and how to manage risks proactively. It also provides a structured approach for monitoring and mitigating risks as they arise.
In every project, there are risks. The Hazard Log is where you keep track of all the risks that could impact patient safety in your Health IT System.
What is the Hazard Log? The Hazard Log is a living document where you record all identified hazards, their causes, mitigation measures, and the current status of these hazards.
Key Contents: Hazard descriptions: What could go wrong. Causes: Why the hazard might occur. Controls: What measures are in place to mitigate the hazard. Status: Whether the hazard is still active or has been resolved. Why Is It Important? Without a well-maintained Hazard Log, it’s easy to lose track of potential risks. This document ensures that risks are continuously monitored and managed throughout the system's lifecycle.
To prove your Health IT System is safe, you need a Clinical Safety Case (CSC). This is the formal document where you present evidence that all risks have been identified and controlled.
What is the CSC? The CSC is a structured argument backed by evidence that shows the Health IT System is safe for clinical use. It grows and evolves throughout the system’s lifecycle, with updates made at key milestones.
Key Contents: Risk identification and evaluation: Documenting all potential hazards and the steps taken to mitigate them. Evidence of safety: Proof that all risks have been controlled, usually sourced from risk assessments, test results, and user feedback. Ongoing safety monitoring: Updates made as new risks emerge or the system is modified. Why Is It Important? The CSC proves to your organisation and external stakeholders that the system is safe to use. Without it, you can’t proceed to full deployment or make changes to the system.
The Clinical Safety Case Report (CSCR) is a summary of all the work done to ensure the system is safe for use.
When Do You Need a CSCR? Pre-deployment: To confirm that the system is safe to go live. Post-modification: After any updates or changes. During decommissioning: To ensure safe transition and removal of the system. Key Contents: Summary of hazards and controls: A concise overview of the risks identified and how they have been mitigated. Residual risk assessment: A final evaluation of any remaining risks and whether they are acceptable. Approval by the CSO: The CSCR must be signed off by the Clinical Safety Officer before the system can progress. Why Is It Important? The CSCR is a critical checkpoint at every stage of the system’s lifecycle. It gives top management the confidence that risks are managed and that patient safety is prioritised.
Even with the best risk management processes, things can go wrong. The Safety Incident Management Log helps you keep track of issues as they arise and manage their resolution.
What is the Safety Incident Management Log? This log records any incidents that could pose a risk to patient safety, including their causes, the actions taken, and whether they have been resolved.
Key Contents: Incident description: What happened. Risk assessment: How severe is the risk? Resolution actions: What steps were taken to resolve the issue. Incident status: Whether the issue has been resolved. Why Is It Important? By keeping track of all incidents, you can make sure they’re addressed quickly and effectively, reducing the risk of future issues and keeping your system running smoothly.