CCAIGS Exam Prep Guide

Key Concepts to Master

• The NIST AI RMF has four core functions: GOVERN, MAP, MEASURE, MANAGE. GOVERN is the overarching function that directs the other three.
• GOVERN establishes policies, roles, and a culture of risk management. It should be established FIRST when beginning an AI governance journey.
• MAP contextualizes the AI system — identifying intended use, context, stakeholders, and potential impacts.
• MEASURE analyzes, assesses, benchmarks, and monitors AI system performance, including bias, reliability, and drift.
• MANAGE allocates resources to identified risks, responds to incidents, and manages ongoing AI system lifecycle.
• Seven characteristics of trustworthy AI: Valid & Reliable, Safe, Secure & Resilient, Explainable & Interpretable, Privacy-Enhanced, Fair (with Harmful Bias Managed), Accountable & Transparent.
• The NIST AI RMF Playbook provides actionable steps for implementing each subcategory — the RMF is the framework, the Playbook makes it operational.
• "Telemetry" in the MEASURE function refers to automated collection and analysis of AI system performance data during operation, enabling drift detection.

Must-Know References

Common Pitfalls

• Confusing "Explainable and Interpretable" (users understanding outputs) with "Accountable and Transparent" (ability to monitor and control the system).
• Thinking MAP should come before GOVERN. GOVERN provides the foundation — policies, roles, and culture — that enables the other functions.
• Assuming "Scalable" is one of the seven trustworthy AI characteristics. It is NOT — memorize the seven.

Key Concepts to Master

• The HTI-1 Final Rule was issued by the ONC (Office of the National Coordinator for Health IT), NOT the FDA or HHS OCR.
• HTI-1 applies to AI/predictive algorithms that are part of ONC-certified Health IT (CEHRT). It does NOT cover all healthcare software.
• The transparency framework is called PDSI: Predictive Decision Support Intervention.
• The DEVELOPER of the certified health IT is responsible for making source attributes available — not the healthcare provider.
• Source attributes must be made available through a FHIR API (Fast Healthcare Interoperability Resources), enabling machine-readable access.
• Required source attribute categories: intended use/users, purpose, development & training data, validity & reliability measures, maintenance information, and fairness/equity efforts.
• HTI-1 and FDA regulation are complementary but distinct: PDSI applies to certified health IT; FDA regulates medical devices. Some systems may be subject to both.
• Providers are expected to REVIEW source attributes, make them available to clinical users, and establish workflow processes — NOT to independently re-validate algorithms.

Must-Know References

Common Pitfalls

• Confusing which agency issued HTI-1 (ONC, not FDA). The FDA regulates medical devices; ONC regulates certified health IT.
• Thinking providers must independently validate every algorithm. Providers review and manage; developers disclose and make available.
• Assuming source attributes require releasing raw training data or proprietary source code. They require DESCRIPTIONS, not raw data.

Key Concepts to Master

• A comprehensive inventory includes ALL AI systems: approved, pilot, AND shadow/unauthorized AI. Excluding shadow AI creates a critical blind spot.
• Shadow AI discovery requires multiple methods: network traffic analysis (API calls), endpoint scanning (installed tools), and staff surveys (browser-based usage). No single method is sufficient.
• The five-factor risk model: Data Sensitivity, Decision Impact, Human Oversight, Scale of Deployment, and Reversibility of decisions.
• Human-in-the-loop (a human reviews AI outputs before action) significantly reduces risk tier compared to autonomous systems.
• Risk-based prioritization: focus governance effort on high and critical risk systems first. Lower-risk systems get lighter controls.
• Inventory should be reviewed at least quarterly, with continuous updates when new tools are deployed or discovered.
• Each inventory entry should document: vendor, data types, department, intended use, authorization status, and risk tier.
• A clinical AI inventory captures AI-specific metadata (model type, training data description, intended clinical use) that general IT asset inventories do not include.

Must-Know References

Common Pitfalls

• Assuming only FDA-approved medical devices need to be inventoried. Shadow AI is often the biggest risk.
• Blanket-blocking shadow AI without assessment. This drives usage further underground rather than solving the governance gap.
• Treating a clinical AI inventory the same as a general IT asset inventory. AI-specific metadata (model type, training data, bias status) is essential.

Key Concepts to Master

• PHI can be shared with an AI vendor ONLY when a Business Associate Agreement (BAA) is signed and the disclosure is permitted under the HIPAA Privacy Rule.
• Required BAA elements: permitted uses/disclosures, safeguards, breach reporting, and termination provisions. The vendor’s marketing budget is NOT required.
• De-identification methods: Safe Harbor (removal of 18 categories of identifiers) and Expert Determination (statistician certifies "very small" re-identification risk).
• Minimum Necessary standard: AI systems should access only the data fields needed for their function, not entire patient records.
• HIPAA Security Rule Technical Safeguards require encryption of ePHI at rest and in transit (addressable, but standard expectation).
• Breach Notification Rule: notify affected individuals within 60 days of discovery. 500+ individuals also requires HHS notification within 60 days.
• Business associates must notify the covered entity without unreasonable delay and no later than 60 days after discovering a breach.
• AI models may memorize training data, creating PHI leakage risk through model outputs (model inversion / data extraction attacks).
• A DPIA for clinical AI should document: data flows, PHI types, retention periods, access controls, and privacy risks.

