How Software Became a Medical Device

By Alex

The Therac-25 reached the American market in 1983 without a clinical trial. It was a radiation therapy machine, it was a substantial redesign of an earlier model, and it cleared regulatory review by declaring itself equivalent to something already on sale. Its most consequential innovation was invisible: the hardware interlocks that physically prevented the beam from firing at the wrong power had been removed, and the job of stopping that from happening was handed to software. Between 1985 and 1987 at least six patients received massive radiation overdoses. All eleven machines were pulled in 1987.

Four decades later, roughly 97% of the AI-enabled medical devices on the US market got there through the same mechanism — a declaration of substantial equivalence to a predicate device. The framework that regulates medical software today was not designed for software. It was retrofitted, one definitional crisis at a time, onto a body of law built for physical objects that do not change after they ship.

The accident that made software a regulatory object

Before Therac-25, software inside a medical device was treated as an implementation detail. Regulators inspected the device: its materials, its electrical safety, its physical failure modes. Code was something the manufacturer used to build the thing, not the thing itself.

What made Therac-25 a turning point was not that software failed. It was that only software failed. The hardware was fine. There was no burnt component to find, no fatigue crack, nothing an inspector trained on physical devices would recognise as a defect. The failure was a race condition triggered by an operator typing quickly enough to correct a data entry before a magnet finished moving — reachable only through a particular sequence of keystrokes at a particular speed, and therefore invisible to any test regime that assumed a device either works or is broken.

The regulatory lesson took a long time to absorb. From 1983 to 1997, 6% of all FDA device recalls cited software as the cause. That figure has climbed steadily ever since, and it is the reason software validation, design controls and traceability became mandatory rather than advisory. It is also why the modern requirements look strange to a general software team: they are not asking whether the code works. They are asking whether you can prove which requirement each line exists to satisfy, and what you did to establish that it does.

Naming the thing: 2013, and software with no device attached

Therac-25 was software inside a machine. The harder question arrived when the machine went away entirely — when the product was an algorithm running on a general-purpose computer, or later, a phone.

The International Medical Device Regulators Forum settled the terminology in 2013 with “Software as a Medical Device”: software intended for a medical purpose that performs that purpose without being part of a hardware medical device. The following year it published the framework that still underpins how most regulators think about the category, IMDRF/SaMD WG/N12 FINAL:2014, updated in N81 FINAL:2025.

The framework is a two-by-two, and its elegance is that neither axis is technical. One is what the software’s output does: does it inform clinical management, drive it, or diagnose or treat directly. The other is the state of the patient: non-serious, serious, or critical. Cross them and you get categories I through IV.

Nothing in that grid asks about the architecture, the language, the model, or whether there is machine learning involved. Risk is defined entirely by what happens to a patient if the output is wrong and nobody catches it. This is the single most useful thing for an engineering team to internalise, because it means the regulatory burden of a product is set almost entirely by its intended use statement — a document usually written by marketing.

Two continents, two opposite answers

Having named the category, regulators immediately disagreed about how much of it to regulate.

The US carved a hole in it. Section 3060(a) of the 21st Century Cures Act, passed in 2016, amended the Federal Food, Drug and Cosmetic Act to add section 520(o), which excludes certain clinical decision support software from the definition of a device altogether. Not exempt from review — not a device at all. The criteria under 520(o)(1)(E) are the boundary: broadly, software that displays or analyses well-understood medical information, supports a healthcare professional’s own decision, and allows that professional to independently review the basis for the recommendation rather than relying on it.

That last clause is the load-bearing one, and it is why the carve-out excludes software that analyses medical images, signals or patterns. A clinician can independently review a lab value flagged against a guideline. Nobody can independently review a convolutional network’s read of a chest X-ray.

Europe went the other way. Rule 11 of Annex VIII of the EU Medical Device Regulation classifies software by the significance of the information it provides — and its practical effect was a wholesale up-classification. Software that was Class I under the old directives, self-certified with no external involvement, landed in Class IIa or higher, which requires a notified body. For a small European health-software company this was not a paperwork change; for many it was the end of the product.

So the same piece of software can be outside the definition of a device in one jurisdiction and a notified-body-reviewed Class IIa product in the other. Anyone building for both markets is managing two regulatory identities for one codebase.

Where the line actually sits

The abstractions get much clearer with examples, and the examples are more counterintuitive than the rules suggest.

A watch that displays your heart rate is not a medical device. A watch that analyses the same signal and notifies you of a possible arrhythmia is — the sensor did not change, the claim did. A general wellness app that encourages exercise sits outside the definition; the same app that tells a diagnosed cardiac patient how much exercise is safe sits inside it, because the population it addresses moved from healthy people to patients.

A drug dosage calculator that applies a published formula to values a clinician enters is usually the textbook case of excluded decision support: the logic is transparent, the clinician can check the arithmetic, and the underlying reference is public. Wrap the same calculation in a model that weights patient history to produce one recommended dose and the independent-review criterion breaks, because the clinician can no longer reconstruct why that number and not another. Same clinical task, opposite side of the line.

Two patterns run through all of this. The first is that the boundary tracks reviewability, not sophistication — a complicated but inspectable calculation stays outside, while a simple model whose reasoning is opaque does not. The second is that the patient population matters as much as the function. Software aimed at healthy people maintaining wellness has a wide berth. The moment the intended user is someone with a diagnosis, the same functionality is being used to manage a disease, and disease management is the definition of a medical purpose.

This is also where products drift into scope without anyone deciding to. A wellness feature acquires a “consult your doctor if we detect X” notification. A B2B analytics dashboard adds a flag for at-risk patients. Nothing about the release process signals that the regulatory classification just changed, because the change happened in a product decision, not a technical one. The organisations that stay out of trouble here are the ones where someone reviews claims — in the UI, in the marketing copy, in the sales deck — against the classification the product was built for.

