Software in Medical Devices, by MD101 Consulting

Risks

Risks are the combination (or the consequence, I should say) of other concepts:

• Hazardous phenomenon
• Hazardous situation
• Injury
• Gravity of injury
• Probability of occurence of injury

These concepts are chained:

• When a hazardous phenomenon happens, the user or other people in the environment is/are placed in an hazardous situation.
• This hazardous situation may lead to an injury of the user or those other people in the environment.
• The risk is the assessment of:
  • the gravity of the injury, and
  • the probability of occurence of the injury.

Low gravity + low probability = low or negligible risk.
High gravity + high probability = high or unacceptable risk.

The diagram below sums-up all of above: There is a diagram in figure E.1 of ISO 14971 standard that sums-up all these concepts in a better way. I don't have the right to reproduce it here. But if you have a copy of the standard, it's worth having a look at it.

OK we've defined what a risk is, but not the link between risks and other concepts.

Risks vs defects

Let's now apply the chainning described above to critical or major defects:

• When a critical or major bug happens, the software crashes or gives wrong results. Thus people are placed in an hazardous situation.
• This software crash or erroneous result may lead to an injury of people, like:
  • A lung ventilator is controlled by software and stops --> risk of severe injury!
  • A PACS viewer is boggey and shows wrong images --> risk of misinterpretation by the radiologist.
• The risk is the assessment of:
  • the gravity of the injury (see the two examples above),
  • the probability of occurence of the injury --> the probability of occurence of a defect.

Ouch! The probability of occurence of a defect?

I don't know the probability of occurence of a defect. You don't know either. Nobody knows!
We'll see later on how to deal with it.

Risks vs software failure

Let's continue to apply the chainning described above to software failures:

• When a software failure happens, the software crashes or gives wrong results. Thus people are placed in an hazardous situation.
• This software crash or erroneous result may lead to an injury of people (same examples as those for defects)
• The risk is the assessment of:
  • the gravity of the injury,
  • the probability of occurence of the injury --> the probability of occurence of a software failure.

Ouch! the probability of occurence of a software failure?

We'll see later on how to deal with it.

Same chainning

What's interresting here, is that the chainning is the same for critical or major defects, and for software failures.
Remember that (as I said in my previous post):

• Critical and major defects can lead to a software failure,
• Minor and cosmetic defects don't,
• A Software failure can happen without any defect, for other reasons, like wrong input data, hardware failure.

We can add to this that:

• A defect can lead to an hazardous situation and a risk,
• A software failure can also lead to an hazardous situation and a risk.

Defects and software failures vs risks

But not all of defects and software failure could represent a risk.
For example, the archive function doesn't work on your desktop computer because:

• There's a defect in the software (eg, defect in the driver of the CDROM),
• The USB port is out (hardware failure).

If the archive function is not used at all for medical purposes but only by the manufacturer for technical purpose, it's possible to say that there's no risk "attached" to this software failure.

Warning, though, this is a very rare case.
To sum-up: There are 99% chances that critical and major defects, and software failures lead to risks.

This is represented in the diagram below.

The big picture

We've seen that:

• Most of defects (mainly the critical and major ones) generate software failures and represent a risk,
• Most of software failures (from a defect or not) represent a risk,
• Minor defects don't represent a risk,
• Some software failures (very few) don't represent a risk.

To continue and review all cases:

• Some risks are neither software failure, nor defects (those outside software ...),
• Most of minor and cosmetic defects don’t represent a risk,
• Some minor and cosmetic defects may represent a (very remote) risk,
• Some defects (very few), may generate software failure but don't represent a risk.

The last assertion is a bit far-fetched but is still possible ...

The big picture below summarizes all these cases.

Changes in the status of defects, software failure and risks

The status of a defect, a software failure, a risk is not frozen in the lifecycle of a software.
Especially far-fetched or very rare cases may hide more obvious situations. Namely when a critical defect or a software failure doesn't represent a risk now, it may represent a risk in the near future.
Example:

• A minor defect that represent a risk that is not acceptable shall be promoted to major or critical defect,
• A defect that generates a software failure, previously not seen as a risk, may represent a risk now.

The archive function I used as an example above, may become used by physicians to store patient data. Thus it is used for medical purposes and the software failure becomes risky.

Conclusion

I hope I managed to clearly differenciate all of these concepts. I guess reading this article gave you a headache. It gave me a headache writing it!
Next week, I'll post something more fun.

Oh, there is one remaining thing: the probability of occurence of a software failure. We'll see that the week after. Bye.