FDA SaMD (Software as Medical Device) Compliance Guide 2026
Key Takeaways:
- SaMD is software that performs a medical purpose without being part of a hardware medical device — and it is regulated by the FDA
- Not all healthcare software is SaMD — the intended use and risk level determine whether FDA oversight applies
- SaMD is classified into three risk categories based on the seriousness of the condition and the significance of the information provided
- The FDA’s Digital Health Center of Excellence (DHCoE) is actively increasing enforcement of SaMD regulations in 2026
- Getting SaMD classification wrong at the architecture stage is one of the most expensive mistakes a digital health company can make
What Is SaMD?
Software as a Medical Device (SaMD) is software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device.
In plain terms — if your software makes clinical decisions, analyzes patient data to diagnose or treat, or provides information that a clinician uses to make treatment decisions, it is likely SaMD and subject to FDA regulation.
This matters enormously for digital health companies, healthcare IT teams, and software developers building clinical tools. The FDA has been steadily increasing its oversight of SaMD since the 21st Century Cures Act, and its Digital Health Center of Excellence is actively engaged with the software product lifecycle in ways it was not five years ago.
The companies that get into trouble are not always the ones deliberately trying to avoid regulation. Many are genuinely surprised to discover that software they built — a clinical decision support tool, an AI diagnostic algorithm, a risk scoring application — falls under FDA jurisdiction. By the time they find out, they may have launched a product that requires a 510(k) clearance they never obtained.
Understanding SaMD classification before you build is far less expensive than discovering your compliance gap after launch.
How the FDA Defines SaMD
The FDA adopted the International Medical Device Regulators Forum (IMDRF) definition of SaMD:
“Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”
Three elements are critical in this definition:
Intended use. The FDA evaluates what the software is designed and marketed to do — not just what it technically can do. A software tool marketed to help clinicians diagnose atrial fibrillation from ECG data is SaMD even if the same algorithm could theoretically be used for research purposes. Intended use is determined by your labeling, marketing materials, and product documentation — not just the code itself.
Medical purpose. The IMDRF defines medical purpose as including: diagnosis, prevention, monitoring, treatment, or alleviation of disease; diagnosis, monitoring, treatment, alleviation, or compensation for an injury; investigation, replacement, modification, or support of the anatomy or a physiological process; supporting or sustaining life; control of conception; disinfection of medical devices; and providing information by means of in vitro examination of specimens.
Independence from hardware. SaMD runs on general-purpose computing platforms — smartphones, tablets, cloud servers, workstations — rather than being embedded in a dedicated hardware device. Software embedded in a hardware medical device (like the firmware in an infusion pump) is regulated as part of that device, not as SaMD.
Is Your Software SaMD? The Decision Framework
The FDA’s guidance provides a practical framework for determining whether your software falls under SaMD regulation. Work through these questions:
Question 1: Does your software have a medical purpose?
If your software is purely administrative — scheduling, billing, practice management, HR — it is not SaMD. If it touches clinical decision-making, diagnosis, treatment, or patient monitoring in any meaningful way, proceed to Question 2.
Question 2: Is the software intended to be used in the diagnosis, cure, mitigation, treatment, or prevention of disease?
This is the core FDA device definition question. Software that analyzes patient vitals to flag deterioration, scores risk for sepsis, reads medical images to identify pathology, or recommends treatment protocols based on patient data meets this threshold.
Question 3: Does it fall under a CDS exemption?
The 21st Century Cures Act created an exemption for certain Clinical Decision Support (CDS) software that does not meet the SaMD definition. CDS software is exempt if it: displays, analyzes, or prints medical information; supports or provides recommendations to a healthcare professional; the basis for the recommendation is transparent to the user; and the healthcare professional is not expected to rely primarily on the software’s recommendation. If your CDS software meets all four criteria, it may be exempt from FDA device regulation. If the clinician is expected to primarily rely on the software — as in an AI diagnostic tool — the exemption does not apply.
Question 4: Is it a wellness or general health tool?
General wellness products — fitness tracking, stress management, sleep coaching — that are not intended to diagnose or treat disease are generally not SaMD. The line between wellness and medical becomes regulatory when the software makes clinical claims.
If your software passes Questions 1 and 2 and does not qualify for the CDS exemption, it is SaMD and FDA oversight applies.
For healthcare software teams navigating this alongside HIPAA compliance requirements, it is worth noting that HIPAA and FDA SaMD regulations are independent frameworks — a product can be subject to both, either, or neither, depending on what it does and who it serves.
SaMD Risk Classification: The Four Categories
The IMDRF SaMD framework — which the FDA has adopted — classifies SaMD into four risk categories based on two dimensions: the state of the healthcare situation or condition (critical, serious, or non-serious) and the significance of the SaMD’s output to the healthcare decision (treat or diagnose, drive clinical management, or inform clinical management).
Category I — Lowest Risk Software that provides information to inform clinical management for non-serious conditions. Example: software that tracks non-critical chronic condition metrics and surfaces them for physician review without making treatment recommendations.
Category II — Low-Medium Risk Software that drives clinical management for non-serious conditions, or informs clinical management for serious conditions. Example: software that recommends medication adjustments for stable hypertension management, or a tool that surfaces relevant clinical history for a patient with a serious but non-critical condition.
Category III — Medium-High Risk Software that drives clinical management for serious conditions, or treats/diagnoses non-serious conditions. Example: software that automatically adjusts insulin dosing recommendations based on continuous glucose monitor data, or diagnostic software for non-life-threatening conditions.
Category IV — Highest Risk Software that treats or diagnoses critical conditions where inaccurate output could cause serious injury or death. Example: AI software that identifies ST-elevation myocardial infarction (STEMI) from ECG data and triggers a catheterization lab activation, or software that detects acute intracranial hemorrhage from CT images and recommends emergency intervention.
The risk category determines the regulatory pathway required. Higher-risk categories face more rigorous premarket review requirements.
FDA Regulatory Pathways for SaMD
510(k) Premarket Notification — Most Common Path
The 510(k) pathway is used when your SaMD is substantially equivalent to a legally marketed predicate device (a device already cleared or approved by the FDA). You must demonstrate that your device has the same intended use and the same or equivalent technological characteristics as the predicate.
Most low-to-medium risk SaMD products (Categories I–III) pursue 510(k) clearance. The process involves submitting a premarket notification to the FDA, which then reviews and either clears the device or requests additional information. Average review time is 3–6 months for straightforward submissions, though complex AI/ML-based SaMD submissions are taking longer as the FDA develops its review frameworks.
510(k) clearance does not mean FDA approval — it means the FDA has determined the device is substantially equivalent to an existing cleared device. The distinction matters for marketing and legal purposes.
De Novo Classification — For Novel Low-Risk Devices
When there is no predicate device for your SaMD — meaning you are developing something genuinely novel — but the risk level is low to moderate, the De Novo pathway creates a new device classification. A successful De Novo request establishes your product as a predicate for future 510(k) submissions by other companies in the same space.
De Novo is increasingly relevant for AI-based SaMD that has no clear predicate in traditional device categories. FDA review times for De Novo are longer than 510(k) — plan for 12+ months.
PMA (Premarket Approval) — Highest Risk Devices
Category IV SaMD — software that diagnoses or treats life-threatening conditions — typically requires Premarket Approval, the most rigorous FDA review pathway. PMA requires clinical evidence demonstrating safety and effectiveness, not just substantial equivalence to a predicate. This is a multi-year process requiring significant clinical trial data.
Predetermined Change Control Plan (PCCP) — For AI/ML SaMD
The FDA’s 2024 guidance on Predetermined Change Control Plans is specifically designed for AI/ML-based SaMD that learns and changes over time. A PCCP allows manufacturers to describe in advance the types of modifications the algorithm may undergo — retraining, performance updates — without requiring a new 510(k) submission for each change. This is one of the most practically significant recent developments for healthcare AI application developers.
Quality Management System Requirements (ISO 13485)
Regardless of which regulatory pathway your SaMD takes, you need a Quality Management System (QMS) that meets FDA expectations. ISO 13485 is the international standard for medical device QMS and is the practical framework most SaMD companies use.
Key QMS elements for SaMD:
Design Controls. FDA 21 CFR Part 820 requires documented design controls for software: design inputs (requirements), design outputs (specifications), design verification (does the software meet specifications?), design validation (does it meet user needs?), and design transfer (production processes). For SaMD, design controls are where your software requirements, architecture decisions, and testing evidence live.
Risk Management (ISO 14971). A documented risk management process covering hazard identification, risk estimation, risk evaluation, risk control, and residual risk assessment. For SaMD, this means systematically analyzing what happens when the software fails — outputs incorrect recommendations, misclassifies a condition, fails to alert on a critical finding — and documenting how those risks are mitigated.
Software Development Lifecycle (IEC 62304). The IEC 62304 standard defines software development lifecycle requirements specifically for medical device software. It requires software to be classified by safety class (A, B, or C based on potential injury severity), with corresponding documentation and verification requirements for each class.
Post-Market Surveillance. Once cleared and on the market, SaMD requires ongoing post-market surveillance — monitoring real-world performance, tracking complaints, reporting adverse events to the FDA (MDR — Medical Device Reporting), and updating risk management documentation based on post-market data.
Document Control. Every design decision, test result, risk assessment, and change must be documented, version-controlled, and traceable. Audit readiness is not a periodic exercise — it is an ongoing operational state.
Building a QMS from scratch is a significant undertaking. For companies developing their first SaMD product alongside custom healthcare software, the QMS investment is often the single largest non-development cost in the product launch.
FDA’s Software-Specific Guidance Documents
The FDA has published several guidance documents that directly govern SaMD development. These are not optional reading — they define what the FDA expects to see in submissions and audits:
Software as a Medical Device (SaMD): Clinical Evaluation (2016). Describes how to demonstrate the clinical validity and clinical performance of SaMD. Foundational for any premarket submission.
Software in a Medical Device (SAMD): Software Validation (2002, still applicable). Though older, this guidance defines general principles of software validation that FDA reviewers still apply.
Artificial Intelligence and Machine Learning-Based SaMD Action Plan (2021). Outlines the FDA’s framework for regulating AI/ML-based SaMD, including the PCCP pathway and the concept of a “predetermined change control plan” for adaptive algorithms.
Clinical Decision Support Software Guidance (2022). Clarifies the boundary between regulated SaMD and exempt CDS software under the 21st Century Cures Act. Essential reading for any company building clinical decision support tools.
Cybersecurity in Medical Devices (2023). Sets expectations for cybersecurity design, documentation, and post-market management. As of October 2023, cybersecurity documentation is a mandatory component of premarket submissions for all medical devices including SaMD.
SaMD and AI/ML: Special Considerations
AI and machine learning-based SaMD presents unique regulatory challenges that traditional software frameworks were not designed to handle. The fundamental challenge is that AI/ML models can change their behavior through training and retraining — a characteristic that does not fit neatly into traditional device approval frameworks that assume a fixed, validated software specification.
The FDA’s approach has evolved significantly and continues to evolve:
Locked vs. adaptive algorithms. A locked algorithm produces the same output for the same input every time — it does not change after deployment. An adaptive algorithm updates based on new data. Locked algorithms fit traditional 510(k) pathways more cleanly. Adaptive algorithms require a PCCP to describe how the algorithm will change and what performance standards it must maintain.
Training data documentation. For AI-based SaMD, the FDA expects documentation of training data sources, data preprocessing steps, training methodology, validation dataset characteristics, and performance metrics on both internal validation and independent test sets. Bias analysis — demonstrating the algorithm performs equitably across patient demographics — is increasingly required.
Algorithm performance transparency. The FDA expects SaMD submissions to include honest performance characterization — sensitivity, specificity, positive predictive value, negative predictive value — across clinically relevant subgroups. Cherry-picked performance metrics on favorable datasets will not survive regulatory review.
Real-world performance monitoring. For AI/ML SaMD, post-market surveillance must include ongoing monitoring of algorithm performance in real-world deployment — not just the validation dataset. Performance drift, where an algorithm’s real-world performance degrades from its validated performance, must be detected and addressed.
For teams building healthcare AI solutions that may cross into SaMD territory, engaging regulatory counsel and a QMS consultant early in the design process is far less expensive than retrofitting compliance after development is complete.
HIPAA and SaMD: How They Overlap
SaMD and HIPAA are independent regulatory frameworks, but they overlap significantly in practice for any SaMD that handles patient data.
HIPAA governs the privacy and security of Protected Health Information. If your SaMD collects, processes, stores, or transmits PHI — which most clinical SaMD does — you must comply with HIPAA’s Privacy Rule, Security Rule, and Breach Notification Rule in addition to FDA SaMD requirements.
The practical implications for architecture:
HIPAA’s technical safeguards — encryption, audit logging, access controls, transmission security — must be implemented at the infrastructure level. This is entirely separate from FDA’s cybersecurity requirements for SaMD, though there is significant overlap. Meeting one does not automatically satisfy the other. A HIPAA-compliant app architecture is a necessary foundation for SaMD but not a substitute for FDA cybersecurity documentation.
FDA’s 2023 cybersecurity guidance requires a Software Bill of Materials (SBOM) — a complete inventory of all software components, libraries, and dependencies — as part of premarket submissions. This requirement exists to support vulnerability management, not PHI protection, but building the SBOM is easier when your development process already tracks dependencies rigorously as part of good security hygiene.
Business Associate Agreements cover your HIPAA obligations with infrastructure vendors. They have no bearing on your FDA obligations. Both sets of vendor relationships — HIPAA BAAs and FDA-relevant supply chain documentation — must be managed in parallel.
Common SaMD Compliance Mistakes
Misclassifying the product as non-device CDS. The 21st Century Cures Act CDS exemption has four specific criteria. Many companies assume their clinical decision support tool is exempt without rigorously analyzing all four criteria. If a clinician is expected to primarily rely on the software’s output without independent review, the exemption almost certainly does not apply.
Starting QMS documentation after development. FDA design controls require documentation of requirements, design decisions, and risk assessments throughout the development process — not reconstructed after the fact. Retro-fitting QMS documentation to completed development is both expensive and unconvincing to FDA reviewers.
Ignoring IEC 62304. Many software teams building SaMD are familiar with ISO 27001 or HIPAA security requirements but have never encountered IEC 62304. The software safety classification and lifecycle documentation requirements of 62304 are non-negotiable for FDA premarket submissions.
Under-documenting training data for AI. AI-based SaMD submissions that describe the algorithm in detail but provide minimal information about training data, validation methodology, and bias analysis are increasingly rejected by the FDA. Training data documentation is as important as algorithm documentation.
Treating clearance as a one-time event. 510(k) clearance covers a specific version of your software with specific intended uses. Significant changes — new indications, new algorithms, new populations — may require a new submission. Not understanding what changes trigger a new regulatory submission is a common post-clearance compliance failure.
No post-market surveillance plan. Many companies focus entirely on premarket submissions and treat post-market surveillance as something to figure out later. The FDA expects a documented post-market surveillance plan before clearance and evidence of execution after launch.
The Bottom Line
FDA SaMD compliance is not a bureaucratic obstacle — it is the framework that ensures clinical software is safe and effective for patients. The companies that treat it as a checkbox exercise get into trouble. The ones that build it into their development process from day one ship better products, faster.
The most expensive SaMD compliance mistakes are the ones discovered after launch — misclassified products that need regulatory remediation, products recalled because post-market surveillance wasn’t functioning, AI algorithms that perform differently in the real world than in validation. None of these are inevitable. They are all the result of treating regulatory compliance as someone else’s problem.
If you are building software that performs a clinical function and you are not certain whether it is SaMD, get that question answered before your architecture is locked. The answer shapes everything from your QMS investment to your development timeline to your go-to-market strategy.
Talk to Taction Software’s healthcare IT team if you are navigating SaMD classification or building digital health software that needs to be both clinically effective and regulatorily sound.
Related Reading:
FAQs
SaMD runs on general-purpose hardware (phones, computers, cloud servers) and performs medical functions independently. SiMD is software embedded in a dedicated hardware medical device — like the control software in an infusion pump or the firmware in an implantable device. SiMD is regulated as part of the hardware device. SaMD is regulated independently.
It depends entirely on the app’s intended use. A wellness app that tracks steps or sleep is generally not SaMD. An app that analyzes ECG data to detect atrial fibrillation, interprets dermatology images for melanoma screening, or recommends insulin dosing adjustments is SaMD and requires FDA clearance before marketing in the US.
The FDA’s performance goal is to complete 90% of 510(k) reviews within 90 days of acceptance. In practice, complex SaMD submissions — particularly AI/ML-based products — often take 6–12 months due to additional information requests. Poorly prepared submissions that require multiple rounds of FDA questions can extend this significantly.
FDA clearance is required to market a medical device in the United States. International markets have their own regulatory frameworks — CE marking for the EU (MDR/IVDR), PMDA approval in Japan, Health Canada approval in Canada. A company can sell in international markets without FDA clearance, but cannot sell in the US. Most digital health companies pursue FDA clearance first given the size of the US market.
An SBOM is a complete inventory of all software components — libraries, frameworks, open-source packages, third-party modules — used in the SaMD. The FDA requires it as part of cybersecurity documentation so that when a vulnerability is discovered in a component (like a widely used open-source library), the manufacturer can quickly determine whether their product is affected and respond appropriately.
Yes. We work with digital health companies on custom medtech software development including SaMD products, with development processes designed to support FDA design control documentation, IEC 62304 lifecycle requirements, and HIPAA-compliant architecture. Contact us to discuss your product’s regulatory pathway before development begins.
