A SaMD category is not a software safety class

IMDRF crosses two axes, not one

The N12 framework sorts a SaMD's significance of information along three levels — informing clinical management, driving clinical management, or treating or diagnosing directly — and crosses that against the state of the healthcare situation the SaMD addresses: non-serious, serious, or critical. A SaMD whose output is used to treat or diagnose a critical condition sits at the framework's ceiling, Category IV; one whose output merely informs a clinical decision in a non-serious situation sits at the floor. The categorization scales toward the SaMD's clinical role and the patient its output actually reaches — not toward how the underlying code was structured or built.

62304 asks what one software item could do if it breaks

IEC 62304's own classification runs on a different question entirely: Clause 4.3 asks, for each software item inside a device, what harm a malfunction of that specific item could cause — none, non-serious injury, or death or serious injury — and sorts it into Class A, B, or C accordingly. That class scales Clause 5's development-process documentation for the item, not the clinical significance of the finished device as a whole. A single SaMD can contain software items at different classes; the device itself was never the unit IEC 62304 classifies.

Where the two can point in different directions

A dosing-decision-support SaMD used against a critical condition can land at IMDRF Category IV by the framework's own logic, even where a hazard analysis segregates the actual calculation into a software item the manufacturer classifies 62304 Class B, reasoning that a clinician reviews the output before acting on it. Whether that segregation argument actually holds is a risk-management question, not one either classification framework settles on its own. The gap runs the other way just as often: a software item a hazard analysis rates 62304 Class C, because the item itself could directly cause serious harm if it malfunctioned, can sit inside a SaMD whose overall IMDRF category lands lower, because the device's output as a whole only informs a clinician's decision rather than driving or replacing it. Neither classification imports the other's conclusion.

Different audiences, not competing versions of the same test

IEC 62304 is a recognized consensus standard for software lifecycle documentation, used inside a device's own quality file to size an internal record. IMDRF's SaMD categorization was written as an international reference framework rather than a binding submission requirement on its own — but regulators have built directly on it since: FDA's own SaMD clinical evaluation guidance draws on the category to calibrate how much clinical evidence a submission needs, a question 62304's harm-based class was never built to answer, and other markets' software-as-a-medical-device frameworks lean on the same categories to set their own review depth. A file built for one market that carries only the 62304 classification has sized its engineering record correctly and left the clinical-evidence question the IMDRF category answers unaddressed for any market that asks for it directly.

Where this meets the rest of the file

Both classifications eventually answer to the same underlying hazard analysis a risk management file has to carry hazard by hazard — neither one substitutes for running that analysis itself, and 62304's own risk-management clause doesn't scale down with a lower class any more than Clause 7 does for any device. A submission that names one classification and treats the risk question as closed has named a framework, not finished the analysis.

A software classification worksheet that runs the IMDRF category and the IEC 62304 class as two separate determinations, each tied back to its own hazard analysis, is previewed in the launch catalog. If your program scores either one differently, the shelf takes that correction directly.