Regulatory Requirements for Medical Device Software Development

Background and Challenges

In the recalls of electrical medical equipment (ME devices), design-related issues account for a significant proportion, with an extremely high percentage attributable to software defects. Recent studies have revealed that software-related problems are among the major causes of medical device recalls. According to 2024 data, medical device recalls reached a four-year high with 1,059 events recorded. Software issues range from coding errors to design flaws and can directly impact patient safety.

History of Regulatory Strengthening at the FDA

In recent years, regulatory authorities, particularly the U.S. Food and Drug Administration (FDA), have significantly strengthened their review processes for software in medical devices.

In 2010, the FDA conducted a comprehensive review of the 510(k) process. Prior to this, software reviews in 510(k) submissions were insufficient, resulting in devices with inadequately verified safety reaching the market, which led to a series of device recalls. As a consequence of this situation, the FDA faced severe scrutiny from Congress.

Subsequently, the FDA developed a comprehensive action plan to strengthen its software review framework. Furthermore, historical data confirms an upward trend in the rate at which the FDA requests AI (Additional Information) for 510(k) submissions.

Latest Regulatory Developments

In January 2025, the FDA published draft guidance titled “Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations.” This guidance provides recommendations for the development, validation, and submission of AI-enabled medical device software functions, emphasizing the importance of transparency, performance monitoring, and risk management throughout the product lifecycle.

In June 2025, the latest 510(k) guidance was issued, incorporating stringent cybersecurity requirements for medical devices. These requirements must be incorporated from the initial stages of device development and submission to ensure patient safety, data integrity, and regulatory approval.

Additionally, in September 2025, final guidance on Computer Software Assurance (CSA) for production and quality system software was issued. This updates Section 6 of the 2002 General Principles of Software Validation (GPSV).

IEC 62304 as a Regulatory Requirement in Japan

Legal Basis and Implementation Timeline

In Japan, IEC 62304 (Medical Device Software – Software Lifecycle Processes) became a substantive regulatory requirement on November 25, 2017. This is based on Article 12, Paragraph 2 of the Pharmaceuticals and Medical Devices Act (PMD Act) and Article 12, Paragraph 2 of the Essential Principles for Medical Devices.

The Essential Principles stipulate the following:

“Medical devices using programs must be designed to ensure reproducibility, reliability, and performance of the system in light of their intended use. Appropriate measures must be taken to eliminate or reduce, as far as reasonably practicable, risks that may arise from any failure in the system. For medical devices using programs, matters related to the development lifecycle based on the latest technology, risk management, and confirmation and validation to ensure proper operation of the medical device must be considered. In this case, the development lifecycle based on the latest technology, risk management, and confirmation and validation to ensure proper operation of the medical device must comply with JIS T 2304 or standards with equivalent or higher levels, depending on the intended use of the medical device.”

Regarding Transitional Measures: Even for medical devices whose design was completed by November 24, 2017, it is required to identify items necessary for compliance with JIS T 2304 and implement measures to meet them. These measures include analyzing the differences between the requirements of JIS T 2304 and the available information regarding the medical device, addressing them through risk management to ensure acceptable risk levels, and maintaining necessary records.

Overview of IEC 62304

IEC 62304 was published by the International Electrotechnical Commission (IEC) in May 2006 and was adopted as a Japanese Industrial Standard (JIS T 2304:2012) in Japan in 2012. Furthermore, IEC 62304 Edition 1.1, which included Amendment 1 published in June 2015, was released, adding new requirements such as handling legacy software and identifying and avoiding common software defects. In Japan, JIS T 2304:2017 was promulgated in March 2017 in response to this update.

JIS T 2304 is designated as “IDT (identical)” in relation to IEC 62304, meaning it is essentially a JIS version of the international standard IEC 62304.

In the United States, IEC 62304 was recognized by the FDA as a Recognized Consensus Standard in July 2008.

International Application Status

IEC 62304 specifies processes for the development and maintenance of “medical device software.” In addition to Japan, evidence of software development based on IEC 62304 is required for medical device applications in Europe, North America, China, and other regions. In other words, without developing “medical device software” in accordance with IEC 62304, it is not possible to sell medical devices incorporating software (including standalone programs) domestically or internationally.

