SaMD & regulation (FDA · CDSCO · CE)
When does your software become a medical device? The question decides whether you ship on Friday or spend two years in a regulatory pathway — and the line is narrower than most teams assume.
In one line
Software as a Medical Device (SaMD) is software intended for a medical purpose that isn't part of a hardware device. If your software is SaMD, it is regulated like a device — and the line between "a helpful tool" and "a regulated device" is drawn by intended use, not by technology.
The question that decides everything
Not what does it do? but what do you claim it does?
Two identical pieces of software:
- "Displays the patient's lab trends." → probably not a device.
- "Detects sepsis." → almost certainly a device.
Same code. Same maths. Different intended use, different regulatory universe. Regulators read your marketing, your manual, and your sales deck as evidence of intended use — which is why a product manager's enthusiastic sentence can, quite genuinely, reclassify your product.
This catches teams badly. The engineers think regulation is about risk in the code. It is about claims, and the claims are made by people who have never read the guidance.
The FDA's line for decision support
The US CDS guidance turns on whether the clinician can independently review the basis for the recommendation:
- Software that shows its reasoning, so a clinician can reach their own conclusion → generally not a device.
- Software that issues a directive the clinician is expected to rely on, without being able to interrogate why → is a device.
That's support the decision versus make the decision, and it maps directly onto the explainability problem. A black-box model that says "risk 0.83, start antibiotics" cannot be independently reviewed — the opacity itself pushes you across the regulatory line. Explainability isn't only an ethical nicety; it's load-bearing in the classification.
Risk classes, roughly
IMDRF frames it by two axes: the significance of the information (treat/diagnose vs drive clinical management vs inform) crossed with the state of the condition (critical vs serious vs non-serious). Inform-a-decision about a non-serious condition is low risk. Treat a critical condition is the top.
Jurisdictions then map that to their own classes:
| Framework | Classes | |
|---|---|---|
| US | FDA | Class I / II / III — most SaMD lands in II (510(k) or De Novo) |
| EU | MDR | I / IIa / IIb / III — MDR pushed most health software up from I |
| India | CDSCO, Medical Device Rules 2017 | A / B / C / D |
The EU point is worth flagging: MDR reclassified a great deal of software upward, and a product that was self-certified Class I under the old directive frequently needs a notified body now. Teams that assumed CE marking was a formality discovered otherwise.
India specifically
CDSCO regulates under the Medical Device Rules, 2017, with classes A–D and a licensing regime. India's device regulation has been maturing quickly and unevenly, and enforcement of software specifically has lagged the rules on paper.
The honest read for a builder: do not treat lighter enforcement as a lighter obligation. The regulatory direction is one-way, the rules already exist, and retrofitting a quality system onto a shipped product costs far more than building with it. It also interacts with ABDM certification, which is a different gate for a different purpose — passing M3 says nothing about whether your algorithm is a device.
What being a device actually costs
Not a form. A quality management system (ISO 13485), design controls, a documented risk process (ISO 14971), clinical evaluation, post-market surveillance, and vigilance reporting. It changes how you build, not just what you file.
And the AI-specific wrinkle nobody has fully solved: a model that learns after approval is a device that changes after approval. Regulators approve a thing; continuous learning makes the thing a moving target. Predetermined change control plans are the current answer, and they are a compromise, not a solution.
The practical advice
Ask the intended-use question on day one, not at launch. It is cheap to design a Class II pathway from the start and ruinous to discover you're in one after you've sold it. And write the claim down — because if you don't, marketing will write it for you, and the regulator will read theirs, not yours.