An FDA SaMD classification decision tree is a step-by-step method for deciding whether software is regulated as a medical device, whether it qualifies as non-device clinical decision support, what risk class it likely falls into and which FDA pathway may apply. It helps teams plan development, documentation and budgets before engaging regulatory advisers.
Taction Software builds clinical software, AI tools and regulated health products as part of 200+ healthcare projects delivered since 2013, and works alongside regulatory specialists on classification questions. This decision tree walks through each step in plain language, with support pricing at a $50 hourly rate, and complements our FDA SaMD compliance guide.
Our experts are ready to understand your business goals.
Software as a Medical Device, often shortened to SaMD, is software intended for medical purposes that performs those purposes without being part of a hardware device. Deciding whether a product is SaMD, and how the FDA is likely to treat it, shapes architecture, validation, documentation, timelines and budget. Getting the answer wrong can mean building a product that cannot legally launch, or spending heavily on regulatory work that was never required. The decision tree below breaks the question into four steps. The six points below explain how to use it responsibly before starting any regulated software project.
FDA classification depends mainly on intended use: what the software claims to do, for whom and in what setting. Marketing language, labeling and user interface text all express intended use, so product and marketing teams should agree on these claims early.
The first question is whether the software is a medical device at all. Many health apps, administrative tools and some clinical decision support tools fall outside device regulation, while software that diagnoses, treats or drives clinical management often does not.
For software that is a device, the tree estimates risk based on how much the software influences clinical decisions and how serious the condition is. Higher risk usually means stricter controls, more evidence and longer regulatory timelines before the product can launch.
The tree ends by suggesting likely regulatory pathways, such as exemption, 510(k) clearance, De Novo classification or premarket approval. These are starting points for discussion with regulatory experts, not final determinations, because every product has specific facts that affect the outcome.
This decision tree is an educational planning tool. Final classification decisions should involve qualified regulatory professionals and, where appropriate, direct engagement with the FDA. Our FDA SaMD regulatory guide explains the underlying rules in more detail. Use it to prepare better questions.
Adding features, expanding claims or introducing AI can change classification. Teams should revisit the decision tree whenever intended use changes, because a product that started outside regulation can move into it when new functionality or marketing claims are introduced later.
The first step asks whether the software meets the legal definition of a medical device. Software intended to diagnose, cure, mitigate, treat or prevent disease generally meets that definition. However, federal law excludes several categories of software from the device definition, including certain administrative, general wellness, health record and data transfer functions. Many teams assume their product is regulated when it is not, or the reverse. The six questions below help identify whether your software is likely to be a device, and each should be answered using your actual intended use and marketing claims.
If the software analyzes patient data to diagnose a condition, recommend treatment, calculate doses or detect disease, it is likely a medical device. Software that interprets medical images or physiological signals for clinical purposes is almost always considered a device under FDA rules.
Software for scheduling, billing, claims, practice management, inventory or other administrative functions is excluded from the device definition. Most revenue cycle, operations and workflow tools fall into this category, even when they handle clinical data as part of administrative processes.
Software intended to maintain or encourage a healthy lifestyle, such as fitness tracking, general sleep improvement or stress management, and unrelated to diagnosing or treating specific diseases, is generally excluded. Claims that mention specific conditions can move a wellness product into device territory.
Software that stores, transfers, displays or converts health records or device data, without interpreting that data for clinical decisions, is generally excluded from the device definition. Electronic health records and data display tools usually fall here when they avoid clinical analysis.
Clinical decision support software may or may not be a device, depending on specific criteria. If your software provides recommendations to clinicians, continue to Step 2. Our clinical decision support software development work covers both device and non-device tools. Most AI tools belong here.
Software making clinical recommendations directly to patients, rather than to healthcare professionals, cannot use the non-device clinical decision support exclusion. Patient-facing tools that diagnose or recommend treatment are therefore more likely to be regulated as devices and need careful classification early.
Clinical decision support software can fall outside device regulation if it meets four specific criteria set out in federal law and explained in FDA guidance. These criteria are narrower than many teams expect, and failing any one of them usually means the software is a device. The criteria focus on what data the software uses, who it serves and whether clinicians can independently understand and review its recommendations. The six points below explain each criterion and what typically happens when a product meets or fails them, based on current FDA guidance for clinical decision support software.
Non-device clinical decision support must not acquire, process or analyze medical images, signals from in vitro diagnostic devices, or patterns from physiological signals. Software analyzing ECG waveforms, imaging studies or continuous monitoring signals fails this criterion and is generally regulated as a device.
The software must display, analyze or print medical information, such as patient records, guidelines, peer-reviewed studies or lab results, rather than raw device signals. Tools that summarize charts or match patient data against published guidelines usually meet this criterion. Raw signals fail it.
The software must support or provide recommendations to a healthcare professional about prevention, diagnosis or treatment. It should inform clinical judgment rather than replace it. Software that directs a specific action without room for professional judgment may fail this criterion under FDA guidance.
Clinicians must be able to independently review the basis for each recommendation, so they do not rely primarily on the software. Transparent logic, cited sources and explanations support this criterion, while opaque outputs, including many machine learning predictions, often struggle to meet it.
Software meeting all four criteria is generally non-device clinical decision support, outside FDA device regulation. It still needs strong clinical validation, security and quality practices, and federal health IT transparency rules may apply when it is delivered through certified health IT products.
If any criterion fails, the software is likely a device, and you should continue to Step 3 for risk classification. Many AI tools fall here. Our article on FDA SaMD and clinical AI explains why AI often triggers device regulation.
Once software is likely a medical device, the next step estimates its risk class. The FDA classifies devices as Class I, II or III, with increasing risk and regulatory control. International frameworks for software add a useful way to think about risk, combining how significant the software’s output is with how serious the patient’s condition is. The risk estimate strongly influences evidence requirements, documentation and timelines. The six points below explain how risk is typically assessed for software, with examples of the kinds of products that commonly fall into each level.
Consider whether the software’s output treats or diagnoses, drives clinical management or only informs clinical management. Software that directly diagnoses or treats carries more risk than software whose output is one input among many in a clinician’s decision. Output role matters greatly.
Consider whether the condition is critical, serious or non-serious. Software supporting decisions for life-threatening conditions or fragile patients carries higher risk than software used for minor conditions where delayed or incorrect output is unlikely to cause lasting harm. Patient context shapes risk.
Class I devices carry the lowest risk and are subject to general controls. Many are exempt from premarket review. Low-risk software functions that inform management of non-serious conditions may fall here, although each product’s specific facts determine the actual classification.
Class II devices carry moderate risk and are subject to general and special controls, often requiring 510(k) clearance. Many software devices, including imaging analysis and diagnostic support tools, fall into this class. Our article on FDA 510(k) for AI imaging tools explains typical requirements.
Class III devices carry the highest risk, typically supporting or sustaining life or presenting potential for serious harm. They usually require premarket approval with substantial clinical evidence. Few software-only products fall here, but those that do face the most demanding regulatory process.
Reviewing FDA product codes and similar cleared devices, known as predicates, helps estimate likely classification. If similar software has been cleared through a specific pathway, your product may follow the same route, although differences in intended use or technology can change that conclusion.
The final step matches your likely classification to a regulatory pathway. Pathways range from exempt devices with limited premarket requirements to full premarket approval backed by clinical studies. For novel low-to-moderate risk devices without a suitable predicate, De Novo classification may apply. AI products also need a plan for how models will change after authorization. Choosing the pathway early shapes the entire development plan. The six points below describe the main pathways and planning tools, and our FDA SaMD pathway page covers them for AI products. Each pathway has different evidence expectations.
Some low-risk devices are exempt from premarket notification but still must follow applicable general controls, such as registration, labeling and complaint handling. Exempt status does not mean no obligations, so quality practices and documentation remain important for these products. Scope still matters.
The 510(k) pathway shows that a device is substantially equivalent to a legally marketed predicate device. It is the most common route for moderate-risk software. Submissions include device description, performance testing, software documentation and a comparison with the chosen predicate device.
De Novo classification suits novel devices with low to moderate risk and no suitable predicate. A successful De Novo request creates a new classification, which can then serve as a predicate for future devices. Many innovative AI tools have used this pathway.
Premarket approval applies mainly to Class III devices and requires substantial evidence, often including clinical studies, that the device is safe and effective. It is the most demanding and time-consuming pathway, and it significantly affects development budgets and launch timelines.
The FDA’s pre-submission program lets companies ask questions and get feedback before a formal submission. Early engagement can clarify classification, testing expectations and pathway choice, reducing the risk of costly surprises later in development or during formal review. Preparation improves feedback quality.
AI devices change as models are retrained. Predetermined change control plans let manufacturers describe planned model changes and how they will be validated in advance. Our healthcare AI governance framework work supports this change control discipline. Plans require careful validation.
Our support for SaMD classification and regulated software development is billed at a blended rate of $50 per hour, covering regulatory-aware engineers, quality specialists, developers and project management. We work alongside your regulatory counsel or consultants rather than replacing them. Cost depends on product complexity, classification uncertainty, AI components and documentation needs. The ranges below are planning figures, not quotes. FDA user fees and external regulatory consultant fees are separate. Our FDA SaMD compliance services page describes the full scope of our regulated software work. Every estimate lists its assumptions clearly.
A classification assessment typically takes 40 to 120 hours. It reviews intended use, features, claims and similar products, works through the decision tree and documents a reasoned view of device status, likely class and pathway for discussion with regulatory advisers.
Designing architecture, development processes and traceability for a regulated product typically takes 80 to 240 hours. It sets up requirements management, risk management inputs, version control and documentation practices that later support quality system and submission requirements. Rework costs are avoided.
Preparing software documentation, such as requirements, architecture, risk analysis inputs, verification records and cybersecurity documentation, typically takes 200 to 800 hours. Effort depends on device risk, software complexity and the documentation level expected for the chosen pathway. Templates speed later work.
Verification and validation support, including test design, execution, traceability and performance testing for AI models, typically takes 200 to 1,000 hours. Clinical studies, when required, involve separate clinical and statistical partners and costs beyond software testing. Traceability stays complete throughout.
Building a regulated software product under design controls typically takes 1,000 to 4,000 hours, depending on features, integrations, AI components and risk class. Regulated development takes longer than equivalent unregulated software because of documentation, reviews and verification requirements. Phased delivery helps.
Cost rises with higher risk classes, AI components, novel technology, clinical claims and extensive documentation. It falls with narrow intended use, clear predicates and early regulatory feedback. FDA user fees, clinical studies and regulatory consultants are separate from our engineering cost.
These are the questions founders, product leaders and clinical innovation teams ask most often when they try to classify software under FDA rules, whether they are building clinical AI, decision support or patient-facing tools. The answers are short on purpose and are not regulatory or legal advice, so always involve qualified regulatory professionals for final decisions. If your question depends on your product’s intended use, a short call with our team will give you a clearer picture. For specialist support, you can also hire FDA AI SaMD regulatory consultants through our team.
Software as a Medical Device is software intended for medical purposes, such as diagnosing, treating or preventing disease, that performs those purposes without being part of a hardware medical device. Whether a product is SaMD depends mainly on its intended use and claims.
It depends on intended use. Administrative tools, general wellness apps and simple health record tools are usually excluded from device regulation, while apps that diagnose conditions, recommend treatment or analyze medical signals are often regulated. Specific claims matter, so review them carefully.
Some clinical decision support is excluded if it meets four criteria: it does not analyze images or signals, uses medical information, supports clinician recommendations and lets clinicians independently review the basis. Failing any criterion usually means the software is regulated.
Not always, but often. AI that analyzes images or signals, or produces recommendations clinicians cannot independently review, typically fails the non-device clinical decision support criteria. Many AI diagnostic tools therefore need FDA authorization through 510(k), De Novo or other pathways.
We bill a blended $50 per hour. A classification assessment typically costs $2,000 to $6,000, a documentation package $10,000 to $40,000, and regulated product development $50,000 to $200,000, depending on scope. FDA fees are separate. Regulatory consultant fees are separate.
This page is a step-by-step decision tree for classifying software and identifying likely pathways, with support pricing. Our FDA SaMD compliance guide explains the broader regulatory requirements, quality system expectations and compliance obligations for software medical devices. Both work together.
Share your product’s intended use, users, features, claims and any AI components. In a 30-minute call we will walk through the decision tree with you, highlight classification risks and outline what regulated development would realistically cost. Book a free consultation.
Your email address will not be published. Required fields are marked *
Our expert reaches out shortly after receiving your request and analyzing your requirements.
If needed, we sign an NDA to protect your privacy.
We request additional information to better understand and analyze your project.
We schedule a call to discuss your project, goals. and priorities, and provide preliminary feedback.
If you're satisfied, we finalize the agreement and start your project.