If you are developing medical device software, then you will be working closely with the IEC 62304 standard. The number of activities you need to complete according to the standard depend on how harmful your medical device is. This is decided with a software safety classification – the higher risks and severity linked to your software, the higher classification.

Find out more about the IEC 62304 standard and risks relating to medical device software development in this short video.


Probability of occurrence of harm

One of the most misunderstood statements in the medical device software field is that the probability of occurrence of harm should be set to 100% just because you are working with software. Wrong!

The probability of occurrence of harm can be split up into two components, P1 and P2. The probability of occurrence of the hazardous situation is P1 and the likelihood that the hazardous situation will lead to harm is P2.

Probability of occurrence of harm

When people are talking about the probability of occurrence of harm and claim it should be 100%, they refer to P1. But this assumption can also be challenged.

Do you know the answer to this question?

Here is an example where software is used to recommend the right medication. In this example, we assume that 1% of the patients are allergic to drug A.

We have five different drugs to choose from. The software fails by choosing the wrong medication, what is the Po for this risk?

Po for risk

The correct answer is; It depends on the type of software failure we are dealing with. Either the software failure results in randomly selecting one of the five drugs or the failure always results in choosing drug A.

For the sake of safety, we could assume that drug A will always be selected. But, if we are talking about random errors, then the likelihood for the software to only select drug B or any other drug is as high as it is for only selecting drug A. This results in a different scenario.

In the random drug example, I still agree that software failure will always happen, but you cannot predict the outcome. So, in this particular case, if the hazardous situation is that drug A is incorrectly chosen, then the likelihood of the hazardous situation occurring is 20% because it can be any of the five drugs.

That is why you need to start using P1 and P2. As long as you stay with Po only, you will find yourself in a very difficult situation!

Risks and software safety classification

The activities you need to perform according to the IEC 62304 standard vary depending on the classification of your medical device. Below, you will see a simplified flowchart of the standard. As you can see, the software safety classification is divided into A, B and C, where A is the lowest class, which means the software is not likely to contribute to hazardous situations, whereas C is the highest class, which is applicable when there is a likelihood of serious injury or even death.

Software safety classification

If your software is linked to risks with high severity, your classification will go up. There is a flowchart for the classification process in the standard. High severity should drive the rigour of your development process.

If you dislike the outcome of your classification, you can go back and change the intended use or the medical device. You could for example reallocate features from software to hardware, or you could change your requirements.

Would you like to know more about risk control in software?

If you are working with medical device software and would like to learn more about risk management in software development, then our online Introduction to Software Development and IEC 62304 course might be what you are looking for.

The courses on Medical Device HQ are taken by both competent authorities, notified bodies and medical device manufacturers and distributors. With us, you can learn more about software development and get your course certificate in just a few hours.

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.