Software as a Medical Device (SaMD): Definition, Classification, and Regulatory Pathways

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 Prior Question: Is It a Device at All?

Almost every SaMD conversation starts in the wrong place — with “which pathway do we need?” or “what IMDRF category are we?” Neither question has an answer until a prior one is settled: does this software function meet the definition of a device in section 201(h) of the FD&C Act at all? A large share of clinical software does not, and the software that does not is outside FDA’s device authority entirely — no classification, no submission, no Quality Management System Regulation obligation, no medical device reporting.

The order of operations is fixed, and getting it out of order is the single most expensive mistake in this area:

1. Device or not. Apply section 201(h) and the software exclusions in section 520(o)(1) of the FD&C Act, added by section 3060(a) of the 21st Century Cures Act (Public Law 114-255, enacted 13 December 2016). This is a statutory test, decided function by function.
2. If not a device — is an enforcement policy still relevant? General wellness and hardware MDDS sit here. These are compliance policies, not exclusions, and the distinction matters (below).
3. If a device — what class, under which classification regulation? Class I, II or III, and the corresponding pathway: 510(k), De Novo or PMA. See FDA device classification and the 510(k)/PMA pathways and the 510(k) vs PMA comparison.
4. Only then — how do we build and maintain it? IEC 62304 for the software lifecycle, ISO 14971 for risk management, ISO 13485 and 21 CFR Part 820 / QMSR for the quality system.

The IMDRF risk categories described in the next section are a fifth, orthogonal thing. They belong to none of these steps as a matter of law — see the note at the end of that section.

The section 520(o)(1) software carve-outs, in one place

Section 3060(a) of the Cures Act inserted section 520(o) into the FD&C Act, removing five categories of software function from the device definition. Two of them do most of the work in practice and are treated in detail below; the others are worth knowing so you do not spend review cycles on software that was never in scope:

• 520(o)(1)(A) — administrative support of a health care facility (billing, claims, scheduling, practice and inventory management, and similar functions).
• 520(o)(1)(B) — maintaining or encouraging a healthy lifestyle, unrelated to the diagnosis, cure, mitigation, prevention or treatment of a disease or condition. This is the statutory hook the general wellness policy sits alongside.
• 520(o)(1)(C) — electronic patient records created, transferred or maintained by or on behalf of a health care professional, where the records are the equivalent of a paper medical record and the function is not intended to interpret or analyse patient records.
• 520(o)(1)(D) — medical device data systems: transferring, storing, converting formats or displaying device data and results. Discussed below.
• 520(o)(1)(E) — certain clinical decision support. Discussed below, and the one that catches the most products.

Three statutory backstops override all of these. A software function is not excluded if it meets the criteria in section 513(a)(1)(C) (the Class III criteria), if it is used in the manufacture and transfusion of blood and blood components to assist in preventing disease in humans (section 520(o)(4)(B) and (C)), or if the Secretary issues a final order — after notice and comment — finding that the function would be reasonably likely to have serious adverse health consequences (section 520(o)(3)).

Medical Device Data Systems: the Carve-Out Ends at “Interpret or Analyse”

MDDS is the carve-out most often described incorrectly, because the answer changed and a great deal of published material still reflects the pre-2016 position.

Under section 520(o)(1)(D), a software function that is solely intended to transfer, store, convert formats or display medical device data or medical imaging data is not a device — “unless the software function is intended to interpret or analyse clinical laboratory test or other device data, results, and findings.” FDA’s guidance Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices (final, September 2022) calls this a Non-Device-MDDS, and it is genuinely outside FDA’s device laws and regulations — not merely un-enforced.

The parallel Device-MDDS is the hardware performing the same four functions. This is why the classification regulation at 21 CFR 880.6310 now opens “a medical device data system (MDDS) is a hardware device” — it was amended to that wording by the final rule at 86 FR 20278 (19 April 2021) conforming the classification regulations to the Cures Act software provisions. Device-MDDS hardware remains Class I and exempt from premarket notification subject to the limitations in 21 CFR 880.9, and FDA states it does not intend to enforce the regulatory controls — registration and listing, premarket review, postmarket reporting, quality system — even where those limitations would otherwise apply.

