RatedWithAI

RatedWithAI

Accessibility scanner

AI Legal & ComplianceAugust 6, 2026

Your Marketing Page Decided You Were a Medical Device

Whether health software is regulated turns on intended use, and intended use is established by what the company says the product does. Two teams can ship functionally identical features; the one whose landing page promises to flag likely conditions has made a regulatory decision the engineering team never discussed.

Intended use
Claims establish it — the architecture is largely beside the point
All four
The CDS exclusion requires every condition, not most of them
Independent review
The clinician must be able to reach the conclusion without the output

The Definition Is About Purpose, Not Technology

The statutory device definition covers an article intended for use in diagnosis, cure, mitigation, treatment or prevention of disease, or intended to affect the structure or function of the body. Nothing in it references machine learning, and that is the point teams miss. There is no AI-specific trigger. A deterministic rules engine that claims to detect sepsis risk is on the regulated side; a large language model that summarizes a visit note for the clinician's own review generally is not.

Intended use is evidenced by labeling, promotional materials, sales conversations and the circumstances of distribution. Website copy, a demo script, a sales deck, a conference booth banner and a customer-success email are all capable of establishing it. This is why the regulatory question is so often decided by people who were not in the regulatory conversation.

The Clinical Decision Support Exclusion, Condition by Condition

The Cures Act carved certain decision-support software out of the device definition. The conditions are cumulative — meeting three of four leaves you inside the definition.

  • No signal acquisition or analysis. Software that acquires, processes or analyzes a signal from an in vitro diagnostic, a monitor, an imaging system or a wearable sensor stream falls outside the carve-out immediately. Ingesting a structured lab result from a record is different from analyzing the waveform that produced it, and the distinction does real work.
  • Display or analysis of medical information. The software works from patient medical information, clinical guidelines and peer reviewed studies — the kinds of inputs a clinician would themselves consider.
  • For a health care professional. The exclusion is written around professionals. Patient-facing decision support is treated differently and does not benefit from this provision.
  • Independent review of the basis. The professional must be able to independently review the basis for the recommendation so as not to rely primarily on it. This is where most products fail.

Why Independent Review Is Harder Than It Sounds

The condition is not satisfied by transparency in the general sense. It asks whether a clinician could, in the ordinary course, reach the same conclusion from the underlying inputs without depending on the software's output. That means the product needs to surface the specific patient data it relied on, the clinical basis for the relationship, and enough of the reasoning that a professional could evaluate it rather than defer to it.

Several common design patterns cut against this. A single risk score with no decomposition gives nothing to review. Feature-attribution values are an artifact of the model, not a clinical rationale, and a clinician cannot verify them independently. Time-pressured workflows that surface a recommendation at the moment of ordering encourage exactly the primary reliance the condition is meant to exclude. And products that identify a specific patient as high priority for a specific condition — rather than presenting information the clinician evaluates — read as directing the decision.

There is a design corollary worth stating plainly: the interface choices that make a product feel most useful in a demo are frequently the same choices that pull it inside the device definition.

The Wellness Boundary and How Products Drift Across It

The general wellness policy contemplates low-risk products intended to maintain or encourage a healthy lifestyle, with references to health conditions kept general rather than tied to a named disease. Sleep quality, activity, hydration, stress management and general nutrition sit comfortably inside it.

Drift happens gradually and usually through language. A sleep feature adds a note suggesting a user discuss possible apnea. A nutrition tracker starts flagging patterns consistent with prediabetes. A skin-photo feature moves from tracking changes over time to characterizing what a lesion is likely to be. Each step is small, each is a reasonable product decision on its own terms, and the cumulative effect is a product that now names conditions and advises action.

The other frequent driver is the sales team. A wellness product being sold to health systems is under pressure to describe clinical outcomes, and outcome claims about specific diseases are exactly what the wellness policy excludes. It is common for the product documentation to be careful and the enterprise deck to be much less so.

If You Are On The Regulated Side

