Is Your Software a Medical Device? Applying FDA's SaMD Framework to Your Product

The Question Every Digital Health Founder Needs to Answer Before Writing a Line of Code

If your company is building software that touches patient care in any way, you need to answer one foundational question before you finalize your product roadmap, pitch investors, or submit a single document to FDA: is your software a medical device?

This is not a theoretical compliance exercise. Getting the classification wrong can mean launching a product that requires premarket clearance you never obtained, triggering enforcement action, or spending 18 months re-engineering a product that was never designed with regulatory constraints in mind. The stakes are real, and the nuances are significant.

What Makes Software a Medical Device Under FDA Law?

FDA's authority over software derives from the Federal Food, Drug, and Cosmetic Act (FD&C Act), specifically the definition of a device under Section 201(h). Software meets this definition when it is intended to be used for the diagnosis, cure, mitigation, treatment, or prevention of disease or to affect the structure or function of the body.

The critical word here is intended. FDA evaluates intended use based not only on your labeling and instructions for use, but also on your marketing claims, your website copy, sales conversations, and even social media posts. If your commercial messaging suggests a clinical use case, FDA will treat the software accordingly, regardless of what your technical documentation says.

In 2017, FDA published its foundational guidance document, 'Software as a Medical Device (SaMD): Clinical Evaluation,' which adopted the International Medical Device Regulators Forum (IMDRF) framework for SaMD classification. This guidance remains the primary lens through which FDA evaluates software-based products today.

The IMDRF SaMD Risk Framework: How FDA Categorizes Your Software

Under the IMDRF framework, incorporated into FDA's SaMD guidance, risk classification is determined by two intersecting variables: the significance of the information the software provides, and the healthcare situation or condition it addresses.

The three significance categories are:

• Treat or diagnose: Software used to drive clinical management decisions directly, such as a dosing algorithm or autonomous diagnostic tool
• Drive clinical management: Software that informs the next step in care without directly treating or diagnosing, such as a triage support tool
• Inform clinical management: Software that provides information for a clinician to consider, but where the clinical professional makes the ultimate decision

These significance categories are then mapped against the severity of the condition being addressed, ranging from non-serious conditions to serious conditions to critical situations. The intersection of these two axes produces a risk tier from I (lowest) to IV (highest), which directly influences the regulatory pathway FDA expects you to follow.

What FDA Regulations Actually Apply to Your Software

Once you determine your software is a medical device, the full Quality System Regulation under 21 CFR Part 820 applies, including the newly finalized Quality Management System Regulation (QMSR) that aligns Part 820 with ISO 13485. Design controls under 21 CFR 820.30 are especially critical for software, requiring documented design inputs, verification, validation, and risk management activities throughout the development lifecycle.

FDA's 'Design Considerations for Pivotal Clinical Investigations for Medical Devices' guidance and the agency's 2023 draft guidance on AI/ML-enabled device software functions further specify expectations for software validation, especially for adaptive algorithms that change post-deployment.

Additionally, if your SaMD connects to a network or other devices, FDA's 'Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions' guidance (finalized in 2023) creates binding expectations for your premarket submission and postmarket monitoring program.

The Exclusions That May Apply -- and When to Be Careful About Claiming Them

The 21st Century Cures Act created specific exclusions for software that performs administrative functions, general wellness functions, or clinical decision support that relies on clinician interpretation without automating the clinical logic. These exclusions are codified in Section 520(o) of the FD&C Act.

However, FDA has made clear through enforcement letters and its 'Clinical Decision Support Software' guidance (2022) that it scrutinizes exclusion claims carefully. Software that claims the CDS exclusion must not acquire, process, or analyze a medical image, signal, or pattern in a way that replaces a clinician's independent review. If your algorithm is doing the analytical heavy lifting, the exclusion almost certainly does not apply.

Practical Steps to Determine Your Regulatory Path

• Document your intended use early and precisely. Every product decision, from feature scope to marketing language, flows from this single statement.
• Conduct a formal SaMD classification analysis using the IMDRF risk matrix before beginning design controls.
• Assess your predicate landscape for 510(k) pathways or evaluate whether De Novo classification is appropriate for your novel software function.
• Build your quality system in parallel with development, not after the fact. Retrofitting design history files is expensive and often unconvincing to FDA reviewers.
• Engage FDA early through a Pre-Submission (Q-Sub) meeting if your classification is ambiguous or your technology is novel.

The Cost of Getting This Wrong

FDA has issued warning letters to software companies whose products functioned as medical devices without 510(k) clearance. These letters require mandatory market withdrawal, can trigger investor scrutiny, and in some cases have ended companies entirely. The regulatory risk is not hypothetical -- it is a documented enforcement priority.

At the same time, over-classifying your software as a medical device when exclusions legitimately apply creates unnecessary regulatory burden and delays your go-to-market timeline. Calibrated, defensible classification analysis is the objective.

Work With a Regulatory Partner Who Understands Software

At ADB Consulting and CRO Inc., we work with digital health startups and established medical device companies to build regulatory strategies that are grounded in the actual FDA framework, not guesswork. Whether you are evaluating a new product concept, preparing a Pre-Submission meeting request, or navigating a 510(k) submission for a SaMD product, our team brings the technical depth and regulatory experience to get it right the first time.

If you are not certain where your software falls under FDA's SaMD framework, that uncertainty itself is a signal to act. Book a free discovery call with Andre Butler and the ADB Consulting and CRO Inc. team today at adbccro.com. We will help you map your product to the right regulatory pathway and build a strategy that holds up under FDA scrutiny.