Two practical consequences follow. First, citing 880.6310 as authority for a software product being “Class I, 510(k)-exempt” is now wrong: software MDDS is not classified at all, because it is not a device. Second, the exclusion is destroyed the moment the function interprets or analyses. A results viewer that displays a potassium value is Non-Device-MDDS; the same viewer that flags the value as critical, trends it against a reference range to produce a clinical characterisation, or computes a derived index from it is not.

General Wellness: an Enforcement Policy, Not an Exclusion

General wellness is routinely spoken of as though it were a device-definition exclusion. It is not. CDRH’s guidance General Wellness: Policy for Low Risk Devices — issued 6 January 2026, superseding the 27 September 2019 version — is a compliance policy: FDA states it does not intend to examine low-risk general wellness products to determine whether they are devices or, if they are, whether they comply with premarket review and postmarket requirements. That is enforcement discretion. It can be revisited, it is expressly non-binding, and it is a materially weaker position to build a regulatory strategy on than section 520(o)(1)(E), which removes the function from the device definition by statute.

The policy applies only where both factors are met: the product is intended for general wellness use only, and it presents a low risk to the safety of users and other persons.

Factor one — general wellness intended use has two categories. The first makes claims about sustaining or generally improving functions associated with a general state of health with no reference to a disease or condition, and is limited to weight management, physical fitness (including recreational use), relaxation or stress management, mental acuity, self-esteem, sleep management, and sexual function. The second relates a healthy lifestyle to reducing the risk or impact of a chronic disease or condition, but only where it is well understood and accepted that healthy lifestyle choices play an important role in outcomes for that disease or condition. If the product’s intended uses are not limited to these, the guidance does not apply at all.

Factor two — low risk is a screen, not a balancing exercise. A “yes” to any of three questions takes the product out of the policy: is it invasive (penetrates or pierces skin or mucous membranes)? Is it implanted? Does it involve an intervention or technology that may pose a safety risk if specific regulatory controls are not applied, such as lasers or radiation exposure? FDA adds that being Class I under section 513(a)(1) does not by itself make a product low risk for these purposes, and recommends also considering whether CDRH actively regulates products of that type.

The January 2026 revision added the provision most relevant to consumer wearables, and it is worth reading closely if you build one. FDA may treat products using non-invasive sensing (for example optical sensing) to estimate, infer or output physiological parameters — blood pressure, oxygen saturation, blood glucose, heart rate variability — as general wellness products where the outputs are intended solely for wellness uses, provided the product is non-invasive and not implanted; involves no intervention or technology posing a safety risk absent specific controls; is not intended for diagnosis, cure, mitigation, prevention or treatment; is not intended to substitute for an FDA-authorised, cleared or approved device; includes no claims, functionality or outputs that prompt or guide specific clinical action or medical management; and does not display values mimicking those used clinically unless validated to reflect them. Such products may show values, ranges, trends, baselines and longitudinal summaries, and may contextualise them against sleep, activity, stress or recovery.

The disqualifiers are stated just as explicitly. A product is not a general wellness product where its labelling, advertising, user interface or functionality includes references to specific diseases, clinical conditions or diagnostic thresholds; alerts, alarms or prompts recommending or requiring specific clinical action or medical management; treatment guidance intended to inform or direct medical management; claims of clinical equivalence, clinical accuracy, “medical grade” or “clinical grade”, or substitution for an authorised device; or intended-use statements explicitly targeting diagnosis, screening, monitoring or management of a disease. Nor does the policy cover products intended to measure, estimate or report physiological values for medical or clinical purposes — blood pressure monitors, fingerstick glucose meters and continuous glucose monitors, ECG recording and analysis devices, and anything whose outputs are intended to be used to make treatment decisions such as medication dosing. A notification telling the user that evaluation by a health care professional may be helpful when outputs fall outside wellness-appropriate ranges does not, by itself, remove a product from the policy.

