This week I’ve been developing a hazard log for an innovative health IT product. Constructing a hazard log from scratch can be a daunting experience and many see it as a labour-intensive tick-box exercise. But done properly, the activity really makes you examine the product – often you are the first person to look at the system in quite that level of detail. The analysis can yield fascinating results which helps to drive product quality. Remember that the hazard log is really just a convenient outcome of a detailed quality analysis.
Hazard logs form the basis of a safety argument and they are a requirement in ISB 0129 and ISB 0160. But given the hazard log is maintained for the lifetime of a product, you’re potentially in it for the long haul, so getting it right is a good investment.
Here are my top 10 practical tips for building a good hazard log (in no particular order):
- Use simple, unambiguous language. One of the main purposes of writing a hazard log is the communication of knowledge and gaining a mutually agreed understanding of the system. A hazard log full of clinical jargon, philosophical argument or overly technical terminology will exclude members of your audience who might just be the people you need to engage.
- Avoid three-word hazards. I’ve noticed that humans have a strange tendency to write hazards using robotic, three-word statements; “Wrong drug selected”, “Patient not found”, “Screen doesn’t load”. Concise maybe but this level of brevity fails to communicate context. Compare, “Allergies not known” versus “The user could fail to be made aware of the existing allergies already recorded for a patient in the system”. A few more words but far more engaging.
- Avoid overly-repetitive, non-specific text. For example, having simply “Training” as a control for every hazard is not helpful. It might be technically correct but nothing is really learnt in documenting these kinds of controls. Instead you could summarise the training strategy in the Safety Case and include specific learning points as controls, e.g. “Users will be trained that where a patient has many allergies they will need to scroll the screen”.
- Be aware of whether you write causes as possibilities or statements. Compare, “The system could fail to show allergy data correctly” versus “Allergy data is shown incorrectly”. Both are perfectly valid but personally, I prefer the conditional approach. I find it hard to tell whether “Allergy data is shown incorrectly” is a theoretical possibility or a known bug.
- Controls should stand by themselves. Compare, “The system will be tested to make sure this doesn’t happen” with “The system will be tested to ensure that when allergies are present, they are always displayed correctly on the screen”. The latter is more useful as these statements can be extracted in their own right and passed to other stakeholders to ensure they are implemented.
- Concentrate on the most effective controls. Some controls (e.g., those related to design features) are much more effective than others (e.g. human factors). It’s not necessary to document a whole host of potentially ineffective controls when already a couple of strong controls have been implemented and validated. Hazard logs can quickly become bulky and cumbersome if you’re not careful.
- Get the level of granularity right. In developing every hazard log one needs to balance specificity with coverage. A high-level document with nebulous causes and controls is difficult to evidence and of little practical value. One full of detailed specifics can be vast, difficult to navigate and become a maintenance nightmare. As a guide, be specific and detailed where the level of risk justifies that degree of analysis.
- Avoid simple cause-control contradictions. Don’t include causes in your hazard log only to create a single control which is the exact opposite. For example, “Cause: Users might forget to save information. Control: Users should always remember to save information”. It’s easy to fool yourself into thinking that you are making a system safer by doing this – you’re not!
- Don’t make your hazard log a list of gripes and groans. Every health IT system has its idiosyncrasies. Some might be critical to patient safety whilst others might impact reputation, finances, aesthetics or project success. These are very real issues that need careful managing but creating a new hazard for each and every potential hiccup is not useful.
- Avoid over-thinking things. “Is this piece of information a new hazard, an existing hazard, a cause, a cause of a cause, a lack of a control or……?”. It’s easy to get bogged down in logic and philosophy when constructing a hazard log. Really…. it doesn’t need to be that hard. It’s more important that something is captured and communicated than it stand up to the rigours of the scientific method.
So those are my top ten hazard log tips. Happy hazard hunting.
Dr Adrian Stavert-Dobson is the Managing Partner of Safehand, independent consultants in clinical risk management, and the author of Health Information System: Managing Clinical Risk.