| This article is part of our series on US Healthcare Software Compliance, Security, and Regulatory Strategy for Developers |
FDA SaMD classification is one of the most consequential regulatory decisions US healthtech startups face. It is also among the most frequently misunderstood areas. Many founders build entire product architectures, including decisions around healthcare software development services before asking a critical question: does this qualify as a medical device?
Getting that wrong carries real consequences. Products functioning as medical devices without FDA clearance face warning letters, import alerts, product seizures, and injunctions. FDA enforcement actions are documented, public, and recurring. Any one of them can end a startup before it scales.
Many product founders label as wellness tools or administrative software actually meet the FDA’s SaMD definition. This guide covers the classification framework, regulatory pathways, and AI/ML-specific requirements, built for healthcare mobile app product teams making real architecture decisions.
What is FDA SaMD, and Who Does It Apply To?
The FDA defines Software as a Medical Device as software intended for one or more medical purposes. It performs those purposes without being part of a hardware medical device. That hardware independence is what separates SaMD from SiMD.
SiMD (Software in a Medical Device) is embedded in hardware and regulated as part of that device. SaMD operates standalone: on iOS and Android smartphones, cloud platforms, or desktops. The platform doesn’t drive classification. Intended use does. Teams building standalone clinical software through healthcare mobile app development must resolve SaMD classification before any architecture decision is finalized.
If software diagnoses, treats, cures, mitigates, or prevents disease, it qualifies as SaMD. Examples include AI diagnostic imaging tools, ECG analysis software that detects atrial fibrillation, and CDS tools that provide specific treatment recommendations.
Not every healthcare-adjacent product qualifies. Appointment scheduling, billing platforms, general wellness apps without clinical claims, and administrative workflow tools don’t meet the threshold.
The line is drawn by intended use — not just what the product does, but what labeling, marketing, and promotional materials claim it does. The FDA’s Policy for Device Software Functions and Digital Health Center of Excellence resources clarify this distinction in detail.
FDA SaMD Risk Classification: Classes I, II, and III
The FDA applies a risk-based classification system to all medical devices, including SaMD. Class I carries the lowest risk and is subject only to general controls. Class II carries a moderate risk and typically requires 510(k) clearance or De Novo authorization. Class III carries the highest risk and requires Premarket Approval (PMA).
For SaMD specifically, the FDA uses the IMDRF risk framework. It evaluates two dimensions: the significance of the information the software provides to healthcare decisions, and the state of the healthcare situation it addresses. A non-serious condition with supplementary information sits at low risk. A critical condition with treatment-driving output sits at high risk.
Most healthtech startups operate in the Class II space. Basic clinical reference tools that support non-critical decisions may fall into Class I. Software-based diagnostic aids, clinical decision support tools, and monitoring applications typically sit in Class II. Software that drives autonomous treatment decisions in life-sustaining contexts falls into Class III, the PMA track.
The De Novo pathway serves novel, moderate-risk devices with no cleared predicate. Many first-in-class AI diagnostic tools have used it. It creates a new device classification that can become a predicate for future 510(k) submissions.
The 510(k) Clearance Pathway: What Healthtech Startups Need to Know
The 510(k) pathway is the primary clearance route for most Class II SaMD. It requires demonstrating substantial equivalence to a legally marketed predicate device. That predicate relationship is the structural foundation of the submission strategy.
Substantial equivalence requires the same intended use as the predicate, and the same technological characteristics, or different characteristics that don’t raise new safety questions. Both dimensions must be addressed with specificity.
510(k) software documentation is extensive. It includes risk classification, software descriptions, lifecycle documentation, requirements, and validation testing. Teams that treat it as an afterthought often face costly delays. Custom software development for SaMD products should embed the software lifecycle documentation framework into the development workflow from the first sprint not assembled retrospectively before submission.
The FDA targets a 90-day review timeline from acceptance. Interactive reviews and deficiency responses routinely extend that window. The Pre-Submission (Q-Sub) program lets teams get written FDA feedback before investing in full submission preparation. It is the most underused tool in early-stage regulatory planning.
AI/ML-Based SaMD: Additional FDA Requirements
Traditional SaMD runs on locked algorithms. They behave the same post-deployment as during validation. AI/ML-based SaMD can learn and drift after release. That creates a direct regulatory question: when does a changed algorithm become a new device?
The FDA’s answer is the Predetermined Change Control Plan (PCCP). It lets AI/ML developers pre-specify planned algorithm modifications before submission. If the PCCP is accepted, qualifying updates can proceed without a new 510(k).
A PCCP must define algorithm performance specifications clearly. Acceptable thresholds, evaluation datasets, and monitoring metrics are all required. Vague performance boundaries don’t hold.
Real-world performance monitoring is mandatory for AI SaMD. Post-market surveillance plans must specify how algorithm performance will be tracked post-deployment. This is an upstream requirement, not a post-clearance task.
Transparency and explainability requirements continue to evolve. Current FDA guidance emphasizes clarity about algorithmic inputs, outputs, and performance limits. Black-box outputs create both clinical and regulatory risk.
What Software Is Exempt from FDA SaMD Regulation
The 21st Century Cures Act excludes certain software categories from medical device classification. Understanding these exemptions is just as important as understanding what qualifies as SaMD.
Administrative software is generally exempt. This includes scheduling, billing, coding, claims processing, and practice management tools. General wellness apps are also exempt if they promote healthy behavior without making clinical claims or managing serious conditions.
EHR software itself is exempt. However, software that analyzes EHR data to generate diagnostic or treatment recommendations may still qualify as SaMD. The exemption applies to the record system, not always to the analytical layer built on top of it.
The clinical decision support exemption is conditional and applies only if all four FDA requirements are met simultaneously. A key requirement is transparency, meaning clinicians must be able to review the basis for generated recommendations independently. Organizations should verify each requirement before assuming the exemption applies. Failing to do so can result in costly compliance mistakes.
The FDA Pre-Submission Program: Your First Regulatory Step
The Pre-Submission (Q-Sub) program gives healthtech startups direct access to written FDA feedback before formal submission. No other early-stage regulatory tool delivers as much strategic value at as low a cost.
A Q-Sub can address device classification questions, regulatory pathway selection, predicate device strategy, performance testing requirements, and proposed labeling. These are precisely the questions that derail teams after they’ve invested significantly in engineering and clinical work.
The process is structured: submit a Pre-Sub meeting request with written questions, receive a written FDA response. Request an optional in-person or virtual meeting if needed. FDA responses to Q-Sub questions are not binding. But they reflect the agency’s current thinking and materially reduce pathway uncertainty.
The quality of the Q-Sub questions determines the value of the FDA’s response. Vague questions produce vague answers. Most first-time teams benefit significantly from regulatory consultant support in structuring their Q-Sub questions before submission.
Building FDA Compliance into Healthcare Software Early
FDA SaMD compliance is navigable and structured. The classification framework is clear. The pathways are defined. The tools for early-stage engagement with the FDA exist and are underused.
What consistently creates costly outcomes isn’t regulatory complexity but sequencing. Classification questions are answered after the engineering investment is sunk. Pathway decisions made without FDA input. Exemption assumptions that collapse under scrutiny.
Startups that embed regulatory thinking into architecture design avoid most of these outcomes. Those who treat it as post-build compliance absorb the consequences.
If your healthcare software product may qualify as SaMD, begin with an FDA regulatory strategy before product design. Plus, a Pre-Submission consultation will be the most cost-effective path to market clearance. Learn more about digital transformation solutions from a leading AI software company in the United States.
