Glossary

SaMD — Software as a Medical Device — is the FDA's category for software that meets the definition of a medical device on its own, without being embedded in a hardware device. Nearly every AI-enabled radiology triage tool, clinical LLM with a specific diagnostic claim, or wearable-derived risk-prediction algorithm falls under this label. The classification matters because it triggers the full weight of premarket review (usually via 510(k), sometimes De Novo, occasionally PMA), quality-system regulation, post-market surveillance obligations, and — for AI/ML products — the newer Predetermined Change Control Plan framework. The International Medical Device Regulators Forum (IMDRF) provides a global framework the FDA has largely adopted for how SaMD is classified by risk.

Not every clinical-decision-support tool is SaMD. Software that provides recommendations but which the physician can "independently review" (under the 21st Century Cures Act CDS exclusion) is often out of scope. That line has been steadily narrowed by FDA guidance since 2022.

A PCCP is a plan a device manufacturer submits alongside its AI/ML-enabled device that describes, up-front, what post-market changes to the model it intends to make, how those changes will be validated, and what performance envelopes will be maintained. Once accepted, the manufacturer can execute those changes without a new 510(k) submission — as long as the changes fit inside the PCCP envelope.

The framework was finalized in December 2024, updated in guidance released through 2026, and is a direct answer to the previous decade's tension: AI models get updated frequently, but the traditional device-change framework required a new submission for any significant modification, effectively freezing many cleared products. A PCCP is not a blank check — the plan itself is scrutinized during review, and updates outside the envelope still require re-submission — but it is a meaningful improvement for post-market model lifecycle management. Expect PCCP references to become standard boilerplate on new AI-enabled device clearances through 2027.

A 510(k) is the FDA pathway for demonstrating that a new medical device is "substantially equivalent" to a legally marketed predicate device with the same intended use and technological characteristics. The vast majority of AI/ML-enabled medical devices — imaging triage, computer-assisted detection, quantification tools — come to market via 510(k). It is faster than the De Novo or PMA pathways (roughly 3–6 months when the submission is clean) but the resulting authorization is constrained to claims the predicate could plausibly support.

For AI products, the 510(k) submission includes performance data (usually retrospective test-set evaluation), device-description material, and — increasingly — a PCCP describing intended post-market changes. When Google Health or Aidoc or Viz.ai ships a new imaging AI product in the U.S., "we filed a 510(k)" and "we received 510(k) clearance" are the two milestones you will hear referenced.

The De Novo pathway is used for novel low-to-moderate-risk devices that have no valid predicate for a 510(k) submission. It is slower and more evidence-intensive than 510(k), but a granted De Novo creates a new device classification that subsequent products can chase as their predicate. IDx-DR — the first FDA-authorized autonomous AI diagnostic (diabetic retinopathy screening in primary-care settings) — was a landmark De Novo. As of 2026, a growing number of ambient AI scribes and patient-facing clinical LLM products are pursuing De Novo classifications because the intended-use language does not fit cleanly into existing predicates.

Premarket Approval is the FDA's highest-tier device pathway, used for Class III devices — those that sustain or support life, are of substantial importance in preventing impairment of human health, or present a potentially unreasonable risk of illness or injury. PMA requires prospective clinical evidence at a level that most AI/ML-enabled products cannot generate economically. It is rare in the AI-in-healthcare space: most AI products are cleared via 510(k) or De Novo. When you see "PMA" attached to an AI-enabled device, it usually means the device is combined with a physical Class III component (an implanted device, an interventional platform).

Computer-Assisted Detection describes AI (or classical machine-vision) tools that mark or flag findings on a medical image for a clinician to review. A CADe system for mammography marks candidate lesions; a CADe system for chest X-ray marks candidate nodules; a CADe system for colonoscopy marks candidate polyps. The clinician still makes the diagnostic call.

The CADe category has the longest evidence trail in medical imaging AI, going back well before the current deep-learning era. In 2026, colonoscopy CADe systems (endoscopy AI) and chest-X-ray CADe systems have effectively become standard-of-care in many settings; mammography CADe has a more contested evidence base owing to the mixed record of the previous generation of tools.