In Europe, compliance with IEC 62304 is recognized as a harmonized standard under the Medical Device Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR).

Characteristics and Requirements of IEC 62304

Complexity and Diversity of Interpretation

IEC 62304 is known as a highly complex standard. Generally, process standards tend to be interpreted differently by each company, resulting in significantly different procedural documentation. IEC 62304 is no exception, and specialized knowledge and experience are required when translating the standard’s requirements into specific development processes.

However, IEC 62304 does not require a specific software development methodology. It is fundamentally premised on waterfall model software development, but with appropriate risk management implementation, it can also be applied to other development methodologies such as agile development.

Software Safety Class Classification

One of the most distinctive elements of IEC 62304 is software safety class classification. Medical device software systems are classified into three safety classes—Class A, B, and C—based on the risk of harm they may cause.

Class A: When the software system cannot contribute to a hazardous situation

Class B: When the software system can contribute to a hazardous situation, but the hazardous situation does not lead to serious injury or death

Class C: When the software system can contribute to a hazardous situation, and the hazardous situation may lead to death or serious injury

This classification determines the rigor of the development processes applied to each software component. Software classified as safety Class C is subject to the most stringent documentation, verification, and testing requirements.

Key Process Requirements

IEC 62304 specifies comprehensive processes throughout the software lifecycle:

Software Development Planning: Activities, roles, and responsibilities must be defined, and plans must be documented according to the safety class.

Software Requirements Analysis: Functional and performance requirements must be identified and documented. These must be traceable to system-level specifications.

Software Architectural Design: Safety-critical design elements must be clearly distinguished from others in the architectural specification. This requirement is similarly emphasized in the FDA’s General Principles of Software Validation (GPSV).

Software Detailed Design: Detailed design specifications at the software unit level must be created.

Software Unit Implementation and Verification: Coding and unit testing must be performed.

Software Integration and Testing: Integration and testing of software items must be performed.

Software System Testing: Verification of the software system against requirements must be performed.

Software Release: Before release, it must be confirmed that all verification activities have been completed and results evaluated.

Software Maintenance: A maintenance plan is required to manage post-release software updates, bug fixes, and changes.

Integration with Risk Management

IEC 62304 requires integration with the risk management processes outlined in ISO 14971 (Application of Risk Management to Medical Devices). Software-related risks must be identified, evaluated, and mitigated throughout the software development lifecycle.

For Class B and C software, software-specific risk management processes are required:

• Analysis of software that causes hazardous situations
• Identification of software items contributing to hazardous situations and their potential causes
• Risk analysis (including analysis of severity of harm and probability of occurrence)
• Implementation and verification of risk control measures

Important Differences Between FDA’s GPSV and IEC 62304

There is an important difference regarding safety classification between the FDA’s General Principles of Software Validation (GPSV, issued in 2002) and IEC 62304.

GPSV: Fundamentally assesses safety based on risk before implementing risk control measures (pre-residual risk). In other words, it considers the worst-case scenario that software alone could cause.

IEC 62304: Allows safety classification to be performed using risk after reduction (residual risk) when risk is reduced by other control measures (e.g., mechanical design, electrical design, procedural measures). In other words, system-wide risk control can be taken into account.

This difference can have a substantial impact on software safety class classification. However, regardless of which approach is adopted, adequate risk management implementation and appropriate documentation remain essential.

Latest Related Standards and Technological Trends

IEC 82304-1 (Health Software)

For medical software for PCs and smartphones (particularly SaMD: Software as a Medical Device), IEC 82304-1 (Health Software – Part 1: General Requirements for Product Safety) may apply in addition to IEC 62304.

AI/ML-Enabled Medical Devices

For medical device software incorporating AI/machine learning, in addition to the aforementioned FDA draft guidance (January 2025), the following special considerations exist:

• Lifecycle management of continuous learning algorithms
• Monitoring data drift and performance evaluation
• Utilization of Predetermined Change Control Plans (PCCP)

