A clinical hazard log is the controlled record of how a health IT team identifies potential patient harm, evaluates it and tracks the controls intended to reduce it. A useful entry lets a colleague trace failure mode → clinical consequence → control → verification → remaining risk. NHS England's clinical risk management standards set the manufacturer and deploying-organisation contexts for that work.
An illustrative entry
Fictional system: an appointment-follow-up dashboard. Illustrative hazard: a scheduled data import fails, but the dashboard still looks current. A clinician may therefore miss a patient requiring follow-up, potentially delaying review.
| Field | Illustrative entry |
|---|---|
| Hazard ID and scope | H-014; dashboard release 2.1, nightly appointment import |
| Cause | Import fails after source-system timeout; stale list remains visible |
| Potential harm | Follow-up is delayed because a patient is absent from the displayed list |
| Proposed controls | Fail the import visibly; show the last successful update time; alert the service owner; provide a documented fallback list |
| Owner | Product engineering for detection and display; deploying service for fallback procedure |
| Verification | Timeout test, stale-data display test and a local fallback exercise, each linked to its record |
| Residual risk | To be assessed by the real team against its approved criteria after controls are verified |
This is not a completed hazard log. The ID, version, tests and owners are fictional teaching details. It deliberately contains no made-up severity score or claim that risk is acceptable. Those judgements require the actual system, clinical pathway, risk matrix and people accountable for it.
Five mistakes a worked entry helps reveal
- Starting with a vague hazard: “the system is unsafe” gives no failure mode to control.
- Confusing a cause with harm: a timeout is a technical event; delayed care is the possible clinical consequence.
- Using a non-testable control: “staff will be careful” gives a reviewer little evidence that risk has changed.
- Losing the handover: the manufacturer may build a stale-data warning, but the deploying service must decide who responds to it.
- Closing a row before verification: a planned control is not the same as an implemented, evidenced one.
The hazard log should feed the clinical safety case report and be revisited when the product, workflow or incident evidence changes. NHS England's safety-case training module asks practitioners to treat safety cases as living documents. See our clinical safety case guide for how the pieces fit together.
Primary sources