The Cures Act Clinical Decision Support Carve-Out, and What the Current Guidance Actually Says

This is where most of the confusion in SaMD actually lives, and where the position has moved recently enough that guidance summaries written even a year ago are unreliable. Section 520(o)(1)(E) of the FD&C Act excludes a clinical decision support software function from the device definition only if it meets all four of the following:

1. not intended to acquire, process or analyse a medical image, a signal from an in vitro diagnostic device, or a pattern or signal from a signal acquisition system (section 520(o)(1)(E));
2. intended for the purpose of displaying, analysing or printing medical information about a patient or other medical information, such as peer-reviewed clinical studies and clinical practice guidelines (section 520(o)(1)(E)(i));
3. intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis or treatment of a disease or condition (section 520(o)(1)(E)(ii)); and
4. intended for the purpose of enabling that health care professional to independently review the basis for the recommendations the software presents, so that it is not the intent that the professional rely primarily on any of those recommendations to make a clinical diagnosis or treatment decision about an individual patient (section 520(o)(1)(E)(iii)).

Which guidance is current matters. FDA’s final guidance Clinical Decision Support Software (docket FDA-2017-D-6569) was issued on 29 January 2026 and supersedes the version issued on 6 January 2026, which in turn superseded the September 2022 final guidance. The 2022 guidance is the one that narrowed what much of industry had read section 3060 to permit, and it caught a great many products that had shipped on a broader reading. If your regulatory rationale was written against the 2022 text, it needs re-reading against the current one — parts of the position have moved again, and in one respect moved back.

Criteria 1 and 2 are a single question about inputs. Read together, criterion 1 describes the data inputs that make software a device and criterion 2 describes the inputs that Non-Device CDS uses. If a criterion 1 input is used, the function stays a device regardless of the other three criteria. FDA reads the terms broadly:

• Medical image covers images from medical imaging systems (CT, x-ray, ultrasound, MRI) and images acquired for a medical purpose such as pathology or dermatology — including images not originally acquired for a medical purpose but processed or analysed for one.
• Signal covers responses requiring an IVD (an electrochemical or photometric assay response processed into a clinical test result) or a signal acquisition system measuring a parameter within, attached to or external to the body for a medical purpose.
• Pattern means multiple, sequential or repeated measurements of a signal or from a signal acquisition system. Discrete, episodic or point-in-time physiological measurements — routine vital signs taken at a clinical encounter — generally do not by themselves constitute a pattern. Named examples of patterns: an ECG waveform and QRS complex; next-generation sequencing output including variant datasets and VCF files; and the repeated glucose measurements produced by a continuous glucose monitor.

Software that assesses or interprets the clinical implications of a signal, pattern or image does not meet criterion 1. That is why computer-aided detection and diagnosis, ECG arrhythmia analysis, NGS variant interpretation and assay-result generation all sit outside this carve-out and need 510(k), De Novo or PMA. One boundary case is worth noting in the other direction: a signal acquisition system whose measurement is not intended or marketed for a purpose in the device definition — retinal image analysis for building access, for instance — is not a device at all.

Criterion 3 is about whether the software supports the clinician or supplants them. FDA reads it as condition-, disease- or patient-specific recommendations intended to enhance, inform or influence a decision, but not to replace or direct the professional’s judgment. A function that provides a specific preventive, diagnostic or treatment output or directive fails criterion 3.

The January 2026 guidance then adds a qualification that was not available in the same form under the 2022 text, and it is the most consequential change for products that were caught by that guidance: where only one option is clinically appropriate and the function otherwise meets all of the section 520(o)(1)(E) criteria, FDA intends to exercise enforcement discretion — it does not intend to enforce FD&C Act requirements for such functions. The guidance works this through with paired examples, and the pairs are the useful part, because each pair differs by one fact:

