SaMD risk classification, explained

The first axis is what the software’s output is used for: whether it treats or diagnoses directly, whether it drives clinical management — meaning a clinician would act on it without independently re-deriving the answer — or whether it merely informs clinical management, contributing one input among several a clinician weighs. The second axis is the state of the healthcare situation the software addresses: critical, serious, or non-serious. A glucose-dosing recommendation and a symptom-checker can both be "diagnostic" in a loose sense; they land in very different places once you ask what the clinician actually does with the output and how much room for error the situation allows.

Founders routinely conflate the two axes, usually by treating "this could affect a real medical decision" as the whole analysis and skipping the second question. A tool that informs a non-serious situation and a tool that drives a critical one can both be defensibly described as "clinical decision support," and the honest classification exercise is precisely the work of pulling those two cases apart before a reviewer does it for you.

The IMDRF category is reasoning, not a submission input — no regulator accepts "Category III" as a classification. What it gives you is a shared vocabulary that both EU MDR’s Rule 11 and FDA’s device classification approach draw on, even though neither maps to it one-for-one. Under EU MDR, software providing information used for diagnostic or therapeutic decisions is Class IIa by default, rising to IIb where a wrong decision could cause serious deterioration in health or require surgical intervention, and to III where it could cause death or irreversible deterioration. Software monitoring physiological processes follows a parallel rule, keyed to whether the monitored parameters are vital and how dangerous rapid variation would be.

Working the IMDRF axes through first, before opening the EU MDR or FDA rulebook, is what keeps the eventual classification honest. Reasoning "what does this output do, and how serious is the situation" in plain language, and only then translating that into Rule 11 or an FDA product code, catches the gap between what the product does and what its marketing claims it does — which is usually where the real classification risk lives.

The most expensive mistake is writing an intended purpose — including in marketing copy, which counts as evidence of it — that classifies the product upward by accident. A landing page claiming the product "detects" or "predicts" a condition can qualify software that the regulatory file quietly describes as a wellness tool, and the mismatch is exactly the kind of thing a notified body or a competitor’s counsel notices. The second most common mistake runs the other way: assuming that because a human clinician is technically "in the loop," the software only informs rather than drives the decision. If the workflow doesn’t give the clinician a realistic, independent basis to disagree with the output, "informs" is not the honest description, whatever the interface implies.

Classification is not a paperwork exercise that happens once, near the end. It sets the IEC 62304 software safety class, which sets the documentation and testing burden and, more consequentially, tells you where the safety-relevant boundary of the system actually is. Architecture decisions made without that boundary in view — what runs in the same process as the safety-relevant logic, what a hardware interlock or independent monitoring channel could legitimately take off the critical path — are exactly the decisions that are cheap to make correctly at the start and expensive to unwind once a codebase and a QMS have grown up around the wrong assumption.

Classifying a product honestly, before committing to an architecture or a first submission, is the substance of our SaMD regulatory strategy advisory. It is also the first conversation in most of the free mentoring sessions offered to founders earlier than that — before a classification decision has become load-bearing anywhere yet.