SaMD FDA Classification: What Medical Device Startups Must Know Before Submitting

Software as a Medical Device: Getting the Classification Right Before It Costs You

If you are building software that diagnoses, treats, monitors, or manages a disease or condition, you are likely developing a Software as a Medical Device—and FDA has a specific, nuanced framework for determining how it will regulate your product. Getting this classification wrong does not just delay your launch; it can trigger enforcement action, require costly re-submissions, or send you down a regulatory pathway your product was never designed to survive.

This post breaks down the FDA SaMD classification framework with the specificity your team needs to make informed regulatory decisions early—before you've committed your architecture, your clinical strategy, or your budget.

What Qualifies as SaMD Under FDA's Framework

FDA aligns with the International Medical Device Regulators Forum (IMDRF) definition: SaMD is software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device. This distinction matters. Software in a device (embedded firmware in an insulin pump, for example) is regulated differently than software as a device (a standalone clinical decision support app).

Under 21 CFR Part 880 and the broader device definition in 21 CFR 201(h), FDA has authority over software that meets the statutory definition of a device. However, the 21st Century Cures Act (2016) carved out certain software functions from that definition entirely. Understanding what is excluded is the first analytical step your regulatory team must take.

The Four Exclusions Under the 21st Century Cures Act

Congress explicitly excluded the following software functions from FDA's device definition:

• Administrative support functions (scheduling, billing, claims processing)
• General wellness functions that pose low risk and relate to a general healthy lifestyle
• Electronic health records software
• Certain clinical decision support (CDS) software—but only under specific conditions

That last exclusion is where most startups miscalculate. FDA's 2019 Clinical Decision Support Software guidance clarifies that non-device CDS must meet four criteria simultaneously: it must not acquire, process, or analyze medical images or signals; it must display, analyze, or print medical information; it must support or provide recommendations to clinicians; and critically, the clinician must be able to independently review the basis of the recommendation without simply following it. If your software makes recommendations a clinician is likely to follow without independent review—think alert fatigue scenarios or AI-driven triage tools—FDA will almost certainly consider it a regulated device.

The IMDRF Risk Framework FDA Uses for SaMD

For software that is regulated as a device, FDA applies the IMDRF's two-dimensional risk characterization framework described in its 2019 proposed regulatory framework for modifications to AI/ML-based SaMD and the foundational 2017 Digital Health Software Precertification Pilot documents. Risk is assessed along two axes:

• Significance of information: Treat or diagnose versus drive clinical management versus inform clinical management
• State of healthcare situation: Critical (immediately life-threatening), serious (long-term irreversible consequences), or non-serious conditions

A SaMD that drives clinical management decisions for a critical condition—say, an autonomous ECG interpretation tool flagging ST-elevation MI—sits at the highest risk tier and will require the most rigorous regulatory pathway. One that merely informs management of a non-serious condition may qualify for enforcement discretion or a simpler submission type.

Regulatory Pathways: 510(k), De Novo, or PMA

Once you have established your device classification and risk tier, the pathway decision follows from FDA's three-class device framework under 21 CFR Parts 862–892:

• Class I / Exempt: Low-risk SaMD with general controls sufficient for reasonable assurance of safety and effectiveness. Many administrative or low-acuity informational tools land here if they are regulated at all.
• Class II / 510(k) or De Novo: Moderate-risk SaMD requires substantial equivalence to a predicate device. If no valid predicate exists, a De Novo request under 21 CFR 860.257 can establish a new classification. This is increasingly the pathway for novel AI-driven diagnostic tools.
• Class III / PMA: High-risk SaMD with no predicate and insufficient general or special controls. Autonomous diagnostic or therapeutic software without a well-established clinical evidence base is most vulnerable to this classification.

For AI/ML-based SaMD specifically, FDA's 2021 Action Plan for AI/ML-Based SaMD signals continued evolution toward a predetermined change control plan (PCCP) framework, which means your submission strategy must account for how your algorithm will be updated post-market—not just its initial validation.

Practical Steps Before You Submit

Classification and pathway selection should happen before design lock, not after. Specifically, your team should:

• Conduct a formal intended use and indications for use analysis mapped against the Cures Act exclusions
• Apply the IMDRF risk matrix to establish your SaMD risk tier in writing
• Search the FDA 510(k) and De Novo databases for predicate devices with comparable software functions
• Review applicable product codes and classification regulations in 21 CFR Parts 862–892
• Consider a pre-submission (Q-Sub) meeting with FDA under the 2019 Q-Submission Program guidance if your pathway is ambiguous

The Q-Sub process is underutilized by startups and small device companies. A well-prepared pre-submission can resolve classification ambiguity, validate your predicate strategy, and clarify FDA's expectations for clinical evidence—saving months of back-and-forth during formal review.

Don't Let Classification Be an Afterthought

The SaMD regulatory landscape is more dynamic than any other segment of FDA device regulation. FDA is actively issuing guidance, the PCCP framework is maturing, and enforcement posture toward non-compliant digital health products has stiffened since 2022. Founders and regulatory leaders who treat classification as a checkbox exercise rather than a strategic decision routinely find themselves re-engineering submissions—or their products—at the worst possible time.

At ADB Consulting & CRO Inc., Andre Butler and the team work directly with SaMD developers to establish defensible classification rationales, select the optimal regulatory pathway, and build submission packages that hold up under FDA scrutiny. Whether you are pre-submission, mid-development, or navigating a classification dispute, we bring the regulatory depth your product requires.

Ready to get your SaMD classification strategy right the first time? Book a free discovery call with Andre Butler at adbccro.com and get clarity on your pathway before you invest another dollar in the wrong direction.