01What Software as a Medical Device (SaMD) Is

Most AI medical devices are "software alone," with no dedicated hardware of their own. Japanese law calls this Software as a Medical Device (= SaMD, software that itself functions as a medical device). The 2014 revision of the Pharmaceutical Affairs Act renamed the law the Pharmaceutical and Medical Device Act (= the Act on Securing Quality, Efficacy and Safety of Products Including Pharmaceuticals and Medical Devices), and it was at this point that standalone software was formally brought within the scope of medical devices.

What matters is that not every healthcare app becomes a medical device. The dividing line is: "Is the software used for the diagnosis, treatment, or prevention of disease, and how much does a malfunction affect human life or health?" A record-keeping wellness app falls outside; software that detects lesions from images to support a physician's diagnosis becomes a medical device.

This line is decisive at the very start of development. If the software is a medical device, it cannot be sold until it obtains approval or certification. Concluding that it is not a device when in fact it is — that misclassification is itself a serious problem, amounting to the supply of an unapproved product. So the first task is to determine, with evidence, which side of the line your software sits on.

02Class Classification — Risk Determines the Weight of Review

Medical devices are divided into four classes according to the risk they pose to patients. Which class an AI medical device falls into changes both the pathway it travels and the weight of evidence required. First, the overall picture.

ClassRisk levelExample and procedure for AI medical devices
Class I (general medical devices)Even a malfunction has minimal effect on the bodyFew AI devices qualify. Notification suffices
Class II (controlled medical devices)Relatively low risk from malfunctionMeasurement support for imaging, etc. Certification by a third-party certification body (for items with a standard)
Class III / IV (highly controlled medical devices)A malfunction can be life-threateningLesion detection, therapeutic apps, etc. Ministerial approval following PMDA review

Software that uses AI to detect lesions or to step into treatment decisions often falls in the upper part of Class II through Class III, and faces PMDA review head-on. What is asked here is not "Is the AI smart?" but whether efficacy and safety can be demonstrated within the scope of the intended use. High performance and evidence sufficient for approval are different things, and that has to be understood from the outset.

03The PMDA Review Process

For Class III and above, or for items with no certification standard, approval by the Minister of Health, Labour and Welfare is obtained through PMDA review. Here is the flow, seen along the developer's movements, in four stages.

Step 01

Pre-development consultation

"ask before you design"

Use PMDA's face-to-face advice (= a scheme for consulting in advance on a product still under development) to align early on the evaluation approach and the tests required. The first checkpoint that reduces rework.

Step 02

Performance and clinical evaluation

"gather the evidence"

Verify the AI's performance within the scope of the intended use. Separate training data from evaluation data, and demonstrate sensitivity, specificity, and the like in the expected use population.

Step 03

Application and review

"submit and answer"

Submit the application dossier to the PMDA and work through rounds of queries and responses with the reviewers. Consistency across intended use, performance, and risk management is tested.

Step 04

Approval and launch

"the scope is fixed"

The approved intended use and indication become, as they stand, the frame for sales and explanation. Nothing outside that frame can be claimed.

The spine running through all four stages is to define the "intended use" first and not move it to the end. Depending on its training data, an AI can be made to do any number of other things — but approval rests on the promise of "used for this purpose, in this population." How firmly you can support the scope of that promise with evidence and explanation — that is what the review examines.

04The Change-Plan Confirmation Procedure (IDATEN)

AI medical devices carry a difficulty no other device has: they learn, and their performance changes over time. You want to add training data after launch to raise accuracy — but approval was granted against "performance as of the time of application." Re-obtaining approval from scratch every time you change something would kill the very speed of improvement that is the strength of AI.

What answers this contradiction is the Change-Plan Confirmation Procedure (= IDATEN, Improvement Design within Approval for Timely Evaluation and Notice, a scheme for approving the plan for change in advance). It was introduced in the revised Pharmaceutical and Medical Device Act that took effect in 2020. If you have the range of future performance improvement and its verification method approved in advance as a plan, changes within that plan's scope can be implemented without re-obtaining approval each time.

PointWithout IDATENWith IDATEN
Procedure at each improvementRedo the approval application for every changeNo re-application needed if within the approved plan
What must be decided in advanceNothing in particular (handled case by case)Promise the scope of change, verification method, and handling of deviations up front
Suited toDevices that change rarelyAI medical devices that learn and improve continuously

