SaMD Explained: When Does Your Health App Need FDA Clearance?

What Is Software as a Medical Device (SaMD)?

Software as a Medical Device is software that is itself intended for a medical purpose and performs that purpose independently of any hardware medical device. The FDA adopts the definition developed by the International Medical Device Regulators Forum (IMDRF): software "intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." A mobile app, a cloud-based analytics platform, a web application, and a hospital software system can all qualify as SaMD if they meet that intended-use threshold.

The term SaMD is distinct from two related categories the FDA also recognizes. Software in a Medical Device (SiMD) is software that is embedded in or integral to a hardware medical device -- the operating software inside an MRI machine, for example. Software used in the manufacture or maintenance of a medical device supports production or upkeep and is generally not itself regulated as a device. For health app founders, the relevant category is typically SaMD.

Four practical examples illustrate where the line typically falls, though intended use is always the determining factor:

• General wellness tracker (steps, calories, sleep duration) -- typically not SaMD, as no medical purpose is served beyond general health maintenance.
• General health information app providing educational content about conditions -- typically not SaMD when it makes no diagnostic or treatment claims about the individual user.
• Software that analyzes a patient's blood glucose data and alerts the user when readings suggest hypoglycemia -- the intended use shifts toward a medical purpose; whether it is regulated as SaMD depends on the specific functions, claims, and applicable FDA criteria.
• Software that processes medical images to identify potential tumors -- clearly intended to serve a diagnostic medical purpose and likely qualifies as SaMD, with regulatory classification determined by risk and available predicates.

The key point is that the delivery format -- a mobile app, a SaaS platform, an embedded widget inside an EHR -- does not determine regulatory status. Intended use and function do.

When Does a Health App Need FDA Clearance or Another FDA Pathway?

A health app needs FDA premarket review when it qualifies as a medical device under the Federal Food, Drug, and Cosmetic Act (FD&C Act) and no applicable exemption or enforcement-discretion policy applies. Whether an app qualifies as a medical device depends on its intended use -- what the manufacturer intends the software to accomplish, as reflected in its labeling, marketing, documentation, and actual software functions.

Five factors consistently appear in FDA's assessment of whether a health software product is a regulated device:

• Intended use: Is the software designed to diagnose, treat, prevent, or monitor a disease or medical condition? Claims in an app store listing, a product website, investor materials, or onboarding flows contribute to the intended-use determination -- not only the product's technical description.
• Medical claims: Does the product explicitly or implicitly claim to detect, screen for, diagnose, predict, or manage a specific disease or condition?
• Function and output: What does the software actually do? An app that simply records a user's inputs is different from one that analyzes physiological data and returns an interpretation.
• Role in clinical decisions: Is the output intended to inform a clinician's diagnosis or treatment decision? Software that drives or replaces professional clinical judgment is treated differently from software that provides general educational information.
• Risk: If the software fails or produces incorrect output, what is the potential patient harm? Higher-risk functions are more likely to be regulated and subject to more rigorous pathways.

To illustrate how these factors interact:

• A step-counting app with no medical claims generally falls outside FDA device regulation under the agency's general wellness policy.
• An app that estimates blood pressure using optical sensors and sends the user a notification framed as a health insight -- without naming a condition, using clinical thresholds, or advising clinical action -- may remain outside device regulation under FDA's January 2026 wellness guidance, depending on specific features and claims.
• An app that uses the same sensor data to flag potential hypertension and recommend consulting a physician is more likely to be treated as a medical device, because the output is diagnostic in character.
• Medical image analysis software that returns a specific finding -- identifying a lesion as potentially malignant -- is very likely regulated as a SaMD and would require premarket authorization.
• An app that calculates an insulin dose recommendation based on patient data is regulated as a device, carries significant risk, and would generally require a rigorous pathway.

FDA regulation is not binary. Some products require full premarket review; some are subject to enforcement discretion (where FDA has determined it will not actively enforce device requirements even if the product technically qualifies as a device); and some are clearly outside device regulation. A product's specific facts determine which applies.

How Can You Find the Right Healthcare Software Development Partner?

Buyers developing potentially regulated health software should evaluate development partners for direct experience with healthcare product builds, not just general technical capability. The right partner brings familiarity with regulated software development practices -- requirements traceability, design controls, risk management documentation, and verification and validation processes -- alongside security, EHR integration experience, and an understanding of how regulatory obligations affect architecture decisions from day one.

