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.
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?
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.
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 learn more about Medical Software Development?
Get instant access to our online Software for Medical Devices and IEC 62304 course right here. In 6 hours, you canLearn how to be effective in medical software development according to the process of the IEC 62304.
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 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.