FDA SaMD Guide: Navigating Medical Device Regulations
Not every healthcare software application is a medical device — but the ones that are face a fundamentally different regulatory path. When software diagnoses conditions, recommends treatments, predicts clinical deterioration, or guides therapeutic decisions, it crosses the line from health IT tool to Software as a Medical Device (SaMD). Understanding where that line is — and what happens once you cross it — determines whether your product needs FDA clearance, what pathway it follows, and what quality systems you must maintain.
Tell Us Your Requirements
Our experts are ready to understand your business goals.
Trusted by Industry Leaders Worldwide
Awards & Recognitions
What is Software as a Medical Device?
The FDA defines Software as a Medical Device (SaMD) as software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device. The key phrase is “intended use” — the same software functionality may or may not be SaMD depending on what it’s intended to do.
SaMD examples: An AI algorithm that analyzes chest X-rays to detect pneumothorax. A mobile app that analyzes ECG data to identify atrial fibrillation. A clinical decision support tool that recommends chemotherapy regimens based on tumor genomic profiling. A remote monitoring platform that predicts sepsis onset from vital sign trends.
Not SaMD: An EHR system that stores and displays clinical data without analysis. A patient portal that shows lab results. An administrative scheduling tool. A billing platform. A clinical reference database that provides drug information for clinician review (without automated recommendations). A FHIR API that transfers data between systems.
The gray area: CDS software that meets all four criteria of Section 3060 of the 21st Century Cures Act is excluded from FDA device regulation: (1) not intended to acquire, process, or analyze medical images, signals, or patterns; (2) intended for the purpose of displaying, analyzing, or printing medical information; (3) intended for healthcare professionals; AND (4) intended to enable the professional to independently review the basis for the recommendation. If all four criteria are met, the software is exempt from FDA device regulation.
FDA Classification and Regulatory Pathways
- 01
Risk Classification
The FDA classifies SaMD based on the significance of the information it provides and the state of the patient’s condition:
Class I (Low Risk) — SaMD that provides information to inform clinical management but doesn’t drive critical decisions. Example: wellness trend tracking. Generally exempt from premarket review.
Class II (Moderate Risk) — SaMD that provides information to drive clinical management or to diagnose. Example: AI that detects diabetic retinopathy from fundus images. Requires 510(k) clearance or De Novo classification.
Class III (High Risk) — SaMD that provides information to treat or diagnose life-threatening conditions without established predicates. Example: AI that guides radiation therapy planning. Requires Premarket Approval (PMA).
- 02
510(k) Clearance
The most common pathway for moderate-risk SaMD. You demonstrate that your software is substantially equivalent to a legally marketed predicate device — similar intended use, similar technology, and at least as safe and effective. 510(k) submissions include device description, intended use, comparison to predicate, performance data, software documentation, and cybersecurity information.
Timeline: FDA review targets 90 days from submission acceptance, though actual timelines vary.
- 03
De Novo Classification
For novel SaMD that have no predicate device but present low-to-moderate risk. De Novo establishes a new regulatory classification and creates a predicate for future 510(k) submissions by other developers. More complex than 510(k) but doesn’t require the extensive clinical trials of PMA.
- 04
Predetermined Change Control Plan
A recent FDA innovation allowing SaMD developers to describe anticipated modifications — including AI/ML model updates — in the original premarket submission. If the actual changes fall within the predetermined plan, they can be implemented without a new submission. This is critical for adaptive AI algorithms that improve over time through retraining.
Technical Implementation for SaMD Compliance
- 01
Quality Management System (QMS)
FDA-regulated SaMD requires a Quality Management System compliant with 21 CFR Part 820 (Quality System Regulation). Key requirements: design controls (design input, output, review, verification, validation, transfer), document control, corrective and preventive action (CAPA), complaint handling, and management review.
For software, design controls translate to: requirements documentation, software architecture documentation, code review processes, verification testing (does the software meet requirements?), validation testing (does the software meet user needs?), and traceability from requirements through design through testing.
- 02
Software Documentation
FDA expects specific software documentation depending on the level of concern (Minor, Moderate, Major): software requirements specification, software design specification, traceability matrix, software testing (unit, integration, system), risk analysis (per ISO 14971), and cybersecurity documentation.
- 03
Cybersecurity Requirements
The FDA requires cybersecurity documentation for all SaMD submissions — threat modeling, security architecture, vulnerability testing, software bill of materials (SBOM), and a plan for post-market cybersecurity management. The FDA’s premarket cybersecurity guidance (2023) establishes specific expectations for authentication, encryption, HIPAA alignment, and vulnerability disclosure.
- 04
Real-World Performance Monitoring
Post-market, SaMD developers must monitor real-world performance — tracking whether the software performs as intended in production clinical environments. For AI/ML-based SaMD, this includes monitoring for model drift, performance degradation across demographic subgroups, and emerging failure modes.
Compliance Checklist
Regulatory classification:
- Intended use clearly defined and documented
- SaMD vs. non-SaMD determination completed (including Cures Act Section 3060 analysis)
- Risk classification determined (Class I, II, or III)
- Regulatory pathway selected (510(k), De Novo, PMA, or exempt)
How Taction Ensures Compliance
At Taction, our team builds SaMD products and helps healthcare software companies navigate FDA regulatory requirements from concept through clearance and post-market maintenance.
What we do:
- SaMD classification analysis — We evaluate your software’s intended use against FDA classification criteria and Cures Act exemptions — determining whether your product is SaMD, what risk class applies, and which regulatory pathway to pursue.
- FDA-compliant software development — We build SaMD with design controls, documentation, and quality processes aligned with 21 CFR Part 820 — from requirements through verification and validation.
- Premarket submission support — We prepare software documentation packages for 510(k), De Novo, and PMA submissions — including software descriptions, performance data, risk analysis, and cybersecurity documentation.
- AI/ML SaMD development — We build AI-powered clinical software with predetermined change control plans, model monitoring infrastructure, and performance validation frameworks designed for FDA compliance.
- Post-market surveillance — We build real-world performance monitoring systems that track SaMD performance in production — detecting model drift, adverse events, and cybersecurity threats.