When evaluating vendors for a potentially regulated product, ask specifically about their experience with healthcare app development for regulated or near-regulated products, their documentation practices, and whether they can support quality management processes aligned with FDA expectations. A vendor's track record with HIPAA-compliant software and HIPAA-compliant development is a starting point, but FDA device development requires additional rigor that general health software experience may not cover.

How Are General Wellness Apps Different From Medical Device Software?

General wellness apps are different from medical device software because they are intended to maintain or encourage general health and well-being -- not to diagnose, treat, prevent, or manage a specific disease or condition. The FDA's General Wellness policy, updated in January 2026 and superseding the 2019 version, provides a framework for identifying when a low-risk product focused on wellness functions is not regulated as a device.

Under current guidance, the FDA generally does not regulate products that:

• Are intended only to maintain or encourage a healthy lifestyle.
• Do not diagnose, treat, prevent, cure, or manage a disease or medical condition.
• Pose low risk to users if they perform differently than intended.

Practical examples of software that typically stays in the wellness category include habit tracking for exercise or nutrition, general sleep coaching, stress-management guided sessions, and general fitness logging. Wearable fitness devices that estimate physiological parameters such as heart rate, sleep patterns, or activity levels for general wellness purposes -- without naming a condition, using clinical thresholds, or framing outputs as diagnostic -- may also remain outside device regulation under the 2026 guidance. The January 2026 update specifically clarified that certain optical-sensing features can qualify as wellness products, provided they avoid medical claims in labeling and behavior.

The distinction, however, is not purely about what the software does. It is equally about what the manufacturer says it does. A product that tracks the same physiological data but describes outputs as detecting atrial fibrillation, screening for pre-diabetes, or monitoring a chronic condition in its app store listing, marketing materials, or onboarding content has made medical claims that shift the regulatory analysis significantly. The FDA's assessment of intended use draws on all of a manufacturer's communications -- not only technical specifications.

Changing a disclaimer or removing a medical keyword does not automatically move a product into the wellness category if the product's actual functions, outputs, and commercial context suggest a medical purpose. A product marketed for weight loss with general coaching features is treated differently from an app that analyzes body composition data to diagnose metabolic conditions, even if both involve similar underlying software. The full intended use and the product's behavior matter.

What Is the Difference Between FDA Clearance, FDA Approval, and De Novo Authorization?

These three terms describe distinct FDA regulatory pathways, and they are not interchangeable. Using "FDA approval" as a generic term for all premarket submissions is a common error that can create confusion about a product's actual regulatory status. The appropriate pathway depends on the device's classification, its risk level, and whether a legally marketed predicate exists.

510(k) clearance is the most common pathway for medical software products that have established predicates. It evaluates whether the new device is substantially equivalent to a legally marketed device -- meaning the same intended use and either the same technological characteristics or different characteristics that do not raise new safety concerns. A device cleared through 510(k) has been found substantially equivalent, not independently proven safe and effective through clinical trials in the way a PMA-approved device must be.

De Novo authorization creates a new device classification. It is intended for novel devices with no appropriate predicate that nonetheless pose low-to-moderate risk controllable through general or special controls. When De Novo is granted, the device is classified as Class I or Class II, and the order can serve as a predicate for future 510(k) submissions from other manufacturers.

Premarket Approval (PMA) is the most rigorous pathway and is generally required for Class III devices -- those that support or sustain human life, are of substantial importance in preventing health impairment, or present a potential unreasonable risk of illness or injury. PMA requires valid scientific evidence, typically including clinical study data, demonstrating that the device is safe and effective for its intended use.

The right pathway for any specific SaMD product depends on how the device is classified, whether an appropriate predicate exists, and the applicable regulatory requirements. No single pathway applies universally to health apps or AI-enabled software. Pathway determination is a product-specific regulatory assessment, not a category decision.

How Does the FDA Evaluate AI-Powered Medical Software?

AI functionality does not automatically make a health app a medical device, and it does not automatically require FDA authorization. The regulatory analysis of an AI-powered health app begins the same way as any other software product: with its intended use, the medical purpose it serves, and whether it meets the definition of a device. What changes with AI is the set of additional considerations FDA examines when that threshold is crossed.

For AI-enabled software that does qualify as a medical device, FDA's evaluation focuses on:

