Skip to content
The Safety Incident Log
For digital health risk management in the UK, the DCB0129 and DCB0160 standards form a crucial partnership. DCB0129 details the responsibilities of the health IT manufacturer, ensuring software is designed and built safely. DCB0160 details the responsibilities of deploying and managing the software safely for the healthcare organisation.
Both standards require concise documentation, including Hazard Logs and Clinical Safety Case Reports, and both require the maintenance of the Safety Incident Log.
A well-maintained safety incident log is the backbone of a functioning clinical safety management system. It provides evidence that the Hazard Log is a representative risk assessment of the system, allowing for continuous improvement for both the manufacturer and the healthcare provider.
In this blog written by CSO Nick Pavard, we outline the definition and purpose of Safety Incident Logs as part of DCB0129 and DCB0160, as well as practical guidance on how robust incident reporting provides additional failsafes in the deployment of digital health technology and medical devices.
What is a Safety Incident Log?
A safety incident log is a structured record of all safety-related events, near misses, and observed problems associated with a health IT system. It must capture important details such as:
- Date and Time of the incident.
- System Details: The name of the software and the specific version number.
- Event Description: A clear narrative of what happened, who was involved, and what they were doing.
- Clinical Impact: The actual or potential harm, classified using a standard severity scale (e.g., No harm to Catastrophic).
- Immediate Actions Taken: What was done at the time to mitigate the issue? These should be quick fixes to reduce the risk whilst robust long-term solutions are investigated.
- Long-term Planned Actions: Long-term solutions will need to be documented before closing the incident. Importantly, immediate actions enable long-term solutions to be thoroughly tested and risk-assessed.
- Reporter Details: To allow for follow-up and clarification.
- Incident Status: (e.g., Open, Under Review, Closed).
This detailed record is the foundational evidence upon which all subsequent safety activities are built.
What needs to be captured in the Safety Incident Log?
For the log to be effective, there must be a clear understanding of what warrants reporting. Using the NHS’s definition of a patient safety incident can help capture the required issues:
“Patient safety incidents are any unintended or unexpected incidents which could have, or did, lead to harm for one or more patients receiving healthcare. Recording them supports the NHS to learn from mistakes and to take action to keep patients safe.”
The risk management team should review any event where a Health IT system is implicated, including:
- Events Causing Actual Harm: This is the most obvious category. Any instance where the use of—or failure of—the IT system was a contributing factor to any level of patient harm, from minor to catastrophic.
- Near Misses: These are arguably the most valuable learning opportunities. A near miss is an event that could have resulted in harm, but did not, either due to timely intervention or pure chance..
- Unexpected System Behaviour: The system does not need to cause harm to be hazardous. Any deviation from expected behaviour should be logged for review, as it may indicate an underlying flaw. This includes:
-
-
-
-
-
- System crashes, freezes, or unresponsiveness.
- Display of incorrect, ambiguous, or out-of-date information.
- Significant performance degradation that impacts clinical workflow.
-
-
-
-
- Usability and Workflow Problems: When a system is confusing, complex to use, or poorly aligned with an established clinical workflow, users may create their own “workarounds”. These unofficial processes can be a significant source of risk, and their emergence should be logged as an incident.
The Safety Incident Log's Role for the Manufacturer
The manufacturer’s responsibility for safety does not end when the software is launched. Under DCB0129, they must have a system for post-market surveillance, which is not dissimilar from rules for Medical Device manufacturers, and the healthcare organisation’s safety incident log is a critical input in its efficacy.
Pre-launch testing is a critical phase, but it can never fully simulate the complexities of a live clinical environment. Incident reporting is an essential source of real-world data, giving feedback on the system’s performance in its intended setting.
Every Clinical Safety Case Report is underpinned by a series of assumptions regarding the software’s real-world application. The review of incidents serves to either validate or challenge these. This feedback loop allows the manufacturer to re-evaluate the hazard log, ensuring it remains both current and comprehensive.
Incident reports from deploying organisations are the backbone of an effective product development lifecycle. They represent the most effective way to identify bugs, usability issues, and previously unforeseen hazards. This feedback is essential for informing future software updates and patches, thereby ensuring an effective continuous cycle of improvement and risk mitigation.
The Safety Incident Log's Role for the Healthcare Organisations
For the healthcare provider’s Clinical Safety Officer (CSO) and risk management team, incident reporting and reviewing the hazard log are essential for monitoring the safe deployment of new and existing Health IT solutions.
An incident report activates the risk management process, as mandated by the DCB0160 standard. The risk management team should analyse the event, cross-referencing it with the existing hazard log to verify whether the hazard was previously known and to confirm if the assigned likelihood and impact scores remain accurate.
Effective incident reporting, including near-misses, can highlight local deployment issues and allow an organisation to rectify these local factors. Furthermore, it provides the necessary evidence to escalate the systemic problems to the manufacturer, thereby feeding into the manufacturer’s own post-market surveillance and product development lifecycle.
While a single incident provides a snapshot, a collection of incidents reveals a narrative. This is crucial for the deploying organisation and the manufacturer. By regularly analysing the log, the DCB0160 team can perform trend analysis to identify recurring problems and systemic weaknesses. This capability enables the organisation to transition from a reactive to a proactive model of risk management, addressing minor issues before they have the potential to escalate into significant clinical events.
In addition, as discussed below, an organisation reporting a use issue carries significantly less weight than multiple organisations reporting the same issue, thus driving the cycle of safety.
When a healthcare organisation (DCB0160) maintains a high-quality safety incident log and establishes a clear channel of communication with the manufacturer (DCB0129), a cycle of safety is created.
The safety incident log is crucial for the maintenance of the entire risk management system. It transforms clinical safety from a static set of pre-deployment documents into a constantly improving system, reflected in a suite of documents that continue to communicate the safety of the system, on sale or deployed.
Making safety incident logs painless
More commonly now, similar information is captured in wider reporting systems, such as Jira, EQMS, or Daytix. This ensures alignment with wide incident reporting and risk management activities. It is imperative for the success of contracted CSOs that they utilise existing organisational processes as much as possible to minimise any process disruption caused by integrating DCB0129/DCB0160 requirements. No matter what system is used, the CSO must ensure that incidents are cross-referenced against the existing hazard log to ensure that the cause and impact are captured. Without his the Hazard Log becomes an inaccurate representation of the overall safety of the system.
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.
