We cover this topic in our SCCI 0160/0129 Clinical Risk Management Course but here are some thoughts on the subject.
Many of us who have worked on large projects are used to the idea of a risk log – arguably an essential component of any well-managed project. However, safety standards such as SCCI 0129 and SCCI 0160 require us to maintain a hazard log for the lifetime of our digital health systems. Since these two requirements appear similar it would seem reasonable to combine the project and SCCI 129/0160 hazard logs, maintain them in one place and rationalise processes. But before doing so we probably ought to look more closely at how the two logs should be used and managed.
The hazard log is a repository of knowledge about the risks associated with an eHealth system and its operation. It is a core piece of evidence for the safety argument set out in the safety case. All of the hazards described within it will typically be mitigated by their associated controls. For example: the user may have the potential to select the wrong drug but careful screen design, a sensible system formulary and user training will all help to reduce the risk – this is all good material for preserving in the hazard log.
The project risk log will look a little different. Rightly or wrongly, most risks usually only make it to the project risk log when something active needs to be done, when escalation is warranted, more resources required or key controls in need of rigorous monitoring. It’s a tool to be worked through line by line on a regular basis, a task list for project managers, an actively managed bucket of worries, problems and evils.
Read any project risk log and you’ll quickly realise that not all of the project risks will have a clinical impact and conversely in the hazard log most of the content will lead to little or no project risk. A solid project risk log will typically have estimated costs associated with each risk so that contingency funds, indemnity and insurance can be evaluated. But would it be meaningful to estimate costs for clinical risks? Are we really forced to consider the cost of human life each time we identify a potential hazard in the eHealth system?
But where the two logs really diverge is in the area of risk closure. Once a project risk or issue has been managed it is typically closed. It no longer warrants priority attention or escalation, we can free ourselves to focus on other concerns. At best the need to manage a particular project risk might be captured as part of lessons learned exercise. On the other hand, the hazard log (in its capacity as a knowledge repository) needs to preserve the details of each hazard so long as it remains a credible – often until the point of decommissioning. Our stakeholders have typically thought long and hard to derive and document the hazard register content. We’ve brought together clinical, technical and product experts to examine the system so we should hold on to that knowledge, cherish it and pass it on to our successors. Who knows when a change in the system, its configuration or operation will inadvertently remove or weaken an established control?
Whether or not you maintain the hazard log and project risk log together or separately is a decision for your organisation and what works for you. Just make sure that whatever your methodology you can effectively:
What do we do at BT? We work closely with both the hazard log and the project risk log but they are maintained and managed separately. It works well for us and gives us the best of both worlds.
So if we have two separate logs, is there any crossover? Can risks move from one log to the other? Do stakeholders need to see both? Well…that’s for another post.
Dr Adrian Stavert-Dobson is the Managing Partner of Safehand, independent consultants in clinical risk management, and the author of Health Information Systems: Managing Clinical Risk.