The crux of IDATEN is to agree with the PMDA, before you change anything, on "what may be changed and how far". It does not make you free to change at will; it places the very scope of change into the review. It is not a scheme that permits unlimited learning — it reconciles speed and safety by promising the path of improvement in advance.

05Post-Market Management — The Real Work Begins After Launch

Approval is not the goal but the start of management. Medical devices require post-market safety management (= surveillance based on standards such as GVP), and for AI medical devices a distinctive task is added on top: watching for changes in performance.

What demands special care is data drift (= the phenomenon where the data at the actual site of use gradually diverges from the assumptions at training time). If the distribution of real patients shifts away from the population used for training, the performance shown at approval may not reproduce in the field. So post-market, you must not only collect malfunction reports but also continually confirm that performance is being maintained as planned.

"Running" and "working correctly" are not the same: An AI medical device may keep running without throwing errors while its performance alone quietly declines. Data drift does not surface as an on-screen error. That is precisely why post-market performance monitoring must be designed together with the IDATEN change plan, and why you must decide, before launch, who responds and how when degradation is detected. Only when surveillance after launch is included is the design truly complete.

If a malfunction or a suspected health harm arises post-market, the marketing authorization holder has a duty to report it. This is a safety-assurance mechanism under the Pharmaceutical and Medical Device Act, and being AI-made grants no exemption whatsoever. If anything, because performance can move, the responsibility to keep watch grows heavier.

06International Alignment — Don't Look at Japan Alone

Regulation of AI medical devices does not conclude within Japan. If you try to release the same product in multiple countries, you face each one's regulations. What helps here is a set of internationally shared ways of thinking.

The details differ by country, but the root question is shared: demonstrate efficacy and safety within the scope of the intended use, and how do you manage performance that keeps changing? Designing with international alignment in mind reduces the need to rebuild evidence when delivering one product to multiple markets. Building only around Japanese approval can make a later global rollout difficult.

07Corporate Practice — What Development and Medical Affairs Do First

Now we translate all of the above into a form the field of a pharmaceutical or medical-device company can act on. If you handle AI medical devices, there are four things to decide early in development.

Practice 01

Fix classification first

Whether the software is a medical device, and if so which class. Determine it with evidence at the very start of development. The point where backtracking costs the most.

Practice 02

Write the intended use in one sentence

Define "for whom, for what purpose, how it is used" in a single sentence. Approval, explanation, and advertising are all bound within that sentence. Don't proceed while it stays vague.

Practice 03

Weave the change plan into the design

Think about how you will improve in future, within the IDATEN frame, from the design stage. Don't scramble to build a plan after launch. Draw the path of improvement in advance.

Practice 04

Decide post-market surveillance before launch

Set the flow of performance monitoring and of response and reporting on degradation before you ship. Design it down to who watches and who stops it.

What the four share is the stance of turning "decide later" into "decide first." Regulation of AI medical devices is not cosmetics applied once development is done. Intended use, evidence, change plan, and post-market surveillance are built into the very skeleton of the design. Only then can the speed of AI and the safety of a medical device coexist within one product.

08The Fences of Advertising and Information Provision — The Same Yardstick for AI Medical Devices

After obtaining approval, how do you describe and communicate the product? Here too there are fences that do not move. The advertising provisions of the Pharmaceutical and Medical Device Act reach not only drugs but medical devices. The core is these three.

ArticleWhat it sets outCaution for AI medical devices
Article 66Prohibition of exaggerated advertising. No false or exaggerated expression regarding efficacy or performanceBeware of emphasizing performance beyond the approved scope, such as "AI diagnoses" or "◯% accuracy"
Article 68Prohibition of advertising a medical device before approvalThe product name or efficacy cannot be advertised before obtaining approval or certification
Article 68-2Provision of information for proper use (a duty of effort)Avoid omitting information that should be conveyed, such as performance limits and precautions for use

