Menu
Menu
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.
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.
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!
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.
You can compare this with a waterfall approach where you typically aim to have nearly a full set of requirements and then go for a review. You will not verify as frequently as you do in Scrum, but you will spend more time in every review.
You can also work with Agile principles and meet the requirements of the standard. It is only a question of how you have chosen to meet the requirements.
With our medical device software course selection, you can choose between Software for Medical devices and IEC 62304 and SaMD, IEC 62304 and IEC 82304-1 depending on your interest and need.
The courses are suitable for anyone working with software development, such as R&D engineers, quality assurance department and auditors of software development. The courses do not cover actual coding.
Or if you’re looking for a tailored training to align with your company’s specific needs – contact us for inhouse training options.
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.
Receive FREE templates and quarterly updates on upcoming courses that can help you in your career! Subscribe to our newsletter now.
When you submit this form, you will be sending personal information to medicaldevicehq.com. To comply with GDPR requirements, we need your consent to store and use the personal data you submit. Take a look at our Privacy policy for more details.
Important! Please be advised that there will be scheduled downtime across our platforms from 13:00 CET Apr 26th to no later than 16.00 CET Apr 28th. During this period you will not be able to access the website or your account. For more information, please contact us at support@medicaldevicehq.com
