Medical Device Software Development

Introduction

The development of software (programs) embedded in medical devices requires regulatory requirements that differ significantly from general software development, necessitating a rigorous and comprehensive approach. This article explains the requirements for medical device software development in Japan, with particular focus on the positioning and practical application of JIS T 2304 (IEC 62304).

Background of Regulatory Requirements for Medical Device Software

As of November 25, 2017, when applying for the approval or certification of medical devices using programs (software), applicants must explain compliance with JIS T 2304 (which corresponds to the international standard IEC 62304) in the documents attached to the application.

This regulatory requirement was clarified by a director’s notification issued on May 17, 2017, by the Medical Device Review Division of the Pharmaceuticals and Medical Devices Agency (PMDA), titled “Application of Basic Standards for Medical Devices, Article 12, Paragraph 2” (Reference: Yakuseikinshi-hat 0517 No. 1). The appendix of this notification provides examples of document descriptions that serve as the basis for demonstrating compliance with JIS T 2304, offering practical guidance for manufacturers.

Characteristics of JIS T 2304 as a Process Standard

When compared with safety standards such as the IEC 60601 series, JIS T 2304 exhibits distinctive characteristics. While safety standards provide clear pass/fail results based on test outcomes, JIS T 2304, as a process standard, results in compliance assessment that approximates a form of corporate self-declaration. In other words, the role of regulatory authorities is to verify after the fact whether the development process conformed to the standard, making the company’s responsibility in documenting and maintaining these processes critical.

JIS T 2304 and the Waterfall Model

Fundamentally, the software development process based on JIS T 2304 (IEC 62304) shares no major differences with conventional software development processes using the waterfall model. Both approaches have in common that development proceeds through staged phases including planning, requirements definition, design, implementation, and testing.

The primary distinction from general software development lies in the need to ensure the safety of medical devices. At the architecture specification phase, item decomposition must be performed, followed by software safety classification for each item. This is an essential requirement to prevent medical devices from causing harm to patients.

Practical Considerations for Software Safety Classification

Under JIS T 2304 (IEC 62304), when performing software safety classification, if risks are appropriately reduced through other risk control measures—such as hardware redundancy design or external warning mechanisms—the safety classification after risk reduction may be documented.

This represents a flexible approach that recognizes the reality that risk reduction may be achieved through the overall medical device system, not solely through software controls.

In contrast, the FDA’s “General Principles of Software Validation” guidance requires a different approach. Under FDA requirements, even when other risk reduction measures exist, the Level of Concern for the software must be determined based on risks associated with the software itself (before risk reduction). Therefore, when pursuing simultaneous compliance with international standards and FDA regulations, careful attention to this distinction is essential.

Relationship Between QMS Regulations and JIS T 2304

A frequently asked question from medical device development companies, particularly startups, concerns the relationship between QMS Regulations (the Ministerial Ordinance on Standards for Manufacturing Control and Sales Management of Medical Devices by Manufacturers of Medical Device Products) and JIS T 2304.

Under QMS Regulations, design and development requirements are primarily centered on hardware (H/W). Consequently, for the software portion of development, requirements under QMS Regulations alone are insufficient, and separate compliance with JIS T 2304 (IEC 62304) must be achieved during design and development. QMS Regulations and JIS T 2304 maintain a complementary relationship, and medical device companies bear the responsibility of meeting the requirements of both.

In the case of standalone software programs (SaMD: Software as Medical Device) that do not incorporate hardware components, compliance with JIS T 2304 (IEC 62304) alone is generally sufficient. However, even for SaMD, quality management, document management, and personnel management requirements under QMS Regulations must still be observed.

Overall QMS Framework for Medical Device Startups

When medical device startups seek to obtain manufacturing and sales approval, they must establish a comprehensive Quality Management System (QMS) beyond design and development. The QMS encompasses the following domains:

Management responsibility (leadership, quality policy, objective setting)
Resource management (personnel, infrastructure, document management)
Product planning and development (design and development, including JIS T 2304 compliance)
Product provision (manufacturing, distribution management)
Measurement, analysis, and improvement (internal audits, nonconforming product management, corrective actions, etc.)

During the establishment inspection (GCP inspection) for obtaining manufacturing and sales approval, detailed evaluation is conducted regarding compliance with both QMS Regulations and GVP Regulations (the Ministerial Ordinance on Measures to Ensure Proper Management and Provision of Medical Literature Information by Medical Device Manufacturers). Particular emphasis is placed on examining design and development records, quality management results, and post-market information management.

Additional Requirements for International Market Expansion

An increasing number of companies are considering market entry in Europe and the United States in addition to Japan. Requirements for medical device software in the European Union, United Kingdom, and United States differ as follows:

European Union (EU MDR) essentially requires compliance equivalent to IEC 62304; however, additional rapid expansion is occurring in cybersecurity requirements (IEC 81001-5-1) and AI/machine learning transparency requirements (newly established AI Act in 2024).

United Kingdom (MHRA) has undergone regulatory reform in 2024, whereby approval processes for some lower-risk medical devices have been accelerated, while software-related safety assessment requirements have simultaneously become more stringent.

United States (FDA) has issued new guidance beyond the “General Principles of Software Validation,” including the 2023 guidance on “Clinical Software Assurance for Off-The-Shelf (OTS) Software Use in Medical Device Cybersecurity,” reflecting evolving expectations for security and software component management.

Conclusion

Medical device software development requires not only software development expertise but also a deep understanding of regulatory requirements. Because JIS T 2304 is a process standard, corporate self-declaration and responsibility are paramount. Building design and development processes, along with the comprehensive QMS, while remaining cognizant of international standards and current regulatory trends, represents the most efficient pathway to market authorization.