FDA Software as a Medical Device (SaMD): What Digital Health Startups Need to Know

“

Meerako — helping digital health startups build software architected for FDA regulatory reality from day one.

A growing share of digital health products don't fit neatly into the traditional model of software that merely supports a clinician's decision-making from the sidelines. Symptom-checking apps that generate a differential diagnosis, algorithms that analyze medical imaging, software that calculates a drug dosage, and AI models that flag a likely cardiac event from wearable sensor data are all, in various forms, Software as a Medical Device (SaMD) — software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device itself. If your product's software genuinely diagnoses, treats, or directly informs a clinical decision in specific enough ways, the FDA very likely considers it a medical device, subject to the same general regulatory framework that governs a physical diagnostic instrument.

This distinction matters enormously for a digital health startup, because it changes nearly everything about how the product should be built, tested, documented, and shipped. A startup that treats its software purely as a typical SaaS product — moving fast, shipping frequently, iterating based on user feedback in production — and only later discovers its core feature actually requires FDA clearance faces an extremely costly, sometimes existential, retrofit. Understanding SaMD classification early, and architecting development practices around it from the start, is one of the highest-leverage decisions a digital health founding team can make.

• What actually makes software SaMD, and what doesn't.
• The FDA's risk-based classification framework and what it means for your specific product.
• The 510(k) pathway versus De Novo versus PMA, and which applies when.
• What Quality Management System requirements actually mean for day-to-day software development.
• How AI/ML-based SaMD introduces additional regulatory considerations.
• Common mistakes digital health startups make with SaMD classification.

