Software as a Medical Device (SaMD) is the International Medical Device Regulators Forum's term, used by FDA, for "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." The category can reach clinical decision support tools, AI-driven diagnostic aids, treatment-planning algorithms and some monitoring software. A digital health company that describes itself as "just software" may still be selling a device.
The line moves, too. In January 2026 FDA revised its guidance on clinical decision support software and on general wellness products, widening what falls outside device oversight. A classification call made under the earlier guidance is worth rechecking.
What Counts as a Medical Device
Under 21 U.S.C. § 321(h)(1), a device includes "an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article" intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment or prevention of disease, that does not achieve its primary intended purposes through chemical action or by being metabolized. Software can meet that definition even though it never touches a patient. The definition excludes the software functions carved out by section 520(o) of the Federal Food, Drug, and Cosmetic Act.
The 21st Century Cures Act Exclusions
The 21st Century Cures Act (2016) added section 520(o), which excludes several software functions from the device definition, including software intended for maintaining or encouraging a healthy lifestyle and unrelated to disease, and certain clinical decision support (CDS) software. For CDS, the exclusion applies only when the software:
- Is not intended to acquire, process or analyze a medical image, a signal from an in vitro diagnostic device, or a pattern or signal from a signal acquisition system
- Is intended to display, analyze or print medical information about a patient or other medical information, such as peer-reviewed clinical studies and clinical practice guidelines
- Is intended to support or provide recommendations to a health care professional about prevention, diagnosis or treatment of a disease or condition
- Is intended to enable the health care professional to independently review the basis for the recommendations, so that the professional does not rely primarily on any of them
AI-driven tools can have trouble with the fourth criterion when the basis for an output isn't available for the clinician to review. FDA's January 2026 CDS guidance, which replaced the September 2022 version, sets out how FDA applies these criteria.
Patterns Worth Checking
Situations where software can cross into device territory include:
- A wellness app whose claims drift into diagnosing or treating a disease
- An analytics platform that gives treatment-specific recommendations
- A decision support tool whose outputs the clinician can't independently review
- A monitoring platform that estimates clinical measurements or triggers clinical alerts from proprietary algorithms
- A tool that recommends medication dose adjustments
A Public Example
On July 14, 2025, FDA sent WHOOP, Inc. a warning letter stating that its Blood Pressure Insights feature was a device marketed without clearance or approval. After WHOOP modified the feature and its labeling, and consistent with FDA's January 2026 general wellness guidance, FDA closed the matter in June 2026, saying it did not intend to enforce device requirements on the modified version. The case shows both sides: claims and design can make software a device, and changes to the product, its labeling or FDA policy can resolve the question.
Remediation Pathways
For a product that is a device but hasn't been authorized, the options typically include changing claims and design so the product falls within an exclusion or FDA's enforcement policy; seeking marketing authorization through the pathway that fits (a 510(k) if a suitable predicate exists, otherwise a De Novo request or PMA); or removing the features that make it a device. Each has different revenue and timeline effects, so it is worth checking whether the company has a plan and budget for the option it chose.
Diligence Questions
Does the product make claims related to diagnosis, treatment or prevention of disease? Can clinicians independently review the basis for its recommendations? Has the company assessed its classification against FDA's January 2026 CDS and general wellness guidance? Where device status is plausible, has it categorized risk using the IMDRF SaMD framework, or engaged FDA through a Pre-Submission? What happens to revenue if FDA disagrees with its characterization?
Device status is easier to settle before FDA raises it or a transaction depends on it. A diligence read should examine the classification directly rather than accept the company's regulatory characterization at face value.
References
- FDA. "Software as a Medical Device (SaMD)." fda.gov
- 21 U.S.C. § 321(h), definition of device. Legal Information Institute. law.cornell.edu
- 21st Century Cures Act, Section 3060. Public Law 114-255, December 2016. congress.gov
- FDA. "Clinical Decision Support Software." Final guidance, January 2026. fda.gov
- FDA. "General Wellness: Policy for Low Risk Devices." Final guidance, January 2026. fda.gov
- FDA. Warning letter to WHOOP, Inc., July 14, 2025. fda.gov
- MedTech Dive. "FDA drops Whoop warning letter over blood pressure feature." June 24, 2026. medtechdive.com
- IMDRF. "Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations." IMDRF/SaMD WG/N12FINAL:2014, September 18, 2014. imdrf.org