Risk is a word we see daily. We all know what it means. However, when it comes to a specific situation, i.e., developing software that needs to be safe, risk is something you need to understand thoroughly to deal with risk management properly.
You need good risk management because it is a regulatory requirement, you can avoid killing your patients, and it helps you understand on which areas to focus the most.
This article will cover basic risk management terminology. The video above, which is a part of our online course on Software for Medical devices and IEC 62304 explains the matter in-depth.
The definition of risk
We define the notion of risk as the combination of the probability (Po) of the occurrence of harm, and the severity (S) of that harm. Speaking pure math, this means that we would have the same risk level with a situation unlikely to happen, but which bears severe consequences as a risk very likely to happen, but with low severity.
In simple words, a hazard is a potential source of harm. The ISO 14971 standard defines harm as
“…injury or damage to the health of people, or damage to the property or the environment.”
A typical example of a hazard is bacteria. But, can software be a hazard? Yes, and no.
By itself, the software cannot be a hazard since it is not a source of harm. However, it can misbehave and cause harm to happen, and this is why it often ends up as a hazard in the documentation Formally, it would be more correct to say that software contributes to a sequence of events leading to the possibility of harm.
Sequence of events
The requirement in ISO 14971 to identify sequence of events is as follows:
“For each identified hazard, the manufacturer shall consider the reasonably foreseeable sequences or combinations of events that can result in a hazardous situation…”
Forgetting to wash your hands, then potentially transferring bacteria to yourself or the patient is a typical example of the sequence of events.
When it comes to this, there are two things to be careful about:
- What is reasonable?
- How many combinations to consider?
In terms of software, the unlikely can very quickly become likely. The sequence of events can be any combination of events, especially with software. The goal is to find the proper balance between reasonable and combinations, and not blindly scribble down everything you can envision – just to make your documentation look good.
The standard defines a hazardous situation as
“circumstance in which people, property, or the environment is/are exposed to one or more hazards.”
An example of this is punctured skin, where the hazard can occur – bacteria. It all comes from a sequence of events, no hand washing, which, in the case of skin being punctured, becomes a hazardous situation.
In terms of software, this can be the software calculating incorrect doses, exposing a patient to too long or short treatment, providing incorrect diagnosing information, and much more.
Finally, harm is defined as
“injury or damage to the health of people, or damage to property or the environment.”
As previously said, the software cannot directly cause harm, but it is likely to cause it indirectly, through external actions, and this is the reason why software risk management is so focused on the sequence of events leading up to a hazardous situation.
Estimating the risk
In an ideal situation, you would estimate the risk by using solid and reliable statistical data you found in published articles, standards, tests, and investigations. Ideally, yes, but this is sometimes impossible, and what happens then?
In such a situation, you will have to do your best to make guesses. Bear in mind that this should not be your main method of estimating the risk, since the consequence of doing it wrong can be very serious, even severe.
You start the risk estimation by determining the probability of occurrence of harm, Po.
The probability of occurrence of harm consists of two parts:
- P1 – the likelihood of the hazardous situation occurring. It is the result of the sequence of events that came before.
- P2 – the likelihood of harm occurring from a hazardous situation.
Surely, the software can contribute to a hazardous situation (P1), but factors outside of the software (P2) are needed to cause harm. For example, if a clinician acts according to the output from the software, how likely are these actions to cause harm?
P1 is the primary interest for software, but severity and risk are essential too. They give insight into which risks are the most important, and therefore where to focus efforts.
When working with software risk management, there is an established assumption that software failures always happen. But, this is an initial assumption before risk control measures. And, the assumption about failures always happening only applies to P1, not P2.
Probability is usually represented through percentage or a decimal number; in risk management, you multiply P1 with P2 to get Po, and then you translate the probability into a semi-quantitative number, for example, 1-5.
The most effective way of risk evaluation is to use a matrix based on severity and probability. Remember that there is no right or wrong here: every product can have its own evaluation matrix tailored for its needs.
Risk evaluation inevitably leads to some non-acceptable risks popping up, especially with software because of the initial P1. In those situations, you will need to implement risk controls in order to reduce those risks. When working with risk control measures in software, you can look for several things such as:
- Safe design. If possible, even try to remove unnecessary functionality.
- Segregation of functionality
- A good development process
An important thing to remember is that software risk management is very much about understanding how the software can contribute to a hazardous situation, P1.
This article was made to help you understand the terminology of risk better. Feel free to read more of our articles here.
Would you like to learn more about Medical Software Development?
Get instant access to our online Software for Medical Devices and IEC 62304 course right here. In 15-25 hours, you can learn how to be effective in medical device software development according to the IEC 62304 standard. The course is suitable for anyone working with software development, such as R&D engineers, quality assurance department and auditors of software development. The course does not cover actual coding.
Christian Kaestner is a consultant and entrepreneur with a wealth of knowledge about the medical device industry. He is an expert member of the project team authoring IEC 62304 and also actively participated in the creation of IEC 82304-1.
He has extensive experience of medical device development and, as a software developer, a strong dedication to software development. In the software domain he has worked in many roles such as software developer, project manager, auditing and quality management.