The assumption AI breaks: that a device stops changing

Every mechanism described so far shares a hidden premise. A device is reviewed, cleared, and then it is that device. If you change it materially, you file again. The premise held for decades because it was a fact about physical manufacturing.

It is not a fact about a model that retrains on new data. The old workaround was the “locked algorithm” — freeze the weights at submission, ship the frozen version, and treat any retrain as a new submission. This is regulatorily clean and clinically absurd, since the whole argument for machine learning in diagnostics is that performance improves as data accumulates.

FDA’s answer arrived on 3 December 2024 as final guidance on the Predetermined Change Control Plan. A PCCP lets a manufacturer describe, in the original submission, changes it intends to make later — and get those changes authorised in advance. It has three parts: a description of the modifications, a modification protocol setting out how each will be developed, validated and rolled out, and an impact assessment. Unlike the draft, the final guidance covers all AI, not only machine learning.

The conceptual shift is larger than it looks. Regulators are no longer only approving an artifact. They are approving a process for changing an artifact — reviewing the manufacturer’s method rather than only its output. Which, incidentally, is roughly what ISO 27001 does for security management, and what design controls have always attempted for device development. Software keeps pushing regulators from inspecting things toward auditing processes.

The practical consequence for anyone building an AI-enabled product: the PCCP has to exist at submission time. Deciding a year later that you would like to retrain on new hospital data does not get you a PCCP retroactively. It gets you a new submission.

What the category actually looks like today

The numbers are worth sitting with. FDA had authorised roughly 1,451 AI/ML-enabled devices through the end of 2025, up from six in 2015. The 2025 cohort alone was 295 devices.

The distribution is lopsided in two directions. By specialty, radiology accounts for about 76% of everything cleared, with cardiovascular at 9% and neurology at 5% — a consequence of imaging having been digital, labelled and centrally stored for longer than any other clinical data. By pathway, roughly 97% went through 510(k), about 2–3% through De Novo, and around 0.4% through premarket approval.

That 97% deserves more attention than it gets. The 510(k) pathway establishes that a new device is substantially equivalent to a legally marketed predicate. For an AI product, the predicate is frequently another AI product, which was itself cleared against an earlier one. The chain can run back to a device cleared before deep learning was in clinical use at all. Substantial equivalence was designed to spare manufacturers from re-proving what a near-identical device had already proven. It was not designed to carry a category whose underlying technology turns over every eighteen months.

This is the direct descendant of the Therac-25 problem. Not the same failure, but the same structural gap: a pathway built on the assumption that similar-looking devices fail in similar ways, applied to systems whose failure modes depend on training data nobody outside the manufacturer has seen.

The regimes are now stacking — and diverging

Two things happened in 2026 that pull in opposite directions.

In Europe, an AI-enabled device that already needs a notified body under MDR is also a high-risk AI system under the AI Act, because it is a safety component of a product subject to third-party conformity assessment under Annex I harmonisation legislation. In practice that means MDR Class IIa, IIb and III devices generally inherit high-risk status. The obligations — risk management, data governance, technical documentation, logging, human oversight, post-market monitoring — overlap heavily with MDR but are not identical to it. The deadline for embedded high-risk systems is 2 August 2028, and a single conformity assessment is permitted where the notified body holds accreditation under both regimes — though how many bodies actually will is an open question.

In the US, the direction reversed. In January 2026 FDA issued a revised final CDS guidance replacing the September 2022 version, and its central change was enforcement discretion for single-recommendation outputs under criterion 3 — software that gives one answer rather than a ranked list, previously a strong signal that the tool had crossed into device territory. By July 2026 the agency had announced a broader easing of digital health oversight, with Commissioner Marty Makary framing the goal as regulation moving at “Silicon Valley speed.”

The result is a genuine strategic problem rather than a compliance detail. A product can be simultaneously moving out of scope in its largest market and into a second parallel regime in another. Documentation built for one is not automatically evidence for the other, and the EU’s requirements do not relax because the US relaxed.

What this means if you are building the software

Three things follow, and none of them are about the code.

First, the intended use statement is the highest-leverage document in the project. “Detects pulmonary nodules” and “assists radiologists in reviewing chest imaging” describe the same model and different regulatory products. This is not a loophole to exploit — claiming less than the product does creates its own liability — but it is where classification is actually decided, and it should be settled before architecture, not after.

Second, the evidence has to be generated as you go. Design history, requirement traceability, verification and validation records, risk analysis under ISO 14971, and a software lifecycle under IEC 62304 are all reconstructable in principle and nightmarish in practice. Teams that treat them as a documentation phase after development discover that the records they need are the ones nobody wrote down. This is the same lesson that structured QA practice teaches in ordinary software, with a regulator instead of a customer at the end of it.

Third, plan the change mechanism before you need it. If the product will learn, the PCCP belongs in version one. If it will ship in Europe, the MDR classification and the AI Act’s high-risk obligations need to be assessed together rather than sequentially. Retrofitting either is expensive in a way that scales with how successful the product has already become — which is precisely when nobody wants to stop and do it. Working through this on a real submission, as with certifying a device end to end or building software that is itself the device, tends to be where teams discover which of their assumptions were engineering assumptions and which were regulatory ones.

The category has been assembled backwards over forty years, one edge case at a time, and it shows. Every layer — equivalence, SaMD, the CDS carve-out, Rule 11, PCCPs — exists because the previous layer met something it could not classify. AI is simply the current thing that does not fit, and it will not be the last. The useful posture is not to memorise the current rules but to understand what each of them was trying to fix, because that is what predicts where the next patch lands.