--- name: managing-predictive-analytics-clinical language: en description: Evaluates and deploys clinical predictive models with validation, bias assessment, and monitoring. Use when evaluating prediction models, assessing algorithmic bias, or deploying clinical ML. tags: - management - health-informatics - clinical metadata: author: casemark practice_areas: - Health Informatics - Health IT - Clinical Informatics document_types: - Management Report skill_modes: - Management - Coordination --- # Managing Predictive Analytics Clinical Evaluates and deploys clinical predictive models with validation, bias assessment, calibration monitoring, and clinical workflow integration. This skill covers the lifecycle from model evaluation through production surveillance for predictive tools used in patient care, covering both proprietary vendor models and locally developed algorithms. ## Why This Skill Exists Predictive analytics in healthcare ranges from well-validated tools (LACE for readmission, APACHE for ICU mortality) to proprietary "black box" models embedded in EHR systems. High-profile failures --- notably the Optum algorithm that systematically underestimated illness severity for Black patients --- demonstrate that deploying predictive models without rigorous validation, bias assessment, and ongoing monitoring creates patient safety risks and health equity harms. This skill provides a structured approach to evaluating, deploying, and monitoring clinical predictive models that protects patients while enabling beneficial use of analytics. The regulatory landscape for clinical predictive models is evolving rapidly. The FDA's Predetermined Change Control Plan framework, the Blueprint for an AI Bill of Rights, state algorithmic transparency laws, and CMS requirements for AI disclosure in Medicare Advantage are creating new obligations. Organizations deploying predictive models must navigate both patient safety and regulatory compliance simultaneously. --- ## Checkpoint A --- Intake & Scoping Answer every question before proceeding. Mark unknowns with [VERIFY]. 1. **Model description** --- What does the model predict? (30-day readmission, sepsis onset, clinical deterioration, no-show probability, length of stay, mortality risk) 2. **Model provenance** --- Who developed the model? (EHR vendor embedded, academic publication, internal data science team, third-party analytics vendor) 3. **Intended use** --- How will predictions be used in clinical workflow? (CDS alert, risk score on patient list, care management triage, resource planning) 4. **Training data** --- What data was the model trained on? (Institution, time period, patient population, sample size, outcome prevalence) 5. **Model type** --- What is the model architecture? (Logistic regression, gradient boosting, neural network, proprietary/undisclosed) 6. **Regulatory classification** --- Does the model meet FDA Software as a Medical Device (SaMD) criteria? Is it marketed as a clinical decision support tool under the 21st Century Cures Act CDS exclusion criteria? 7. **Current deployment status** --- Is this a new model evaluation, a model already in production, or a model being considered for procurement? ### Required Documents - Model documentation (development methodology, features, training data description, performance metrics) - Vendor model card or algorithm specification sheet (if proprietary) - Local validation dataset description (patient population, time period, outcome prevalence) - Intended clinical workflow integration design - FDA SaMD classification assessment (if applicable) - Institutional AI/ML governance policy --- ## Step 1 --- Evaluate Model Performance Validate the model on local institutional data: - **Local validation dataset** --- Assemble a dataset from your institution's data that mirrors the intended deployment population. Minimum 1,000 patients or 100 outcome events (whichever is larger) for statistical stability - **Discrimination metrics** --- Calculate: AUROC (target > 0.70 for useful discrimination), AUPRC (essential when outcome prevalence is < 10%), sensitivity and specificity at the proposed operating threshold, positive predictive value (PPV) at the operating threshold - **Calibration assessment** --- Generate calibration plots (predicted probability vs. observed outcome rate in deciles). A model that predicts 30% risk should have approximately 30% observed event rate in that risk group. Calculate Hosmer-Lemeshow goodness-of-fit and Expected Calibration Error (ECE) - **Temporal validation** --- Test on data from a more recent time period than the training data. Models trained on 2019-2021 data may perform differently on 2023-2024 data due to practice changes, COVID impact, and population shifts - **Comparison to existing tools** --- Benchmark against the current clinical risk assessment (even if it is informal clinician judgment). A model that does not improve on existing practice does not justify the implementation cost - **Fairness metrics selection** --- Choose appropriate fairness metrics based on the clinical context: demographic parity (equal positive prediction rates across groups), equalized odds (equal true positive and false positive rates), predictive parity (equal PPV across groups), or individual fairness (similar patients receive similar predictions regardless of group membership). No single fairness metric is universally appropriate; the choice depends on the clinical use case and its equity implications --- ## Step 2 --- Assess Algorithmic Bias Evaluate model fairness across protected subgroups: - **Subgroup performance** --- Calculate discrimination (AUROC) and calibration metrics separately for: race/ethnicity groups, sex, age groups, insurance type, primary language, and disability status. Performance should not vary substantially across subgroups - **Error rate parity** --- Compare false positive rates and false negative rates across subgroups. A model with higher false negative rates for Black patients systematically under-identifies risk in that population - **Feature audit** --- Examine model features for proxy discrimination: zip code as a proxy for race, insurance type as a proxy for socioeconomic status, prior utilization as a proxy for access. The Optum model failed because it used healthcare cost as a proxy for health need, disadvantaging patients with less access to care - **Outcome definition audit** --- Verify that the outcome variable itself is not biased. "Readmission" may reflect discharge practice variation rather than patient acuity. "No-show" may reflect transportation barriers rather than patient engagement - **Health equity impact assessment** --- Document how model deployment would differentially affect care delivery across subgroups. If the model drives care management resource allocation, would it disproportionately exclude disadvantaged populations? --- ## Step 3 --- Design Clinical Integration Specify how predictions enter clinical workflow: - **Alert design** --- Define the presentation: interruptive alert (only for high-confidence, actionable predictions), passive risk score display (on patient list, rounding report), or background triage (risk-sorted worklist for care managers) - **Threshold selection** --- Choose the operating threshold based on the clinical consequence asymmetry. For sepsis prediction: lower threshold (higher sensitivity) because missing sepsis is more harmful than investigating false alarms. For elective surgery risk: higher threshold (higher specificity) because acting on false positives means canceling needed procedures - **Actionable response** --- Define what clinicians should do with the prediction. A risk score without a response protocol is a distraction, not decision support. Specify: what assessment to perform, what intervention to consider, what to document, when to escalate - **Override and feedback** --- Allow clinicians to document disagreement with the prediction and the clinical reasoning. Capture this data for model refinement - **Display requirements** --- Show the model name, version, key contributing factors (if interpretable), and confidence level. Never display a risk score without context about what it means and what to do about it - **Human factors design** --- Apply human factors engineering principles to prediction display: minimize information overload (display only when actionable), use calibrated language ("elevated risk" vs. specific probability depending on clinical context), avoid anchoring bias (present prediction after initial clinical assessment, not before), and design for appropriate trust calibration (neither over-trust nor under-trust) --- ## Step 4 --- Address Regulatory and Governance Requirements Ensure compliance with applicable frameworks: - **FDA SaMD assessment** --- Apply the FDA's CDS guidance: does the model meet the Cures Act CDS exclusion criteria (intended for clinician use, does not replace clinical judgment, allows independent review of the basis for recommendations)? If not, it may require FDA premarket review - **Institutional review** --- Submit the model through the organization's AI/ML governance committee for review. Include: model documentation, validation results, bias assessment, intended use, and clinical workflow design - **Transparency requirements** --- Document the model sufficiently for external audit: development methodology, training data characteristics, feature list, performance metrics by subgroup, known limitations - **Informed consent** --- Determine whether patients should be informed that predictive analytics influence their care. At minimum, ensure clinicians understand when and how models are used in their workflow - **Vendor contract requirements** --- For proprietary models, negotiate contractual access to: model performance data, training data demographics, update notification, and validation data access for local testing --- ## Step 5 --- Deploy and Monitor Production deployment requires ongoing surveillance: - **Phased deployment** --- Deploy to a single unit or provider group first. Monitor for 4-6 weeks before broader rollout - **Performance monitoring** --- Track weekly: AUROC (or AUPRC for rare outcomes), calibration drift (are predicted probabilities still matching observed rates?), alert volume per provider per shift, clinician response rates (acceptance, override, ignore) - **Drift detection** --- Implement statistical tests for distribution shift in model inputs (feature drift) and outputs (prediction drift). Kolmogorov-Smirnov test or Population Stability Index (PSI) on monthly basis. Feature drift > 0.1 PSI triggers investigation - **Outcome feedback loop** --- When outcomes are observed (readmission occurred or did not), link back to the prediction for ongoing performance tracking. This creates the foundation for model retraining - **Retirement criteria** --- Define conditions for model deactivation: AUROC drops below 0.65, calibration ECE exceeds 0.10, bias assessment reveals new disparity, clinical workflow demonstrates no benefit from the prediction - **Retraining protocol** --- Define the retraining cadence (quarterly, biannually) and the retraining dataset requirements (minimum recency, minimum size, subgroup representation) - **Model lifecycle management** --- Establish a model lifecycle framework: development, validation, deployment, monitoring, retraining, and retirement. Each lifecycle stage has defined entry criteria, activities, and exit criteria. No model should persist in production indefinitely without periodic re-evaluation against current data and clinical practice --- ## Checkpoint B --- Deployment Readiness Review Before activating the model in production: - [ ] Local validation demonstrates discrimination and calibration meeting minimum thresholds - [ ] Bias assessment shows no clinically significant performance disparities across subgroups - [ ] Clinical workflow integration is designed with actionable response protocols - [ ] Operating threshold is selected with documented rationale - [ ] FDA SaMD assessment is completed (model is either excluded from FDA jurisdiction or has appropriate clearance) - [ ] Institutional AI/ML governance committee has approved deployment - [ ] Monitoring infrastructure is in place for performance tracking and drift detection - [ ] Clinician training on model use, limitations, and override procedures is completed - [ ] Fairness metrics are selected appropriate to the clinical context and measured for all subgroups - [ ] Human factors design principles are applied to the prediction display - [ ] Model lifecycle framework defines criteria for each stage from development through retirement --- ## Quality Audit - [ ] Model documentation meets minimum transparency standards (model card or equivalent) - [ ] Local validation uses data from the institution's patient population, not vendor-supplied benchmarks alone - [ ] Validation dataset has sufficient outcome events for stable metric estimates (minimum 100 events) - [ ] Bias assessment covers race, ethnicity, sex, age, and insurance type at minimum - [ ] Feature list has been reviewed for proxy discrimination risks - [ ] Clinical integration design follows the CDS Five Rights framework - [ ] Regulatory assessment (FDA SaMD, Cures Act CDS exclusion) is documented - [ ] Monitoring metrics and drift detection thresholds are defined before deployment - [ ] Retirement criteria are established with clear trigger conditions - [ ] Fairness metric selection is documented with rationale for the chosen metric(s) - [ ] Human factors assessment of prediction display has been conducted with end-user testing - [ ] Model lifecycle management framework is documented with stage-gate criteria - [ ] Ongoing monitoring infrastructure confirms continued model performance above retirement thresholds --- ## Guidelines - Never deploy a clinical predictive model without local validation. Vendor-reported performance metrics from development data do not transfer reliably to your institution's population - Calibration matters more than discrimination for clinical use. A model with perfect AUROC but poor calibration will assign wrong risk levels to patients, leading to incorrect resource allocation - Bias assessment is not optional and not a one-time activity. Population shifts, practice changes, and data pipeline modifications can introduce new disparities after initial validation - Treat proprietary "black box" models with heightened scrutiny. If the vendor cannot explain what features drive predictions, you cannot assess for proxy discrimination or clinical face validity - The biggest risk of clinical predictive models is not technical failure but automation bias: clinicians trusting the model more than their own clinical assessment. Design workflows that complement, not replace, clinical judgment - For models that influence resource allocation (care management, bed assignment, triage priority), bias assessment must specifically evaluate whether the model perpetuates existing access disparities - Document all model limitations prominently and communicate them to end users. A model trained on academic medical center data may not generalize to community hospitals - Monitor for "alert fatigue by prediction" --- if risk scores are displayed ubiquitously without actionable thresholds, clinicians will learn to ignore them, negating the investment - Every clinical predictive model should have a defined retirement date or retirement trigger. Models that persist in production without re-evaluation gradually degrade as patient populations, clinical practices, and data capture methods evolve. An abandoned model generating silent predictions is a latent safety hazard - Fairness in clinical prediction is not achieved by removing protected characteristics from the model. Proxy variables (zip code, insurance type, prior utilization) can perpetuate the same disparities. Fairness requires active measurement, not passive omission