Is Your Feature a Medical Device? A PM's Map of SaMD and FDA Regulatory Pathways

Your feature becomes a medical device the moment its intended use claims to diagnose, treat, cure, mitigate, or prevent disease — not because of the algorithm, the data, or how sophisticated the code is. A symptom checker that says "here's information to discuss with your doctor" is different, in the FDA's eyes, from one that says "you likely have condition X." That single sentence in your UI copy is a regulatory decision.

Quick Answer: Software becomes a regulated medical device (SaMD) when its labeled intended use is to diagnose, treat, or drive a clinical action — not based on its technology. Clinical Decision Support tools that inform rather than direct clinicians are often exempt; tools that replace clinical judgment usually need 510(k) clearance or De Novo authorization.

Most healthtech PMs discover this the hard way: mid-sprint, when legal asks "wait, what does this feature actually claim to do?" This piece gives you the decision tree, the real regulatory categories, and the wording discipline to catch the issue before legal has to.

What Actually Triggers FDA Medical Device Regulation

The trigger is the intended use statement — what you claim the software does, as expressed in labeling, marketing, and the UI itself — not the underlying technology stack. The FDA regulates claims, not code.

This distinction traces back to the FD&C Act's definition of a "device," which turns on intended use for diagnosis, cure, mitigation, treatment, or prevention of disease. Software that merely organizes, displays, or stores health information generally falls outside that definition.

Three factors determine whether your feature crosses the line:

1. The claim — does the output text say "this is informational" or does it say "you have"?
2. The clinical role — does a clinician review the output before any action, or does the software drive the decision directly?
3. The population and severity — is this for a low-acuity, non-time-critical condition, or something where a wrong output causes real harm?

The FDA's 2022 Clinical Decision Support guidance and the 21st Century Cures Act's Section 3060 exemptions both hinge on these same three questions — intended use, clinician role, and time-criticality.

Why PMs Own This, Not Just Legal

Regulatory classification isn't a legal afterthought bolted onto a finished feature — it's a product decision made in the spec, usually accidentally, by whoever wrote the button copy. A PM writing "diagnose your rash" versus "understand possible causes" has just picked a regulatory pathway.

This is exactly the kind of decision that belongs in your specification alongside acceptance criteria, not discovered in a legal review two weeks before launch. Teams building on frameworks from our healthtech complete guide treat intended-use wording as a first-class spec artifact, reviewed with the same rigor as data schemas.

The Decision Tree: Exempt, 510(k), or De Novo

Software falls into one of four broad buckets, and each has a different burden of proof, timeline, and cost. Knowing which bucket you're aiming for before you design the feature changes what you build.

Class I, II, and III map onto risk, not novelty — Class I devices carry general controls only, Class II (where most SaMD lands) requires 510(k) or De Novo, and Class III requires the much heavier Premarket Approval (PMA) pathway, reserved for high-risk devices like implantable defibrillator software.

Step 1: Does It Meet the Device Definition at All?

Ask whether the software's intended use, as written, claims a diagnostic or therapeutic function. If your feature only aggregates patient-reported data for a clinician to review with their own judgment, it's likely not a device — but document that reasoning; "we didn't think about it" isn't a defense during an audit.

Step 2: Does It Qualify for the CDS Exemption?

The 21st Century Cures Act carved out an exemption for Clinical Decision Support (CDS) software meeting four criteria: it doesn't analyze medical images or signals directly, it displays recommendations rather than acting alone, it explains the basis for its suggestion, and a clinician can independently review that basis without relying on the software as the sole source.

• Fails any one criterion → likely regulated, not exempt.
• The "independent review" bar is the one teams misjudge most — a black-box confidence score with no rationale usually fails it.
• FDA's non-binding CDS guidance (2022) is the primary reference; when in doubt, a pre-submission (Q-Sub) meeting with the FDA can confirm your read before you build.

Step 3: 510(k) or De Novo?

