Why Software Safety Classes Can Be Reduced Through Other Risk Control Measures

In medical device development, ensuring software safety is an unavoidable critical issue. Particularly in recent years, with the introduction of AI technology and the advancement of IoT, the role of software in medical devices has become increasingly significant. This article explains why the safety class of medical device software can be reduced through other risk control measures, along with the rationale and practical considerations.

IEC 62304 and the Fundamental Concept of Software Safety Classes

Overview of the IEC 62304 Standard

IEC 62304 is an international standard concerning the lifecycle processes of medical device software. This standard defines requirements for ensuring safety throughout all processes, from software development planning to maintenance and decommissioning. The current version is IEC 62304:2006, with Amendment 1 published in 2015. However, a significant revision is underway, with the second edition expected to be published in 2026.

Classification of Software Safety Classes

IEC 62304 currently classifies software safety classes into the following three levels:

Class A: No injury or harm to health occurs Class B: Possibility of non-serious injury occurring Class C: Possibility of death or serious injury occurring

This classification is determined based on the degree of potential harm that software failures or defects could cause to patients or users. It is important to note that this classification is based on the severity of potential harm, not on the probability of occurrence.

Important Changes in the Second Edition

The draft of the second edition of IEC 62304, scheduled for publication in 2026, introduces significant changes to the classification system. The current three-level software safety classes (A, B, C) will be replaced by a two-level “Software Process Rigor Level” system (Level I and II). This change aims to simplify the classification process and align with related standards such as IEC 81001-5-1. Level I essentially corresponds to the current Class A, while Level II encompasses the current Classes B and C. Additionally, the standard will expand its scope from medical device software to all health software, and will include specific requirements for AI, machine learning, and deep learning technologies.

Mechanism for Reducing Safety Classes Through Risk Control Measures

Concept of System-Wide Safety Evaluation

A distinctive feature of IEC 62304 is that it evaluates safety in the context of the entire system, rather than software in isolation. This reflects the fact that medical devices are complex systems composed of multiple elements, including software, hardware, and mechanical components.

As a critical point, IEC 62304 requires assuming a 100% probability of software failure when determining safety classes. This conservative assumption treats software as if it will inevitably fail, and then evaluates the effectiveness of external risk control measures for protection. However, it is important to understand that this assumption applies specifically to determining the initial hazardous situation. When calculating overall risk (probability of harm occurring), it becomes necessary to consider the probability of transition from a hazardous situation to actual harm (P2 in ISO 14971 risk management terminology).

Types and Effects of Risk Control Measures

Risk control measures mainly include the following methods:

Hardware-Based Protection Functions

Hardware-based protection functions provide safety mechanisms that operate independently of software. Watchdog timers detect abnormal behavior and initiate recovery procedures. Independent safety circuits can forcibly stop device operation when dangerous conditions are detected. Redundant systems implement fail-safe designs where backup systems take over when the primary system fails.

Mechanical Safety Mechanisms

Mechanical safety mechanisms provide physical protection that operates regardless of software state. Physical stoppers and limiters mechanically prevent movement beyond safe ranges. Pressure relief valves and other safety devices automatically operate when preset thresholds are exceeded. Manual override functions allow operators to directly control devices when software malfunctions.

Electrical Protection Circuits

Electrical protection circuits provide safeguards for electrical hazards. Overcurrent protection circuits prevent excessive current flow. Insulation monitoring systems detect deterioration of electrical insulation. Emergency stop circuits enable immediate power cutoff in dangerous situations.

Real-World Examples of Safety Class Reduction

Consider the software of an insulin pump as an example. If evaluated solely as software, it might be classified as Class C due to the risk of overdose from malfunction. However, by implementing the following hardware protection functions, the system’s overall risk can be reduced:

Independent flow rate monitoring circuits detect abnormal delivery rates and trigger alarms or automatic stops. Mechanical maximum dose limiting mechanisms physically prevent delivery beyond preset limits regardless of software commands. Automatic stop functions upon battery abnormalities ensure the device cannot operate in potentially dangerous degraded states.

Through these protection functions, the possibility of software defects directly causing harm to patients is significantly reduced, making it possible to lower the safety class to B or even A. The key principle is that while software failure probability remains 100% for classification purposes, the external risk control measures prevent that failure from resulting in serious harm to the patient.

Original Risk Scenario	Risk Control Measure	Residual Risk After Control	Resulting Safety Class
Software malfunction causes overdose (Class C)	Independent hardware flow monitoring + Mechanical dose limiter	Minor deviation possible, serious harm prevented	Class B or A
Display error causes treatment delay (Class B)	Audible alarms + Backup visual indicators	Timely error detection ensured	Class A
Communication failure affects monitoring (Class B)	Automatic safe state transition + Local data logging	Patient safety maintained during disconnection	Class A

Considerations for Regulatory Authority Submissions

Requirements for FDA Submissions

When submitting to the U.S. FDA, it is important to note that a different approach from IEC 62304 is required. The FDA uses the concept of “Documentation Level,” which is evaluated based on the software’s risk level before applying other risk control measures.

In the FDA guidance revised in June 2023 (effective August 14, 2023), two documentation levels are defined:

Enhanced Documentation: Required when there is a risk of death or serious injury before risk mitigation measures are applied Basic Documentation: All other cases

This replaces the previous three-level “Level of Concern” system (Minor, Moderate, Major) with a simplified two-level approach. This approach fundamentally differs from IEC 62304’s method of determining safety classes based on residual risk after applying risk control measures. The FDA explicitly requires evaluation of software risks “prior to the implementation of risk control measures,” making it impossible to reduce documentation requirements through external risk controls. Therefore, special attention is required when planning FDA submissions, as a device with Enhanced Documentation requirements due to pre-mitigation risks cannot be downgraded to Basic Documentation even if effective hardware controls are implemented.

The practical implication is that manufacturers must maintain two parallel assessments: one for IEC 62304 safety classification (considering risk controls) and another for FDA documentation level (before risk controls). This dual approach ensures compliance with both frameworks but requires careful documentation management.

Response in Japan and Other Regions

Japan’s Pharmaceuticals and Medical Devices Agency (PMDA) and European Notified Bodies fundamentally accept approaches compliant with IEC 62304. In Japan, software documentation conforming to IEC 62304 is generally accepted as part of technical documentation for regulatory approval. European conformity assessment under the Medical Device Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR) also recognizes IEC 62304 as a harmonized standard, making compliance a key pathway to demonstrating conformity with essential requirements.

However, there are subtle differences in regulatory requirements among countries, making it necessary to respond appropriately according to the target market. For instance, while the EU emphasizes cybersecurity considerations alongside IEC 62304 compliance, Japan may have specific expectations regarding software validation documentation formats. Understanding these regional nuances helps manufacturers prepare comprehensive and appropriate submissions.

Practical Recommendations

Integration of Risk Management Processes

For effective safety class management, it is important to operate the following processes in an integrated manner:

Initial Risk Analysis: Identify worst-case scenarios for software in isolation, assuming 100% probability of software failure and evaluating potential hazardous situations that could result.

Risk Control Design: Select and implement appropriate protection functions based on the hazardous situations identified, ensuring these controls are effective, reliable, and independent of the software whose failure is being mitigated.

Residual Risk Evaluation: Re-evaluate risk levels after applying protection functions, considering both the effectiveness of risk controls and any new risks introduced by the controls themselves.

Verification and Validation: Confirm the effectiveness of protection functions through rigorous testing, including failure mode testing where software is deliberately caused to fail to verify that risk controls operate as intended.

The integration of these processes should be documented in a comprehensive risk management file that demonstrates traceability from initial hazards through implemented controls to verified residual risks. This integrated approach aligns with ISO 14971 requirements and supports regulatory review efficiency.

Importance of Documentation

To fulfill accountability to regulatory authorities, it is essential to properly create and maintain the following documents:

Risk analysis reports should comprehensively identify all potential hazardous situations and their severity classifications. Design rationale for risk control measures must explain why specific controls were chosen, how they address identified hazards, and why they are considered effective and reliable. Verification test results should provide objective evidence that risk control measures perform as intended under both normal and fault conditions. Traceability matrices should link hazards to risk controls to verification activities, ensuring nothing is overlooked.

When using external risk control measures to reduce safety classes, it is particularly important to document evidence verifying the effectiveness of those measures. This should include detailed test protocols, acceptance criteria, test results, and analysis demonstrating that the controls successfully prevent hazardous situations from progressing to harm. In the draft considerations for the second edition of IEC 62304, this verification requirement is expected to be further strengthened, with more explicit requirements for demonstrating independence and reliability of risk control measures.

Manufacturers should also maintain documentation explaining their safety classification rationale, particularly when claiming class reduction through risk controls. This documentation should clearly articulate the logical progression from potential software failures through hazardous situations to potential harms, and then demonstrate how each risk control measure breaks this chain of causation. Such thorough documentation not only satisfies regulatory requirements but also provides a solid foundation for design modifications, safety updates, and post-market surveillance activities throughout the product lifecycle.

Conclusion

The ability to reduce software safety classes through external risk control measures reflects the system-level approach embedded in IEC 62304. This principle recognizes that patient safety depends not solely on software perfection, but on the effective integration of multiple protective layers within the medical device system.

However, regulatory requirements continue to evolve. The upcoming second edition of IEC 62304 will introduce simplified classification with two rigor levels instead of three safety classes, while the FDA maintains its distinct approach of evaluating risks before risk control implementation. Manufacturers must navigate these different frameworks while ensuring genuine patient safety.

Effective implementation requires comprehensive risk management that considers software within its full system context, rigorous verification of risk control effectiveness, and thorough documentation that demonstrates the safety rationale to regulatory authorities. As medical devices incorporate increasingly sophisticated software capabilities, including AI and machine learning, the principles of system-level risk assessment and multi-layered risk control become ever more critical.

By understanding and properly applying these concepts, manufacturers can develop medical device software that achieves appropriate safety classifications while maintaining the highest standards of patient protection. The key lies not in minimizing documentation burden, but in implementing genuinely effective risk control strategies that are thoroughly understood, properly verified, and clearly communicated to all stakeholders including regulatory authorities, users, and patients.