• Intended medical use of the AI feature: What clinical question is the model designed to address? Screening, diagnosis, risk stratification, treatment recommendation, and monitoring carry different regulatory implications.
• Inputs and outputs: What data does the model receive, and what does it return? A model that receives a raw medical image and returns a specific finding ("likely malignant nodule at upper-right lobe") has a clearly diagnostic output. A model that surfaces general wellness insights from wearable data is assessed differently.
• Role in clinical decision-making: Does the output inform or replace professional clinical judgment? Clinical Decision Support (CDS) software that provides general reference information may qualify for enforcement discretion under FDA's 2026 CDS guidance. Software that drives specific clinical actions on individual patients is subject to closer scrutiny.
• Model performance and clinical validation: Has the AI been validated on data representative of the intended use population? FDA expects rigorous evidence of analytical and clinical performance, including sensitivity, specificity, and subgroup performance.
• Bias and generalizability: Does the model perform consistently across demographic groups, clinical settings, and patient populations? Bias in AI training data is a documented concern FDA addresses in its guidance on AI-enabled devices.
• Human oversight: Is a qualified clinician in the decision loop? Software that presents outputs to a health care professional who reviews and acts on them is treated differently from software that delivers outputs directly to patients as clinical guidance.

Predetermined Change Control Plans (PCCPs) are a significant development for AI-enabled medical software. FDA finalized PCCP guidance in December 2024. A PCCP allows a manufacturer to pre-specify the types of modifications -- such as model retraining, performance updates, or changes to device inputs -- that can be made after authorization without requiring a new premarket submission each time, provided the changes stay within the approved scope. PCCPs can be included with 510(k), De Novo, and PMA submissions. They require a description of planned modifications, a protocol for making them (covering data management, retraining, performance evaluation, and user communication), and an impact assessment addressing risks and mitigations.

Beyond FDA authorization, AI-enabled medical software carries additional obligations that are distinct from the device-clearance question: cybersecurity requirements under FDA's medical device cybersecurity guidance, ongoing post-market surveillance, software change control, and clinical performance monitoring. These obligations apply alongside -- not instead of -- privacy, HIPAA, and other applicable healthcare regulations. Understanding the relationship between HIPAA, HITRUST, and SOC 2 is relevant here, because security certifications and FDA device requirements address different questions and often coexist on the same product.

What Should Founders Do Before Building a Potentially Regulated Health App?

The most expensive regulatory mistake in health software development is discovering that a product requires FDA clearance after the architecture is already built, the feature set is locked, and the clinical evidence plan was never started. A regulatory assessment belongs at the beginning of product development -- before the sprint planning, not before the launch date.

A practical pre-development checklist for founders:

1. Define the intended users and the medical purpose clearly. Who will use the software, in what setting, and for what health-related purpose? Write this down before any feature discussion begins.
2. Document what the software will and will not do. A written product scope that includes both included and excluded functions protects the team from scope creep and informs the regulatory assessment.
3. Identify every claim in planned marketing, product materials, and onboarding. Medical claims made anywhere in the product experience -- not only in technical documentation -- contribute to the intended-use determination.
4. Map inputs, outputs, and how users act on outputs. If a clinician will use the output to make a specific decision about a specific patient, that is a different regulatory profile than output reviewed as background information.
5. Assess whether the functions may fall within FDA medical-device oversight. Review relevant FDA guidance documents for the applicable product category. Search the FDA's 510(k) and De Novo databases for comparable authorized products. This is not a substitute for qualified regulatory advice, but it gives the team baseline context.
6. Identify clinical evidence and validation needs early. If premarket authorization is likely required, evidence planning -- what studies are needed, in what populations, with what endpoints -- directly affects development timeline and budget. Understanding healthcare AI development costs in 2026 is harder without knowing the regulatory path.
7. Plan for cybersecurity, privacy, data governance, and quality processes from day one. These are not features added at the end of development; they require architectural decisions that are expensive to retrofit.
8. Determine which regulatory questions require qualified specialist advice before committing to architecture or launch plans. FDA's product classification, predicate identification, submission strategy, and evidence planning are areas where specialist guidance changes outcomes. General research and AI-generated summaries are not a substitute.
9. Budget for regulatory strategy, documentation, testing, and potential study costs. Reviewing healthcare software development cost benchmarks for 2026 helps founders set realistic expectations before committing to a product scope.

How Can FDA Requirements Affect Development Cost, Timeline, and Vendor Selection?