As of August 2024, 97% of AI-enabled devices cleared by the FDA went through the 510(k) pathway, with over 1,000 AI-enabled devices cleared since 2015.

Cybersecurity Requirements

Medical device cybersecurity has become a major focus for regulatory authorities. The FDA guidance of June 2025 requires a lifecycle-based security approach for all medical devices with network connectivity (including latent connections).

Manufacturers must demonstrate alignment with the Secure Product Development Framework (SPDF) and comply with risk management procedures based on Quality System Regulations (QSR).

Industry Impact and Implementation Considerations

Integration with Quality Management Systems

Compliance with IEC 62304 requires integration with ISO 13485 (Medical Devices – Quality Management Systems). In fact, to obtain IEC 62304 certification, it is typically necessary to hold a valid ISO 13485 certification.

Documentation and Traceability

IEC 62304 requires comprehensive documentation and traceability. Detailed records of all software development activities (including design, testing, and verification) must be maintained. Complete traceability from requirements through design, implementation, and test results is required.

Management of SOUP (Software of Unknown Provenance)

IEC 62304 defines special requirements for the use of SOUP (Software of Unknown Provenance, including off-the-shelf software and open-source libraries). When using SOUP, the appropriateness of use must be evaluated based on a risk-based decision model, and appropriate testing requirements must be defined.

Continuous Compliance

Continuous compliance is required throughout the lifecycle of medical device software. All software changes, updates, or maintenance activities must be managed with the same rigor as the initial development.

Conclusion

The regulatory environment for medical device software continues to evolve in response to technological advancement and increasing safety demands. Compliance with IEC 62304 has become a fundamental requirement for marketing medical device software in major markets including Japan.

Manufacturers must pay attention to the following points:

• Comprehensive compliance with related standards such as IEC 62304, ISO 14971, and ISO 13485
• Implementation of development processes based on appropriate software safety class classification
• Response to the latest guidance from the FDA and regulatory authorities in each country
• Understanding special requirements in emerging technology areas such as AI/ML and cybersecurity
• Continuous compliance and quality assurance throughout the lifecycle

Compliance with regulatory requirements is not merely a compliance issue but provides a systematic approach to ensuring patient safety and developing high-quality medical device software. By understanding and properly implementing the requirements of standards, manufacturers can reduce time to market, minimize regulatory risks, and ultimately provide better care to patients.

Comparative Summary: Key Differences Between Regulatory Approaches

Aspect	FDA GPSV	IEC 62304	Latest Trends (2025)
Risk Assessment Basis	Pre-mitigation risk	Post-mitigation risk allowed	System-wide approach emphasized
Software Classification	Not explicitly defined	Class A, B, C	Enhanced with AI/ML considerations
Development Methodology	Assumes waterfall model	Flexible with proper justification	Agile increasingly accepted
SOUP Handling	General guidance	Specific risk-based framework	Increased focus on supply chain security
Cybersecurity	Limited coverage (2002)	Integrated with risk management	Mandatory lifecycle approach (2025)
AI/ML Devices	Not addressed	Amendment 1 provides some guidance	Comprehensive guidance issued (2025)

Key References and Resources

International Standards:

• IEC 62304:2006 + Amendment 1:2015 – Medical Device Software – Software Lifecycle Processes
• ISO 14971:2019 – Medical Devices – Application of Risk Management to Medical Devices
• ISO 13485:2016 – Medical Devices – Quality Management Systems
• IEC 82304-1:2016 – Health Software – Part 1: General Requirements for Product Safety

FDA Guidance Documents:

• General Principles of Software Validation (2002)
• Computer Software Assurance for Production and Quality System Software (2025)
• Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations (Draft, 2025)
• Marketing Submission Recommendations for a Predetermined Change Control Plan for AI-Enabled Device Software Functions (2024)

Japanese Regulations:

• JIS T 2304:2017 – Medical Device Software – Software Lifecycle Processes
• PMDA Notification on Software Lifecycle Processes (May 17, 2017)
• Essential Principles for Medical Devices (Ministry of Health, Labour and Welfare)

These resources provide the foundation for understanding and implementing compliant medical device software development processes in the current regulatory landscape.