Back to Software Team Onboarding
    Software & AISoftware LifecycleSaMD /sam-dee/

    Software as a Medical Device

    Software intended for medical purposes that performs without being part of a hardware device.

    Reviewed by Christian Espinosa, Founder, Blue Goat CyberLast reviewed September 19, 2026

    Definition

    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.
    What the regulation says
    IMDRF’s September 2014 SaMD risk categorization framework (IMDRF/SaMD WG/N12FINAL:2014) is non-binding guidance, not legislation. It groups SaMD into four categories using the significance of its information and the seriousness of the healthcare situation. These categories do not automatically determine national legal classifications or submission requirements. In the United States, FDA assesses whether software meets the device definition in section 201(h) of the Federal Food, Drug, and Cosmetic Act. Section 520(o), added by the 21st Century Cures Act on December 13, 2016, excludes certain software functions, including some clinical decision support, when specified conditions are met. Regulated SaMD follows applicable device requirements; there is no single SaMD approval pathway. In the EU, Regulation (EU) 2017/745, adopted on April 5, 2017 and applicable from May 26, 2021, governs software qualifying as a medical device under Article 2(1). Annex VIII, Rule 11 generally places software informing diagnostic or therapeutic decisions in class IIa, with higher classes where potential consequences warrant them. Other provisions address physiological monitoring and remaining software. For MedTech developers, intended purpose and classification determine conformity assessment obligations; Annex I safety and performance requirements and Article 61 clinical evaluation requirements also apply.

    What this means in practice

    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.

    Examples

    • A mobile app that analyzes retinal images to screen for diabetic retinopathy without connecting to hardware.
    • A cloud service that triages CT scans and flags suspected large-vessel occlusion strokes for radiologist review.
    • AI software that estimates ejection fraction from standard echocardiograms.

    Use cases

    1 scenario
    1

    Mobile app analyzing skin lesions for melanoma risk

    Founder / RA

    The app meets the FDA SaMD definition. The team applies IMDRF risk categorization, follows IEC 62304 for software lifecycle, and uses GMLP principles for the underlying model. They submit a 510(k) with a cleared dermatology AI as predicate.

    OutcomeThe product launches as a regulated Class II SaMD with a clear update pathway via a Predetermined Change Control Plan.
    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.

    Frequently asked questions

    SaMD (Software as a Medical Device) performs a medical purpose without being part of a hardware device. SiMD (Software in a Medical Device) is embedded in or required to operate a hardware device, such as pump firmware or imaging system control software.

    Cross-references

    Governed by

    Often confused with

    Grouped by theme
    Cited by

    Where this term appears across MedTech Terms.

    Learning paths (3)
    Ecosystems (1)
    Comparisons (1)

    Latest in MedTech

    Sources

    3 sources

    Every citation below opens the original document. Each is graded against our source-tier hierarchy so you can see what rests on binding law versus commentary.

    Tier 2Regulator guidance and consensus· 3
    Link health: 3 verified· last checked 2026-06-20
    IMDRF·1FDA·2
    1. 1
      IMDRF SaMD
      Tier 2 Verified
      IMDRFimdrf.org
    2. 2
      FDA SaMD Resources
      Tier 2 Verified
      FDAfda.gov
    3. 3
      FDA - AI/ML-Enabled Medical Devices
      Tier 2 Verified
      FDAfda.gov

    Inline markers like [1] jump to the matching reference above.