Is my software in class A, B or C? - 2015 reloaded
Almost four years since I wrote in 2012 the post Is my software in class A, B or C?.
In 2015, IEC 62304 Amendment 1 was published, changing a bit the game about software safety class.
Is my software in class A, B or C? is the second most viewed page on this website, after the templates repository for software development process.
Thus it deserves an update to explain how the software safety class is assessed with IEC 62304 amendment 1.
IEC 62304:2006 defines in section 4.3 the software safety classes, based only on the consequence of a hazardous situation on the patient:
- Class A: No injury or damage to health is possible
- Class B: Non-SERIOUS INJURY is possible
- Class C: Death or SERIOUS INJURY is possible
Another way of viewing this definition is to disregard the probability of risks linked to a software failure, and to focus only on the severity.
Here is an example of risk matrix:
Remark: don't take account of discussions about ISO 14971:2009 vs ISO 14971:2012 and risk acceptability criteria. The words unacceptable, tolerable and acceptable are here just examples to support the current discussion.
The software safety classes can be seen as areas on the risk matrix:
But this point of view has been challenged by manufacturers, when software-related hazards don't represent an unacceptable risk, prior to software mitigation action (i.e. prior to a mitigation action only implemented in software).
For example, a life sustaining medical device contains embedded software. The life sustaining functions are managed by plain old electronics. The embedded software is here to record and display informative data. But for some reason (this is just an example), a software failure could result in a hazardous situation for the patient that could lead to a serious injury. The probability of such situation is improbable (less that once is the device lifetime) and no mitigation outside this software system was identified.
With IEC 62304:2006 this embedded software is in class C, hence we have at least one risk of critical severity prior to software mitigation action where software failure is the hazardous phenomenon.
Although this risk has a high severity, the risk evaluation matrix of manufacturers usually deems a risk acceptable or tolerable for the cell (critical, improbable). Thus setting the software in the highest class doesn't match the acceptability of the risk prior to software mitigation action.
That's one reason for the amendment of IEC 62034:2006. Let's see what has changed in the amendment, in section 4.3 where software safety classes are defined.
IEC 62304 Amd1 2015
The definitions of software safety classes were totally reworded:
- The SOFTWARE SYSTEM is software safety class A if:
- the SOFTWARE SYSTEM cannot contribute to a HAZARDOUS SITUATION; or
- the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which does not result in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM.
- The SOFTWARE SYSTEM is software safety class B if:
- the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM and the resulting possible HARM is non-SERIOUS INJURY.
- The SOFTWARE SYSTEM is software safety class C if:
- the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM and the resulting possible HARM is death or SERIOUS INJURY.
These definitions are accompanied by a flowchart, which explains at a glance the selection of safety class.
Here is a snapshot of the flowchart found in section 4.3 of IEC 62304 Amd1 2015:
The questions can be mapped to the above definitions:
- Answering 'No' to Question 1 = First bullet of definition of class A,
- Answering 'No' to Question 2 = Second bullet of definition of class A,
- Answering 'Yes' to Question 1 and 2 = first part of the definition of class B and class C (the common part, before the words "and the resulting..."),
- Answering 'Non serious injury' to Question 3 = definition of class B,
- Answering 'Serious injury' to Question 3 = definition of class C.
The consequence of these definitions is the introduction of the acceptability of risks in the assessment of software safety class:
- IEC 62304:2006: severity only
- IEC 62304:Amd1:2015: severity and risk acceptability.
Using the same legend as in the previous matrix, the software safety classes areas can be represented like this:
The class A region can be extended to the upper side of the matrix. This is possible thanks to the sentence in bold in the definition of class A written above. In our example, the cell (critical, improbable) sees its corresponding software safety class set to class A, hence the risk is acceptable.
FDA level of concern
The concept of level of concern defined by the FDA somewhat overrides the concept of safety class found in IEC 62304. The guidance which defines it, is still applicable and hasn't changed since 2005.
Worse, the guidance was reviewed by the FDA in 2015, upon the retrospective review process. There is no information on the FDA website stating that it should be modified after the changes of IEC 62304 Amd1.
The definition of level of concern remains as is since 2005, and is to some extent stricter than the IEC 62034 Amd1 2015 software safety classes.
You could come up with a software system in class A for IEC 62304 Amd1 2015, and in major or moderate level of concern for FDA. Thus don't be too much excited by the amended version of IEC 62304. Your software system could require all the documentation overhead for major or moderate level of concern, while it is deemed in class A for IEC 62304. Or you may have to argue for the low level of concern with FDA reviewers.
IEC 62304 Amd1:2015 brings a major change to the definition of software safety classes. It will prevent manufacturers from classifying software in a high class, in contradiction with the results of the risk management process.
However, it also adds a gap to the concept of level of concern defined by the FDA. Aligning the level of concern of a software system, with the software safety class of IEC 62304 Amd1 2015, may not be accepted by the FDA. In this case the software documentation overhead cannot be avoided.