FDA regulations for medical apps apply when software is intended to diagnose, treat, cure, mitigate, or prevent disease, making it a medical device. Many health apps fall outside FDA oversight, including most administrative tools, EHRs, and general wellness products, while others need clearance before marketing. In January 2026, FDA updated its clinical decision support and general wellness guidance, shifting several lines. This guide explains how to tell whether your app is regulated, the pathways if it is, and what AI and cybersecurity rules mean for developers. Our healthcare app development services plan regulatory strategy from discovery onward.
This guide is general information, not regulatory or legal advice. Confirm your product’s status with qualified FDA regulatory counsel.
FDA regulates software functions that meet the legal definition of a medical device, regardless of whether they run on a phone, in the cloud, or inside hardware. What matters is intended use, shown through labeling, marketing claims, and product functionality, not the technology itself. Two apps with identical code can fall on opposite sides of the line depending on what their makers claim they do. That is why regulatory assessment belongs in discovery, before features and messaging are finalized.
FDA looks at what you say the software does. Claims about diagnosing, treating, or preventing disease suggest a device, while wellness or administrative claims usually do not.
Software as a medical device, or SaMD, is software intended for medical purposes that performs those purposes without being part of a hardware device, such as an image-analysis algorithm.
Software that drives or controls hardware devices, such as an insulin pump app controlling dosing, is regulated as part of that device and typically carries higher risk.
FDA evaluates individual functions, not entire apps. One app can contain regulated and unregulated functions, so assess every feature separately and document your reasoning for each.
The 21st Century Cures Act excluded several categories of software from the medical device definition, and FDA guidance explains additional areas where it does not intend to enforce requirements. These exclusions cover a large share of healthcare apps, which is good news for many developers. However, the boundaries are specific, and adding a single diagnostic feature or claim can move a product into regulated territory. Review each exclusion carefully against your exact functionality.
Scheduling, billing, claims processing, inventory, and practice management software supporting healthcare operations are excluded from the device definition because they do not perform clinical functions.
Software that stores and displays patient records, as long as it is not intended to interpret or analyze data for diagnosis or treatment, falls outside device regulation under the Cures Act.
Software that only transfers, stores, converts formats, or displays clinical data, without analyzing it, is generally excluded. Adding interpretation or alerts can change that status.
Low-risk products intended only for general wellness, such as fitness, sleep, or stress management, fall under FDA’s general wellness policy rather than device requirements, when criteria are met.
CDS software meeting four statutory criteria, including supporting rather than replacing clinician judgment and allowing independent review of the basis, is excluded from the device definition.
On January 6, 2026, FDA issued updated final guidance on clinical decision support software and general wellness products, superseding versions from 2022 and 2019. Both updates broadened where software can operate without device requirements, while keeping FDA’s risk-based approach. For developers of clinician tools, wearables, and AI assistants, these updates may change earlier regulatory conclusions, so revisit past assessments with counsel rather than relying on older interpretations.
To be excluded, CDS must not analyze medical images or signals, must display or analyze medical information, must support healthcare professional recommendations, and must let professionals independently review the basis.
FDA removed most language suggesting time-critical decision support automatically fails the criteria, and signaled enforcement discretion for some software recommending a single option to clinicians.
Non-device CDS must still help clinicians understand the basis for recommendations. Provide clear, accessible documentation of inputs, logic, and limitations within or alongside the software.
The updated guidance indicates some non-invasive products estimating parameters like blood pressure, oxygen saturation, or glucose can qualify as wellness products when outputs are intended solely for wellness.
Wellness products must keep labeling and marketing consistent with wellness uses. Disease diagnosis or treatment claims, or higher-risk technologies, move products outside the general wellness policy.
If your app is a regulated device, FDA classifies it by risk into Class I, II, or III, which determines the premarket pathway. Most regulated software functions fall into Class II and reach the market through 510(k) clearance or De Novo classification. Choosing the right pathway early shapes evidence requirements, documentation, budget, and timeline, so engage regulatory expertise before committing to a development plan.
Low-risk devices often face general controls only, and many are exempt from premarket notification. Few software functions with meaningful clinical claims fall into this category.
Moderate-risk devices usually require 510(k) clearance, showing substantial equivalence to a legally marketed predicate device. Many SaMD products use this pathway when suitable predicates exist.
Novel low-to-moderate risk devices without a suitable predicate can request De Novo classification. Once granted, the device can serve as a predicate for future 510(k) submissions.
High-risk devices that support or sustain life, or present significant risk, require premarket approval with substantial clinical evidence. This is the most demanding and expensive pathway.
FDA’s Pre-Submission program lets developers get feedback on classification, testing, and evidence plans before filing. Early feedback can prevent costly redesigns and failed submissions later.
Regulated medical apps face requirements beyond the premarket submission itself. Developers must operate a quality management system, address cybersecurity throughout the product lifecycle, and, for AI-enabled functions, plan how models will change after clearance. These obligations influence architecture, documentation, and team processes, so design them in from the start. Teams building clinical AI should pair regulatory planning with experienced healthcare AI solutions engineering.
FDA’s Quality Management System Regulation, effective February 2, 2026, aligns device quality requirements with ISO 13485. Software teams need documented design controls, risk management, and change processes.
Recognized standards such as IEC 62304 for software lifecycle processes and ISO 14971 for risk management structure how regulated software is designed, verified, and maintained.
Devices with software that connect to networks face statutory cybersecurity requirements, including vulnerability management plans and a software bill of materials. Security must be documented in submissions.
FDA’s predetermined change control plan approach lets manufacturers describe planned AI model updates in submissions, so certain modifications can occur without new clearances when implemented as described.
FDA issued draft guidance in January 2025 on lifecycle management and submission recommendations for AI-enabled device software functions. Monitor finalization and future updates closely.
A structured assessment prevents both overregulation, which wastes time and money, and underregulation, which risks enforcement and forced product changes. Work through each feature, its intended use, and your planned claims, then compare against statutory exclusions and current guidance. Document conclusions and revisit them whenever features or marketing change. Teams developing clinical AI often bring in specialized healthcare AI developers alongside regulatory counsel during this process.
Break the app into individual functions, such as data display, alerts, risk scores, and recommendations. Assess each function separately, because classification applies function by function.
Draft precise intended use and indications statements for each clinical function. These statements, along with marketing claims, largely determine whether functions are devices.
Check each function against Cures Act exclusions, the 2026 CDS and general wellness guidance, and FDA’s device software function policies. Note where functions fall clearly inside or outside.
Record conclusions with reasoning and dates. Review them before launching new features, entering new markets, or changing marketing, because small changes can alter regulatory status.
Related: FDA and HIPAA are separate regimes. See our guide to building a HIPAA-compliant app.
Our work and story have been picked up by news outlets and databases worldwide.
As featured on
It depends on intended use. Apps that diagnose, treat, cure, mitigate, or prevent disease may be medical devices needing FDA clearance or approval. Administrative apps, EHRs, data display tools, general wellness apps, and qualifying clinical decision support are generally excluded. Assess each function and claim with qualified regulatory counsel.
Software as a medical device is software intended for medical purposes, such as diagnosing or treating disease, that performs those purposes without being part of a hardware device. Examples include algorithms analyzing images or physiological data. SaMD is regulated based on risk, typically through 510(k), De Novo, or PMA pathways.
On January 6, 2026, FDA updated its clinical decision support and general wellness guidance. The CDS update removed most language treating time-critical support as automatically regulated and eased enforcement for some single-recommendation tools. The wellness update clarified that certain non-invasive physiologic estimates can qualify as wellness when intended solely for wellness.
Generally not, when they are low risk and intended only for general wellness, such as fitness, sleep, or stress management, without disease diagnosis or treatment claims. FDA’s general wellness policy applies. Adding disease-specific claims or higher-risk technologies can move a product into device regulation.
Timelines vary by pathway and readiness. A 510(k) review follows FDA’s review goals once a complete submission is filed, but preparing evidence, documentation, and quality systems often takes much longer. De Novo and PMA pathways usually take longer. Pre-Submission meetings help avoid delays.
Assess whether each AI function diagnoses, treats, or drives clinical decisions, and whether it meets the non-device CDS criteria, including allowing clinicians to independently review its basis. AI that analyzes medical images or signals is generally regulated. Book a free consultation to plan your app’s regulatory and technical strategy.
Tell us what you’re building. Our team will get back to you within one business day with a clear, no-obligation plan.
