On this page
Software as a medical device (SaMD) is software intended to be used for one or more medical purposes that perform those purposes without being part of a hardware medical device. It is regulated as a medical device by the FDA, Health Canada, the EU, and other authorities. The classification depends on the software's intended use and the claims made about it, not on the underlying code or technology.
- Software as a medical device performs a medical function independently, without being embedded in a hardware device; this distinguishes it from software that runs inside medical hardware.
- The primary test for SaMD classification is intended use: does the software intend to diagnose, treat, monitor, or prevent disease in humans?
- Marketing claims and labeling determine SaMD status, not the software's technical capabilities; the same code may or may not be a medical device depending on how it is presented.
- Risk-based regulatory frameworks sort SaMD into categories based on how critical the software's output is to patient care and the severity of the condition it addresses.
- General wellness software that tracks activity or provides lifestyle guidance without medical claims remains unregulated, even if similar code could qualify as SaMD if marketed differently.
A doctor uses software to analyze a patient's heart rhythm and flag irregular patterns. A fitness app tracks daily steps and reminds the user to move more. Both are software. Only one is a medical device.
The distinction matters because medical devices are regulated. Software as a medical device (SaMD) must meet safety and effectiveness standards set by health authorities before it reaches patients. Understanding what qualifies as SaMD is essential for healthcare professionals deciding which tools to trust, software developers building health applications, and compliance teams determining what regulatory pathway a product must follow.
The classification is not about how sophisticated the code is or what hardware it runs on. It hinges on a single question: does the software intend to perform a medical function independent of any hardware device? This explainer walks through the definition, the criteria that trigger it, the boundaries that separate SaMD from related categories, and the regulatory consequences that follow.
What software as a medical device actually is
Software as a medical device is software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device. The definition comes from the FDA and is echoed by the International Medical Device Regulators Forum (IMDRF), which defines SaMD identically.
The key phrase is "without being part of a hardware medical device." This means the software runs standalone, on a general-purpose device like a smartphone, tablet, or computer. It is not embedded in or tethered to specialized medical hardware. A piece of software that runs inside a ventilator or an infusion pump is not SaMD; it is software in a medical device, a different regulatory category. A piece of software that runs on your phone and diagnoses a skin condition is SaMD.
The second key element is medical purpose. The software must be intended to diagnose, treat, monitor, prevent, or manage a disease or condition in humans. Software that merely collects data about health without making a medical determination typically falls outside this definition, though the line between data collection and medical purpose can be subtle and context-dependent.
How software qualifies as a medical device
A piece of software qualifies as SaMD if it meets two tests. First, it must be intended for a medical purpose. Second, it must perform that purpose independently, without being embedded in hardware. The determination rests not on what the code can do in theory, but on what the developer intends it to do and how it is marketed and labeled.
Intended use and patient impact
The primary criterion is intended use: does the software intend to diagnose, treat, monitor, or prevent disease? This is the medical purpose test. A software application that analyzes a patient's symptoms and suggests possible diagnoses is intended to diagnose. Software that tracks blood glucose readings and recommends insulin dosages is intended to treat. Software that alerts a patient when their heart rate exceeds a threshold is intended to monitor.
Intended use is not the same as actual capability. A piece of software might technically be capable of performing a medical function, but if the developer does not intend it to do so and does not market it that way, it may not qualify as SaMD. Conversely, software that performs a medical function but is marketed only for research or educational purposes may still be classified as SaMD if the intent is there, because intent is what regulators examine.
The impact on the patient is also relevant. Software that provides information that directly influences a clinical decision carries higher regulatory weight than software that provides supporting information. Software that autonomously recommends a treatment is treated differently from software that presents data for a clinician to interpret.
Claims and marketing language
The claims made about software determine its classification as much as the underlying code does. The same algorithm could be marketed as a medical device in one context and as a general wellness tool in another, depending on the claims attached to it.
Suppose a developer builds software that analyzes facial images and predicts the likelihood of a genetic disorder. If the marketing materials say "Use this to screen for the disorder before you see a doctor," the software is making a medical claim and qualifies as SaMD. If the same software is marketed as "Explore how facial features vary in the population" with no medical claim attached, it does not qualify as SaMD, even though the underlying code is identical.
Regulatory bodies examine labeling, instructions, advertising, and any other materials that communicate the software's purpose to users. A medical claim need not be explicit. Implied claims count. If marketing materials suggest that the software can be used to make a medical decision, regulators treat it as a medical device claim regardless of disclaimers added later.
Software as a medical device versus software in a medical device
A critical boundary exists between SaMD and software that is embedded in or part of a hardware medical device. The distinction determines which regulatory framework applies and which approval pathway the product must follow.
SaMD is standalone software. It runs on a general-purpose computing platform like a smartphone, laptop, or cloud server. The software itself is the medical device. No specialized hardware is required for it to function.
Software in a medical device (sometimes called SiMD) is software embedded in or integral to a hardware device. A pacemaker contains software that controls the device's function. An ultrasound machine runs software that processes the images. A glucose meter uses software to calculate readings from sensor data. In each case, the software is part of the hardware device; you cannot use the software separately from the hardware.
This distinction matters for regulation. SaMD and SiMD follow different approval pathways in most jurisdictions. SaMD may be subject to less stringent requirements in some cases because it can be updated more easily than hardware-embedded software. SiMD is often regulated as part of the hardware device classification.
The boundary can blur in practice. Software that runs on a smartphone but requires connection to a hardware sensor might be considered part of a system. Software that runs on a general-purpose computer but is sold only as part of a medical hardware package might be treated as SiMD. Regulators examine the entire system to determine the appropriate classification.
Concrete examples of software that qualifies as SaMD
A diagnostic software application that analyzes medical images and flags regions of concern is SaMD. The software runs on a computer or mobile device and performs a diagnostic function. It does not require specialized hardware to operate.
A mobile app that monitors a patient's symptoms over time and alerts the user and their physician if patterns suggest a worsening condition is SaMD. It performs a monitoring function independent of hardware.
Software that calculates drug dosages based on patient characteristics, lab values, and drug interactions is SaMD. It performs a treatment-related function without being embedded in hardware.
A clinical decision support system that runs on a hospital computer and recommends treatment options based on patient data and clinical guidelines is SaMD. It performs a function that influences medical decisions.
An app that uses artificial intelligence to detect skin lesions and classify them by risk level is SaMD. It performs a diagnostic function on a general-purpose device.
All of these examples share the same characteristics: they run on general-purpose computing platforms, they are intended for medical purposes, and they perform those purposes independently without being part of hardware medical devices.
Software that does not qualify as a medical device
Not all health-related software is regulated as a medical device. Understanding what falls outside the SaMD category helps clarify the boundaries.
General wellness and fitness software
A fitness app that counts steps, tracks calories burned, and suggests daily activity targets is not SaMD. It does not intend to diagnose, treat, monitor, or prevent disease. It provides general lifestyle guidance without making medical claims.
A meditation app that helps users manage stress is not SaMD. Even though stress can affect health, the app does not make a medical claim about treating or preventing a disease.
A nutrition app that logs meals and provides general dietary recommendations is not SaMD. It offers lifestyle guidance rather than medical treatment or diagnosis.
The line between wellness and medical purpose is not always sharp. An app that tracks sleep patterns and offers general sleep hygiene tips is wellness software. An app that analyzes sleep data and diagnoses sleep disorders is SaMD. The difference is the medical claim and intended use.
Software that supports but does not perform medical functions
Software that helps clinicians organize patient data, schedule appointments, or manage records is not SaMD. It supports medical practice but does not perform a medical function itself. The clinician, not the software, makes the medical decision.
Software that displays test results or imaging studies to a healthcare provider is not SaMD by itself. It presents information that the clinician interprets. The software does not diagnose or treat.
The distinction is between software that informs a clinician and software that makes or recommends a medical decision. Software that presents data for human interpretation is a tool. Software that analyzes data and outputs a diagnosis or treatment recommendation is performing a medical function.
This boundary can shift depending on context. Software that simply displays results to a clinician is supportive. Software that displays results and flags abnormal values with interpretive guidance is moving toward a medical function. Software that displays results, flags abnormalities, and recommends a clinical action is performing a medical function and likely qualifies as SaMD.
How regulatory bodies classify SaMD
SaMD classification carries regulatory consequences. Different jurisdictions use similar frameworks to sort SaMD by risk and determine the approval pathway each product must follow. The FDA, Health Canada, the European Union, and other health authorities have all adopted risk-based approaches to SaMD regulation.
Risk determines regulatory pathway
Regulatory bodies sort SaMD into risk categories. Higher-risk software faces more stringent approval requirements. The IMDRF developed a framework that sorts software into four categories based on two factors: the significance of the information provided by the software and the state of the healthcare condition it addresses.
Software that provides informational support for non-serious conditions faces lower regulatory burden. Software that drives a clinical decision for a serious or critical condition faces higher burden. Software that diagnoses or treats critical conditions faces the highest burden.
This risk-based approach reflects the principle that regulatory intensity should match the potential for harm. Software that recommends a lifestyle change for a minor condition poses less risk than software that recommends a treatment for a life-threatening disease. Regulators calibrate their requirements accordingly.
The IMDRF framework has been adopted or adapted by multiple jurisdictions. The FDA uses a similar risk-based approach in its guidance on SaMD. Health Canada and the European Union have developed their own frameworks that follow the same underlying logic: higher risk requires more evidence and more rigorous review.
Why SaMD classification matters
Classification as SaMD triggers regulatory obligations. The software must be developed following quality and safety standards. It must undergo review and approval before it can be marketed. It may be subject to post-market surveillance to ensure it continues to perform safely and effectively.
For developers, SaMD classification means additional time and cost before launch. It means documentation requirements, testing protocols, and regulatory submissions. It means potential delays in bringing the product to market.
For healthcare providers and patients, SaMD classification means assurance. Software classified as a medical device has been reviewed by a regulatory authority. It has met safety and effectiveness standards. Its claims have been evaluated. This reduces the risk that the software will perform poorly or harm patients.
For compliance teams, SaMD classification determines which regulatory pathway the product must follow. Different jurisdictions have different requirements. Software that qualifies as SaMD in the United States must follow FDA requirements. Software sold in Europe must follow EU regulations. Understanding SaMD status is the first step in determining what regulatory approvals are needed.
The classification also affects how the software can be modified and updated. Some regulatory frameworks allow SaMD to be updated more easily than hardware-embedded software, because software changes can be deployed rapidly. Other frameworks impose restrictions on updates to ensure that changes do not compromise safety or effectiveness. The regulatory status of the software determines which rules apply.
Do this automatically
Determining whether software qualifies as a medical device requires evaluating its intended use and independent functionality against regulatory definitions, a classification process that organizations must repeat for each software product, across multiple jurisdictions, and update whenever claims or functionality change. This ongoing assessment of intended use, performance independence, and regulatory boundaries can be systematized and scaled through software automation. Healthcare research reads ClinicalTrials.gov records, regulatory filings, and published literature directly, and cites each claim to the record it came from, across as many subjects as you need, with Mimir attaching a citation to every figure. It will not predict a trial's outcome or advise on anyone's treatment. Those decisions stay with clinicians and regulators, and deliberately so. Every plan includes it, including the free one.
Start your first report and run it on something you already know well.
This article is general information about healthcare and life-sciences topics. It is not medical advice, diagnosis, or treatment guidance, and it is not a substitute for a qualified professional. Any treatment decision should be discussed with a clinician.
