Hazard log and clinical safety case report: what goes in them?

The words, as the standards define them

• Harm: death, physical injury, psychological trauma and/or damage to the health or well-being of a patient.
• Hazard: a potential source of harm to a patient.
• Clinical risk: the combination of the severity of harm and the likelihood of it happening.
• Hazard log: a mechanism for recording and communicating the ongoing identification and resolution of hazards associated with a health IT system.
• Clinical safety case: the accumulated product and process documentation and evidence, through the system's lifecycle.
• Clinical safety case report: a report presenting the arguments and evidence for a compelling, comprehensible and valid case that the system is safe for a given application in a given environment at a defined point in its lifecycle.

How the documents fit together

The clinical risk management plan comes first and sets the risk acceptability criteria. The hazard log is opened and kept up to date, with every version approved by the clinical safety officer. Each clinical safety case report is issued with the hazard log of that moment. Everything sits in the clinical risk management file, kept for the life of the system, and incidents go in the safety incident management log. A manufacturer has to make each safety case report available to the receiving organisation, which may be a hospital or another manufacturer.

Example hazards for AI software

NHS England's guidance on AI ambient scribing gives a useful starting list, which carries over to most AI tools in a hospital. Technical risks include output errors, system unavailability, integration failures and data loss. Clinical hazards include missing critical information, incorrect information or context, and delayed outputs. The same guidance adds overreliance or automation bias, poor fit with clinical workflows, and effects on the patient-clinician interaction. For each, the hazard log should say what could happen, how likely and how severe it is, what controls are in place, and who owns it.

Writing one that people actually use

• Write hazards about patients, not software: "result shown against the wrong patient", not "mapping bug".
• Link each control to evidence: a test, a design feature, a training step, a monitoring check.
• Reopen the log when anything changes: a new feed, a new model, a new ward. DCB0129 also asks for every third-party product in a release to be assessed.
• Keep the safety case report short enough for the people approving deployment to read.