If you work in the medical device industry, then you know software risk management is not to be taken easy. The following video comes from our online course Introduction to software for medical devices and IEC 62304 and it might help clear some of the tricky details related to reducing software-related risks.

Bear in mind that this article is an overview of the basics, and is not the same as taking the course. Our courses deal with medical device industry topics in-depth, but if you’re interested in reading more blog posts like this one, you can find them all here.

The best way to start is to name the three most common problems:

  1. Not understanding how to manage the probability of software failure
  2. Software risks usually cannot be properly managed in risk assessment templates
  3. Confusing similar terms, such as software risk controls and risk controls implemented by software

“Software risk control” vs “Risk controls implemented by software”

In this field of work, it happens occasionally that two very similar names denote quite different things, and this kind of confusion is often complicating software risk management. For example, “software risk controls” and “risk controls implemented by software” sound almost identical, yet confusing them would also confuse your risk management work.

“Risk controls implemented by software” means that software is used to reduce the probability of harm for functionality outside of the software itself. In order to minimize risk, the software could for example issue a warning, which is a risk control measure, but not a software risk control measure.

On the other hand, a software risk control measure is used to reduce the likelihood that a failure in the software can contribute to a hazardous situation.
A simpler explanation might be that risk controls implemented by software are used to reduce the risks OUTSIDE the software, whereas software risk control measures deal with the risks WITHIN the software itself.

Perhaps your head starts spinning now, but when implementing risk control measures in software, you should also evaluate if you need to add software risk control measures to assure the safe functionality of the implemented risk control measure.

Software risk management

The scope of software risk management (in this text referred to as P1), as defined by IEC 62304, is about software risk controls. Sometimes, we want to add risk control measures to reduce the likelihood of harm occurring, and this is referred to as P2. This type of measures usually refers to risk control measures outside of software and should be documented in the system risk analysis.

Risk according to ISO 14971 2

We should always start with the assumption that a software failure will always occur, but, this does not mean that the probability of the occurrence of harm, Po, should be set to a hundred percent, because this implies that a failure will always occur and that it will always lead to harm.

Software risk management is about finding the methods and ways to reduce the likelihood of P1, and this is done by taking the actions we believe will minimize the probability of failure.

Steps in software risk management

The first thing to do is always to identify potential causes for software failures. When researching the causes, there are several things to do.

Firstly, a well-established development process serves to reduce the probability of mistakes, i.e. software failures.

The next step is to research the options to reduce the likelihood of software failing on the software system level – this often relates to architectural design.

Lastly, evaluate your options at software item level. But be careful here! When working with risk control measures at software item level, this is often related to adding functionality to the source code, such as protecting data with checksums. The tricky thing here is that adding more source code also means that more things can go wrong.

Steps in software risk management

It is worth mentioning that it is acceptable to combine different risk control measures. Naturally, one would assume that the probability of occurrence of hazardous situations will become lower with this, but we should remember that there is always a remaining risk.

Multiplying many small numbers will eventually result in zero which is not reasonable when working with software. Therefore, it is suggested to define the lowest possible P1 regardless of how many values are multiplied. This can be documented in the risk management plan, or software development plan.

Software risk assessment

As always, we must remember documentation! One option is to integrate software risk management into a hazard traceability matrix.

A typical HTM includes the following elements: hazard, reasonably foreseeable sequence or combination of events, hazardous situation, harm, probability of occurrence (Po), severity (shortened to S), and a conclusion whether the risk is acceptable or not. Finding only Po in the HTM is not enough – if you work a lot with software, you should expand the matrix to also include P1 and P2. Po can then be based on the combination of P1 and P2. You can choose if you want to use this approach only for software-related risks but there is certainly no harm in using this approach to all your risk management work.

hazard traceability matrix 1

Ultimately, based on a multiplication of P1 and P2 you can now calculate Po and convert it into a semi-quantitative number which is commonly used for Po. With the help of Po and the severity, you can determine whether the risk is acceptable or not.

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 portrait

Christian Kaestner

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 IEC62304 and also actively participated in the creation of IEC82304-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.