The ABCs of software safety classification: Part 3 — Classification in practice

Applying the classification principles of IEC 62304 in real devices is a common stumbling block for many manufacturers, resulting in misclassified software systems and a lack of rigour in documenting key safety-relevant aspects of medical device software.

In Part 1 of this blog series, we established that software safety classification is a crucial step in the medical device software development lifecycle. Under IEC 62304, this classification informs the required depth of development activities, level of documentation, and ultimately how your submission will be received by the assessing body.

And yet, despite the rules outlined in Clause 4.3(a), many struggle with this in practice. This blog post will dive into how classification can be understood and applied in practice, as well as where teams often go wrong.

A quick recap

As covered in Part 1, classification hinges on three core concepts:

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

The supporting notes introduce key assumptions (further rationale for these assumptions is available in IEC 62304 Clause 7.2.2(b)):

• Assume software failure (probability = 1)
• Risk controls implemented in software are likewise assumed to fail

Classification case studies

Example 1: Software contribution & software segregation

A clinical decision support (CDS) app assists oncologists by suggesting treatment regimens based on patient data. It has:

• Core module - risk stratification algorithm that recommends chemotherapy dosage
• Support module - generates patient summary reports and stores them in PDF

Common misstep

A manufacturer classifies the entire application as Class C, since the core algorithm clearly carries high patient risk. However:

• They have not documented or demonstrated any level of software segregation, so supporting modules inherit an unnecessarily high classification
• A higher level of documentation and assessment rigour must now be applied against the entire device system

A better approach

• Maintain Class C for the algorithm module, as incorrect recommendations could directly lead to serious harm
• Segregate the software implementation of the reporting module from the algorithm module, such that it has independent operation and decision logic
• With proper evidence, the support module can likely be classified as Class A, reducing the required rigour in meeting IEC 62304 requirements
• Provide supporting evidence to demonstrate software-segregation effectiveness (e.g. architectural diagrams and/or segregation-testing reports)

Takeaway

In Software as a Medical Device (SaMD), demonstrating which modules contribute to clinical risk and proving effective segregation avoids over-classification and unnecessary rigour in documenting safer software modules.

Example 2: Probability of failure (inside and outside of software)

A wearable heart-monitoring app tracks ECG signals and alerts patients if it detects arrhythmias that may require medical attention.

Common misstep

A manufacturer argues that classification should be Class B, with the following reasoning:

• The algorithm’s false negative rate is statistically very low
• Patients are instructed to seek follow-up if symptoms persist, providing a “safety net”

This reasoning relies on probability of failure (low false-negative rate) rather than severity of possible harm.

A better approach

• IEC 62304 requires classification by severity of harm, regardless of probability. Remember that probability of software failure is assumed to be 100% (=1)
• If the app outputs a false negative, the downstream effect could be potentially life-threatening outcomes
• Even if clinicians are brought into the loop, the probability of failure may still create unacceptable risk
• The core software module is therefore at least Class C, unless robust safeguards external to the software system or other factors justify that the risk is acceptable

Takeaway

For SaMD, developers must resist the temptation to reduce classifications based on low probability of failure. The severity of potential harm is the key factor in determining software safety classification.

Example 3: Risk-control failure & implementation considerations

A radiology image post-processing tool generates 3D reconstructions from CT scans to aid surgical planning. Risk controls include:

• An internal consistency checker that flags corrupted image data
• Requirement for clinician approval before use in surgery

Common misstep

The manufacturer has:

• Assigned Class B, arguing that risk controls (internal software checker & human review) mitigate the risk of poor image data
• Demonstrated that the internal checker is implemented in software, but sufficiently segregated from the core post-processing tool

However, they fail to account for the broader assumption of software failure, which also applies to software-based risk controls.

A better approach

• Since the internal consistency checker is implemented in software, failure must be assumed, leaning on severity of potential harm. In this case, Class C may be warranted
• If the internal consistency checker is implemented in a software module, either module does not inherently receive lower classification. In fact, IEC 62304 Clause 7.2.2(b) states: “assign to each software item that contributes to the implementation of a risk control measure a software safety class based on the risk that the risk control measure is controlling”. This would mean that both modules (the one introducing risk and the one implementing a related risk control) would be classified as Class C
• Human review, while a valid control, may only result in this risk being acceptable under the broader context of ISO 14971 when working in tandem with software-based risk controls. Once software failure is assumed, this risk may be unacceptable under IEC 62304
• The device may benefit from supplementary risk-acceptability determinations where risks have been mitigated with software-based controls in order to justify lower classifications. Manufacturers may need to demonstrate that some risks remain acceptable even once software failure is assumed

Takeaway

When documenting risk controls in software, modules implementing risk controls must be classified based on the risks those measures are controlling, and risk controls external to software need to be considered in the context of software failure.

Context matters

There are, however, scenarios in which each of the above ‘missteps’ could be perfectly reasonable approaches to software safety classification.

Not every device configuration and software architecture can be accounted for — it is ultimately up to manufacturers to clearly describe and demonstrate their device’s software architecture and be transparent about the possible harms that may occur.

Here are a couple of examples of alternative approaches that may suit specific software architectures and clinical applications.

Significant contributing factors external to software

A device, upon initial risk analysis as per ISO 14971:

• Has a key risk that is deemed acceptable on the basis of low occurrence of risk factors in patient populations and low probability of software failure
• Risk controls in and out of software are in place

Based on IEC 62304, even once software failure is assumed, this risk may remain acceptable, based solely on the probability of other non-software factors. In this case, the probability of occurrence in patient populations may be sufficiently rare to justify risk acceptability. Risk control external to software may also play a part here.

Even if software failure is guaranteed, other factors can demonstrate that the risk is still acceptable — allowing the software system or module to be deemed Class A.

Consolidating risks and risk controls into specific modules

A device that carries multiple significant risks that could cause significant injury would usually warrant either an overall Class C classification, or multiple Class C modules due to contributions to risk factors and risk controls.

If a manufacturer anticipates this upfront through thorough initial risk analysis activities, they benefit from being able to approach software-system design with IEC 62304 in mind. 

In practice, this could involve:

• A software architecture that consolidates these risk factors and risk controls into one or a small number of ‘critical’ Class C modules
• Demonstrating segregation between core operations in these modules and others that provide supporting functionality

This means that the high level of rigour required of IEC 62304 is only applied where absolutely necessary. Consideration of this standard in the foundations of a device’s design also demonstrates a strong understanding of regulatory requirements and consideration of user safety.

Summary

Getting software safety classification right under IEC 62304 can be tricky, but it’s one of the most important steps for SaMD development. As we’ve seen, mistakes often come from over-classifying whole systems, leaning on low failure rates instead of harm severity, or forgetting that software-based risk controls can fail too.

Context is everything.

Break down your software into clear modules, document segregation properly, and always classify based on the worst-case harm if the software fails. Doing this not only makes your submission stronger but also keeps the focus where it should be — building safer, more reliable tools for patients and clinicians.

Read Part 1 & Part 2 if you haven't already.