If a similar device has already been cleared — a predicate — you likely file a 510(k) showing substantial equivalence. If nothing comparable exists, you need De Novo, a novel-risk pathway that establishes a new device classification and, notably, itself becomes a predicate for future submissions once granted.

De Novo is often the right call for genuinely new AI-driven diagnostic categories — but it's slower and requires original risk-benefit evidence, not just a comparison.

The Symptom-Checker Example: One Sentence, Two Regulatory Worlds

The clearest way to see the intended-use trigger in action is a single feature phrased two ways. Same model, same UI, same data — different regulatory fate depending on the closing sentence.

Version A (likely non-device or CDS-exempt): "Based on what you've described, here is general information about conditions with similar symptoms. This is not a diagnosis — please discuss with your doctor."

Version B (likely Class II device requiring 510(k)): "Based on your symptoms, you likely have [condition]. Recommended action: [treatment]."

Version A frames the output as educational context a person weighs before seeking care — closer to a search engine than a diagnostician. Version B asserts a specific clinical conclusion and a directive next step, which is precisely the diagnose-and-treat function the FD&C Act's device definition targets.

The underlying model can be identical. Nothing about the algorithm changed between A and B — only the claim did. That's the whole point: wording is the regulatory decision, and it's usually a PM, not a lawyer, who writes it first in a spec doc or a Figma comment.

Where Teams Get Burned

• Marketing copy drifts past what engineering built. A landing page promising "instant diagnosis" can pull an exempt tool into device territory even if the in-app text is careful.
• Feature creep changes intended use silently. A symptom-information tool that later adds "confidence: 87%" next to a specific condition name has quietly become directive.
• Localization loses nuance. "Podría indicar" (could indicate) translated loosely can become an assertive claim in another language's UI.

Building Regulatory Awareness Into Your Product Process

Regulatory risk should be a gate in your spec, not a surprise in your legal review — reviewed at the same checkpoints as security or privacy, because the cost of catching it late is a redesign, not a copy edit.

Neither of these replaces a real regulatory consultant or an FDA pre-submission meeting — they're intended as an earlier, cheaper checkpoint in the drafting process, not a substitute for legal sign-off.

Pair This With Your Broader Compliance Stack

SaMD classification rarely travels alone — the same feature that raises a device question usually touches data privacy too. If you're handling protected health information alongside the clinical claim, review it against the practices in HIPAA for product managers at the same spec stage.

Because SaMD decisions almost always affect both a clinician and a patient differently, revisit your interface plans through the lens of clinician vs. patient dual-user design — the same wording that's "informational" to a clinician reading a chart may read as "directive" to an anxious patient. And if your feature layers AI on top of clinical judgment at all, AI clinical decision support safety covers the safety-monitoring practices FDA guidance increasingly expects post-market.

Documenting the Decision So It Survives an Audit

A verbal agreement that "this is fine" doesn't hold up when an investor's due-diligence team or an FDA auditor asks for your reasoning. Write down the intended-use analysis the same way you'd document any other product decision with legal weight.

Understanding how your users actually experience and act on these claims also sharpens the intended-use analysis — the jobs to be done complete guide and customer journey complete guide frameworks are useful here for mapping exactly which moment in a user's journey your feature's output lands in, and how directive it actually feels to them in context — which is often more revealing than the literal copy.

Key Takeaways

• Intended use, not technology, triggers device regulation — the same model can be exempt or Class II depending on how its output is worded.
• CDS exemption (Cures Act Section 3060) applies only when a clinician can independently review the basis for a recommendation, not just see a confidence score.
• 510(k) requires a comparable predicate device and substantial-equivalence evidence; De Novo applies when no predicate exists and typically takes longer.
• Marketing copy and localization can silently change your regulatory status even when the in-app UI language was carefully written.
• Document the rationale, not just the decision — auditors and investors will ask why, not just what.
• Build the gate into your spec process — readiness gates and pre-launch critiques catch drift before it ships, they don't replace regulatory counsel.