Global SaMD Regulations in 2026: How Medical Software Is Classified and Approved Across Major Markets

Software as a Medical Device (SaMD) is software that serves a medical purpose on its own, without being part of a hardware medical device. Software that helps detect breast cancer in medical images fits that description, as does an app that flags heart rhythm problems.

Each market classifies this software into risk classes, and the class determines the approval route, cost, and release schedule. For medical software, SaMD regulations set the pace of launch and the size of the evidence file. A correctly claimed class in the first market carries much of that regulatory evidence into the next.

Why Does SaMD Classification Decide Your Time to Market?

SaMD classification decides time to market because each class carries a distinct review route and evidence burden. In the US, Class III devices need premarket approval (PMA) and most Class II devices need a 510(k), according to the FDA's overview of device pathways. Some Class I and II devices are exempt from the 510(k). Novel devices with no legally marketed predicate can use the De Novo route.

In the EU, the class determines whether a notified body must assess the product. The vast majority of AI-enabled medical devices require that assessment under the MDR classification rules, as Taylor Wessing's analysis of AI-enabled devices notes.

The risk class you claim on day one shapes your budget, your evidence plan, and the day you reach patients. Consider a hypothetical team that adds a triage feature late in the build. If that feature moves the product into a higher class, the team may need clinical data it had not planned to collect, and the release date may shift.

The market is growing, so more teams will face these decisions. Market.us estimates the SaMD market at $1.4 billion in 2023 and projects $5.0 billion by 2033, a compound annual growth rate of 13.6 percent. In a crowded category, a classification mistake that forces rework can hand the first slot to a competitor.

How Do Regulators Classify SaMD?

Most regulators classify SaMD by two factors: the seriousness of the patient's condition and the weight of the software's output in the clinical decision. The term comes from the International Medical Device Regulators Forum (IMDRF). Its 2013 key definitions describe SaMD as software intended for one or more medical purposes and used outside a hardware medical device. The FDA's SaMD page uses the same definition.

Two facts drive the class in most markets: how sick the patient is and how much the clinician relies on the software's output. Health Canada, for example, adapted the IMDRF risk categorization to its own Class I to IV rules.

The EU applies the same logic under Rule 11 of the Medical Devices Regulation. MDCG 2019-11 rev.1 explains that software informing diagnostic or therapeutic decisions starts at Class IIa. It rises to IIb if those decisions could cause serious deterioration of health or surgery, and to III if they could cause death or irreversible deterioration. Software that monitors physiological processes is IIa, or IIb for vital parameters where changes could put the patient in immediate danger. All other software is Class I.

Use the two factors as a scoping test. List every function that produces a clinical output, note the condition it addresses, and mark who acts on the result. The function with the highest risk determines how much evidence the release needs, so decide early whether it belongs in version one of your product.

The IMDRF keeps refining this approach. Its N81 document from January 2025 adds considerations for characterizing medical device software and its software-specific risks. It complements the earlier N12 risk framework, Emergo by UL notes.

Which Health Apps Count as SaMD?

An app counts as SaMD when its intended medical purpose comes from the software alone. The FDA's list of SaMD examples shows where regulators draw the line.

Intended use determines the decision, and regulators read it from your labeling and marketing. Identical code can be a wellness product in one launch and a medical device in the next, once the claims change. Draft the intended-use statement before the first sprint, and compare every landing page and app store description against it.

Workflow position matters as much as the feature list. A triage function that ranks patients by urgency informs clinical decisions, which places it at Class IIa or higher under MDCG 2019-11 rev.1. Clinical communication software, such as messaging or video calls between clinicians and patients, is on the FDA's non-SaMD list. Medication adherence features fall in between, and their class depends on whether they only remind patients or also suggest dose changes.

The line also moves. The FDA's January 2026 update to its general wellness guidance indicates that it may treat some products with non-invasive sensing, such as wearables estimating blood pressure or heart rate variability, as wellness products, provided they avoid disease claims and claims of clinical accuracy. Products integrated with connected hospital equipment need the same check for each software function.

In What Ways Do SaMD Rules Differ Across Major Markets?

SaMD rules differ mainly in class labels, review routes, and the dates of recent reforms. The table compares 11 jurisdictions, from the US and the EU to Singapore.

Choose your first market based on the evidence you can reuse in the next one. An EU MDR certificate also covers Great Britain, and on October 21, 2026, the UK government confirmed it intends to recognize CE-marked devices indefinitely, with legislation planned before June 30, 2028. Swiss classification applies Annex VIII of the EU MDR. Canada and Australia weigh similar risk factors, so one well-argued classification rationale can travel with minor changes. Japan, China, and South Korea each require a national filing with the local regulator.

Those national filings shape the budget. In Japan, the route runs from a Class I notification to MHLW approval for Class IV. China handles Class I by filing and requires registration for the higher classes. Include local regulatory support for those markets in the initial budget, and schedule them after the market whose evidence package you can build fastest.

A US-first plan suits products with a legally marketed predicate, because novel devices go through the De Novo classification route.

What Must Be in Place Before You File a SaMD Submission?

A filing needs a defensible class, a documented development process, and plans for security and change. Use this checklist before you book a pre-submission meeting.

1. Intended use and class per market. Record the medical purpose, the target users, and the class you claim in each jurisdiction, with the rule that supports it.

2. Quality system and lifecycle records. Plan design controls, a traceability matrix, and lifecycle records under IEC 62304, and keep them aligned with ISO 13485. Since February 2, 2026, the FDA's Quality Management System Regulation incorporates ISO 13485:2016 by reference, so one quality system can serve both the US and the EU.

3. Cybersecurity file. The FDA's February 3, 2026, cybersecurity guidance expects cyber device submissions to include a cybersecurity management plan and a software bill of materials (SBOM).

4. Change plan for AI models. A predetermined change control plan (PCCP) lets manufacturers make preauthorized modifications without a new FDA submission. The FDA finalized its PCCP guidance for AI-enabled device software in December 2024. PCCP planning can begin at an AI medical device's MVP stage.

5. EU AI Act timeline. AI systems in medical devices that need notified body review count as high-risk, and Regulation (EU) 2026/1744 moved those obligations to August 2, 2028.

6. Development partner. Ask each vendor for lifecycle records and a traceability matrix from a past regulated project, and for the regulatory affairs firms it works with.

Every item on this list is cheaper to build into the first release than to retrofit after a reviewer asks for it. Integrating with hospital systems raises the bar further because each connected function deserves a separate classification check. For Eargo's FDA Class II hearing aids, the iOS and Android apps communicate one way with the hardware via ultrasound and Bluetooth, so every app release affects a regulated device.

Why Should SaMD Regulations Shape Your Product Architecture?

SaMD regulations work best as an input to product design because regulators judge software as a medical device by what it claims to do. The intended-use statement, the risk class, and the quality system shape which features you build, how you release them, and which market sees them first. Teams that connect regulatory work to their roadmap from sprint one maintain a single, growing evidence base across markets.

That alignment pays off over years of updates, new markets, and new AI features. Monterail's healthcare engineers build regulated products and refer clients to partners for regulatory affairs and clinical testing. Talk to Monterail about your SaMD roadmap.