Publication of Guidance Materials concerning Application for Marketing Approval of Medical Device Software in Japan

1. What this administrative notice is (and why it matters)

Japan’s Ministry of Health, Labour and Welfare (MHLW) issued an administrative notice on the publication of guidance materials to be used when preparing marketing approval applications for software intended for the diagnosis and/or treatment of disease (i.e., medical device software and related storage media that require prior approval).

The notice explains that the guidance was prepared based on discussions in an AMED-funded regulatory science project (FY2015) that examined common issues encountered in approval reviews of medical device software.

It also links the publication to a national strategy statement (public-private dialogue on Japan’s economic revitalization) aiming to enable clinical use of AI-enabled diagnostic support systems and to publish review guidance accordingly.

2. How to use the published materials

MHLW requests that stakeholders consult the guidance and attached reference materials together when preparing marketing approval applications for relevant medical device software.

The appendix guidance further strongly recommends that companies use PMDA consultation services during development when approval is expected, to address issues that may affect review readiness.

3. What the appendix guidance covers (practical structure)

The appendix, titled Guidance for Application for Marketing Approval of Medical Device Software, organizes common review issues and the types of supporting data that are desirable to attach to the application.

3.1 Determining whether the software is a medical device

Applicants are told to clarify intended use, function, use situation (impact of results), and users, then determine whether the software falls within the medical device definition (including software installed on general-purpose platforms such as PCs and mobile devices) and whether its impact on life/health warrants regulation as a medical device.

3.2 Completing the approval application form

The guidance instructs applicants to complete each field of the approval application form by referring to relevant regulatory notifications, including the foundational notification on handling medical device software and the administrative notice providing form examples for software applications and attached data.

3.3 Review-related issues (what reviewers tend to focus on)

The guidance lists noteworthy issues for evaluating safety and efficacy of software intended to support disease diagnosis and treatment plans, emphasizing clear, objective, logical descriptions in both the application and attached data. It also notes these issues apply not only to new approvals but also to partial change applications that may affect efficacy/safety (e.g., new functions or algorithm changes).

Key expectation areas include:

• Clinical significance: why using the software matters clinically.
• Functionality identification: what the software does, input types, and outputs.
• Algorithm clarity: computation flow, processing criteria, and cut-off values.
• Platform and use environment requirements: ensuring patient/user safety in the intended clinical environment, and considering coexistence with other software on the same platform.
• Concurrent use conditions: identification of other devices/drugs expected to be used with the software and whether co-development or additional procedures may be needed.

3.4 Evaluation expectations (evidence planning)

The appendix describes evaluation considerations such as:

• Verifying/validating the clinical significance and computational algorithm with appropriate supporting evidence.
• Ensuring performance evaluation uses the same software version as in the application (or justifying differences).
• Selecting appropriate comparators where needed (e.g., standard methods or physician diagnosis vs computer-aided diagnosis).
• Verifying the validity of input and output data, including standardization considerations (e.g., imaging conditions).
• Evaluating precision where output precision is clinically relevant.
• Evaluating correlation with real tests and, for diagnostic support, considering error types by comparison with independent clinical diagnoses.

3.5 Post-approval changes (design for change control)

Because medical device software often evolves, the guidance highlights that changes affecting efficacy/safety (including adding functions or changing algorithms) may require partial change approval. It encourages applicants to consider, from the initial application stage, what should be included to manage foreseeable changes.

3.6 Quality and safety foundations referenced in the guidance

The appendix notes good practices such as establishing software lifecycle processes (e.g., IEC 62304 / JIS T 2304), conducting risk management (e.g., JIS T 14971), and addressing cybersecurity risks when connectivity or removable media are relevant, referencing Japan’s medical device cybersecurity notifications.

4. Applicant checklist (actionable takeaways)

• Map your product to the medical device software definition and articulate the impact on life/health.
• Build the dossier around clinical significance, clear functional specs, and transparent algorithms (including cut-offs).
• Define platform requirements and demonstrate safe operation in the real clinical environment, including coexistence with other software.
• Plan evidence with discipline: version control, comparator strategy, input/output validation, and clinically meaningful precision metrics.
• Treat change as inevitable: pre-plan your approach to algorithm/function updates and the corresponding regulatory pathway.
• Use PMDA consultation early if approval is expected.

References

• MHLW/PMDA Administrative Notice: Notice concerning the Publication of Guidance Materials concerning Application for Marketing Approval of Medical Device Software (PDF)