The International Medical Device Regulators Forum (IMDRF) published final principles for predetermined change control plans on August 6, 2026, stating that changes covered by a plan should stay within the product's original intended purpose. That same boundary sits at the start of classification: the frameworks examined for this report assess what software is meant to do and the consequence of a wrong output, not whether its code contains artificial intelligence (AI).
The IMDRF document does not create one worldwide route for software changes. It says implementation varies and some jurisdictions may not accept predetermined change control plans; initial device status and legal class also remain market-specific.
A separate APPI News report explains how a planned change can be scoped, tested and documented. This report follows the earlier decision: whether a software function enters medical-device rules, how its risk can be characterized and what evidence should accompany its claimed use.
Intended purpose decides whether software enters device rules
IMDRF defines Software as a Medical Device (SaMD) as software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. The definition can cover software running on a phone or general-purpose computer, while software that drives a hardware device falls outside this particular category.
The definition turns on the manufacturer's intended medical purpose. A product name containing “AI,” “smart” or “clinical” does not settle its status, and packaging the same function as an app does not remove a medical purpose.
National and regional rules draw the boundary in their own terms. The US Food and Drug Administration's guidance, reissued in January 2026, says software intended to maintain or encourage a healthy lifestyle and unrelated to diagnosis, cure, mitigation, prevention or treatment is not a device under US law. A disease-related claim, clinical threshold or output used for medical management can change that analysis.
Guidance from the European Union's Medical Device Coordination Group, revised in June 2025, says intended purpose is relevant to both qualification and classification, and its decision tree asks whether software does more than storage, archival, communication, simple search or lossless compression. This is an EU test, not a substitute for the rules of another market.
The following table is an APPI News synthesis of those documents. It identifies the questions that separate functions, but it does not classify a product.
| Software function | First regulatory question | Record to inspect |
|---|---|---|
| Stores, displays or transmits information | Does it alter or interpret the data for a medical purpose? | Intended-use statement, input, output and user instructions |
| Flags a possible finding or ranks cases | How does the output change the next clinical action? | Target condition, intended user, timing and fallback |
| Produces a diagnosis, risk estimate or treatment parameter | What harm could follow from a wrong or delayed output? | Market-specific class, authorization scope and clinical evidence |
The international risk matrix has two axes
The IMDRF risk framework combines the significance of information to a healthcare decision with the state of the healthcare situation or condition. The first axis asks whether software treats or diagnoses, drives clinical management or merely informs it; the second separates critical, serious and non-serious situations.
| Healthcare situation | Treat or diagnose | Drive clinical management | Inform clinical management |
|---|---|---|---|
| Critical | Category IV | Category III | Category II |
| Serious | Category III | Category II | Category I |
| Non-serious | Category II | Category I | Category I |
Category IV represents the highest relative impact and Category I the lowest within this framework. These are IMDRF categories, not legal device classes, and the document says they do not replace the classification system of any jurisdiction.
The matrix also shows why an algorithm name is not enough. IMDRF places software that analyzes images to diagnose acute stroke for treatment decisions in Category IV, while software that stores historical blood-pressure information for later professional review appears in Category I. The role of the output, the condition and the time available to act produce the difference.
A broader intended use can raise the category. IMDRF says a product covering several healthcare situations takes the highest applicable category, and a change to the intended-use statement should trigger another categorization assessment.
CADe and CADx describe different outputs
In the US Food and Drug Administration's 2022 radiology guidance, computer-assisted detection (CADe) identifies, marks or highlights parts of an image or radiology data that may reveal an abnormality. The document describes computer-assisted diagnosis (CADx) as going beyond attention-directing output to assess the likelihood, type, severity or stage of a condition, or to provide information about an intervention.
Those descriptions are specific to a US radiology guidance. They do not establish one international definition for every system that analyzes laboratory values, physiological signals, genetic data or other clinical inputs.
Detection and diagnosis can still be separated as stages in a workflow. Data first enter a preprocessing step, a model extracts features, and the software returns a location, score or classification to an intended user. The stated use of that output and the harm caused by an error matter more to risk characterization than the model family used to generate it.
Legal classes diverge by market
The Medical Device Coordination Group's revised EU guidance explains how Rule 11 of the EU Medical Device Regulation applies to software that provides information used for diagnostic or therapeutic decisions. It places such software in class IIa by default, class IIb when a wrong decision may cause serious deterioration or surgery, and class III when it may cause death or irreversible deterioration.
That sequence cannot be converted into a US class by changing the regulator's name. The US general-wellness guidance addresses a different threshold under US law, while US product classification and premarket pathways depend on the specific device type and claims.
The difference also prevents a bare statement that a product “is approved.” A defensible record names the country or region, regulator, decision or certificate, intended use, product version and date. Availability and regulatory status must be verified separately in every market where the product is offered.
Classification opens the evidence question
A class or category does not establish clinical performance. IMDRF's clinical-evaluation framework separates valid clinical association, analytical validation and clinical validation: the output needs a sound link to the target condition, the software must produce the intended technical output reliably, and that output must achieve the intended purpose in the target population and care context.
An overall accuracy figure cannot answer all three questions. Evidence needs measures that fit the task, error counts or rates, unusable inputs, a defined reference standard and results for the population and setting named in the intended use.
IMDRF's 10 good machine learning practice principles from 2025 call for representative datasets, appropriate independence between training and test data, external validation proportionate to risk, assessment of the human-AI team and monitoring after deployment. They also call for subgroup results, data characteristics, acceptable inputs, known limitations and update information to reach users.
APPI News's medical AI validation report sets out the evidence chain from intended use to independent testing and monitoring. A broader five-control deployment framework adds interoperability, human authority and operational fallback.
Procurement checks the claim, version and market
A buyer or hospital cannot recreate a regulator's decision from a sales demonstration. It can check whether the supplied records describe the same product that will enter the clinical workflow.
- Intended use and market: record the medical purpose, target condition, population, user, setting and the country or region whose regulatory status is claimed.
- Function and output: identify whether the software stores data, flags a possible finding, ranks cases, estimates risk or produces information used for diagnosis or treatment.
- Evidence: match training and test populations, sites, equipment, reference standards and performance measures to the claimed use.
- Workflow: define who reviews the output, what that person may accept or reject and what process remains when the system is unavailable.
- Version and changes: link the deployed version to its evidence, change history, user notice and any authorized change-control plan.
- Monitoring and recovery: set review intervals, incident reporting, pause criteria and a tested route back to a previous process or version.
These records separate model performance from deployment readiness. A valid authorization for one use does not support a broader population or another workflow, and evidence for one version does not automatically cover a later model.
No framework supplies a worldwide class
IMDRF documents provide shared vocabulary and evidence principles, but they are not regulations. The US and European sources in this report show how named jurisdictions apply their own thresholds; they do not determine status elsewhere.
APPI News could not find a public cross-country registry that assigns one legal class and current authorization status to medical AI devices. This report therefore does not classify a named product or verify a product authorization in Taiwan or any other market.
A current product check has to end with the relevant national or regional regulator's records. The searchable fields should connect the manufacturer, product, intended use, version, decision and conditions of use, because a model name or the label “AI medical device” does not provide that chain.
Sources and further reading
- Essential Principles and Content of Predetermined Change Control Plans（International Medical Device Regulators Forum）
- Software as a Medical Device: Key Definitions（International Medical Device Regulators Forum）
- Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations（International Medical Device Regulators Forum）
- Software as a Medical Device: Clinical Evaluation（International Medical Device Regulators Forum）
- Good machine learning practice for medical device development: Guiding principles（International Medical Device Regulators Forum）
- General Wellness: Policy for Low Risk Devices（US Food and Drug Administration）
- Guidance on Qualification and Classification of Software under the EU medical device regulations（European Union Medical Device Coordination Group）
- Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data（US Food and Drug Administration）
