Software as a Medical Device (SaMD) is a regulatory category, not a marketing term. Getting the classification right determines whether a piece of software needs FDA clearance or approval before use, what quality system governs how it’s built, and — for anyone working in a university or hospital research setting — whether a research tool has quietly crossed the line into being a regulated medical device. This guide covers the international definition, the risk-classification frameworks used in the US and EU, the AI/ML-specific issues that are reshaping this space, and what the boundary means in practice for academic researchers and technology transfer offices.
What Is Software as a Medical Device (SaMD)?
The International Medical Device Regulators Forum (IMDRF) — the body that coordinates device regulators from the US, EU, Japan, Canada, Australia, Brazil, China, Russia, Singapore, South Korea, and the UK — defines SaMD as software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device (IMDRF/SaMD WG/N10FINAL:2013). Three things follow from that definition:
- The software’s purpose has to be medical — diagnosis, prevention, monitoring, treatment, or alleviation of a disease, injury, or disability — not merely adjacent to healthcare.
- SaMD is a medical device in its own right. It doesn’t derive its regulatory status from being bundled with hardware; a mobile app that analyzes a photograph of a skin lesion to flag likely malignancy is SaMD even though it runs on a general-purpose smartphone.
- SaMD is distinct from Software in a Medical Device (SiMD) — firmware or embedded control software that is physically or functionally part of a hardware device (the software controlling an infusion pump’s dosing, for example). SiMD is regulated as part of the hardware device, not as a standalone product.
SaMD is also distinct from software used in the manufacturing or quality management of a device — a document control system, a CAPA tracker, or a batch-record system used by a device manufacturer under ISO 13485 is not itself a medical device, because its purpose is internal quality management rather than a medical purpose applied to a patient. The same logic separates general health, wellness, and administrative software (scheduling, general fitness tracking, health record storage without a diagnostic or therapeutic function) from SaMD — those tools fall outside FDA’s device definition entirely, or are addressed through separate general-wellness policy rather than the SaMD framework.
The IMDRF Risk Categorization Framework
In 2014, IMDRF published Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations (IMDRF/SaMD WG/N12FINAL:2014), which most national regulators — including FDA — reference as the international baseline for thinking about SaMD risk. The framework does not assign a device class directly; instead it categorizes SaMD along two independent dimensions and combines them into four risk categories, I through IV, with IV being the highest risk.
Dimension 1 — the significance of the information the SaMD provides to the healthcare decision:
- Treat or diagnose — the SaMD’s output is used to take immediate or near-term clinical action; the information itself drives the action.
- Drive clinical management — the output is the primary basis for a clinical management decision, used alongside other information.
- Inform clinical management — the output is one factor among several; it is not the primary basis for the decision.
Dimension 2 — the state of the healthcare situation or condition the software addresses: critical, serious, or non-serious.
Combining the two dimensions produces the category matrix:
| State of healthcare situation | Treat or diagnose | Drive clinical management | Inform clinical management |
|---|---|---|---|
| Critical | IV | III | II |
| Serious | III | II | I |
| Non-serious | II | I | I |
This is a conceptual risk framework, not a jurisdiction’s binding classification rule — FDA and the EU each translate SaMD risk into their own statutory device classes (below) using their own criteria, informed by but not identical to the IMDRF categories.
US Regulatory Position: Classification and Pathways
In the United States, SaMD is regulated the same way any other medical device is: FDA assigns it to Class I, II, or III based on the level of control needed to provide reasonable assurance of safety and effectiveness, and that class determines the premarket pathway. Most SaMD reaches market through one of three routes, covered in more depth in our guide to FDA medical device classification, 510(k), and PMA pathways:
- 510(k) premarket notification — for Class II devices that can demonstrate substantial equivalence to an already-legally-marketed predicate device. This is the most common pathway for incremental SaMD, including many AI/ML-based diagnostic-support tools.
- De Novo classification — for novel, low-to-moderate-risk devices that have no valid predicate to compare against; a successful De Novo request creates a new predicate that later 510(k) submissions can then cite.
- Premarket Approval (PMA) — the most rigorous pathway, required for Class III devices, generally those supporting or sustaining life, of substantial importance in preventing impairment of health, or presenting a potential unreasonable risk.
The 21st Century Cures Act Clinical Decision Support Exclusion
This is where most of the confusion in SaMD actually lives. The 21st Century Cures Act (Public Law 114-255, 2016) amended the FD&C Act’s device definition (Section 520(o)(1)(E)) to exclude certain clinical decision support (CDS) software from being a “device” at all — meaning it falls outside FDA’s premarket review requirements entirely, provided it meets all four statutory criteria:
- The software is not intended to acquire, process, or analyze a medical image, a signal from an in vitro diagnostic device, or a pattern/signal from a signal acquisition system.
- The software is intended for displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines).
- The software is intended to support or provide recommendations to a healthcare professional about prevention, diagnosis, or treatment of a disease or condition.
- The software is intended to enable the healthcare professional to independently review the basis for the recommendations, so that the professional does not rely primarily on the software’s output rather than their own clinical judgment.
FDA finalized guidance interpreting this exclusion (most recently updated guidance issued in 2022, with a further update in early 2026) — and the fourth criterion, “independent review of the basis,” has been the most contested in practice: software whose logic isn’t transparent enough for a clinician to meaningfully evaluate it generally fails the exclusion and reverts to being a regulated device. Software that analyzes a medical image or signal (criterion 1) is automatically excluded from the exemption regardless of the other three criteria — which is precisely why most AI/ML-based imaging and signal-analysis tools cannot use this pathway and require 510(k), De Novo, or PMA clearance instead.
EU Regulatory Position: MDR Annex VIII, Rule 11
Under the EU Medical Device Regulation (2017/745), standalone software is classified using Annex VIII, Rule 11 — a rule introduced specifically for software that did not exist in the same form under the prior Medical Devices Directive, and which is widely credited (and criticized) for pushing a large share of software into higher risk classes than it would previously have occupied:
- Software intended to provide information used to take decisions with diagnostic or therapeutic purposes is Class IIa by default, escalating to Class III if those decisions could cause death or irreversible deterioration of health, or Class IIb if they could cause serious deterioration of health or require surgical intervention.
- Software intended to monitor physiological processes is Class IIa by default, escalating to Class IIb if it monitors vital physiological parameters where variation could pose immediate danger to the patient.
- All other software is Class I.
Because most clinically meaningful SaMD is intended to inform diagnosis or treatment in some way, Rule 11’s default position of Class IIa (rather than the Class I default many products held under the old directive) is the single biggest driver of increased EU regulatory burden for software developers since MDR took full effect. It also means a Notified Body — not a self-certification — is required for the great majority of SaMD placed on the EU market.
AI and Machine Learning: What’s Different
AI/ML-based SaMD raises issues the classification frameworks above weren’t originally built to handle, because the central premise of those frameworks — that a device’s behavior is fixed at the point of clearance — doesn’t automatically hold for a model that keeps learning.
- Locked vs. adaptive algorithms. A “locked” algorithm produces the same output every time it receives the same input; its performance doesn’t change once deployed. An “adaptive” (continuously learning) algorithm can change its behavior in response to new data after deployment. Locked algorithms fit the traditional premarket-review model reasonably well; adaptive ones don’t, because a change to the algorithm is, in effect, a change to the device.
- The Predetermined Change Control Plan (PCCP). FDA’s approach for handling planned, anticipated modifications to an AI/ML-based device without requiring a new marketing submission for each change: a sponsor pre-specifies, at the time of the original submission, the types of modifications it anticipates making (e.g., retraining on new data within defined performance bounds), the methodology it will use to implement and validate those changes, and the impact assessment it will conduct. If a change falls within the pre-authorized plan, it can be made without a new 510(k) or PMA supplement; changes outside the plan still require one.
- Good Machine Learning Practice (GMLP). A set of AI/ML-specific development principles — jointly articulated by FDA, Health Canada, and the UK’s MHRA — covering areas like multidisciplinary expertise throughout the product lifecycle, representative and well-characterized training/tuning/test data, appropriate separation between training and test datasets, and performance evaluation that reflects clinically relevant, real-world conditions rather than only benchmark datasets.
- Algorithmic bias and training-data representativeness. A model trained predominantly on one demographic, one imaging device vendor, or one clinical site’s patient population can perform materially worse on populations underrepresented in that training data — a patient-safety issue as much as a fairness issue. Regulators increasingly expect sponsors to characterize and disclose the composition of training/validation data and to evaluate performance across relevant subgroups, not just in aggregate.
- Post-market performance monitoring and drift. Because a deployed model’s real-world input distribution can diverge from its training distribution over time (a new imaging protocol, a shifted patient mix, a change in an upstream lab assay), SaMD quality systems increasingly need ongoing, structured post-market surveillance of model performance, not just the one-time validation that satisfied premarket review, to catch degradation before it affects patient care.
See our related guide on FDA’s AI guidance for drug development and medical devices for a fuller treatment of how these principles are being formalized into agency policy.
Quality Systems and Standards Governing SaMD
Regardless of classification or jurisdiction, SaMD is expected to be developed and maintained under a recognized set of quality and engineering standards:
- ISO 13485 — the quality management system standard specific to medical devices, covering design controls, document control, CAPA, and management responsibility. In the US, FDA’s Quality Management System Regulation (QMSR), effective February 2, 2026, incorporates ISO 13485:2016 by reference, largely replacing the legacy 21 CFR Part 820 framework for device manufacturers, including SaMD developers.
- IEC 62304 — “Medical device software — Software life cycle processes,” the standard governing how SaMD (and SiMD) should be planned, developed, verified, maintained, and eventually retired, including software safety classification (A, B, or C) based on the severity of harm the software could contribute to.
- ISO 14971 — the medical device risk management standard, applied to software through the systematic identification of hazards, estimation and evaluation of risk, and risk control measures, carried through the entire product lifecycle rather than treated as a one-time premarket exercise.
- Cybersecurity. Because SaMD is inherently networked, connected, or data-exchanging software, FDA now expects premarket cybersecurity documentation (software bill of materials, threat modeling, vulnerability management plans) as a standard part of a device submission, and expects sponsors to maintain a postmarket vulnerability-monitoring and patching capability for the life of the product — cybersecurity is treated as a safety issue, not a separate IT concern.
What This Means for Academic Researchers and Tech Transfer Offices
A research tool built in a university lab can cross into SaMD territory well before anyone intends it to — and the earlier that boundary is recognized, the fewer downstream problems it causes.
- Research use vs. clinical deployment. A prediction model, image-analysis algorithm, or clinical scoring tool developed and used purely for a research study — where its output does not inform an actual clinical decision about the specific patient being studied — generally sits outside SaMD regulation while it stays in that lane. The moment a research tool’s output is intended to inform real clinical care (even in a pilot or “advisory” capacity within a health system), the SaMD analysis above starts to apply, and the investigational-device framework becomes relevant.
- Investigational Device Exemptions (IDE) and non-significant-risk (NSR) determinations. If a study is designed to evaluate whether a not-yet-cleared SaMD is safe and effective, and the device is determined to pose “significant risk,” an IDE application to FDA is generally required before the study can proceed. Many software-based studies are instead determined to be non-significant-risk by the reviewing IRB, which allows the study to proceed under abbreviated IDE requirements — but that NSR determination has to be made deliberately and documented, not assumed by default. See our entry on the broader concept of an investigational device for how that risk determination is made.
- IRB considerations. Beyond the standard human-subjects review, an IRB evaluating a SaMD-adjacent study needs to understand what the software actually does with patient data, whether its output influences clinical management during the study, and whether the significant-risk/non-significant-risk determination has been made and documented — this is a substantively different review than a purely observational or behavioral study.
- Data integrity and electronic records. Where a SaMD-adjacent research system captures, transmits, or stores data intended to support a future regulatory submission, 21 CFR Part 11 electronic records/signatures requirements and general data-integrity expectations start to matter well before the software formally becomes a marketed device.
- Postmarket reporting obligations. Once a SaMD product is cleared or approved and on the market, adverse events and malfunctions are subject to medical device reporting (MDR) obligations — a downstream compliance obligation that licensees and spinouts need to be resourced for, not just the university that did the original research.
- What a tech transfer office needs to evaluate before licensing clinical software. Licensing a research-developed algorithm or clinical software tool to a company (or spinning it out) raises questions that don’t arise with most other university IP: what SaMD classification the underlying technology is likely to receive, what quality-system and clinical-validation work already exists (and what’s still needed) to support a future submission, whether any training data used has the provenance and rights necessary for a regulatory filing, and whether the licensee has (or is committing to build) the regulatory and quality infrastructure — ISO 13485 certification, a design history file, a risk management file under ISO 14971 — to actually bring the product to market. These are diligence questions worth raising early, not after a term sheet is signed.
Frequently Asked Questions
Is an app that reminds patients to take medication SaMD?
Generally no, on its own — a medication reminder with no diagnostic, therapeutic, or clinical-decision function is a general wellness or adherence tool, not SaMD. It can become SaMD-adjacent if it starts making dosing recommendations or analyzing patient-reported data to flag a clinical concern.
Does a locked AI algorithm still count as SaMD?
Yes — classification as SaMD depends on the software’s intended medical purpose, not on whether its underlying algorithm is locked or adaptive. Locked vs. adaptive affects how the product is reviewed and how changes to it are handled post-market, not whether it’s SaMD in the first place.
What’s the difference between SaMD and a Software Precertification program?
FDA’s earlier “Software Precertification” pilot explored certifying an organization’s software development and quality culture rather than reviewing each product individually; it was a pilot program, not a general SaMD pathway, and organizations should confirm current FDA policy before assuming precertification is available as an alternative to standard premarket review.
Can a university publish and share a SaMD-adjacent research algorithm without regulatory clearance?
Publishing methods, code, or model weights for research purposes is generally not, by itself, “placing a device on the market” in the regulatory sense. Regulatory obligations attach when the software is intended for actual clinical use on real patients outside a research protocol — the distinction is intended use, not the act of publication.
This guide provides a general orientation to SaMD regulatory concepts and is not legal or regulatory advice. Classification is fact-specific and depends on a product’s actual intended use; consult qualified regulatory affairs counsel before making a classification determination for a specific product.
