The ABCs of software safety classification: Part 1 — A closer look at IEC 62304 4.3

The level of detail required in medical device software documentation (as required by IEC 62304) hinges heavily on the concept of software safety classification — a key idea that comes with a host of often-overlooked nuances.

Much of the applicability of IEC 62304 leans on the safety classification of the software items that make up software as a medical device (SaMD), as many of its requirements are only relevant depending on whether a software item has been classified as A, B or C — where C is the highest classification reserved for high-risk software items that could contribute to serious injury. 

Generally speaking, software safety classification is a tool leveraged throughout IEC 62304 that results in more detail and diligence being required of the documentation of a software item the higher the safety risk associated with it. Despite the impact of this classification on the scope of the technical file, it is surprisingly common for manufacturers to overlook crucial details, leading to misclassified software items and gaps in their technical file submissions.

Thankfully, IEC 62304 Clause 4.3 also provides the necessary framework to help manufacturers determine these safety classifications. This framework incorporates many elements of risk management (IEC 14971), while applying specific interpretations in the areas of risk probability and risk controls. 

In this blog post, we’ll dive into some of the nuances of this classification framework and explore their relationships to risk-management processes.

An important distinction

It is important to point out that software safety classification (IEC 62304) is an entirely distinct concept from device risk classification (EU MDR). While these two classifications both relate to risk, they are determined based on different criteria, and affect different aspects of SaMD regulatory conformity:

Despite these distinctions, confusion often (and understandably) arises from where these concepts and terminologies overlap, particularly in areas related to risk management and IEC 14971 requirements. 

Look out for a follow-up blog post where we’ll do a deeper dive into the interplay between IEC 62304 and IEC 14971.

A, B, or C?

With that distinction clarified, let’s look at how software safety classification is determined:

Exact classification rules can be found in IEC 62304 Clause 4.3.a.

It is worth highlighting that under IEC 62304, Class C does not necessarily mean “dangerous.” Fundamentally, it surfaces components where, if software fails and there are no external mitigations, the potential harm to users could be serious injury or death. 

These rules rely on three core concepts for classification:

• Software system contribution to hazardous situations
• Possible harms and whether those harms include death and/or serious injury
• Risk acceptability after the consideration of risk controls implemented external to the software system

A singular software safety classification can be assigned to the software system as a whole, or to individual software items by justifying risk segregation, which can allow for different classifications. See one of our previous blog posts that discusses risk segregation and software architecture in further detail.

A note on notes

Clause 4.3.a asserts some critical assumptions and interpretations on how to handle risks that arise from software failure:

In determining the software safety classification of the SOFTWARE SYSTEM:

• Probability of a software failure shall be assumed to be 1.

• Only RISK CONTROL measures not implemented within (external to) the SOFTWARE SYSTEM shall be considered.

Note: Such RISK CONTROL measures may reduce the probability that a software failure will cause HARM, and/or the severity of that HARM.

Note: A SOFTWARE SYSTEM which implements RISK CONTROL measure may fail, and this may contribute to a HAZARDOUS SITUATION. The resulting HARM may include the HARM which the RISK CONTROL measure is designed to prevent (see 7.2.2b)

In practice, this has an impact on:

• How manufacturers determine the probability of risks, hazardous situations, and harms, where a contributing event involves software failure — as software failure is now assumed to be expected
• How manufacturers think about risk controls and their implementation — as only those implemented externally to the software system can impact software safety classification

In a future blog post, we’ll discuss how some of these assumptions and interpretations apply in practice, and more importantly how they may affect manufacturers’ overall approach to risk management.

Summary

Software safety classification dictates the documentation rigour required for medical device software (as per IEC 62304), and can significantly impact the scope of manufacturers’ technical documentation. However, it is important to remember that this classification is distinct from EU MDR Device Risk Classification, and brings with it very specific assumptions on how to handle software failure probability and risk controls. 

In Part 2, we’ll explore the differences in approach to risk between IEC 62304 and IEC 14971 — including intent, common pitfalls, and how that can influence a manufacturer’s approach to software architecture. 

Note: An updated version of IEC 62304 is currently being drafted and is expected in 2026. The current draft introduces changes to software safety classification, moving away from the existing A, B, C classification in favour of two levels of rigour and consistency with IEC 81001-5-1. Expect an updated blog post from Scarlet once those changes are introduced.