• Cardiovascular risk prediction from weight, smoking status, blood pressure and a BNP result is covered — but the same function predicting a cardiovascular event in the next 24 hours is a device software function, and so is the same function fed genomic variant data with no established relevance to the recommendation.
• A recommended treatment plan for cognitive impairment, to be reviewed, revised and finalised by a clinician, is covered — but not if the function also analyses PET images.
• Recommending a specific FDA-approved antibiotic from symptoms, recent hospitalisations and prior antibiotic exposure is covered — but not if the function also analyses spectroscopy data to diagnose infection.
• Classifying chronic low back pain into a single care pathway is covered — but the same function for acute back pain due to trauma, where immediate intervention may be required, is not.
• Estimating 90-day and 1-year post-transplant mortality for planning is covered — but predicting intraoperative or in-hospital mortality from near-real-time physiological measurements to guide immediate escalation of care is not.

The pattern across all five is the same: time-criticality and signal-level inputs are what move a function across the line, not the presence of a single recommendation.

Criterion 4 is the one that decides most real cases. The statutory words are “independently review the basis” — not “explain”, not “show the inputs”. FDA recommends four things to satisfy it, and each is a documentation obligation as much as a design one:

• (a) State the purpose and intended use, including intended professional user and intended patient population. Critically: FDA does not consider a software function intended for a critical, time-sensitive task or decision to meet criterion 4 at all, because the clinician is unlikely to have time to review the basis. Time-criticality is not a factor to be weighed — for this criterion it is close to dispositive.
• (b) Identify the required input medical information, in plain language: how inputs should be obtained, their relevance, and data quality requirements.
• (c) Give a plain-language description of the underlying algorithm development and validation — the general approach relied on (meta-analysis, expert panel, statistical modelling, AI/ML techniques); a description of the data relied on, sufficient for a clinician to judge whether it represents their patient population (relevant sub-groups, disease conditions, collection sites, sex, ethnicity) and whether best practices such as independent development and validation datasets were followed; and the results of clinical studies validating the algorithm, including sub-populations with untested or highly variable performance.
• (d) Surface the knowns and unknowns in the output itself — relevant patient-specific information plus missing, corrupted or unexpected input values — so the clinician can apply judgment to the final decision.

FDA states that this applies regardless of the complexity of the software and regardless of whether it is proprietary, and that the information must be presented in a way that promotes usability and avoids information overload. Developers may need to run usability testing to show their implementation meets criterion 4. And beyond the four recommendations, FDA says it considers two further things when deciding whether a function permits independent review: the level of software automation, and the time-critical nature of the decision.

For a research group or a spinout, the operational reading is blunt. Trade secrecy over model logic and an inability to characterise training data are not neutral commercial choices here — they are the two most common reasons a product fails criterion 4 and finds itself a regulated device. That is a decision to take at design time, not at submission time.

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

An IMDRF category is not a US regulatory class, and this conflation is the most common error in SaMD writing. IMDRF Categories I to IV are the output of a conceptual risk framework produced by a voluntary forum of regulators. They are not a jurisdiction’s binding classification rule, they appear in no statute or regulation, and no US premarket submission turns on them. A device’s US classification comes from its classification regulation in 21 CFR Parts 862 to 892 and the class that regulation assigns, which in turn sets the pathway. FDA participates in IMDRF and the N12 framework’s thinking demonstrably informs how reviewers reason about software risk — FDA’s own clinical decision support guidance cites the N12 framework — but that is influence, not classification. There is no lookup table from IMDRF Category IV to Class III, and a submission or a risk file asserting one invites a question you cannot answer. The same caution applies in the EU, where classification comes from Annex VIII of the MDR, not from an IMDRF category.

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.

Where the Device-or-Not Question Sits in This Sequence

None of the three pathways above is reached until the software function is established to be a device in the first place. That determination — section 201(h) plus the section 520(o)(1) carve-outs, the clinical decision support criteria, medical device data systems and the general wellness policy — is set out in full under The Prior Question: Is It a Device at All? above, and it is the step that most often disposes of the question before any classification analysis is needed.

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.

Is my software a device? What is the shortest reliable test?

