Software that diagnoses, monitors, or guides clinical decisions is no longer a peripheral concern for regulators. It sits at the center of patient safety policy worldwide. Understanding software as medical device regulatory categories is not optional for healthcare professionals and regulatory affairs specialists. It determines your premarket submission pathway, your quality management obligations, and ultimately your timeline to market. This article cuts through the complexity of FDA, EU MDR, and TGA frameworks to give you a clear, jurisdiction-by-jurisdiction breakdown of how SaMD is classified and what each category demands from your team.
Table of Contents
- Key Takeaways
- 1. Software as medical device regulatory categories: the global framework
- 2. FDA software as medical device classifications and pathways
- 3. EU MDR software categories under Rule 11
- 4. TGA regulatory categories for SaMD in Australia
- 5. Comparing FDA, EU MDR, and TGA classifications side by side
- My take on navigating SaMD classification after years in the field
- How Jjccgroup helps you get SaMD classification right
- FAQ
Key Takeaways
| Point | Details |
|---|---|
| IMDRF is the global foundation | The IMDRF framework’s four risk categories inform how FDA, EU MDR, and TGA classify SaMD. |
| FDA uses three device classes | Class I, II, and III determine whether you need a 510(k), De Novo, or PMA submission. |
| EU MDR Rule 11 skews higher | EU MDR generally assigns higher classifications to SaMD than FDA does for comparable software. |
| Qualification comes before classification | Determining whether your software meets the medical device definition is the critical first step. |
| Software updates trigger re-evaluation | Each significant release may change your regulatory status and require updated evidence. |
1. Software as medical device regulatory categories: the global framework
Before you can classify your software under any single jurisdiction, you need to understand the international framework that most regulators draw from. The International Medical Device Regulators Forum (IMDRF) established a four-tier SaMD risk framework that organizes software by two intersecting factors: the significance of the information the software provides and the severity of the healthcare situation it addresses.
Category I represents the lowest risk. Category IV represents the highest. A software tool that provides information to treat a critical condition sits at the top. One that informs decisions in non-serious situations sits at the bottom. This matrix logic is what the FDA, the European Commission, and Australia’s TGA have each adapted into their own classification rules.
Three terms are worth distinguishing before going further:
- SaMD (Software as a Medical Device): Standalone software intended to perform a medical purpose without being part of a hardware medical device.
- Accessory software: Software that supports a hardware medical device but does not itself perform the medical function.
- Embedded software: Software built into a hardware device and regulated as part of that device, not as standalone SaMD.
Pro Tip: Run a formal qualification assessment before any classification work begins. Skipping this step is one of the most common reasons teams face unexpected compliance scope and QMS requirements later in development.
2. FDA software as medical device classifications and pathways
The FDA classifies SaMD into three classes based on risk level. Class I is low risk, Class II is moderate risk, and Class III is high risk. What matters most is that the FDA does not treat software as a fundamentally different category of device. Classification logic aligns with other medical devices and relies on intended use, product codes, and risk controls.
Here is how the classes typically map to SaMD:
- Class I: General wellness software or administrative tools with minimal patient impact. Most are exempt from premarket notification.
- Class II: The largest category for SaMD. Includes diagnostic imaging software, clinical decision support tools, and remote monitoring applications. Cleared via 510(k) or De Novo.
- Class III: High-risk software making autonomous clinical decisions. Requires Premarket Approval (PMA), the most rigorous pathway.
For premarket submissions, most AI/ML SaMD is cleared via 510(k) or De Novo. The 510(k) pathway requires demonstrating substantial equivalence to a legally marketed predicate device. When no predicate exists, the De Novo pathway allows novel low-to-moderate risk software to establish a new classification. PMA is reserved for the highest risk devices and demands clinical trial data and full safety and effectiveness evidence.
Pro Tip: If your SaMD lacks a clear predicate, engage the FDA through a Pre-Sub meeting early. It can save months of back-and-forth and clarify whether De Novo or PMA is the right path before you invest in a full submission package.
One important nuance: FDA classification decisions involve intended use, product codes, and risk controls. The IMDRF category informs but does not dictate the final classification. A software tool that falls into IMDRF Category III may still land in FDA Class II depending on how intended use is scoped and what special controls apply.
3. EU MDR software categories under Rule 11
The European Union’s Medical Device Regulation takes a different approach. Under EU MDR, standalone software is classified primarily through Rule 11, which focuses on the clinical decision significance of the software and the potential for patient harm.
The classification tiers under EU MDR for SaMD are:
- Class IIa: Software intended to provide information used to make decisions with diagnosis or therapy purposes in non-serious situations. This is the entry-level regulated class for most SaMD in the EU.
- Class IIb: Software intended to monitor physiological processes or provide decision support in serious situations. Monitoring vital parameters that could lead to immediate intervention typically lands here.
- Class III: Software whose output drives decisions that could cause death or irreversible deterioration of health. Autonomous diagnosis of life-threatening conditions is the clearest example.
A key difference from the FDA framework: there is effectively no Class I for standalone SaMD under EU MDR Rule 11. Software that would be Class I or even exempt under FDA often becomes Class IIa in the EU. This means a higher regulatory burden in Europe compared to the US for comparable software products.
| Classification | Clinical decision significance | Patient harm potential |
|---|---|---|
| Class IIa | Moderate, non-serious situations | Low to moderate |
| Class IIb | Serious situations, monitoring vital signs | Moderate to high |
| Class III | Critical decisions, life-threatening outcomes | Irreversible or fatal |
For software performing in vitro diagnostic functions, the EU’s In Vitro Diagnostic Regulation (IVDR) applies instead of MDR. Teams developing lab-based or diagnostic software should confirm which regulation governs their product before beginning classification work. Legacy products transitioning from the older MDD to MDR also face reclassification challenges, often moving up one or two class levels.
4. TGA regulatory categories for SaMD in Australia
Australia’s Therapeutic Goods Administration requires that software meet the statutory definition of a medical device before any regulatory obligations apply. TGA regulates SaMD that meets this definition and mandates inclusion in the Australian Register of Therapeutic Goods (ARTG) before the product can be supplied, unless it qualifies for a specific exclusion or exemption.
The TGA uses a four-tier classification system that mirrors the IMDRF risk logic:
- Class I: Lowest risk. Includes software with no direct patient contact and minimal clinical impact. Most Class I devices are self-assessed and do not require conformity assessment by a third party.
- Class IIa: Low to moderate risk. Software providing clinical information in non-critical situations. Requires conformity assessment.
- Class IIb: Moderate to high risk. Software used in more serious clinical contexts. Stricter conformity requirements apply.
- Class III: Highest risk. Software whose malfunction or incorrect output could cause serious injury or death. Requires the most rigorous conformity assessment and TGA review.
Certain clinical decision support software is exempt from ARTG registration but remains regulated in other respects. This distinction matters because teams sometimes assume exemption means no regulatory obligations at all. It does not. Qualification under TGA is the step that determines whether your software crosses the statutory threshold, and it is often the most challenging part of the compliance workflow.
Pro Tip: Do not conflate TGA exemption with regulatory freedom. Exempt software may still need to meet performance and safety requirements. Confirm the full scope of obligations with a qualified regulatory specialist before assuming you are in the clear.
5. Comparing FDA, EU MDR, and TGA classifications side by side
With three major frameworks in play, regulatory affairs teams working on global submissions need a clear picture of how classifications align and where they diverge. The table below summarizes the key comparison points.
| Criterion | FDA | EU MDR | TGA |
|---|---|---|---|
| Classification classes | Class I, II, III | Class IIa, IIb, III | Class I, IIa, IIb, III |
| Primary classification rule | Intended use and risk controls | Rule 11 (clinical decision significance) | Statutory definition plus risk-based rules |
| Lowest class for standalone SaMD | Class I (often exempt) | Class IIa (minimum) | Class I |
| Highest risk pathway | PMA | Notified body conformity assessment | TGA conformity assessment |
| Novel device pathway | De Novo | No direct equivalent | N/A |
| IMDRF alignment | Strong | Moderate | Strong |
Several practical factors influence where your software lands across all three systems:
- Intended use statement: This is the single most consequential document in your classification package. A narrowly scoped intended use can reduce classification level. An overly broad one can push you into a higher class with significantly more evidence requirements.
- Patient population: Software used in pediatric or critically ill populations typically receives higher classification due to elevated vulnerability.
- Degree of automation: Software that makes autonomous decisions without clinician review consistently lands in higher risk categories across all three frameworks.
One common pitfall is treating classification as a one-time event. Software updates impact regulatory status, and compliance-ready teams build lifecycle controls that link traceability and risk management to each release. Cloud-based and AI/ML SaMD are especially susceptible to this because their functionality can shift significantly between versions.
Pro Tip: Build your regulatory evidence strategy as a living system, not a submission artifact. Every significant software update should trigger a documented change assessment that evaluates impact on classification, intended use, and required controls.
A formal medical device risk assessment at the start of development and at each major release cycle is the most reliable way to stay ahead of reclassification risk.
My take on navigating SaMD classification after years in the field
I have worked with teams across the SaMD space for years, and the pattern I see most often is this: developers underestimate the qualification step and overestimate how well their intended use statement will hold up under regulatory scrutiny.
The assumption that software is “probably Class II” before anyone has done a formal assessment is not a strategy. It is a liability. I have seen products that teams assumed were straightforward Class II devices turn out to require PMA-level evidence once the intended use was properly examined. The reverse happens too, where overcautious teams pursue PMA for software that a well-scoped De Novo would have handled cleanly.
What actually works is treating the regulatory pathway as a design input, not an afterthought. When classification logic informs your architecture decisions early, you avoid the expensive rework that comes from discovering your software’s functionality has outgrown its intended use statement.
The international harmonization trend is real and moving in the right direction, but it is not there yet. EU MDR Rule 11 still produces materially higher classifications than FDA for the same software in many cases. Teams planning global launches need jurisdiction-specific strategies, not a single classification that they hope translates everywhere.
The professionals who navigate this best are the ones who stay curious, document everything, and build regulatory review into their sprint cycles rather than their launch checklists.
— Mike
How Jjccgroup helps you get SaMD classification right
Getting SaMD classification wrong costs more than time. It costs market access. Jjccgroup brings over 30 years of regulatory consulting experience to the exact challenges described in this article, from qualification assessments and intended use scoping to premarket submission strategy across FDA, EU MDR, and TGA frameworks.
Whether you are preparing a first-time 510(k) for a clinical decision support tool or managing a global SaMD portfolio through MDR transition, Jjccgroup’s team provides the depth of knowledge and hands-on support that turns regulatory complexity into a manageable process. Explore FDA compliance consulting to learn how Jjccgroup can support your classification strategy, reduce submission errors, and accelerate your path to market with confidence.
FAQ
What are software as medical devices?
Software as a medical device is standalone software intended to perform one or more medical purposes without being part of a hardware medical device. Examples include clinical decision support tools, diagnostic imaging software, and AI-based patient monitoring applications.
Why is software as a medical device regulated?
SaMD is regulated because it directly influences clinical decisions that affect patient safety. Regulators like the FDA and EU MDR require premarket review and post-market controls to verify that software performs as intended without causing harm.
What are the FDA’s SaMD classes?
The FDA classifies SaMD into Class I, II, and III based on risk level. Class I is low risk, Class II is moderate and typically requires a 510(k), and Class III is high risk and requires Premarket Approval.
How does EU MDR classify standalone software?
Under EU MDR Rule 11, standalone software is classified as Class IIa, IIb, or III based on the clinical significance of its output and the potential for patient harm. There is no Class I for standalone SaMD under this rule.
Do software updates affect regulatory classification?
Yes. Software updates can impact regulatory status, particularly for AI/ML or cloud-based SaMD. Each significant release should be evaluated against the original intended use and risk controls to determine whether reclassification or updated submissions are required.
