How New Health Tech Actually Gets Approved

In the United States, the Food and Drug Administration reviews anything that meets the legal definition of a medical device before it can be marketed for a medical purpose — historically physical hardware like pacemakers and imaging machines, now extended to qualifying software as well. Most countries run an equivalent body; the specific name changes, the underlying idea does not.

Not everything health-adjacent needs this review. A general wellness app that tracks steps and never claims to diagnose or treat anything typically falls outside it entirely — the trigger is a specific claim about diagnosing, treating, or preventing a disease, not just the general subject matter of health.

Which review a given product actually gets, though, is not uniform even among the software that does qualify. Regulators sort medical devices, software included, into risk classes first, and the class is what actually decides how much evidence has to exist before anyone is allowed to use it.

A device's risk class is set by how much harm a failure could cause, not by how complex the technology inside it is — a simple piece of software making a high-stakes call can sit in a stricter class than a complex one making a low-stakes suggestion.

SaMD covers software that performs a medical function on its own, without needing to run on a piece of dedicated hardware — an app that analyses a scan and outputs a diagnosis-relevant result, for instance, without itself being a scanner. The category exists because that kind of software makes exactly the sort of decision that used to require a physical device a regulator had already been reviewing for decades, and pretending it was “just an app” because it ran on a phone would have left a real gap in oversight.

Most SaMD lands in Class II, the moderate-risk tier — meaning most of it does not go through the full evidence-generation process Class III requires. That shortcut is common enough, and consequential enough, to be worth understanding on its own.

Most Class II devices, software included, clear a pathway that asks a narrower question than “is this safe and effective”: is it substantially equivalent to a device already on the market? Show that, and a company can clear a new product by comparing it to an existing predicate, rather than proving from first principles that it works.

The weakness is what happens over years. A new device can cite a predicate cleared five years earlier, which itself cited a predicate from five years before that, and so on — a chain that in the most-criticised cases traces back decades, sometimes to a device that was never clinically tested at all because it reached the market before today's evidence standards existed. Being substantially equivalent to something that was itself never proven safe is not the same as being proven safe.

1. 1

   A device is cleared as novel

   It goes through full review because nothing like it exists on the market yet.

2. 2

   A second device cites the first as its predicate

   It only has to show substantial equivalence — not repeat the original evidence-gathering.

3. 3

   A third device cites the second

   The chain has now moved two steps away from any product actually tested from scratch.

4. 4

   A later device in the chain reaches the market

   On paper it is equivalent to a product from a different technological era — one that may never have faced a trial at all.

Every pathway above assumes a device is a fixed thing: it gets reviewed once, and what gets approved is what ships. That assumption holds for a locked algorithm — the exact weights the model uses on day one are the exact weights it uses five years later, so testing that one snapshot really does tell you what the product will keep doing.

It does not hold for a model built to keep learning from new data after it is already deployed — what regulators call an adaptive algorithm. The version reviewed on approval day and the version actually running in a hospital eighteen months later can behave differently, and neither the original clearance nor a patient trusting the device particularly knows how differently. Regulators have started publishing draft frameworks for exactly this problem, mostly built around requiring a company to pre-specify the boundaries an algorithm is allowed to drift within rather than freezing it entirely — but there is no settled, universally adopted answer yet. It is one of the open questions in this entire field.

A typical consumer app ships, gets user feedback, and iterates in public — bugs get patched after launch, not eliminated before it. A regulated medical device, software or not, has to demonstrate safety and effectiveness with real evidence before a single patient can be affected by it, and any meaningful change afterward can trigger a fresh review rather than a routine update.