SaMD
What is SaMD? Early development questions for the Japanese market
When developing medical software, start with who will use it, for what purpose and in which setting. Before proceeding with development, clarify what the software will diagnose or treat, then consider the tests and evaluations needed to verify its performance and safety.
This page introduces questions that companies and researchers can prepare before an initial discussion about SaMD development in Japan.
Is every medical app a SaMD?
SaMD stands for Software as a Medical Device. It serves a medical purpose as software, rather than as part of a hardware medical device, and may run on general-purpose computers. IMDRF definition
In Japan, regulatory status depends on the medical purpose and the health risks of malfunction. Low-risk software equivalent to Japan’s Class I (general medical devices) is excluded from this regulatory scope. The labels “app” or “AI” alone do not determine status. MHLW overview
We recommend starting by describing the information the product provides and the decisions or actions a user takes in response.
Five things to describe early
- Intended purpose: Which disease or condition, and what task will the product support?
- Users and setting: Who uses it, where and under what conditions?
- Inputs and outputs: What data enters the product, and what results does it return?
- Value and limitations: How could it contribute to existing care, and what can it not determine?
- Available material: Specifications, research findings, literature, test data and unresolved questions.
You do not need a completed submission dossier to start. A concept diagram or short product description can help identify the questions to discuss.
Identify the Japanese pathway and consultation route
There is no single application route for every SaMD. Using current guidance and notices, assess medical-device status, classification and applicable certification standards to identify the procedures relevant to the product. PMDA SaMD resources
PMDA’s centralized SaMD consultation window covers medical-device status, regulatory development and reimbursement. A free consultation may lead to a recommendation for a paid consultation appropriate to the issues. PMDA consultation window
Build an evaluation plan around the intended purpose
Clinical and performance evaluation should address what evidence supports the intended purpose. The role of literature, existing data, additional testing or a clinical study is product-specific. Do not assume that literature alone is sufficient. Equally, a new clinical trial is not necessarily required for every product. MHLW development and approval guidance
Our approach is to compare the available evidence with the proposed claims, separating what is supported, what is missing and what needs discussion with the authority. For AI-enabled products too, we first clarify what the product will assess or support, who will use it and in which settings, before considering how to evaluate it.
Address software-specific questions
Software lifecycle and product-safety standards have different scopes. Consider how specifications, verification and maintenance records should be prepared and maintained for the product. PMDA standards presentation
Cybersecurity planning considers the operating environment and attack risks throughout the product lifecycle, not only during initial development. PMDA cybersecurity resources
For new functions and updates, assess the evaluation and regulatory procedures appropriate to the change. A software update is not automatically exempt from regulatory change requirements. Related notices
Discuss the scope with us
We have experience in medical-device regulatory support and literature-based clinical evaluation, but do not currently have SaMD-specific practical experience. With that distinction made clear, we discuss with you which tasks we can undertake for your SaMD enquiry.
We can start by describing the intended purpose and comparing the available documents with the points that need further explanation. We then discuss with you potential questions and supporting evidence for PMDA, and the documents to be prepared. For specialist work such as software development controls, verification and cybersecurity, we first assess feasibility and the division of work with appropriate specialists. We do not commit in advance to handling every stage.
As the work becomes clear, we agree with you on the documents to be prepared and each party’s tasks.
Frequently asked questions
Can we discuss a product still in development?+
Yes. Tell us about the concept, intended users and problem you want to address. We keep unresolved points clearly identified rather than treating them as settled.
Does using AI make the product a SaMD?+
Not by itself. Describe its medical purpose, functions, use setting and risks, and use the official status consultation route where needed.
Can reimbursement be considered too?+
Regulatory and reimbursement procedures should be considered separately. We can discuss which questions and consultation routes are relevant to the product. Regulatory approval does not automatically establish reimbursement eligibility.
Is there a charge for talking to us?+
There is no charge at the consultation stage with us. Fees apply when we provide specific deliverables, based on a quotation. This is separate from fees charged by regulatory authorities.
Explore regulatory strategy and PMDA consultation support
Reviewed: 29 October 2026. This page provides general information and explains our consultation approach. It does not determine a product’s regulatory status, requirements, service scope or prospects for approval, certification or reimbursement. When using PMDA’s product-specific review points, distinguish drafts from finalized documents.
Feel free to get in touch
Unsure whether your product is a medical device, what to evaluate or how to prepare consultation materials? You can start by telling us its purpose and the questions you are facing.
Discuss SaMD development and regulation in Japan