What is this course about?
Clinical decision support sits closest to patient harm and carries the least settled liability. This course covers evidence grounding and citation to primary literature, automation bias as the central risk, algorithm transparency obligations, performance across patient populations, and local validation before deployment.
Who is this course for?
- Chief medical informatics officers
- Clinical decision support committees
- Physician and nursing leadership
- Quality and patient safety officers
What do I need before starting?
- Clinical background or clinical informatics experience
- Familiarity with your CDS governance
What will I be able to do afterwards?
- Distinguish clinical decision support from a regulated device
- Ground recommendations in primary literature with citation
- Recognize and mitigate automation bias
- Assess performance across patient populations
- Design local validation before any clinical deployment
What does each module cover?
What is clinical decision support, and where is the regulatory line?
45 minThe boundary between decision support and a regulated medical device.
Objectives
- Define clinical decision support
- Identify the regulatory boundary
- Classify your intended use
Topics
Activity. Classify three intended CDS uses against the regulatory boundary.
How do you ground in primary literature?
50 minEvidence grounding with citation, so a clinician can check the basis for a recommendation.
Objectives
- Ground recommendations in primary literature
- Cite so clinicians can verify
- Handle areas where evidence is weak or conflicting
Topics
Activity. Ground a recommendation set in primary literature with verifiable citations.
What is automation bias and why is it the central risk?
50 minThe tendency to defer to a recommendation, which grows as the system becomes more reliable.
Objectives
- Explain automation bias mechanically
- Recognize it in clinical workflows
- Design interfaces that preserve clinical scrutiny
Topics
Activity. Design an interface intervention aimed at preserving clinical scrutiny.
What must you disclose about the algorithm?
45 minTransparency obligations to clinicians and the information they need to judge a recommendation.
Objectives
- Determine transparency obligations
- Provide clinicians the information they need
- Handle vendor confidentiality claims
Topics
Activity. Assess whether your clinicians have the information needed to judge a CDS recommendation.
Does it perform equally across your patients?
55 minPerformance assessment across demographic and clinical subgroups.
Objectives
- Assess performance across patient subgroups
- Identify subgroups where performance degrades
- Determine whether degradation is acceptable
Topics
Activity. Assess performance across subgroups in your own patient population.
Where does liability land?
45 minLiability allocation between clinician, institution, and vendor, which is genuinely unsettled.
Objectives
- Map liability exposure across parties
- Identify where the law is unsettled
- Manage exposure through documentation and consent
Topics
Activity. Map liability exposure for one CDS deployment with counsel.
Why must you validate locally?
50 minLocal validation before deployment, because vendor performance figures do not transfer.
Objectives
- Design local validation
- Compare local against vendor-reported performance
- Set deployment criteria
Topics
Activity. Design a local validation protocol with explicit deployment criteria.
Building the validation protocol
50 minThe workshop module: a complete validation protocol for one CDS use case.
Objectives
- Produce a complete validation protocol
- Include subgroup analysis
- Define stopping criteria
Topics
Activity. Complete the protocol and present it to a CDS committee for approval.
What is the capstone project?
Local validation protocol for one CDS use case
Produce a complete CDS validation protocol: regulatory classification, evidence grounding with citations, an automation bias mitigation design, transparency assessment, subgroup performance analysis on your own population, liability mapping with counsel, and explicit deployment and stopping criteria.
Deliverable: A validation protocol approved by a clinical decision support committee.
How are learners assessed?
- Subgroup analysis conducted on the organization's own patient population
- Protocol must include stopping criteria that could halt deployment
- Liability mapping reviewed by 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?
The hands-on modules run against agents already deployable on the ibl.ai platform for healthcare.
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.
- HealthIT.gov
ASTP/ONC
Algorithm transparency requirements for certified health IT.
- AI/ML in Software as a Medical Device
FDA
The regulatory boundary analyzed in Module 1.
- Augmented Intelligence in Medicine
American Medical Association
Physician guidance on CDS use and professional responsibility.
- Agency for Healthcare Research and Quality
AHRQ
Patient safety and evidence methodology for the validation design.
Delivery notes
Binding guidance for anyone preparing and delivering this course.
- Module 3's automation bias is the safety core. The paradox — that a more reliable system produces more dangerous deference — is counterintuitive and must be demonstrated, not asserted.
- Module 5's subgroup analysis must use the organization's own population. Published performance figures from a different population are the standard failure in CDS deployment.
- Module 6 must state that liability allocation is unsettled. Any confident answer here is wrong and would mislead institutions making real decisions.
- Have both clinical leadership and counsel review the course. The regulatory and liability content is consequential and should not be written by informaticists alone.
- Module 8's stopping criteria must be capable of halting a deployment leadership wants. A protocol that cannot say no is a formality.
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 AI in Clinical Decision Support: Evidence, Limits, and Liability course cover?
Clinical decision support sits closest to patient harm and carries the least settled liability. This course covers evidence grounding and citation to primary literature, automation bias as the central risk, algorithm transparency obligations, performance across patient populations, and local validation before deployment. It runs 6 hours across 8 modules across 8 modules, at advanced level, and closes with a capstone: Local validation protocol for one CDS use case.
Who should take AI in Clinical Decision Support: Evidence, Limits, and Liability?
It is written for Chief medical informatics officers, Clinical decision support committees, Physician and nursing leadership, Quality and patient safety officers. Prerequisites: Clinical background or clinical informatics experience; Familiarity with your CDS governance.
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 AI in Clinical Decision Support: Evidence, Limits, and Liability?
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.