This is the fourth in a series of blog postings in which we present a top-ten list of common errors encountered in the context of medical projects. Of course, such a ranking depends on personal observations and individual experience – and hence has a subjective outcome. Please feel invited to tell us about your perspective in the comments section!
In today’s post, we focus on a single statement found in the IEC 62304 standard – a statement that has caused a lot of confusion over the years.
Section 4.3 of the aforementioned standard is all about software safety classification. To this end, the standard defines three safety classes for software systems (and for individual software items, too, if applicable), namely in item 4.3(a). The criteria used in the definition put an emphasis on the severity, not the probability, of related hazards. For example, if a software system can contribute to a hazard possibly resulting in the death or serious injury of a person, then that software system must initially be considered to be in class C.
In order to underline the fact that severity, not probability, is the key to classification, earlier versions of the standard went on to state that the probability of failure shall be assumed to be 100 percent. This comment has been misinterpreted again and again, making people believe that software failures must be considered to have probability one in the context of medical software, no matter what the question is.
The above misinterpretation can easily have undesired consequences: For example, if all software failures are considered equally likely in an FMEA (Failure Mode and Effects Analysis), then the resulting rank order of risks will not reflect the true criticality. Inapproriate importance will be given to esoteric failure scenarios, and hence, the resulting risk mitigation measures (RMMs) will be out of proportion. In the big picture, this leads to medical products that are less safe than they could have been!
Amendment I (IEC 62304A1:2015) replaces item 4.3(a) with a new definition of the safety classes based on a decision diagram. Unfortunately, the diagram paraphrases the misleading statement discussed above, saying that the probability of a software failure shall be assumed to be one. On the positive side, however, the text in the diagram puts this statement into context – it makes explicit that the probability-one rule is only to be applied when determining the classification. Let us hope that this reduces the confusion in the future.
Coming up next: #6, As Low As Reasonably Practicable. See you there!
Top Ten Errors in Medical Projects – #8: Eager Beaver / Lazy Bum
Top Ten Errors in Medical Projects – #9: Process versus Project
Top Ten Errors in Medical Projects – #10: Clinical Something!