Being a device is not a disaster; being an unregistered one is a problem. The practical consequences are a risk-based classification, a marketing pathway — most AI-enabled software has historically come through premarket notification or the De Novo route for genuinely novel low-to-moderate risk products — plus quality-system obligations, labeling requirements, adverse-event reporting and postmarket surveillance.

For continuously improving models, the predetermined change control plan is the mechanism that makes iteration compatible with clearance. The sponsor describes the modifications it anticipates, the protocol for developing and validating them, and an assessment of their impact, and changes falling within that pre-authorized envelope can ship without a new submission. Building the plan forces a discipline most teams benefit from anyway: writing down in advance what kinds of change are in scope and what evidence will demonstrate the model still performs.

A Practical Review Before Your Next Launch

  • Collect every external claim in one place — homepage, feature pages, app store listing, sales deck, onboarding copy, support articles — and read them as a single statement of intended use, because that is how they will be read.
  • Flag every verb that implies diagnosis, detection, prediction of a named condition, triage, or a recommendation to act. Those are the sentences that decide the question.
  • For each claim, ask whether a clinician could independently reach that conclusion from what the product shows them. If the honest answer is that they would take the output on trust, the carve-out is not available.
  • Check whether any input is a signal from a sensor or diagnostic rather than recorded medical information. That fact alone can settle it.
  • Confirm the sales and marketing narrative matches the product documentation. Divergence between the two is both an FDA problem and an advertising-claims problem.
  • Write the intended-use statement down and put someone in charge of it. Absent an owner, intended use is defined by whoever last edited a landing page.

Frequently Asked Questions

We only summarize notes and surface guidelines. Are we clear?

Administrative and documentation support, summarization for the clinician's own review, and retrieval of published guidance sit well away from the device definition as long as the product is not characterizing a patient's condition or recommending a course of action. Watch the edges: a summary that adds an assessment the source did not contain, or a guideline surfaced as applicable to this patient, is a different product from the one described in the requirements document.

Does having a clinician in the loop remove the regulatory question?

No. Human review is relevant to the independent-review condition, but only where the human is genuinely positioned to evaluate the basis rather than to acknowledge an output. A sign-off step in a workflow that presents a conclusion and an approve button is not the same thing, and the FDA's analysis has focused on whether the design supports real independent judgment.

Is a disclaimer that we are not a medical device sufficient?

A disclaimer sitting alongside claims that describe diagnostic function generally does not resolve the tension; it documents that you were aware of it. Intended use is assessed from the whole picture, and a boilerplate line in a footer carries little weight against specific promises made elsewhere. Fix the claims rather than annotating them.

How do EU rules interact with this?

The EU Medical Device Regulation has its own definition and classification rules for software, and its risk classification for decision-support software is generally regarded as stricter than the historical US treatment. The EU AI Act adds a further layer, treating AI that is a safety component of a regulated device as high risk with its own obligations. A product outside the US device definition can still be regulated in the EU, so the analyses must be run separately.

What triggers an FDA look at a small company?

Most commonly complaints from competitors or clinicians, publicity around a specific claim, adverse-event reports, and the company's own promotional material. There is no scale threshold in the definition. In practice, though, many companies encounter the issue first through enterprise procurement, where a health-system review asks whether the product is a device and expects a defensible answer.

Our claims have drifted over three years. Where do we start?

Start with an inventory rather than a rewrite. Pull every public claim into one list with its location and date, sort by how strongly it implies diagnosis or treatment, and work down. The exercise usually turns up a small number of old pages carrying claims nobody would approve today, which are also the pages most likely to be quoted back to you.

Find Every Health Claim on Your Site Before a Regulator Does

Intended use is built from the sentences on your website, and those sentences accumulate across years and teams. The strongest claim is almost never on the page you would think to check.

See every claim your site makes in one pass. Run a free scan and read the results as a statement of what your product is intended to do.

This article is general information and not legal or regulatory advice. Device classification is fact-specific and FDA guidance evolves. Confirm your analysis with qualified regulatory counsel before making launch or labeling decisions.