The FDA (aligned with the International Medical Device Regulators Forum's framework) defines SaMD as software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. The key phrase is "intended medical purpose" — software that diagnoses, treats, mitigates, or directly informs a specific clinical decision about a specific patient's condition is far more likely to qualify as SaMD than software that provides general wellness information or supports administrative healthcare workflows without directly influencing a specific clinical decision.

This distinction produces real edge cases that trip up founding teams. A general fitness-tracking app that shows step counts and heart rate trends is very unlikely to be SaMD. That same app adding a feature claiming to detect atrial fibrillation from the same heart rate sensor data crosses into SaMD territory, because it's now performing a specific diagnostic function informing a clinical decision, not just displaying general wellness data. The line isn't always obvious from a product-marketing perspective, which is exactly why regulatory consultation early in product design — not after a feature is built and about to ship — matters so much.

The FDA classifies medical devices, including SaMD, into three classes based on risk. Class I covers the lowest-risk devices, subject to general controls and, for most Class I devices, no premarket submission requirement at all. Class II covers moderate-risk devices, and most SaMD products that do require FDA clearance fall here, typically requiring a 510(k) premarket submission demonstrating substantial equivalence to an already-cleared predicate device. Class III covers the highest-risk devices — those supporting or sustaining human life, or presenting a potentially unreasonable risk of illness or injury — and generally requires the more rigorous Premarket Approval (PMA) pathway, involving extensive clinical evidence.

The IMDRF framework additionally categorizes SaMD along two dimensions relevant to determining actual risk: the significance of the information the software provides to a healthcare decision (informing clinical management, versus driving clinical management, versus treating or diagnosing directly) and the seriousness of the healthcare situation or condition involved (non-serious, serious, or critical). Software that directly diagnoses a critical condition sits at a fundamentally different risk tier than software informing a clinician's judgment about a non-serious condition, and the applicable regulatory pathway follows that risk tier accordingly.

The 510(k) pathway is the most common route for Class II SaMD, and it requires demonstrating "substantial equivalence" to a predicate device already legally marketed — an existing, comparable, already-cleared product the FDA can compare your submission against. This is often the fastest realistic pathway when a genuinely comparable predicate exists, since the burden is comparative rather than requiring standalone clinical evidence from scratch.

The De Novo pathway applies when no suitable predicate device exists but the product is nonetheless determined to be low-to-moderate risk — a common situation for genuinely novel digital health products using algorithmic approaches without a clear existing analog. De Novo classification, once granted, also then serves as a predicate for future similar products, including potentially your own future product iterations.

PMA is reserved for Class III devices and requires the most extensive evidentiary burden — typically real clinical trial data demonstrating safety and efficacy, comparable in rigor to what's required for a novel drug approval, and correspondingly the longest and most expensive pathway by a wide margin.

For any SaMD product proceeding through FDA clearance, a compliant Quality Management System (QMS) — typically built around ISO 13485 and FDA's Quality System Regulation (21 CFR Part 820) — isn't optional paperwork bolted on before submission; it fundamentally shapes how software gets built. Design controls require documented, traceable requirements, design inputs and outputs, verification and validation activities, and formal change control for any modification to a cleared product, all maintained as auditable records, not just implicit engineering knowledge held informally by the team. This is a genuinely different development discipline from typical fast-moving SaaS iteration — a startup accustomed to shipping several times a day needs to build a development process compatible with formal design control and change management well before a submission is anywhere near ready, since retrofitting QMS discipline onto an already-built, already-shipped codebase is dramatically more painful than building it in from the start.

Software using machine learning models for a diagnostic or clinical-decision function introduces additional regulatory considerations beyond traditional rule-based SaMD, largely because a model's behavior can change as it's retrained or updated in ways traditional software doesn't. The FDA has developed a specific framework for AI/ML-based SaMD centered on a "predetermined change control plan" — essentially, pre-specifying to the FDA exactly what kinds of model updates are anticipated and how they'll be validated, allowing a cleared AI/ML product to be updated within that pre-approved envelope without requiring a full new submission for every model retrain. Building toward this framework requires genuine collaboration between the ML engineering team and regulatory strategy from early in development, since the kinds of model updates a team plans to make in production need to be anticipated and documented well before the initial submission, not improvised afterward.

The most damaging and common mistake is not seriously evaluating SaMD classification until a product is already built and close to launch, at which point discovering that a core feature requires FDA clearance can mean months or years of delay and a substantial unplanned budget, sometimes threatening the company's runway directly. A second common mistake is treating regulatory strategy as a compliance checkbox handled entirely by outside consultants disconnected from actual product and engineering decisions, rather than as a genuine input into product architecture and development process from the start — the two need to be built together, not sequentially. A third mistake, specific to AI-driven products, is building and iterating on models without any thought toward how those iterations would need to be documented and controlled under a predetermined change control plan, creating a genuine retrofit problem when regulatory strategy catches up to already-established ML development practices.

Most digital health startups don't have in-house regulatory affairs expertise on the founding team, and bringing in specialized regulatory counsel or consultants early is genuinely worth the cost, even for an early-stage company watching every dollar of runway closely. The mistake to avoid is treating that engagement as a one-time classification opinion delivered at the start and then never revisited — SaMD classification isn't a static fact about a product concept, it can shift as features are added, as marketing claims evolve, or as the product's actual clinical use expands beyond its original scope. A recurring, structured check-in with regulatory counsel at each significant product milestone — not just at initial concept — catches classification-relevant changes before they've already shipped to users, which is considerably cheaper than discovering a compliance gap after the fact.

It's also worth being deliberate about how marketing and product teams describe the product's capabilities, since regulatory classification often turns partly on the specific claims a company makes about what its software does, not purely on the underlying technical functionality. A feature description that says a tool "helps you understand your heart rhythm data" sits in a meaningfully different regulatory posture than one claiming it "detects atrial fibrillation" — and it's genuinely common for marketing copy to drift toward stronger, more specific clinical claims than the underlying regulatory strategy actually supports, creating exposure that has nothing to do with the underlying code at all.

Startups building for a global market face the added complexity that SaMD-equivalent regulatory frameworks exist independently in other major markets — the EU's Medical Device Regulation (MDR), the UK's MHRA framework, and various other national frameworks — each with its own classification rules, submission requirements, and timelines that don't automatically align with an FDA clearance obtained in the US. A product cleared under a 510(k) in the US doesn't automatically carry regulatory standing in the EU or elsewhere, and teams planning international expansion should factor a genuinely separate, parallel regulatory strategy into their timeline and budget rather than assuming US clearance transfers directly. This is worth planning for early as well, since some architectural and documentation decisions made to support a US submission can be structured to also support parallel international submissions more efficiently, if that alignment is planned from the start rather than addressed as an afterthought once US clearance is already in hand.

For digital health startups, SaMD classification isn't a late-stage legal formality — it's a foundational product and engineering decision that shapes development process, timeline, and go-to-market strategy from the earliest stages. Startups that evaluate classification honestly and early, and build development practices compatible with FDA's quality and change-control expectations from the start, avoid the costly, sometimes existential retrofit that comes from discovering the requirement only after a product is already built.

Building a digital health product that may be regulated as SaMD? Let's architect it correctly from day one.