A potential medical-device classification changes the scope, structure, and cost profile of a health software project in ways that go far beyond adding a compliance checklist. The effects begin at requirements documentation and continue through every stage of the software development lifecycle -- and then beyond deployment into post-market surveillance and change control.

Key areas where FDA device requirements add development obligations:

• Requirements and traceability: Regulated software development typically requires a formal requirements specification and a traceability matrix showing that every requirement is tested and every test result is documented. This is not standard practice in general software development.
• Risk management: A risk management file documenting hazards, causes, risk controls, and residual risk is expected for regulated medical devices. ISO 14971 is the widely adopted standard for medical device risk management.
• Verification and validation (V&V): Testing must be documented in a way that can be presented to FDA reviewers. For AI-enabled products, validation includes both technical performance testing and, in many cases, clinical study evidence.
• Design history file: Regulated software development under FDA's quality system regulation (21 CFR Part 820) requires a design history file documenting the design and development process.
• Change control: Changes to regulated software after clearance may require a new premarket submission depending on their nature and risk implications. This directly affects how the product is maintained and updated over time.
• Cybersecurity: FDA's medical device cybersecurity guidance requires a documented cybersecurity risk management plan, a software bill of materials (SBOM), and post-market monitoring for vulnerabilities.
• Post-market surveillance: Manufacturers of regulated devices are required to monitor post-market performance and report certain adverse events and malfunctions to the FDA.

When evaluating a development partner for a regulated or potentially regulated health software project, a structured vendor assessment matters. Key questions to ask:

• Has the team delivered comparable medical software products that received FDA clearance or authorization?
• How does the team manage requirements documentation and traceability from the start of development?
• What testing and verification documentation will be delivered at project completion, and in what format?
• How are cybersecurity risks managed through the development lifecycle and after deployment?
• Who is responsible for regulatory strategy and formal regulatory submissions -- and is that expertise in-house or contracted?
• What quality management system does the team work within?
• Who owns the design history file, requirements documentation, and other project artifacts after delivery?
• What post-deployment support and software maintenance are included?
• Does the team understand that the product manufacturer -- not the development vendor -- retains regulatory responsibility for the device?

Reviewing verified healthcare software development provider reports can help buyers identify vendors with documented experience in regulated product development before starting the selection process.

What Should You Do If You Are Unsure Whether Your App Is a Medical Device?

Uncertainty about whether a health app qualifies as a medical device should prompt a structured assessment -- not an assumption that the product is exempt. The most common and costly mistake is treating the question as resolved by a superficial reading of the general wellness policy, a competitor's apparent lack of clearance, or the absence of a medical label in marketing copy. None of those factors independently resolves the regulatory question for a specific product.

A practical decision framework for teams facing this uncertainty:

1. Write out the intended use in one clear paragraph. If the intended use includes diagnosing, treating, preventing, monitoring, or managing a disease or medical condition, the product needs a formal regulatory assessment before proceeding.
2. Audit all product claims. Review the app store listing, product website, investor deck, onboarding flow, and any planned marketing for medical claims. Claims can be explicit ("detects atrial fibrillation") or implicit (a notification that tells a user their reading is "outside the normal range").
3. Identify the output and how it is used. If a healthcare professional or patient could plausibly use the output to make or inform a specific clinical decision, the product is closer to the device end of the spectrum.
4. Search FDA databases for comparable authorized products. The FDA's 510(k) database and De Novo database show comparable products that have received authorization. Their product codes and intended-use descriptions provide useful framing for where a product likely sits.
5. Apply the general wellness policy checklist honestly. FDA's guidance provides specific criteria. If a product does not clearly satisfy them, do not assume it qualifies for the wellness category.
6. Seek qualified regulatory counsel before committing to architecture or launch plans. A regulatory attorney or experienced regulatory affairs professional can provide a defensible intended-use analysis and a preliminary classification assessment that generic research cannot.
7. Consider a Pre-Submission meeting with FDA. For products with a genuinely unclear regulatory status, a Pre-Submission (Q-Sub) meeting with FDA is a formal mechanism to get the agency's preliminary views on regulatory pathway before investing in the premarket submission.

The time to resolve regulatory uncertainty is before committing to a product architecture, a feature set, and a development contract -- not at launch. Builders who discover late that their product requires a 510(k) face not only the cost of the submission but the cost of reworking documentation, testing evidence, and potentially software architecture to meet regulated-product standards.