Mistaking which article applies itself damages trust. Exaggerated advertising is Article 66, unapproved advertising is Article 68, and information provision is Article 68-2 — this is a foundation worth memorizing outright. For sales-information-provision activities on prescription drugs there is the Sales Information Provision Activity Guideline (= HanteiG, the Guideline on Sales Information Provision Activities for Prescription Drugs, notice of the Director-General of the Pharmaceutical Safety and Environmental Health Bureau, MHLW, 2018), and for the yardstick of advertising expression there is the Standards for Fair Advertising of Drugs and the Like (= the standards issued as a notice of the Director of the Surveillance and Guidance / Narcotics Control Division, Pharmaceutical Safety and Environmental Health Bureau, MHLW). When communicating an AI medical device, the guiding thinking is no different. Rather than speaking to an impression that "it's smart because it's AI," communicate within the scope of the approved intended use, faithful to the facts. That is the way to stay inside the fence.

09Connections to Other Chapters on This Site

This installment gains depth when read together with the following chapters.

In Closing

An AI medical device cannot reach the market merely by being "smart software." It is classified by risk as Software as a Medical Device (SaMD), demonstrates efficacy and safety within the scope of the intended use, and is approved following PMDA review — only through this path does it reach patients. And to the difficulty distinctive to AI — its "keep-learning, keep-changing" nature — the Change-Plan Confirmation Procedure (IDATEN) responds. By promising the path of improvement in advance, it reconciles speed and safety.

Approval is not the goal but the start of post-market management. Keep watch on the danger of performance quietly declining through data drift, and decide the response to degradation before launch. The fences of advertising and information provision — Article 66 on exaggeration, Article 68 on the unapproved, Article 68-2 on information provision — reach AI medical devices just the same. Build regulation into the skeleton of the design, not as cosmetics applied after development. In doing so, tie the speed of AI and the trust of a medical device together within one product. Next time we move to the ethics that lie beyond — fairness, explainability, and consent.

Key Points — Three to Take Away
  1. Most AI medical devices qualify as Software as a Medical Device (SaMD) and are divided into four classes by risk. Lesion detection and therapeutic apps fall from the upper part of Class II into Class III and require ministerial approval following PMDA review. What is asked is not "smartness" but efficacy and safety within the scope of the intended use.
  2. For continuously learning AI, the Change-Plan Confirmation Procedure (IDATEN, introduced in the revised Pharmaceutical and Medical Device Act effective 2020) provides the answer. Get the range and verification method of future improvement approved in advance, and changes within the plan can be implemented without re-application. It is not unlimited learning but a scheme that promises the path of improvement first.
  3. Approval is the start of management. Because performance can quietly decline through data drift, design post-market performance monitoring and the response to degradation before launch. Advertising is reached by the Pharmaceutical and Medical Device Act — exaggeration is Article 66, the unapproved is Article 68, information provision is Article 68-2 — so don't mistake which article applies.
Sources & References
  1. Ministry of Health, Labour and Welfare. Act on Securing Quality, Efficacy and Safety of Products Including Pharmaceuticals and Medical Devices (Pharmaceutical and Medical Device Act). Act No. 145 of 1960 (including the provisions on Software as a Medical Device and Articles 66, 68, and 68-2). (Primary legislation)
  2. Ministry of Health, Labour and Welfare. Basic Approach to Whether a Program Falls under Medical Devices. Notice of the Director-General of the Pharmaceutical Safety and Environmental Health Bureau, 2021 (Reiwa 3). (Criteria for SaMD classification)
  3. Ministry of Health, Labour and Welfare. Act Partially Amending the Act on Securing Quality, Efficacy and Safety of Products Including Pharmaceuticals and Medical Devices (introduction of the Change-Plan Confirmation Procedure = IDATEN). Act No. 63 of 2019, effective 2020. (Approval scheme for continuous improvement)
  4. Pharmaceuticals and Medical Devices Agency (PMDA). Various Notices and Guidance on Medical Device Approval Review and Consultation Services. PMDA. (Practice of review and face-to-face advice)
  5. Director-General, Pharmaceutical Safety and Environmental Health Bureau, MHLW. Guideline on Sales Information Provision Activities for Prescription Drugs (HanteiG). 2018 (Heisei 30). (Yardstick for sales-information-provision activities)
  6. Director, Surveillance and Guidance / Narcotics Control Division, Pharmaceutical Safety and Environmental Health Bureau, MHLW. On the Standards for Fair Advertising of Drugs and the Like. Notice of 2017 (Heisei 29). (Standard for advertising expression)
  7. International Medical Device Regulators Forum (IMDRF). Software as a Medical Device (SaMD): Key Definitions / Possible Framework for Risk Categorization. IMDRF, 2013–2014. (International framework for SaMD classification)