Computer-Assisted Triage describes AI tools that re-order a clinical worklist — moving the likely-emergency case to the top so a radiologist or ED physician sees it first. The classic CADt use case is large-vessel-occlusion detection on head CT (Viz.ai's original product); more recent CADt clearances cover pulmonary embolism, aortic dissection, intracranial hemorrhage, and pneumothorax. CADt does not make a diagnostic claim — it re-orders queues based on model output. But because the tool influences what the clinician looks at first, the FDA has treated CADt as a distinct device class with its own scrutiny of triage-performance metrics.

RUAIH — Responsible Use of Artificial Intelligence in Healthcare — is the Joint Commission's voluntary certification program for hospitals and health systems that operate AI in clinical or operational settings. The certification requires demonstrated governance, use-case intake, monitoring, and post-deployment surveillance processes. Since its launch, RUAIH has become a de-facto governance standard even for health systems that do not formally certify — the framework is used internally by CMIO and quality teams to structure AI oversight.

For AI vendors, "our tool is compatible with RUAIH-certified deployments" has become a procurement-relevant claim. For clinicians, it is a signal that a health system has (at minimum) thought through the governance layer around the tool.

A Business Associate Agreement is a contract under HIPAA between a covered entity (usually a health provider or health plan) and a business associate — a third party that will handle protected health information on the covered entity's behalf. For AI vendors, the presence of a BAA is table stakes for any deployment involving PHI. The BAA governs how the vendor may use and disclose PHI, what safeguards must be in place, what breach-notification obligations apply, and what happens on contract termination.

In the LLM era, BAA coverage has become a category-defining feature: does the vendor offer PHI-safe access to the underlying foundation model (through a BAA-covered API, an on-premises deployment, or a dedicated instance)? For OpenAI, Anthropic, Google, and Microsoft Azure, BAA-covered deployment options exist but are typically separately contracted from consumer APIs. Any deployment that runs PHI through a non-BAA-covered API is out of policy at every well-governed health system.

The Health Information Technology for Economic and Clinical Health (HITECH) Act, enacted in 2009 as part of the American Recovery and Reinvestment Act, drove the U.S. transition to electronic health records through Meaningful Use incentives and later penalties. HITECH also strengthened HIPAA's enforcement regime — increasing penalties, extending direct liability to business associates, and creating the breach-notification framework that governs how PHI incidents (including AI-related ones) are reported today.

HITECH is why nearly every U.S. hospital runs an EHR, and by extension, why healthcare AI has an EHR-integration story at all. Most modern AI-in-healthcare deployment realities — Epic and Oracle Health dominance, SMART-on-FHIR interop, patient-portal messaging as an AI use case — trace back through HITECH.

The 21st Century Cures Act, enacted in 2016, included a provision that carved out certain clinical decision support (CDS) software from FDA device regulation — provided the physician is able to independently review the basis for the software's recommendation and not rely primarily on it. That "independent review" clause has done a lot of work in the AI/CDS space: many LLM-based decision-support tools have relied on it to avoid device classification, and the FDA has been steadily narrowing what counts as "independent review" in practice.

FDA guidance released through 2022–2026 has clarified that surfacing model outputs without transparent reasoning, or presenting an AI recommendation in a way that materially crowds out physician deliberation, does not qualify — pushing such tools into the SaMD category. Expect the boundary to keep shifting as more clinical LLMs come to market.

A foundation model is a large model — typically a neural network with billions of parameters — trained on broad data at scale and adaptable to many downstream tasks with fine-tuning, prompting, or retrieval augmentation. In healthcare, foundation models show up in two flavors: general-purpose LLMs (GPT-4/5, Claude, Gemini, Llama) applied to clinical tasks, and healthcare-specific foundation models (Google's Med-PaLM series, Microsoft/Mayo's clinical foundation model, Epic-trained models). The distinction matters for evidence, governance, and BAA coverage: a general LLM applied to a clinical task inherits both the strengths and the failure modes of its general training corpus, while a healthcare-specific model has narrower knowledge but potentially better clinical alignment.

An ambient scribe is an AI system that listens to a clinical encounter — through the clinician's phone, a wearable, or a room microphone — and generates a draft visit note that the clinician reviews, edits, and signs. The category exploded post-2023 as LLMs became reliable enough for the summarization task and BAA-covered deployment options became available. See the Ambient AI Scribes topic for the state of the market, evidence base, and deployment considerations.

FHIR is HL7's modern standard for exchanging healthcare data. It defines resources (Patient, Observation, Encounter, Condition, MedicationRequest, and many more) as JSON or XML documents with a REST-style API. FHIR is the plumbing for SMART-on-FHIR apps, patient-facing APIs mandated by CMS interoperability rules, and most modern EHR-to-third-party integrations. For AI-in-healthcare deployment, FHIR is often the substrate for reading patient data into a model and writing recommendations back — either as a discrete observation, a task, or a communication resource. The USCDI defines the specific data elements CMS-regulated payers and providers must expose via FHIR.

USCDI is the ONC-defined standardized set of health-data classes and elements that certified health IT must be able to exchange. It is updated on a roughly annual cadence and each new version raises the interoperability floor across the U.S. health-IT ecosystem. USCDI matters to AI-in-healthcare because it defines the minimum data payload an AI vendor can rely on across every certified EHR — a much better starting point than negotiating a bespoke data-feed with every deployment.

Prior Authorization AI covers the AI systems on both sides of the prior-authorization transaction: payer-side systems that receive PA requests and make (or recommend) coverage decisions, and provider-side systems that assemble, submit, and appeal PA requests on behalf of hospitals and clinics. The category has been at the center of the U.S. regulatory response to healthcare AI since 2023, with CMS's Interoperability and Prior Authorization Final Rule reshaping the operational envelope and multiple state laws restricting fully-automated denials. See the Payer AI topic for context on where the market is going.

LLM guardrails are the layers of engineering — retrieval grounding, prompt engineering, output filtering, refusal behavior, human-in-the-loop checkpoints, hallucination detection — that sit around a large language model to constrain what it can say and do in a clinical or patient-facing context. In healthcare AI, guardrails are usually the most important engineering artifact: the underlying model may be a general-purpose foundation model, but the guardrails are what make a specific deployment safe for clinical or patient use. Evaluating a clinical LLM without evaluating its guardrails is a category error; most safety incidents trace to guardrail failure, not raw model failure.

Retrieval-Augmented Generation is an architectural pattern in which an LLM answers a question by first retrieving relevant documents from a curated knowledge base and then generating its response conditioned on those documents. In clinical settings, RAG is the dominant architecture for keeping LLM responses grounded in institutional guidelines, up-to-date evidence, or patient-specific data pulled from the EHR via FHIR. Well-implemented RAG systems can cite the specific passage they used, which is a substantial improvement over "the model just knows"; poorly-implemented RAG systems inherit the hallucination risk of the underlying model with false grounding. Guardrails matter here as much as anywhere.

A model card is a structured document describing an AI/ML model's intended use, training data, evaluation methodology, performance characteristics (usually stratified by demographic subgroup), limitations, and known failure modes. The FDA increasingly asks for model-card-style content in device submissions; health systems ask for it in AI procurement due diligence; and the Joint Commission's RUAIH framework treats availability of a meaningful model card as a governance signal.

The concept originated in the fairness-in-ML research community (Mitchell et al. 2019) and has become a de-facto expectation in healthcare AI. A "we can't share that" response to a model-card request is, in 2026, a serious procurement red flag.

Protected Health Information is the HIPAA-defined category of individually identifiable health information held or transmitted by a covered entity or business associate. In the AI context, PHI is what the BAA governs the handling of: it is why "does this LLM API contract cover PHI?" is a hard-blocking procurement question at every well-governed health system, and it is why most enterprise AI deployments carve out a PHI-safe path (BAA-covered API, dedicated instance, on-premises deployment) separate from any experimental use of consumer AI tools.

Explainability in clinical AI is the collection of techniques and design choices that make a model's output comprehensible to the clinician using it. In imaging AI, explainability often shows up as a heatmap or bounding box highlighting the regions of the image the model relied on. In LLM-based decision support, explainability means citing the specific source documents the model used, or (in more advanced systems) producing a stepwise reasoning trace.

The regulatory and clinical stakes are high: the 21st Century Cures Act CDS exclusion hinges on whether the physician can "independently review" the basis for the recommendation, and explainability is the mechanism that makes that possible. In practice, explainability is a governance requirement, not a "nice to have."

Model drift refers to degradation in a deployed model's performance over time — either because the underlying patient population shifts (dataset shift), because the practice patterns of the users shift, because upstream data sources change format, or because the model itself is updated in ways that alter its behavior. In healthcare AI, drift detection is one of the pillars of post-deployment surveillance. Mature governance programs monitor pre-specified performance metrics against a threshold, page a designated owner if the model drifts outside that envelope, and have sunset criteria for pulling a tool that drifts persistently. PCCP-covered updates and drift response are increasingly intertwined.