The rapid evolution of digital health technologies has led to a significant increase in the development and use of Software as a Medical Device (SaMD). In Japan, these innovative software solutions are regulated under the "Act on Securing Quality, Efficacy and Safety of Products Including Pharmaceuticals and Medical Devices" (PMD Act or Yakkiho). Recognizing the unique nature of software, the PMD Act was amended in 2014 to explicitly include "programs" (software) and their recording media as medical devices if they are intended for medical purposes. Understanding how Japan defines, classifies, and regulates these "medical device programs" (医療機器プログラム - iryōkiki puroguramu) is crucial for developers and businesses aiming to introduce SaMD into this advanced healthcare market.

Defining "Medical Device Programs" Under the PMD Act

The PMD Act, in Article 2, Paragraph 4, defines a "medical device" as an instrument, machine, appliance, or similar product intended for diagnosing, treating, or preventing diseases in humans or animals, or for affecting the structure or functions of the body. The 2014 revision clarified that "programs" (and their recording media) that fulfill such medical purposes are also considered medical devices. This encompasses standalone software that performs medical functions independently of a hardware medical device. Software that is integral to, and exclusively controls, a hardware medical device (i.e., embedded software or firmware) is typically regulated as part of that hardware device, though its development still falls under Quality Management System (QMS) requirements.

The key determinant for a piece of software to be regulated as a "medical device program" is its intended use. If the software is intended to be used for:

• Diagnosing diseases (e.g., analyzing medical images to detect abnormalities, providing diagnostic scores based on patient data).
• Treating diseases (e.g., software guiding therapeutic interventions, calculating radiation dosage for cancer treatment, providing cognitive behavioral therapy).
• Preventing diseases (e.g., software predicting risk of disease onset and recommending preventive actions based on individual data).
• Affecting the structure or functions of the body for medical purposes.

It will likely be considered a medical device program.

Criteria for Determining if Software is a "Medical Device Program"

The Ministry of Health, Labour and Welfare (MHLW) has issued guidance documents, such as the "Basic Principles on the Applicability of Programs to Medical Devices" (プログラムの医療機器への該当性に関する基本的な考え方について - Notification from the Director of the Medical Device Evaluation Office, PSEHB, MHLW, dated November 21, 2014, with subsequent updates and Q&As), to help determine whether specific software falls under the definition of a medical device program.

Key Factors for Classification as SaMD:

1. Direct Medical Purpose: The software must have a direct purpose related to the diagnosis, treatment, or prevention of a disease, or to affecting body structure/function for medical reasons.
2. Processing or Analysis of Medical Data for Medical Judgment: Software that processes or analyzes patient-specific data (e.g., images, physiological parameters, lab results) to provide information used in clinical decision-making is typically SaMD. This includes functions like calculating risk scores, identifying trends, or providing diagnostic suggestions.
3. Patient Management with Therapeutic Intent: Software that guides or manages patient treatment, such as calculating drug dosages, planning surgical procedures, or delivering digital therapeutics, is generally SaMD.

Software Generally NOT Considered a Medical Device Program:
According to MHLW guidance, the following types of software are generally not considered medical device programs:

• Administrative or Operational Support Software: Software used for general hospital administration (e.g., accounting, patient scheduling, inventory management), electronic health record (EHR) systems that primarily store and retrieve data without significant diagnostic/therapeutic processing, or general communication tools.
• General Well-being, Fitness, or Lifestyle Management Software: Applications intended for general health maintenance, fitness tracking, diet, or lifestyle improvement that do not make claims related to specific diseases or medical conditions, and do not provide patient-specific diagnostic or therapeutic interventions for diseases. The line can be blurry, and claims are critical. If such an app starts making claims about preventing or managing a specific disease, its status could change.
• Simple Data Storage, Transfer, or Display: Software that merely stores, transmits, or displays medical data without performing significant analysis or interpretation for diagnostic or therapeutic purposes (e.g., a simple medical image viewer that doesn't offer analytical tools).
• Medical Textbooks or General Reference Software: Software that provides general medical information (like a digital textbook or drug database) without applying that information to individual patient data for diagnosis or treatment decisions.
• Software Embedded in and Inseparable from Hardware Medical Devices: As mentioned, this is usually regulated as part of the parent hardware device.

The determination is highly dependent on the specific claims made for the software and its actual functionalities.

Regulatory Pathways for Medical Device Programs

Once software is determined to be a medical device program, it is subject to the same risk-based classification and regulatory pathways as hardware medical devices under the PMD Act.

Risk Classification of SaMD

SaMD is classified into Class I (low risk), Class II (moderate risk), Class III (high risk), or Class IV (highest risk). The risk classification depends on:

• The significance of the information provided by the SaMD to healthcare decisions (e.g., does it inform critical diagnostic or therapeutic choices?).
• The state of the healthcare situation or patient condition it is intended for.
• The potential impact on patient health if the SaMD fails, provides erroneous results, or is misused.

Japan considers international frameworks, such as those from the International Medical Device Regulators Forum (IMDRF) on SaMD risk categorization, in its approach. For example, software that analyzes images to help diagnose a life-threatening condition would be higher risk than software that simply tracks medication adherence for a chronic but stable condition.

Regulatory Pathways Based on Classification:

1. Class I SaMD (Low Risk):
   • Pathway: Pre-market Marketing Notification (製造販売届出 - seizō hanbai todokede) submitted by the Marketing Authorization Holder (MAH) to the PMDA.
   • Generally does not require pre-market review of safety and efficacy data by PMDA or a Registered Certification Body (RCB), but QMS compliance for the MAH and manufacturer is essential.
2. Class II SaMD (Moderate Risk):
   • Pathway:
     • For most designated Class II SaMD: Pre-market Certification (認証 - ninshō) by an MHLW-accredited RCB (登録認証機関 - tōroku ninshō kikan). The RCB assesses conformity to Essential Principles and relevant standards.
     • For certain Class II SaMD not suitable for RCB certification: Pre-market Approval (承認 - shōnin) by the MHLW, following PMDA review.
3. Class III and Class IV SaMD (High/Highest Risk):
   • Pathway: Pre-market Approval (承認 - shōnin) by the MHLW, after a rigorous scientific and technical review by the PMDA. This typically requires substantial evidence, including clinical performance data.

Clinical Evidence and Performance Studies

The requirement for clinical evidence, including formal clinical trials (治験 - chiken) or clinical performance studies, depends on the SaMD's risk class, novelty, and the nature of its claims.

• For innovative SaMD, especially those in higher risk classes or making significant diagnostic or therapeutic claims, clinical studies demonstrating analytical validity (accuracy and reliability of the software's output), clinical validity (correlation with clinical condition/outcome), and, where applicable, clinical utility (positive impact on patient care) are often necessary.
• Japan's GCP (Good Clinical Practice) standards apply to clinical trials of medical devices, including SaMD.

Specific Regulatory Considerations for SaMD

Regulating software presents unique challenges compared to hardware devices. Japan's framework and guidance address several SaMD-specific aspects:

Quality Management System (QMS)

MAHs and manufacturers of SaMD must comply with Japan's QMS Ordinance (MHLW Ordinance No. 169 of 2004, revised), which is aligned with ISO 13485. For SaMD, this involves specific considerations for:

• Software Lifecycle Processes: Adherence to standards like IEC 62304 ("Medical device software – Software life cycle processes") is generally expected for managing design, development, testing, maintenance, and risk management throughout the software's lifecycle.
• Validation: Rigorous validation of the software to ensure it performs as intended and meets user needs.
• Version Control and Change Management: Robust procedures for managing software versions, updates, and patches, including regulatory assessment of changes.
• Risk Management: Specific risk management activities tailored to software hazards (e.g., errors in algorithms, system interoperability issues, cybersecurity vulnerabilities).

Cybersecurity (サイバーセキュリティ - Saibā Sekyuriti)

With increased connectivity, cybersecurity is a major concern for SaMD.

• MHLW and PMDA have issued comprehensive guidance on cybersecurity for medical devices, which is highly relevant to SaMD. This guidance emphasizes a lifecycle approach to cybersecurity risk management.
• Key aspects include:
  • Secure design and development practices.
  • Protection of patient data (confidentiality, integrity, availability).
  • Prevention of unauthorized access, modification, or disruption.
  • Vulnerability management and timely patching.
  • Incident response planning.

Artificial Intelligence (AI) and Machine Learning (ML) in SaMD

AI/ML-powered SaMD is a rapidly advancing field. Japanese regulators are actively developing and refining their approach to these technologies.

• Guidance Documents: MHLW/PMDA have published specific guidance on AI/ML-based medical devices, addressing issues like:
  • The quality and appropriateness of datasets used for training and testing AI/ML models.
  • Methodologies for validating AI/ML algorithms and performance.
  • Transparency and explainability of AI decision-making processes.
  • Managing "adaptive" or continuously learning AI/ML algorithms post-market, including how changes to the algorithm due to new learning are handled from a regulatory perspective (Change Control).
• Focus is on ensuring the safety and efficacy of these complex algorithms while fostering innovation.

Mobile Medical Applications

Mobile apps that meet the definition of a medical device program are regulated as SaMD. Their risk classification and regulatory pathway depend on their intended use and functionality, not the platform (e.g., smartphone, tablet) on which they run.

Post-Market Modifications and Lifecycle Management

Unlike hardware, software can be modified relatively easily. However, changes to SaMD (e.g., software updates, bug fixes, new features, algorithm modifications) are subject to regulatory oversight.

• MAHs must have robust change control processes within their QMS.
• Significant changes that could affect the SaMD's safety, efficacy, or intended use may require a partial change application for an existing approval/certification or even a new application. Minor changes might be managed through internal documentation and periodic reporting.
• Guidance exists on how to classify and manage changes to medical device programs.

Labeling and Instructions for Use

Information such as the intended use, specifications, limitations, system requirements, version number, and necessary warnings must be provided. For SaMD, this information is often provided electronically (e.g., via an "about" screen, online help files, or downloadable manuals).

Manufacturing and Marketing Authorization for SaMD

• Concept of "Manufacturing" SaMD: For SaMD, "manufacturing" activities can include software design, development (coding), verification and validation testing, compilation, and the act of releasing the software or recording it onto media for distribution. Entities performing these functions may need to obtain a medical device manufacturing license (if located in Japan) or Foreign Manufacturer Registration (if located overseas). The scope of licensed/registered activities must cover "programs."
• Marketing Authorization Holder (MAH): As with all medical devices, an MAH based in Japan is required to take overall responsibility for placing the SaMD on the Japanese market. The MAH is responsible for obtaining the necessary pre-market authorization, ensuring QMS compliance across the lifecycle (including for any contract software developers), and conducting post-marketing vigilance (GVP).

International Harmonization and Trends

Japan is an active member of the IMDRF and generally seeks to harmonize its medical device regulations, including those for SaMD, with international best practices and standards. This includes referencing IMDRF guidance documents on SaMD (e.g., risk categorization, clinical evaluation, QMS principles) and international standards like IEC 62304. This alignment can facilitate market entry for global SaMD developers.

Recent Developments and Future Outlook (as of May 2025)

The SaMD landscape is highly dynamic. Since 2018, there has been continued evolution:

• Focus on AI/ML: MHLW and PMDA have continued to issue and refine guidance related to AI/ML-based medical devices, addressing topics like continuous learning algorithms and real-world data utilization. For instance, guidelines on "Good Engineering Practice (GEP)" for AI-based medical software are emerging to ensure robust development and validation.
• Cybersecurity Emphasis: Cybersecurity remains a top priority, with guidance regularly updated to address new threats and best practices.
• Programmatic Improvement Processes for AI/ML SaMD: Discussions and initial frameworks are being developed to allow for more agile post-market updates to certain AI/ML SaMD, particularly those with adaptive algorithms, under pre-defined change control plans (often called "Programmatic Improvement Plans" or similar concepts internationally).
• Emergency Approval System: The 2022 amendments to the PMD Act introduced an emergency approval system (Article 23-2-8) that could potentially apply to critical SaMD needed during public health emergencies, allowing for expedited market access under specific conditions.

Conclusion

Japan has established a clear, albeit complex, regulatory framework for Software as a Medical Device by integrating "medical device programs" into its existing risk-based system for medical devices. For developers and MAHs, successfully navigating this landscape requires a precise definition of the SaMD's intended use, accurate risk classification, diligent adherence to QMS requirements (with specific attention to software lifecycle management, cybersecurity, and validation), and a proactive approach to understanding and implementing evolving MHLW and PMDA guidance, particularly in fast-moving areas like AI/ML. While the regulatory requirements are rigorous, they aim to ensure that innovative SaMD solutions brought to the Japanese market are safe, effective, and contribute positively to healthcare.