# When Your AI Becomes a Medical Device: FDA and SaMD

> Healthcare · AI Course · MED-7
> Source: https://ibl.ai/solutions/medical-healthcare/course/fda-samd-when-ai-becomes-a-device
> Last updated: 2026-08-25

**The regulatory boundary between clinical software and a regulated device — the CDS exemption, SaMD classification, and what changes when a model updates.**

## The Short Answer

**Whether clinical AI is a regulated medical device turns on the CDS exemption's four criteria, and generative systems complicate the analysis. With ibl.ai you own all the code and the data, so an internally developed tool stays under institutional control and its predetermined change management is yours to define rather than a vendor's.**

On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing — so you can deploy anywhere, from your own cloud to a fully air-gapped network.

[Request Access](https://ibl.ai/contact) · [Explore Healthcare](https://ibl.ai/solutions/medical-healthcare)

## Course facts

- **Level:** Advanced
- **Duration:** 5.5 hours across 8 modules
- **Format:** Cohort workshop with classification labs
- **Modules:** 8
- **Catalog code:** MED-7
- **Frameworks covered:** FDA SaMD framework, 21 CFR Part 11, Quality System Regulation, IMDRF

## What is this course about?

Whether your clinical AI is a regulated device determines an enormous amount of downstream obligation, and the analysis is genuinely difficult for generative systems. This course covers SaMD classification, the four criteria of the clinical decision support exemption, predetermined change control for updating models, and institutional exemptions for internally developed tools.

## Who is this course for?

- Regulatory affairs staff in health systems and digital health
- Clinical informatics leaders building internal tools
- Quality and compliance officers
- Counsel supporting clinical technology

### What do I need before starting?

- Familiarity with clinical software development or deployment
- Regulatory context helpful but not required

## What will I be able to do afterwards?

- Classify clinical software under the SaMD framework
- Apply the four criteria of the clinical decision support exemption
- Explain why generative AI complicates the exemption analysis
- Design a predetermined change control plan for an updating model
- Assess whether an institutional exemption applies

## What does each module cover?

### Module 1 — How is software classified as a medical device?

The SaMD framework and the risk categorization that follows classification. _(45 min)_

**Objectives**

- Apply the SaMD classification framework
- Determine risk categorization
- Understand the obligations each category carries

**Topics:** SaMD framework · Risk categorization · Obligation tiers · International harmonization

**Activity:** Classify three clinical software examples under the SaMD framework.

### Module 2 — What are the four criteria of the CDS exemption?

The exemption's criteria and how each must be satisfied. _(55 min)_

**Objectives**

- State the four criteria precisely
- Apply each to a real system
- Identify which criterion typically fails

**Topics:** Four criteria · Criterion application · Common failures · Documentation

**Activity:** Apply all four criteria to a real clinical AI system and document the analysis.

### Module 3 — Why does generative AI complicate the exemption?

The criterion requiring the clinician to independently review the basis, and why generation strains it. _(50 min)_

**Objectives**

- Explain the independent review criterion
- Assess whether generative output satisfies it
- Design toward satisfying the criterion

**Topics:** Independent review criterion · Basis transparency · Generative complications · Design implications

**Activity:** Assess whether a generative system satisfies the independent review criterion.

### Module 4 — How do you handle a model that updates?

Predetermined change control plans for AI that changes after clearance. _(50 min)_

**Objectives**

- Design a predetermined change control plan
- Specify the modifications it covers
- Define what falls outside and requires new submission

**Topics:** Change control plans · Covered modifications · Out-of-scope changes · Resubmission triggers

**Activity:** Draft a change control plan specifying covered and uncovered modifications.

### Module 5 — What clinical evaluation is required?

Clinical evaluation and real-world performance monitoring obligations. _(45 min)_

**Objectives**

- Determine clinical evaluation requirements
- Design real-world performance monitoring
- Handle performance degradation

**Topics:** Clinical evaluation · Real-world performance · Monitoring obligations · Degradation response

**Activity:** Design the clinical evaluation and monitoring plan for one system.

### Module 6 — What if you are the manufacturer?

Quality system obligations when the institution develops the software itself. _(45 min)_

**Objectives**

- Identify manufacturer obligations
- Assess quality system requirements
- Estimate the compliance burden honestly

**Topics:** Manufacturer status · Quality system · Design controls · Burden estimation

**Activity:** Assess your organization's readiness for manufacturer obligations.

### Module 7 — Does an institutional exemption apply?

Internally developed tools used within the institution, and the limits of that position. _(40 min)_

**Objectives**

- Assess whether an institutional exemption applies
- Identify the limits of the position
- Document the determination

**Topics:** Institutional exemption · Position limits · Distribution triggers · Documentation

**Activity:** Assess an internally developed tool for institutional exemption applicability.

### Module 8 — Producing the classification analysis

The workshop module: a documented classification analysis for one AI feature. _(50 min)_

**Objectives**

- Produce a complete classification analysis
- Document the reasoning defensibly
- Identify the follow-on obligations

**Topics:** Classification analysis · Reasoning documentation · Follow-on obligations · Counsel review

**Activity:** Complete the analysis and have counsel review it.

## What is the capstone project?

**Regulatory classification analysis for one AI feature.** Produce a complete classification analysis: SaMD categorization, the four-criteria CDS exemption analysis, an assessment of whether generative output satisfies independent review, a change control plan if applicable, and an institutional exemption determination — all reviewed by counsel.

_Deliverable:_ A documented classification analysis with counsel review and identified follow-on obligations.

## How are learners assessed?

- All four exemption criteria addressed individually with documented reasoning
- Change control plan must specify what falls outside its scope
- Analysis reviewed by regulatory counsel

## What ships with the course?

- **Facilitator guide.** Session-by-session running order, discussion prompts, and the questions that reliably derail a room.
- **Learner workbook.** Exercises, checklists, and the templates each module's activity produces.
- **Hands-on lab environment.** A sandboxed ibl.ai deployment so exercises run against real agents, not screenshots.
- **Assessment bank.** Scenario questions and rubric criteria mapped to each stated learning outcome.
- **Source bibliography.** Every primary regulation and standard cited on this page, linked and dated.

## Which AI agents does this course use?

- [Clinical Support Agent](https://ibl.ai/solutions/medical-healthcare/agent/clinical-support-agent)
- [Compliance Training Agent](https://ibl.ai/solutions/medical-healthcare/agent/compliance-training-agent)
- [Quality Improvement Agent](https://ibl.ai/solutions/medical-healthcare/agent/quality-improvement-agent)
- [Research Agent](https://ibl.ai/solutions/medical-healthcare/agent/research-agent)

## Where does the course material come from?

Every module is grounded in primary sources — the regulation, standard, or research itself, not a summary of it. Each was resolved at authoring time.

- [AI/ML in Software as a Medical Device](https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-and-machine-learning-software-medical-device) — FDA. The primary regulatory framework the course analyzes.
- [21 CFR Part 11 guidance](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application) — FDA. Electronic records requirements applying to regulated software.
- [HealthIT.gov](https://www.healthit.gov/) — ASTP/ONC. Certified health IT requirements intersecting with device classification.
- [Centers for Medicare and Medicaid Services](https://www.cms.gov/) — CMS. Coverage and payment implications of device classification.

## Delivery notes

Binding guidance for anyone preparing and delivering this course:

- This course frames regulatory analysis and does not provide regulatory advice. State that explicitly and require regulatory counsel review of any classification determination.
- Module 3's independent review criterion is the crux for generative systems and the analysis is genuinely unsettled. Present the reasoning rather than a conclusion.
- FDA guidance in this area evolves. Verify current guidance documents at each revision rather than citing a specific version.
- Module 6 should be honest about the burden. Institutions that become manufacturers take on quality system obligations most are not resourced for.
- Module 7's institutional exemption is frequently over-relied upon. Be clear about what triggers distribution and ends the position.

## Why run AI training on a platform you own?

- **You own the course, not a licence to it.** Course content, learner data, and the platform run inside your perimeter — you own all the code and the data.
- **Model-agnostic delivery.** Run the course's AI components on any LLM — Claude, GPT, Llama, Gemini, Command — and switch anytime.
- **No per-seat training licences.** Usage-based or self-hosted, so cost tracks actual use rather than headcount.
- **Deploy anywhere.** Cloud, private VPC, on-premise, or fully air-gapped — including for cohorts that cannot use public AI tools.

## Frequently asked questions

### What does the When Your AI Becomes a Medical Device: FDA and SaMD course cover?

Whether your clinical AI is a regulated device determines an enormous amount of downstream obligation, and the analysis is genuinely difficult for generative systems. This course covers SaMD classification, the four criteria of the clinical decision support exemption, predetermined change control for updating models, and institutional exemptions for internally developed tools. It runs 5.5 hours across 8 modules across 8 modules, at advanced level, and closes with a capstone: Regulatory classification analysis for one AI feature.

### Who should take When Your AI Becomes a Medical Device: FDA and SaMD?

It is written for Regulatory affairs staff in health systems and digital health, Clinical informatics leaders building internal tools, Quality and compliance officers, Counsel supporting clinical technology. Prerequisites: Familiarity with clinical software development or deployment; Regulatory context helpful but not required.

### Can we run this course on our own infrastructure?

Yes. ibl.ai is model-agnostic and deploy-anywhere — cloud, private VPC, on-premise, or fully air-gapped — and you own all the code and the data. Cohort data, submissions, and any material learners upload stay inside your perimeter, which matters for healthcare teams that cannot send work to a public AI tool.

### How do we get access to When Your AI Becomes a Medical Device: FDA and SaMD?

Request access and we will set it up for your cohort — hosted by ibl.ai, or running against your own deployment. Tell us the group size and timing you need, and whether it should run inside your own perimeter.

### How much does AI training for healthcare cost on ibl.ai?

There is no per-seat pricing — you pay for usage or self-host and pay only for the infrastructure, so a 5,000-person rollout does not cost 5,000 licences. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.

## More Healthcare courses

- [HIPAA-Compliant AI: PHI, BAAs, and Where the Data Lives](https://ibl.ai/solutions/medical-healthcare/course/hipaa-compliant-ai): What HIPAA actually requires of an AI deployment — the BAA analysis, Security Rule safeguards, minimum necessary, and the architecture that keeps PHI inside your boundary.
- [Clinical Documentation with AI: Ambient Notes and Review](https://ibl.ai/solutions/medical-healthcare/course/clinical-documentation-with-ai): Deploy ambient documentation safely — accuracy in clinical language, the attestation requirement, note bloat, and measuring whether it returns clinician time.
- [Medical Coding with AI: ICD-10, CPT, and Denial Prevention](https://ibl.ai/solutions/medical-healthcare/course/medical-coding-with-ai): AI-assisted coding that improves accuracy rather than just speed — code suggestion, documentation gap detection, denial prevention, and staying clear of upcoding.
- [Prior Authorization Automation with AI Agents](https://ibl.ai/solutions/medical-healthcare/course/prior-authorization-automation): Compress the highest-friction administrative process in healthcare — payer requirement lookup, packet assembly, status tracking, and appeal drafting.
- [Patient Education Agents: Health Literacy and Safety](https://ibl.ai/solutions/medical-healthcare/course/patient-education-agents): Patient-facing AI that explains conditions and discharge instructions safely — reading level, language access, scope boundaries, and symptom escalation.
- [AI in Clinical Decision Support: Evidence, Limits, and Liability](https://ibl.ai/solutions/medical-healthcare/course/ai-clinical-decision-support): Deploy clinical decision support responsibly — evidence grounding, automation bias, transparency obligations, and where liability actually lands.
