Per IEC 62304 clause 4.3, software is assigned to Class A (no injury or damage to health is possible), Class B (non-serious injury is possible), or Class C (death or serious injury is possible) based on the hazardous situation to which the software system can contribute, assuming failure of any external risk controls. The class sets how much rigor IEC 62304 requires: Class A needs the fewest activities, while Class C adds detailed design, unit-level verification and more documentation. Hardware or other external risk controls can lower a class only if they are outside the software, so classification depends on the system architecture and the ISO 14971 risk analysis. FDA uses a separate concept, the documentation level (Basic or Enhanced), in its 2023 premarket software guidance.

Why it matters

Classification is done at the software system level after the hazard analysis, then propagated to items and units. Amendment 1:2015 allows decomposition so an item can be assigned a lower class than its parent system when there is segregation of concerns with justification. Class B and C add required activities (detailed design, integration testing, verification of software units, unit testing, documented software architecture). Regulators (FDA and Notified Bodies) frequently challenge under-classification, especially when external risk controls are software-based or unproven.

Common pitfalls

•Claiming Class A because 'a clinician always checks the output' without documenting that check as a validated external risk control in the risk file.
•Assigning a class to the whole system when segregation would allow a lower class for isolated items - and losing effort savings.
•Not re-classifying after a design change that removes an external risk control (change control gap).
•Confusing software safety class with IEC 60601-1 basic safety or with ISO 14971 risk levels - they are separate axes.

Sources

IEC 62304:2006/AMD1:2015 · ISO
FDA Content of Premarket Submissions for Device Software Functions (2023) · FDA
MDCG Software Guidance · MDCG

Open full page

Select term B to compare.

Why compare MedTech terms side by side?

MedTech terminology is full of pairs that look interchangeable but carry very different regulatory, clinical, and commercial consequences. Picking the wrong framework, pathway, or standard early in a project can add months to a submission, invalidate clinical evidence, or trigger an audit finding. Side-by-side comparison is the fastest way to surface those differences before they become costly mistakes.

Each comparison on this page pulls from the same vendor-neutral, sourced definitions used throughout the MedTech Terms glossary. You see the one-line summary, the formal definition, why it matters in practice, common pitfalls, and the primary sources (FDA guidance, EU MDR/IVDR articles, ISO/IEC standards, MDCG documents, IMDRF principles) that back each entry. That makes the comparison defensible in regulatory strategy memos, design reviews, and submission narratives.

Common comparison patterns

Regulatory pathway choice - 510(k) vs PMA, 510(k) vs De Novo, Abbreviated vs Special 510(k).
Quality systems - QSR vs ISO 13485, QMSR vs QSR.
Software classification - SaMD vs SiMD, Locked vs adaptive AI.
EU frameworks - MDR vs IVDR, CE Mark vs UKCA.
Cybersecurity artifacts - SPDX vs CycloneDX SBOM, CVE vs CVSS.
Post-market actions - Recall vs field action, Removal vs correction.

How to use this tool

Pick term A and term B from the dropdowns, or click a preset above. The URL updates with both slugs so you can bookmark or share the exact comparison with a colleague, a notified body reviewer, or your regulatory consultant. Click Open full page on either side for the complete entry, including FAQs, related terms, and the full citation list. If you are not sure which term to start with, browse the Categories view or the A-Z index.

MedTech Terms is a vendor-neutral community resource sponsored by Blue Goat Cyber. Definitions are written for educational use and are not legal or regulatory advice.