Must-Know References

Common Pitfalls

• Assuming any use of PHI for AI training is automatically permitted. De-identification or authorization is required.
• Thinking the 60-day breach notification clock starts when the breach occurred. It starts when the breach is DISCOVERED.
• Confusing covered entities with business associates. AI vendors are business associates, not covered entities.

Key Concepts to Master

• Demographic parity: equal positive outcome rates across groups. Does NOT account for base rate differences.
• Equalized odds: equal true positive rate AND false positive rate across groups. Stricter than demographic parity.
• Selection bias: training data does not represent the target population (e.g., trained on male patients, deployed on all patients).
• Label bias: labels in training data reflect historical biases in human judgment (e.g., underdiagnosis in certain populations).
• Concept drift: the relationship between inputs and outcomes changes over time, causing performance degradation even though code hasn’t changed.
• Statistical fairness (equal metrics across groups) vs. clinical fairness (clinically appropriate outcomes accounting for group-specific factors). A model can be statistically fair but clinically unfair.
• Intersectionality: bias at the intersection of multiple dimensions (e.g., race AND sex) that is invisible when evaluating dimensions separately.
• FDA SaMD framework requires a Predetermined Change Control Plan (PCCP) for AI/ML-based medical devices, describing anticipated modifications and evaluation methods.
• Pre-deployment fairness audit: stratify model performance by all relevant demographic groups — not just aggregate accuracy.

Must-Know References

Common Pitfalls

• Deploying a model with high overall accuracy but known group-level disparities. Aggregate accuracy is insufficient.
• Assuming a model that was fair at deployment remains fair after retraining. New data can introduce new bias.
• Evaluating only one demographic dimension. Bias is multi-dimensional and intersectional.

Key Concepts to Master

• AI-specific IRPs must address AI-unique scenarios: model failure, biased outputs, data poisoning, training data leakage, and model drift — beyond traditional cyber incidents.
• Model drift from distribution shift: the real-world population changes, causing the model’s assumptions to no longer hold. This is an AI-specific incident type.
• A HIPAA breach requires: impermissible use/disclosure of unsecured PHI + risk assessment determining exposure is NOT low probability. Not all incidents qualify as breaches.
• AI incident response steps: detection & triage, containment (disable model), investigation, notification (if PHI involved), post-incident review with corrective action.
• The "black-box problem": AI models may produce incorrect outputs for reasons difficult to explain without specialized investigation and vendor involvement.
• Tabletop exercise: a simulated incident scenario where team members discuss (not execute) their roles to test the IRP.
• Model inversion attacks: querying a deployed model strategically to extract training data (potentially PHI). AI-specific threat not in traditional cybersecurity frameworks.
• Model retirement requires: updating the AI inventory, recording in lessons learned, handling data per retention policies, and notifying clinical users.

Must-Know References

Common Pitfalls

• Using a general IT/cyber IRP for AI incidents. AI-specific scenarios (drift, bias, data extraction) are not covered.
• Deleting a retired model without documentation. This creates governance gaps and loses lessons learned.
• Assuming all AI incidents are HIPAA breaches. A risk assessment is required to determine if the exposure meets the breach definition.

Key Concepts to Master

• Effective committee structure: cross-functional representation from clinical, IT, legal/compliance, privacy, ethics, and patient advocacy — with a defined charter and decision-making authority.
• A governance charter defines: scope, authority, membership, decision rights, meeting cadence, and reporting obligations. Without a charter, the committee lacks formal authority.
• Meeting cadence: monthly or quarterly (depending on AI deployment volume) with emergency session capability for incident response.
• Patient advocacy representatives are often overlooked but critical for ensuring governance decisions consider patient interests (NIST GOVERN-4.1: diverse perspectives).
• AI Risk Officer: designated lead responsible for AI governance, with documented authority, inventory oversight, and leadership reporting.
• Decision rights: documented allocation of authority — who can approve, reject, or escalate different categories of AI deployments (e.g., committee approves low-risk, AI Risk Officer approves medium-risk, leadership approves high-risk).
• Effective staff communication: concise guidance integrated into clinical workflows, not 200-page policy documents.
• External stakeholder engagement should be proactive (patient advisory boards, accessible information), not reactive (after an incident).

Must-Know References

Common Pitfalls

• Having a single IT director make all AI governance decisions. Diverse perspectives are essential.
• Creating a committee without a charter. Without documented authority, the committee can only advise, not act.
• Only engaging external stakeholders after a major incident. Proactive engagement builds trust.

Key Concepts to Master

• Duty of care to patients transcends organizational hierarchy. Specialists must document concerns, escalate through governance channels, and consider regulatory reporting as a last resort.
• Conflicts of interest (e.g., financial interest in an AI vendor being evaluated) must be disclosed and the specialist must recuse themselves from related decisions.
• Continuing professional development: specialists must maintain current knowledge of evolving AI regulations and best practices through ongoing education and recertification.
• The CCAIGS code of conduct requires: duty of care, conflict disclosure, continuing professional development, and patient-centered decision-making.

Must-Know References

Common Pitfalls

• Following leadership decisions without question when patient safety is at risk. The specialist has a duty of care.
• Immediately resigning without raising the concern through proper channels.
• Assuming personal preferences for technologies constitute conflicts of interest. Only financial or material interests qualify.