SaMD vs SiMD vs Embedded Software: Classification, Documentation, and Regulatory Strategy
Complete guide to distinguishing SaMD, SiMD, and embedded software for medical devices — IMDRF definitions, IEC 62304 classification, FDA and EU MDR regulatory pathways, MDCG 2019-11 guidance, documentation requirements, and practical decision frameworks for medtech manufacturers.
Why Software Classification Matters More Than Ever
The distinction between Software as a Medical Device (SaMD), Software in a Medical Device (SiMD), and embedded software determines which regulatory pathway applies, what documentation you must produce, how your product is classified, and how changes are managed post-market. Getting this wrong delays submissions, triggers unnecessary requirements, or — worse — leads to enforcement action for marketing an unclassified device.
The stakes have risen. FDA's Quality Management System Regulation (QMSR) took effect February 2026, incorporating by reference ISO 13485 and reinforcing software lifecycle requirements. IEC 62304 is under revision (Edition 2) with publication anticipated in 2026–2027, expanding its scope to AI-driven health products. The EU MDR's Rule 11 in Annex VIII and MDCG 2019-11 (updated Rev.1 in June 2025) have made software classification a central compliance challenge for Notified Bodies.
This guide provides a practical framework for classifying your software, understanding the documentation requirements that follow, and building a regulatory strategy that accounts for the differences between SaMD, SiMD, and embedded software.
Definitions and Boundaries
SaMD — Software as a Medical Device
SaMD is software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device. The definition comes from the International Medical Device Regulators Forum (IMDRF) and has been adopted by FDA, EU regulators, and most major jurisdictions worldwide.
Key characteristics of SaMD:
- Runs on general-purpose computing platforms (smartphones, cloud servers, desktop computers)
- Has its own medical intended purpose, independent of any hardware device
- Is regulated as a medical device in its own right
- Can perform its medical function without being connected to a specific hardware device
Examples:
- A smartphone app that uses the camera to detect signs of skin cancer
- Cloud-based software that analyzes MRI images for tumor detection
- A clinical decision support tool that predicts sepsis risk from patient vital signs
- Software that calculates insulin dosage recommendations based on glucose monitor data
SiMD — Software in a Medical Device
SiMD is software that is embedded within or necessary for the operation of a physical medical device. The hardware device cannot achieve its medical purpose without the software, and the software does not perform a medical function independently.
Key characteristics of SiMD:
- Controls or enables the operation of a hardware medical device
- Cannot perform its medical function without the physical device
- Is regulated as part of the parent device, not as a separate product
- Typically requires hardware-specific validation and verification
Examples:
- Firmware controlling insulin delivery in an infusion pump
- Software managing closed-loop control in a pacemaker
- Control software for an MRI scanner or CT system
- Embedded code running a blood pressure monitor's measurement cycle
Embedded Software — The Broader Category
"Embedded software" is a broader engineering term that encompasses SiMD but also includes software that may not have a medical purpose itself. In the medical device context, embedded software is any software permanently resident in a hardware device. When that software is necessary for the device to achieve its medical purpose, it is SiMD. When it performs ancillary functions (power management, display rendering, communications), it is still embedded software but may not carry the same regulatory weight.
The regulatory distinction is clear: if the software contributes to the medical function of the device, it is subject to IEC 62304 requirements regardless of whether it is classified as SiMD or embedded software.
The Decision Framework: Which Category Applies?
The IMDRF Two-Question Test
Regulators typically apply two questions drawn from FDA and IMDRF guidance:
Question 1: Does the software meet the definition of a medical device?
- Does the manufacturer's intended purpose include diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease or injury?
- If yes, proceed to Question 2. If no, the software is not a regulated medical device (but may still fall under general consumer protection or data protection laws).
Question 2: Is the software necessary for a hardware medical device to achieve its intended medical purpose?
- If the hardware device cannot achieve its medical purpose without the software → SiMD
- If the software can perform its medical purpose on a general-purpose platform without dedicated hardware → SaMD
- If the software supports a hardware device but also provides independent medical functionality → Potentially both SaMD and SiMD components
The Gray Zone: Hybrid Products
Many modern medical devices do not fit cleanly into SaMD or SiMD. Consider these examples:
Infusion pump with companion app: The firmware controlling the pump motor is SiMD. A separate mobile app that displays infusion data and sends alerts to clinicians may be SaMD if it provides independent clinical functionality beyond displaying pump status.
Cloud-connected diagnostic imaging system: The software controlling the MRI hardware is SiMD. The cloud-based AI algorithm that analyzes the images and provides diagnostic suggestions is SaMD.
Wearable cardiac monitor with AI analysis: The firmware running the sensor and local processing is SiMD. The cloud algorithm that detects atrial fibrillation and generates clinical alerts is SaMD.
For hybrid products, the regulatory strategy must address each software component separately. IEC 62304 applies to all medical device software regardless of category, but the regulatory submission and classification may differ for each component.
Classification Under IEC 62304
Software Safety Classes
IEC 62304 establishes three software safety classes based on the potential for harm from software failure:
| Class | Potential Harm | Documentation Rigor | Typical Examples |
|---|---|---|---|
| A | No injury or only minor injury | Basic — lifecycle processes apply but reduced documentation | Clinic scheduling software, non-critical display software |
| B | Non-serious injury | Enhanced — detailed design documentation, structured verification | Drug library management, alarm systems (non-life-threatening) |
| C | Death or serious injury | Comprehensive — full validation, detailed architectural design, extensive change control | Closed-loop insulin delivery, pacemaker control, AI diagnostic algorithms for life-threatening conditions |
The safety class determines the depth of documentation required under IEC 62304:
- Class A: Software development plan, requirements, verification testing, release records
- Class B: All Class A requirements plus architectural design, integration testing, more detailed risk management
- Class C: All Class B requirements plus detailed design documentation, unit verification, robustness testing, comprehensive configuration management
IEC 62304 Edition 2 (Under Development)
The upcoming revision to IEC 62304 expands the standard's scope to explicitly cover:
- AI and machine learning-driven health software
- Health software products beyond traditional medical devices
- Cloud-deployed and continuously updated software
The most significant structural change is the replacement of the current three safety classes (A, B, C) with two Software Process Rigor Levels: Level I (low rigor, for software that cannot contribute to harm) and Level II (high rigor, for software that can contribute to harm). This aligns with IEC 81001-5-1's two-level scheme and simplifies classification decisions. Edition 2 also introduces a dedicated AI/ML development lifecycle (AIDL) for software incorporating adaptive algorithms. Publication is anticipated in 2026–2027 following comment resolution. Manufacturers should begin preparing for these changes, as compliance will be expected for new submissions shortly after publication.
Regulatory Pathway Differences
FDA Pathways
| Aspect | SaMD | SiMD |
|---|---|---|
| Submission pathway | 510(k), De Novo, or PMA as standalone product | Part of the parent device submission |
| Classification | Based on the software's own risk profile (Class I, II, or III) | Based on the parent device classification |
| Quality system | Full QMSR/ISO 13485 compliance required | Covered under parent device QMS |
| Cybersecurity | Premarket cybersecurity documentation required (SPDF, SBOM, threat modeling per FDA guidance) | Cybersecurity as part of parent device submission |
| Change control | Software changes may require new 510(k) or PMA supplement | Software changes evaluated as part of device change control |
| UDI | Requires its own UDI | UDI as part of parent device |
Under FDA's Policy for Device Software Functions and Mobile Medical Applications, some software is excluded from device regulation:
- Software that merely replicates a textbook or reference material
- Software used for administrative or billing purposes
- Software used for general patient education
- Electronic health record (EHR) systems that do not generate or analyze patient-specific data for clinical purposes
EU MDR Pathways
Under the EU MDR, software classification follows Rule 11 in Annex VIII, as interpreted by MDCG 2019-11 (updated 2025 Rev.1):
| EU MDR Classification | Criteria | Typical Examples |
|---|---|---|
| Class I | Software that does not provide information used to make decisions for clinical management, or information used for clinical management but not likely to cause serious harm | General wellness apps, basic patient education |
| Class IIa | Software that provides information used to make decisions for clinical management, but the decisions are not likely to cause death or serious deterioration | Non-critical clinical calculators, basic triage tools |
| Class IIb | Software that provides information used to make decisions for clinical management where the decisions could cause serious deterioration | Diagnostic support for non-life-threatening conditions, dose calculators |
| Class III | Software that provides information used to make decisions where the decisions could cause death or serious deterioration of health | AI diagnostic algorithms for cancer detection, closed-loop treatment decision systems |
Key EU requirements:
- MDCG 2019-11: Guidance on qualification and classification of software in the MDR context
- MDCG 2020-1: Clinical evaluation requirements for software
- IEC 62304: Software lifecycle processes (harmonized standard)
- IEC 82304-1: Applies specifically to standalone health software (SaMD), not to SiMD
- Cybersecurity: Must comply with IEC 81001-5-1 and the upcoming EU Cyber Resilience Act
Global Reference Points
| Jurisdiction | SaMD Framework | Key Standard |
|---|---|---|
| FDA (US) | IMDRF-based, risk classification per 510(k)/De Novo/PMA | IEC 62304, FDA cybersecurity guidance |
| EU MDR | Rule 11, MDCG 2019-11 | IEC 62304, IEC 82304-1, ISO 14971 |
| TGA (Australia) | SaMD framework aligned with IMDRF | IEC 62304, essential principles |
| PMDA (Japan) | SaMD classified under Pharmaceutical and Medical Device Act | IEC 62304, MHLW guidelines |
| Health Canada | Software as a medical device per Medical Device Regulations | IEC 62304, guidance on software |
Documentation Requirements Compared
SaMD Documentation Package
SaMD requires a standalone technical documentation package:
- Software development plan compliant with IEC 62304
- Software requirements specification (SRS) defining functional, performance, and interface requirements
- Software architectural design documentation showing module decomposition and interfaces
- Risk management file per ISO 14971, covering software-specific hazards
- Verification and validation reports including unit, integration, and system testing
- Configuration management records tracking software versions and change history
- Clinical evaluation report per MDCG 2020-1 demonstrating clinical benefit
- Cybersecurity documentation including SBOM, threat model, vulnerability management plan
- Usability engineering file per IEC 62366-1
- Post-market surveillance plan specific to the software
SiMD Documentation Package
SiMD documentation is integrated into the parent device's technical file:
- Software development plan as a section of the design history file (DHF) or technical file
- Software requirements specification tied to system-level requirements
- Software architectural design showing integration with hardware components
- Risk management file integrated into the device-level risk analysis (ISO 14971)
- System-level V&V reports that include software verification as part of overall device validation
- Hardware/software interface specifications
- SOUP (Software of Unknown Provenance) inventory and risk assessment per IEC 62304
- Change control records for both hardware and software changes
Embedded Software (Non-Medical Function)
Embedded software performing ancillary (non-medical) functions still requires documentation:
- Identification of which software modules contribute to the medical function vs. ancillary functions
- Risk assessment for each module
- IEC 62304 safety classification for each module
- Verification and validation proportionate to the safety class
Practical Regulatory Strategy
Step 1: Classify Your Software Early
Before writing code, determine whether your product is SaMD, SiMD, or a hybrid. Misclassification early in development forces expensive rework. Use the IMDRF two-question test and document your rationale.
Step 2: Map Applicable Standards
| Standard | SaMD | SiMD | Embedded Software |
|---|---|---|---|
| IEC 62304 | Yes | Yes | Yes (for medical function modules) |
| IEC 82304-1 | Yes (standalone health software) | No | No |
| ISO 14971 | Yes | Yes | Yes (proportionate) |
| IEC 62366-1 | Yes | Yes | Yes |
| ISO 13485 / 21 CFR Part 820 (QMSR) | Yes | Yes (part of parent device QMS) | Yes |
| IEC 60601-1 | No (unless deployed on medical electrical equipment) | Yes (for medical electrical equipment) | Yes (if in electrical equipment) |
| IEC 81001-5-1 (cybersecurity) | Yes | Yes | Yes (if connected) |
Step 3: Plan Your Submission Strategy
For SaMD:
- Prepare a standalone technical file or 510(k) submission
- Budget and timeline by IEC 62304 class and FDA pathway:
| Build Type | IEC 62304 Class | Pathway | Cost Range | Timeline |
|---|---|---|---|---|
| Class A SaMD MVP | A | 510(k) exempt | $150K–$350K | 7–10 months |
| Class B SaMD | B | 510(k) | $350K–$750K | 10–14 months |
| Class C SaMD | C | 510(k) / De Novo | $750K–$1.5M | 14–20 months |
| AI/ML SaMD with PCCP | B/C | De Novo | $900K–$2M+ | 15–24 months |
These ranges cover software development and submission preparation. Clinical validation ($150K–$500K+ for Class B/C), FDA user fees, and EU Notified Body fees are additional.
For SiMD:
- Include software documentation in the parent device submission
- Software V&V is part of system-level verification
- Budget $600K–$2M+ for Class B/C device firmware, with timelines of 18–30 months
For hybrid products:
- Submit SaMD and SiMD components separately or together depending on the regulatory pathway
- Consider whether the SaMD component requires its own clearance (separate 510(k)) or can be included in the parent device submission
Step 4: Build for Post-Market Change Control
Software changes post-market are the most common compliance failure. Under IEC 62304, all changes must be evaluated for their impact on:
- Software safety classification
- Risk management conclusions
- Existing verification and validation results
- Regulatory submission status (does the change require a new 510(k) or PMA supplement?)
For AI/ML-enabled SaMD, consider filing a Predetermined Change Control Plan (PCCP) with FDA to allow specified algorithm modifications without new premarket submissions.
Frequently Asked Questions
Can my product be both SaMD and SiMD? Yes. A connected medical device may have SiMD components (firmware controlling hardware) and SaMD components (cloud-based analysis software). Each component must be classified and documented separately.
Is SiMD a lower regulatory burden than SaMD? No. SiMD is neither easier nor lower burden. IEC 62304, ISO 14971, cybersecurity requirements, validation, and change control apply fully to SiMD. The difference is that SiMD is submitted as part of the parent device rather than as a separate product.
What about Software of Unknown Provenance (SOUP)? Both SaMD and SiMD may incorporate SOUP — third-party or open-source software components with insufficient documentation for their intended use. IEC 62304 requires all SOUP to be identified, version-controlled, risk-assessed, and monitored for known vulnerabilities. Open-source software is not prohibited; undocumented open-source software is.
Does AI/ML change the SaMD vs SiMD analysis? AI/ML algorithms can be either SaMD or SiMD depending on how they are deployed. An AI algorithm running in the cloud to analyze medical images is SaMD. An AI algorithm embedded in an insulin pump controller is SiMD. The deployment context, not the technology, determines the category.
What happens if I reclassify from SiMD to SaMD mid-development? Reclassification requires building a standalone technical documentation package, establishing an independent regulatory submission, and potentially submitting a separate 510(k) or CE marking application. This can add 6–12 months and significant cost. Classify correctly from the start.