SaMD Resource Hub

SaMD is software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. It runs on general-purpose computing platforms such as a phone, a laptop, or a server, and a qualifying mobile app counts as SaMD. Software whose purpose is to drive or control a hardware medical device is not SaMD. That kind of software lives inside a device and is known as software in a medical device, or SiMD. The definition originates with the International Medical Device Regulators Forum (IMDRF) and has been adopted by the FDA.

Sources: IMDRF/SaMD WG/N10FINAL:2013, "Software as a Medical Device (SaMD): Key Definitions"; FDA, "Software as a Medical Device (SaMD)," fda.gov/medical-devices/digital-health-center-excellence.

Yes. Under the IMDRF definition the FDA has adopted, SaMD is a medical device, including when it functions as an in-vitro diagnostic. In the U.S., the FDA classifies it by risk into Class I, II, or III, and the same device obligations apply, from a quality management system to design controls to risk management. Qualifying as software exempts a product from none of it.

Sources: FDA, "Software as a Medical Device (SaMD)," fda.gov; IMDRF/SaMD WG/N10FINAL:2013 (note: "SaMD is a medical device and includes IVD medical device").

Both are medical device software, but they sit in different places. SaMD performs its medical purpose on its own, without being part of a hardware device. SiMD is software that is part of a hardware device, or that drives or controls one. A single product can contain both. The distinction matters because it drives how the software is qualified, classified, and documented.

Sources: IMDRF/SaMD WG/N10FINAL:2013; Greenlight Guru, "SaMD vs SiMD: what's the difference and why does it matter?", greenlight.guru/blog/samd-vs-simd.

Three standards do most of the work, and they operate together. ISO 13485 sets the quality management system, ISO 14971 governs risk management across the product's life, and IEC 62304 defines the software development and maintenance lifecycle. They interlock in real work: software hazards identified under IEC 62304 feed the ISO 14971 risk file, and the lifecycle deliverables IEC 62304 requires double as the design inputs and outputs ISO 13485 expects.

Sources: Greenlight Guru, "Software as a Medical Device (SaMD): The Ultimate Guide," greenlight.guru/blog/samd-software-as-a-medical-device; ISO 13485:2016; ISO 14971:2019; IEC 62304:2006/AMD1:2015.

IEC 62304 sorts each software item into one of three safety classes by the worst harm a failure could cause. Class A covers software that cannot cause injury or damage to health. Where a failure could cause non-serious injury, the item is Class B. Class C applies when a failure could lead to serious injury or death, and it carries the heaviest documentation and verification burden. Two points trip teams up. The class is judged on potential harm before any external risk controls are credited, and it is separate from the FDA or EU MDR regulatory class, which is evaluated on its own. A second edition of IEC 62304 is in development, expected around 2026, and is proposed to collapse the three classes into two process-rigor levels.

Sources: IEC 62304:2006/AMD1:2015; Greenlight Guru, "IEC 62304 software safety classes," greenlight.guru/blog/iec-62304-software-safety-classes; Johner Institute, "Safety classes according to IEC 62304"; Jama Software, "What Is IEC 62304?"

Yes. A SaMD manufacturer needs a compliant quality management system, the same as any other device manufacturer. As of Feb. 2, 2026, the FDA's Quality Management System Regulation (QMSR) replaced the old Quality System Regulation and incorporates ISO 13485:2016 by reference into 21 CFR Part 820. For software teams, the upshot is straightforward. The QMS standard the FDA now points to is the same ISO 13485 already used across international markets.

Sources: FDA, QMSR / 21 CFR Part 820; 89 FR 7496 (QMSR Final Rule, effective Feb. 2, 2026).

A Predetermined Change Control Plan (PCCP) lets a manufacturer spell out specific future modifications to an AI-enabled device, along with the validation behind them, and get the FDA to authorize that plan up front as part of the original marketing submission. Approved changes within the plan can then ship without a new marketing submission each time. The mechanism exists because AI-enabled software is built to evolve, which does not fit the FDA's traditional model of a fresh submission for every significant change. The FDA finalized its guidance, "Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions," in December 2024.

Sources: FDA final guidance, "Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions" (December 2024); FDA Digital Health Center of Excellence.

Audit-readiness means an auditor can arrive, follow one continuous thread through current records, and never wait for the team to reconstruct anything. That thread runs through a documented quality system under ISO 13485, a living ISO 14971 risk file that reflects the software as it stands today, an IEC 62304 lifecycle whose planning, requirements, architecture, and verification records trace to one another, and a design history connecting inputs to outputs to validation. Teams that pass cleanly build those records as a byproduct of how they work, not as a project they start before an inspection.

Sources: ISO 13485:2016 (design and development file); IEC 62304:2006/AMD1:2015 (lifecycle deliverables); ISO 14971:2019 (risk management file); Greenlight Guru, "Software as a Medical Device (SaMD): The Ultimate Guide," greenlight.guru/blog/samd-software-as-a-medical-device.