What Is Software as a Medical Device (SaMD)?
Software as a Medical Device, or SaMD, is software that performs a medical purpose on its own — diagnosing, treating, monitoring, or informing a clinical decision — without being part of a hardware device's control system. The category is about what the software is intended to do, not what platform it runs on, what language it's written in, or how sophisticated its underlying logic is.
Quick Answer: SaMD is standalone software that performs a medical function by itself, as distinct from software that merely runs inside, or drives, a piece of hardware. Whether a specific product qualifies — and which regulatory pathway would apply if it does — is a fact-specific determination only FDA regulatory counsel can make for your exact product and claims. This article explains the concept and the general decision framework behind it, not a verdict on your app.
SaMD isn't a compliance footnote you handle after building — it's a category that can quietly reshape your product's architecture, your evidence plan, and your runway if you don't spot it early. This piece defines the term and the general reasoning framework behind it. For the broader discipline of testing any startup idea before you commit to building it, start with our complete guide to startup idea validation; this article is the medical-specific layer that sits on top of that general process.
What Makes Software SaMD — and What Doesn't
Three things generally separate SaMD from ordinary software: it has a stated medical purpose, it performs that purpose entirely on its own, and it isn't functioning as part of a hardware medical device's operation. Drop any one of those three, and the software typically falls outside the category.
A stated medical purpose means the software is intended — through its labeling, its marketing claims, or how it's described to users — to diagnose, treat, cure, mitigate, or prevent a disease or condition, or to otherwise inform a specific clinical decision using patient-specific data. This is the piece founders most often underestimate: intended use is usually judged by what you say the product does, not by the cleverness of the code underneath it. Two apps built on identical technology can land on opposite sides of the line purely because of how one is marketed. Our companion piece on whether your app counts as a medical device walks through that intended-use test in more depth.
Performing the purpose on its own is what separates SaMD from software that is simply part of a hardware device. If the software's function is inseparable from operating a physical instrument — the dosing logic inside an infusion pump, the signal processing inside an imaging scanner — it's generally treated as part of that hardware device, not as standalone SaMD. SaMD, by contrast, runs independently: on a phone, a laptop, a general-purpose server, or in the cloud, detached from any specific piece of regulated hardware.
A handful of general factors tend to push software toward the SaMD side of that line, and a handful tend to push it away:
- Toward SaMD: analyzing patient-specific data (an image, a waveform, a set of clinical inputs) to produce an output tied to diagnosis or treatment; naming a specific disease or condition in its claims; producing an output a clinician or patient is meant to act on for a specific medical decision
- Away from SaMD: general wellness, fitness, or lifestyle framing with no disease named; purely administrative functions like scheduling, billing, or general recordkeeping; showing general information back to a user without analyzing their specific data toward a clinical decision
Treat this list as a way to notice when a product is worth a closer look, not as a self-assessment checklist. The actual determination for any real product depends on its exact claims and use context, and that read belongs to a regulatory affairs specialist, not a framework summary.
How SaMD Risk Categorization Works, in General Terms
Regulators don't treat all SaMD the same way — frameworks used to think about SaMD risk generally weigh two variables together: how serious the underlying healthcare situation is, and how much weight the software's output carries in the resulting clinical decision. The more serious the situation and the more the output drives rather than merely informs a decision, the more regulatory scrutiny that combination tends to invite. Where any specific product actually lands on that spectrum is not something to self-assess from a general description — it takes a regulatory specialist looking at the product's real intended use and claims.
The first variable is roughly the state of the healthcare situation the software addresses — think of it as a spectrum from non-serious situations, through serious ones, up to critical, life-threatening ones. The second is roughly the significance of the information the software provides — a spectrum from software that simply informs a decision a clinician will independently evaluate, up through software whose output more directly drives a specific treatment or diagnosis. Higher on both axes generally means a higher expected risk category; lower on both generally means a lighter one. That's the shape of the reasoning, not a rule you can apply to your own product without qualified review.
In the United States, once something is determined to meet the medical device definition, the FDA's general framework sorts devices into risk classes, and a handful of named pathways exist to route products to market. In broad terms: a 510(k) submission rests on showing substantial equivalence to an already-cleared "predicate" device; the De Novo pathway exists for genuinely novel devices, often lower-to-moderate risk, that don't have a suitable predicate; and Premarket Approval (PMA) is the more involved pathway generally reserved for the highest-risk devices, typically backed by clinical data. Each of those names describes a real category of pathway — but which one, if any, would apply to a specific product, what evidence it would require, and how long it would take are questions that depend on specifics that change and vary by device type. Confirm all of that with FDA regulatory counsel for your actual product rather than treating any general description as authoritative.
SaMD vs. Embedded Software vs. Wellness Software: Where Products Land
The fastest way to see where SaMD sits is side by side against the two categories founders confuse it with most often — software embedded in hardware, and general wellness software with no stated medical purpose.
| Software type | What it typically does | Where it generally lands | Why |
|---|---|---|---|
| Standalone diagnostic or analysis software | Analyzes patient-specific data — an image, a signal, a set of clinical inputs — and produces an output meant to inform or drive a clinical decision | Commonly discussed as SaMD-type functionality | Performs a medical purpose entirely on its own, independent of any specific hardware |
| Embedded or device-control software | Runs inside, or directly drives, a piece of hardware — dosing logic in an infusion pump, signal processing in an imaging scanner | Generally regulated as part of the hardware device, not as standalone SaMD | The software's function is inseparable from operating the physical device |
| General wellness or lifestyle software | Tracks habits, shows trends, or offers general encouragement without naming or diagnosing a condition | Generally understood to sit outside the medical device definition | No stated medical purpose tied to a specific disease or clinical decision |
| Administrative or operational software | Handles scheduling, billing, or general records management in a clinical setting | Outside the medical device definition | Doesn't perform a medical purpose on patient data at all |
Read this table as a rough map of where products tend to cluster, not a checklist for scoring your own product. Plenty of real software sits close enough to a boundary row — a wellness app that starts naming a condition, an informational tool that starts producing patient-specific recommendations — that only a regulatory specialist reviewing your actual labeling and claims can say with confidence which side it falls on.
A Hypothetical Diagnostic Algorithm, Walked Through the Framework
Take a purely hypothetical example to see how the reasoning works — not to reach a verdict, since no blog post can determine a real product's status.
Imagine an app where a user photographs a skin lesion, and the software analyzes the image alongside patient-specific inputs — age, lesion history, family history — to output a risk indication and a recommendation on whether to see a dermatologist. Run that hypothetical through the same questions the framework above raises:
- Does it analyze patient-specific data? Yes — the image and the personal history inputs are specific to one patient, not generic content.
- Does the output inform or drive a specific clinical decision? Yes — the recommendation is meant to influence whether someone seeks care for a possible malignancy.
- What's the state of the healthcare situation if the software gets it wrong? Potentially serious — a missed or delayed melanoma finding is not a minor inconvenience.
Every one of those factors points toward a product that would warrant a regulatory conversation well before the label, the marketing claims, or the underlying algorithm's intended use are finalized. That's not because this hypothetical is definitely SaMD — it's an illustrative example, not a real product, and a real determination requires a real regulatory review. It's because when multiple risk factors line up in the same direction like this, guessing gets expensive fast. Apply this same three-question pattern to your own product, and treat a "yes" on more than one of them as the signal to stop reasoning from a blog post and bring in a regulatory affairs specialist or FDA regulatory counsel.
When SaMD Status Changes Your Validation Plan
If there's a real chance your product could be SaMD, the moment to find out is before you've built anything expensive — because the answer changes what you validate, what evidence you need to collect, and how you're legally allowed to describe the product to users. Waiting until after launch to ask the question means discovering it after the architecture, the claims, and the go-to-market plan are already built around an assumption nobody verified.
A handful of things shift once SaMD is even plausibly on the table:
- Architecture decisions get regulatory weight. How you handle data provenance, algorithm versioning, and change control stops being a pure engineering choice and starts being something a regulatory review may scrutinize.
- Evidence planning gets heavier. User research and engagement metrics that satisfy typical product validation usually aren't enough on their own — clinical evidence of safety and performance becomes part of the picture.
- Marketing copy becomes regulated territory. The exact words on your landing page and in your app-store listing can themselves be the thing that determines your regulatory status, not just a description of it.
- Timelines and capital plans need a regulatory input. A go-to-market plan built without a regulatory pathway assumption tends to need a rewrite the moment that assumption turns out wrong.
None of this means treat every health-adjacent idea as automatically SaMD, or freeze work until a lawyer signs off on day one. It means run the regulatory question as its own validation track, in parallel with the rest of your work, rather than as an afterthought. Our guide to validating a medical device startup idea covers exactly that staged, parallel-track approach — proving clinical need and derisking the regulatory question at the same time, so a bad answer on either one kills the idea cheaply instead of after you've spent real money.
Key Takeaways
- SaMD is defined by intended use, not by technology. Software that performs a medical purpose on its own — diagnosing, treating, monitoring, or informing a clinical decision — is the category; how it's built is irrelevant to that question.
- Standalone is the key distinction from embedded software. Software that runs inside or directly drives a piece of hardware is generally regulated as part of that device, not as separate SaMD.
- Risk categorization weighs two things together. How serious the healthcare situation is, and how much weight the software's output carries in the clinical decision — higher on both generally means more expected scrutiny.
- 510(k), De Novo, and PMA are real pathway names, not self-service options. Each describes a different general route to market; which one applies to any specific product is a determination for regulatory counsel, not a framework summary.
- The decision framework is for spotting risk, not making a final call. Use it to notice when a product needs a closer look — never as a substitute for a regulatory affairs specialist reviewing your actual claims and labeling.
- Finding out early changes your validation plan, not just your legal risk. Architecture, evidence planning, marketing language, and capital needs all shift once SaMD is plausibly on the table.
Frequently Asked Questions
What is the difference between SaMD and software embedded in a device?
SaMD performs a medical purpose entirely on its own — on a phone, laptop, or server — independent of any specific piece of hardware. Software embedded in, or directly driving, a piece of hardware (dosing logic in a pump, signal processing in a scanner) is generally regulated as part of that hardware device instead. The dividing line is whether the software's function is separable from operating a physical instrument.
Is my health app automatically SaMD if it uses patient data?
Not automatically. Using patient-specific data is one factor that tends to push software toward SaMD, but it's not sufficient on its own — a food diary or a symptom log that shows information back to a user without producing a clinical recommendation typically stays outside the definition. Whether your specific app crosses the line depends on its actual claims and intended use, which is a determination for regulatory counsel, not a general rule.
Does SaMD need FDA clearance before it can launch?
It depends on the product's specific classification, which only a regulatory review of your actual intended use and claims can determine — some SaMD pathways require premarket clearance or approval, and general classification frameworks exist to sort risk levels, but neither this article nor any general description can tell you which applies to your product. Confirm your specific path with FDA regulatory counsel before finalizing a launch timeline.
Is a fitness or wellness app considered SaMD?
Generally no, as long as it stays in general wellness territory — tracking habits, showing trends, offering encouragement without naming or diagnosing a specific condition. The moment a wellness app starts naming a diagnosis or producing a patient-specific clinical recommendation, it moves toward the kind of claims that warrant a regulatory review rather than an assumption either way.