The FDA SaMD framework is the single most consequential regulatory boundary in clinical AI right now. Engineers shipping diagnostic models, clinical informaticists deploying NLP-based screening tools and compliance officers reviewing vendor contracts all need to know exactly where software transitions from a clinical decision support tool into a regulated medical device. Getting that wrong carries serious legal exposure. Getting it right creates a durable compliance posture that survives software updates, model drift and agency guidance revisions.
This article maps the current FDA SaMD framework against real-world clinical AI use cases, walks through the four-quadrant risk classification model, explains when a 510(k) submission becomes mandatory and unpacks the Predetermined Change Control Plan guidance that changes how adaptive AI systems are regulated across their full development lifecycle.
Why the CDS-SaMD Distinction Defines Clinical AI Risk
Clinical decision support software has existed since the 1980s. Rule-based drug interaction checkers, dosage calculators and evidence-based order sets all qualify. The FDA historically left most of that software alone. The 21st Century Cures Act, signed into law in 2016, codified that hands-off posture for certain CDS categories and directed the FDA to focus regulatory attention on higher-risk software functions.
What changed the stakes is machine learning. A static drug interaction checker applies fixed rules a clinician can inspect and override. A large language model generating a differential diagnosis, a computer vision algorithm flagging a retinal scan for diabetic retinopathy or an NLP pipeline scoring depression severity from clinical notes does something qualitatively different. It generates outputs a clinician may not be able to independently verify in real time. That opacity is precisely what the FDA SaMD framework is designed to address.
The core regulatory question is not whether the software uses AI. The question is whether the software is intended to diagnose, cure, mitigate, treat or prevent a disease or condition. If the answer is yes, the software is a medical device under the Federal Food Drug and Cosmetic Act regardless of whether it runs on a dedicated device, a hospital server or a cloud API.
The FDA SaMD Framework: Four Risk Tiers and What Triggers Oversight
The FDA adopted the International Medical Device Regulators Forum definition of Software as a Medical Device in 2017 and has built its subsequent guidance on that foundation. The IMDRF framework classifies SaMD along two axes: the significance of the information provided by the software (treat or diagnose, drive clinical management or inform clinical management) and the severity of the condition the software addresses (critical, serious or non-serious).
Those two axes produce a four-category risk matrix. Category I software carries the lowest risk: informing clinical management for non-serious conditions. Category IV carries the highest: treating or diagnosing critical conditions. The FDA generally requires premarket review for Category III and IV software and applies a risk-proportionate approach to Categories I and II.
For clinical mental health AI specifically, the risk tier depends heavily on how the output is framed. A tool that surfaces validated PHQ-9 scores from structured intake data and presents them to a Licensed Clinical Doctor for independent review sits differently in the matrix than a tool that generates a DSM-5 diagnosis code and routes the patient to a specific care pathway without clinician review. The first is likely CDS. The second almost certainly triggers SaMD classification.
The FDA's 2019 discussion paper on a proposed regulatory framework for AI and ML-based SaMD and its subsequent 2021 action plan introduced a total product lifecycle approach. That approach acknowledges that a model trained today will perform differently after six months of real-world data exposure. Regulatory oversight has to account for that drift. The Predetermined Change Control Plan concept emerged directly from that recognition.
The 510(k) Trigger: When AI Becomes a Medical Device
A 510(k) premarket notification is the most common pathway to FDA clearance for moderate-risk medical devices. The submitting organization must demonstrate that its device is substantially equivalent to a legally marketed predicate device. For software, that means identifying a cleared SaMD with comparable intended use and technological characteristics.
The 510(k) trigger in AI-assisted clinical tools comes down to three practical questions.
First: does the software acquire, process or analyze patient-specific data and return patient-specific results rather than general population data? A clinical NLP pipeline reading a single patient's progress notes to score suicidal ideation risk meets this threshold. A population analytics dashboard summarizing aggregate risk scores across a panel does not necessarily meet it.
Second: is the intended use diagnostic or therapeutic? If a vendor's marketing materials, user documentation or algorithm design indicate the software is meant to diagnose a specific condition, that declared intent is binding regardless of how the output is technically labeled. The FDA reviews intended use declarations carefully and has cited misleading labeling in warning letters.
Third: can a clinician independently review the basis for the recommendation without specialized technical training? This is the transparency criterion that separates a large portion of modern ML-based tools from their rule-based predecessors. When a Random Forest model or a transformer-based scoring system generates a risk prediction, the clinician typically cannot inspect the reasoning chain the way they could inspect a decision tree. That opacity does not automatically trigger 510(k) requirements but it is a significant factor in the FDA's assessment of whether the software provides recommendations a healthcare professional can independently review.
Organizations that deploy AI-assisted mental health screening tools without performing this three-question analysis are taking on regulatory risk they may not have quantified. At TheraPetic® Healthcare Provider Group, our clinical technology team applies these criteria to every intake AI module before deployment, working alongside our Licensed Clinical Doctors to ensure the human review layer is both structurally present and clinically meaningful rather than a nominal checkbox.
The CDS Safe Harbor and Its Four Criteria
The 21st Century Cures Act created a statutory safe harbor for certain CDS software, excluding it from device regulation. To qualify, a CDS tool must meet all four of the following criteria simultaneously.
The software must not acquire, process or analyze medical images, signals from in vitro diagnostics or signals acquired from a patient. Clinical NLP tools reading free-text notes occupy a gray zone here because progress notes are patient-generated data, though not signals in the physiological sense. The FDA has provided limited formal guidance on this edge case as of 2026.
The software must display, analyze or print medical information that is not specific to an individual patient, or it must support or provide recommendations to healthcare professionals about prevention, diagnosis or treatment of a disease for an individual patient. The second clause is where most mental health AI tools try to anchor.
The intended purpose must be to support or enable a healthcare professional's independent review of the recommendations. This is the most operationally significant criterion. The FDA interprets "independent review" to mean the clinician can reach the same conclusion using the software's underlying data and clinical reasoning without relying on the algorithm's output as an authoritative conclusion. If the user interface design discourages deviation from the algorithm's recommendation, the FDA has indicated that can undermine a CDS classification claim.
The software must not be intended for use to replace the clinical judgment of a healthcare professional. Marketing language matters here. Any positioning that suggests the AI replaces clinical assessment rather than informs it is a red flag in an FDA review.
If a tool fails any one of these four criteria, the CDS safe harbor does not apply and the FDA will analyze the software under the standard SaMD framework. Engineering teams building AI intake tools, risk stratification algorithms or symptom triage models should treat these four criteria as a design checklist, not an afterthought.
Predetermined Change Control Plans and Adaptive AI
The traditional regulatory model assumed a medical device was a fixed artifact: clear it once, sell it. That model breaks down completely with adaptive ML systems. A model fine-tuned on new clinical data, a retrieval-augmented generation architecture pulling from an updated knowledge base or a transformer checkpoint updated to reflect revised DSM-5 criteria is functionally a different software product after the update. Under the traditional model, each update could theoretically require a new premarket submission.
The FDA's proposed Predetermined Change Control Plan guidance addresses this directly. A PCCP allows developers to specify in advance the types of modifications they expect to make to an AI-based SaMD, the methods they will use to validate those modifications and the performance criteria that must be met before a change is deployed. If the FDA accepts the PCCP as part of an initial clearance, the developer can implement the described changes without a new 510(k) submission, provided the changes stay within the PCCP's defined boundaries.
This is architecturally significant for anyone building clinical AI on top of foundation models. A RAG pipeline pulling from a clinical knowledge graph that is updated quarterly needs a change management story. A fine-tuned clinical NLP model retrained on new EHR data every six months needs one too. The PCCP framework gives developers a path to build that story into the regulatory submission rather than scrambling retroactively each time the model changes.
As of 2026, the PCCP guidance remains in proposed form pending finalization. The FDA has accepted voluntary PCCP submissions and indicated it is working toward a final guidance document. Organizations shipping adaptive clinical AI should be designing their model governance pipelines to be PCCP-compatible now, not after the final guidance drops. That means version-controlled model registries, prospectively defined performance thresholds and documented drift detection protocols.
Research published in NEJM AI and npj Digital Medicine has begun examining the performance drift problem empirically, documenting how clinical ML models trained on historical EHR data degrade when deployed in different health systems or after significant changes in patient population demographics. The PCCP framework does not solve that drift but it creates a regulatory structure within which drift monitoring is a compliance requirement rather than an optional engineering practice.
Clinical Mental Health AI: Where TheraPetic® Draws the Line
At TheraPetic® Healthcare Provider Group, we operate on both sides of this regulatory line by design. Our HANK AI system, which powers initial intake and psychosocial screening for support animal documentation through verify.mypsd.org, is architected explicitly as a CDS tool rather than a diagnostic engine.
HANK AI surfaces structured clinical indicators, validated screening instrument scores and patient-reported history to our Licensed Clinical Doctors. It does not generate DSM-5 diagnoses. It does not route patients to care pathways without clinician review. Every clinical determination is made by a credentialed human clinician who can access the underlying data, apply independent clinical judgment and deviate from any algorithmic suggestion without technical or workflow friction. That architecture is not accidental. It reflects a deliberate reading of the CDS safe harbor criteria and a commitment to human oversight that our clinical leadership, under the direction of Dr. Patrick Fisher, PhD, LPC, NCC, considers both ethically required and regulatorily sound.
The data governance layer for this system runs through mydatakey.org, which handles HIPAA-compliant deidentification and data subject rights management. Keeping the AI infrastructure decoupled from identifiable patient data wherever possible is part of how we maintain both compliance and patient trust.
For engineers and clinical informaticists building similar systems, the practical takeaway is this: design the human review layer as a structural requirement, not a UI feature. The clinician's ability to independently reach the same conclusion as the algorithm, using the same underlying data, is the technical and legal foundation of a defensible CDS classification. If your system architecture makes independent review difficult or unlikely in practice, the FDA will notice. So will plaintiffs' attorneys.
The FDA SaMD framework is not a bureaucratic obstacle to clinical AI innovation. It is a risk management structure that, when understood correctly, actually clarifies what you can build and how. The organizations that will deploy the most capable clinical AI at scale in the years ahead are the ones investing now in regulatory literacy at the engineering level, not just in the compliance department.