The industry has come to accept that Health IT (HIT) systems can both mitigate and introduce risk in healthcare delivery. Suppliers and healthcare organisations need to take proactive steps to manage risk in the deployment and maintenance of these systems. Both the FDA and UK’s HSCIC (under ISB 0160 and 0129) require us to formulate and communicate the risk profile through the safety case. But why go to the extent of writing what can be a lengthy and complex document when surely a simple hazard register will suffice?
Ultimately the power of the safety case comes out of its ability to carefully and logically justify risk. The principle of ALARP (As Low As Reasonably Practicable) is accepting of the fact that risk cannot ever be eliminated from HIT systems. Instead, through the safety case, we have an opportunity to explain our rationale and set out a considered case that reasonable measures of risk reduction have been undertaken. By presenting the rationale our readers needn’t blindly accept the claims that the HIT system is safe we can empower individuals to evaluate the risk picture for themselves.
The two building blocks of the safety case are argument and evidence. Argument provides the logical backbone, the narrative glue and inference which brings our hazards, causes and controls together. Evidence gives us confidence that the argument is sound and will hold true in the real world. It is often said that a safety case without argument is unfounded whilst a safety case without evidence is invalid.
So how does the hazard register relate to the safety case? Both play their part and there is often extensive overlap. One can picture the hazard register as the raw data, the underlying material on which our case is built. But the detail in the hazard register makes it difficult for one to see the wood for the trees. How are we able to identify that poorly mitigated hazard in such a sea of information, how might two hazards interact to unexpectedly inflate the risk? For this one requires the analytical narrative and logical explanation which only the richness of the safety case can provide.
Another key feature of the safety case is its role in communicating risk mitigation to project stakeholders. Frequently the responsibility for implementing controls lies across organisational boundaries. For example, a supplier might require healthcare organisations to operate their system in a particular way, on specific hardware or under certain conditions to mitigate an identified hazard. The safety case allows us to set out whom we assume to be responsible for implementing those controls and considers what the outcome might be should those assumptions turn out to be invalid.
But safety cases have their faults. Primarily they require expertise to compile and input from a range of multidisciplinary specialists. For clinicians in particular, safety cases often represent unfamiliar territory. Long and complex safety cases can be difficult to interpret and draw conclusions from. But with a solid document template and by ensuring that analytical content is commensurate with the level of risk, the safety case can be a valuable tool in the assessment of clinical risk in HIT.