Per IMDRF, Software as a Medical Device (SaMD) is software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device. SaMD can run on general-purpose computing platforms, such as phones, cloud services or PCs, and may connect to hardware devices without being part of them. Examples include image analysis software that detects disease and apps that calculate insulin doses. IMDRF's risk categorization framework uses the significance of the information (treat or diagnose, drive or inform management) and the state of the healthcare situation to group SaMD into four categories.

Why it matters

SaMD spans diagnostic apps, AI triage tools, and clinical decision support systems. IMDRF risk categorization (I to IV) considers the state of the healthcare situation (non-serious, serious, critical) and the significance of the information the SaMD provides (inform, drive, treat or diagnose). Regulators worldwide, including FDA, MHRA, and Health Canada, align to the IMDRF framework.

Common pitfalls

•Confusing SaMD with SiMD. If the software is embedded in or required to operate a hardware device, it is SiMD and regulated with the parent device.
•Assuming a wellness app is out of scope. Once the intended use includes diagnosis, treatment, cure, mitigation, or prevention, the software is likely SaMD.
•Skipping IEC 62304 lifecycle documentation because the product feels like a normal SaaS release cycle.
•Treating model updates as bug fixes. Retrained AI models often require a Predetermined Change Control Plan or a new submission.

Sources

IMDRF SaMD · IMDRF
FDA SaMD Resources · FDA
FDA - AI/ML-Enabled Medical Devices · FDA

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.