There is no one-line test, but there is a reliable order. Ask what the software takes in and what it puts out. If an input is a medical image, an IVD signal, or a pattern or signal from a signal acquisition system, and the purpose is medical, it is a device and the clinical decision support carve-out is unavailable. If the inputs are medical information and the output is a recommendation a clinician can independently review and is not intended to be relied on primarily, the carve-out is in play — subject to the criterion 3 and criterion 4 analysis. If the software only transfers, stores, converts or displays device data without interpreting or analysing it, it is Non-Device-MDDS. If it makes only general wellness claims and is low risk, FDA’s general wellness compliance policy may apply, though that is enforcement discretion rather than an exclusion.

Does an IMDRF Category IV mean the device is FDA Class III?

No. There is no mapping between the two, and treating IMDRF categories as though they were regulatory classes is a common and material error. IMDRF Categories I to IV come from a conceptual risk framework; FDA class comes from the applicable classification regulation and the statutory class it assigns. A product can sit high on the IMDRF matrix and reach market via 510(k), and the reverse is also possible. Use the IMDRF categories for what they are useful for — a shared vocabulary for describing risk across jurisdictions and a structure for a risk file — not as a substitute for identifying the classification regulation that actually applies.

Is general wellness the same kind of protection as the clinical decision support exclusion?

No, and the difference is worth understanding before relying on it. The clinical decision support criteria in section 520(o)(1)(E) are statutory: a function meeting all four is not a device. General wellness is a CDRH compliance policy stating that FDA does not intend to examine low-risk general wellness products — enforcement discretion, expressly non-binding, and revisable. Both can be correct answers, but only one of them removes the product from the device definition.

Our clinical decision support tool was compliant under the September 2022 guidance. Is it still?

Not necessarily, in either direction. The current final guidance was issued on 29 January 2026 and supersedes the 6 January 2026 version, which superseded the September 2022 final. Some positions have been elaborated and at least one has been relaxed: where only one option is clinically appropriate and the other criteria are met, FDA now states it intends to exercise enforcement discretion, which was not the position many read into the 2022 text. A rationale written against 2022 should be re-run against the current guidance rather than assumed to still hold.

Primary Sources

Every regulatory position on this page was checked against the source below on 26 August 2026. Where a source is a guidance document, note that FDA guidance is expressly non-binding and describes the Agency’s current thinking.

• Clinical Decision Support Software: Guidance for Industry and Food and Drug Administration Staff — final, issued 29 January 2026, superseding the version issued 6 January 2026; docket FDA-2017-D-6569.
• General Wellness: Policy for Low Risk Devices — final, issued 6 January 2026, superseding the version issued 27 September 2019.
• Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices — final, September 2022.
• 21 CFR 880.6310, medical device data system, as amended at 86 FR 20283 (19 April 2021) by the final rule at 86 FR 20278 conforming device classification regulations to the Cures Act software provisions.
• 21st Century Cures Act, Public Law 114-255, section 3060(a), enacted 13 December 2016, adding section 520(o) to the Federal Food, Drug, and Cosmetic Act.
• IMDRF/SaMD WG/N10FINAL:2013, Software as a Medical Device (SaMD): Key Definitions, and IMDRF/SaMD WG/N12FINAL:2014, Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations.

Related CASRAI Resources

• IEC 62304: software safety classes, lifecycle deliverables and SOUP — once the device question is answered yes, this is the standard that governs how the software is developed and maintained. It does not answer whether your software is a device; that is this page.
• ISO 14971: the risk management file and benefit-risk determination — where SaMD hazard analysis actually lives, including the recognition note that risk is treated probabilistically except for security.
• 21 CFR Part 820 and the QMSR transition — the US quality system regulation, and the 820.10(c) design-control trigger that bites specifically on software-automated devices.
• ISO 13485: medical device quality management systems — the standard the QMSR incorporates by reference.
• Field safety corrective action: FSCA, recall and field safety notice — where a safety-related software version rollback becomes a reportable field action.
• EUDAMED: module status and the SRN registration sequence — the EU registration layer a CE-marked SaMD product has to sit inside.
• Predetermined change control plans for adaptive AI and the IDE significant risk determination.

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.