IEC 62304:2006 (with Amendment 1:2015) defines the lifecycle requirements for medical device software, including software development planning, requirements analysis, architectural design, implementation, integration, testing, release, and maintenance - scaled by software safety classification (Class A, B, C). IEC 62304 assumes the manufacturer has a QMS (such as ISO 13485) and a risk management process (ISO 14971) in place. Its key processes are software development, maintenance, risk management, configuration management and problem resolution. It is recognized by FDA and harmonised under the EU MDR. A second edition has been in development for several years to broaden its scope to health software and update the classification approach.

Why it matters

IEC 62304 is a recognized consensus standard by FDA and a harmonized standard under EU MDR. It is foundational for SaMD and software-containing devices. The standard scales its expectations by software safety class: Class A (no injury possible) requires the lightest process, Class B (non-serious injury) adds detailed design and integration testing, and Class C (death or serious injury) adds unit testing, more rigorous architecture, and stronger SOUP controls.

Common pitfalls

•Under-classifying software to avoid Class C obligations. Auditors and reviewers actively challenge classifications that do not align with the device's hazard analysis.
•Skipping SOUP (Software of Unknown Provenance) requirements for open-source libraries and third-party components.
•Treating IEC 62304 as an alternative to ISO 14971. It complements risk management; it does not replace it.
•Losing traceability between software requirements, architecture items, unit tests, and integration tests.

Sources

IEC 62304:2006/AMD1:2015 · ISO
FDA Recognized Consensus Standards · FDA
IEC Webstore - Medical Equipment · IEC

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.