How to determine the Software Safety Classification?

Incorporating software in medical devices and building stand-alone software-as-medical-device (SaMD) devices is getting increasingly popular in our industry. For medical device manufacturers developing or incorporating SW, the IEC 62034 is the main go-to standard, representing the current-state-of-the-art to ensure compliant SW development and maintenance.

IEC 62304 details required development activities depending on the risk level of the software. The higher risk the device poses, the more activities the standard requires you to perform. IEC 62304 uses the concept of "Software Safety Classification" to determine the minimum set of activities required for a given risk level. Determining the appropriate SW Safety classification gets you the best match between the effort of the required risk reducing activities and the risk your device poses.

But how, exactly, can the safety class be determined?

A method to determine IEC 62304

Let's present the method described in IEC 62304. Starting out, we assume the highest possible class (Class C) by default. Then, we ask ourselves the three important questions that let us define the correct safety class for our device.

Question 1: "Would failure of the SW contribute to patient/user being exposed to a Hazard?".

To answer this question, clear intended purpose and good knowledge of the SW architecture and functioning are required. If the answer is "No", the class is considered to be the lowest (Class A) and no further questions are required.

However, if the outcome is "Yes", things start to get interesting! By getting this far, the conclusion is that a SW failure CAN "expose patients to hazards". But how bad is that?

To proceed, we must conduct a risk analysis according to ISO 14971 to identify, mitigate and evaluate the risks caused by SW failure in our device. The result will be a list of residual risks with a determination of their acceptability.

With the residual risks available, we can address:

Question 2: "Are the residual risks related to a SW failure unacceptable"?

If the answer is "No", again, the safety class result in the lowest class, Class A, and no more questions are required.

If the answer is "Yes" (i.e. there is at least one residual risk related to SW failure that is not acceptable), the result is either Class B or Class C depending on the severity if the (unacceptable) residual risks.

Arriving at our final question, we ask:

Question 3: "Is the resulting injury from the residual risks 'serious' or 'non-serious'?"

Determining whether an injury is serious or not is based on definitions provided by IEC 62304.

If "serious", we get a Class C.

If non-serious, we end up with Class B.

The curveball: SW Failure occurs with 100% probability

We conclude that the risk analysis is central to the process of determining the appropriate software safety class.

However, to accommodate to the special characteristics of software, IEC 62304 requires two specific additional constraints when performing the risk analysis for safety class determination:

• SW failure occurrence shall be assumed to be certain (e.g. the SW failure probability of occurrence shall be 100%).

• To mitigate risks arising from a sequence of events involving a SW failure, only risk control measures external to the failing SW can be considered.

It is the first constraint, in particular, that has caused headaches in an entire industry. At face value, it seems to entail that "with an assumed failure probability of 100%, the vast majority of our risks will become unacceptable, and we will end up with Class C". For those developing software, this seems absurd since they can observe with their own eyes that the software, in fact “does not kill everyone, every time!".

Software Failure Only One Step in Event Sequence Leading to Hazards

By taking a closer look at what constitutes the probability of a risk, we can come to grips with the infamous 100%.

ISO 14971 defines risk as the “combination of the 'probability of occurrence of harm' and the 'severity of that harm'”. Further, the overall 'probability of occurrence of harm: P' is (according to the standard) the intersection of two separate probability components, that we’ll call “P1” and P2”:

• P1 reflects the probability of a hazardous situation to occur; and
• P2 reflects the probability that a hazardous situation results in a defined harm.

Whereas P2 in general depends on clinical factors, P1 on the other hand, is the result of a sequence of events, where each of the events have its own probability to occur. Together, they lead up to the occurrence of the hazardous situation.

The important point is that in this sequence of events, the SW failure may constitute only one link in such a chain of events.

If the probability of occurrence of the other events in the sequence can be justified as not being 100%, then the combined P1 (of occurrence of the hazardous situation) will be lower than 100% even if the SW failure is considered certain (as required by IEC 62304).

100% SW Failure Probability in Safety Classification vs. Risk Management Activities

Another common misconception is that "SW failures probability is 100%"-assumption shall be applied throughout the entire risk management lifecycle.

This is not what IEC 62304 says. The standard only requires this assumption in the context of SW safety class determination.

Should you have data demonstrating that a given SW failure probability can reliably be estimated (at a lower value than 100%), IEC 62304 does not forbid the use of an "evidence-based" SW failure probability estimate in the context of the risk management activities executed to evaluate the benefit/risk profile of the medical device.

Accurate Software Failure Risk Assessment: Streamlining Regulatory Efforts

Since 2006, the "SW failures probability is 100%"-assumption has been the “bête noire” of IEC 62304. Still today, the question causes agitation among professionals.

To summarize what we know so far, we conclude that:

• In the context of determining a SW safety class (and only in this context), the standard indeed requires SW failures to be considered as occurring with maximal probability (100%).

• However, considering this to imply that SW failure-related harm occurrence is always 100% is a simplification. The SW failure may only be one element in the sequence of events leading to a hazardous situation. The sequence as a whole might not always (i.e. with a 100% probability) result in patient/user harm.

• Therefore, to dogmatically estimate the SW-related harm occurrence probability as maximal might result in an artificially high IEC 62304 safety class assignment. This, in turn, leading to unwarranted additional development, testing or documentation effort.

About the Expert

Valentin Chapuis is a Senior Expert in Quality and Engineering at ISS AG, with seven years of experience in the MedTech industry and consultancy. Holding a Master of Science in Materials Science and Engineering from EPFL, he specializes in risk management (ISO 14971) and compliance for medical device software.