Healthcare Analytics MVP
Readmission Intelligence Platform
Hospital intelligence, patient-model research evidence, and auditable model routing in one product.
Multi-source architectureEvidence separated by use case
Current product rule: CMS HRRP supports hospital-level analytics. The selected patient model is packaged for reproducible research inference, but public/clinical probability remains locked.
Condition profile
30-day readmission signal
Loaded from the traceable HRRP summary asset generated by the data pipeline.
Interpretation
Excess Readmission Ratio (ERR)
< 1.0Fewer readmissions than model-expected
≈ 1.0Near model-expected readmission level
> 1.0More readmissions than model-expected
Important: ERR is a risk-adjusted HRRP performance signal. It is not a complete hospital quality score and does not establish causation.
Python-generated analytics
Hospital Readmissions Dashboard
Every value in this view is derived by the repository's Python pipeline and rendered from a versioned JSON asset.
Geographic analysis
Mean ERR by state
Hover over a state to see its mean ERR, hospitals, and valid records.
State values summarize reportable hospital-condition records. Differences are descriptive and do not establish causation or complete hospital quality.
Data availability
ERR reporting coverage
Unavailable or suppressed values are never converted to zero.
Performance signal
ERR distribution
ERR above 1 indicates more readmissions than model-expected, not a complete hospital-quality verdict.
Multi-condition screen
Persistent hospital signals
Clinical conditions
Key findings
Interactive model research
Continue to the Patient Risk Simulator
Test the guarded 30-day readmission model with synthetic or de-identified encounter data.
Hospital-level analytics
Persistent readmission signals
Screen for facilities with consistent ERR patterns across at least five reported HRRP conditions.
Interactive demo
Hospital signal explorer
The three hospital examples are synthetic UI records and do not imply real facility performance.
Patient-level research layer
30-day readmission model evidence
The selected model is a research candidate. Metrics below are traceable to the final GitHub Actions benchmark artifact.
Operational burden
Confusion matrix
True Positive—
False Positive—
False Negative—
True Negative—
Loading alert-burden evidence…
Explainability
Top global risk drivers
Permutation importance reflects predictive contribution, not causation.
Model package
Reproducible inference bundle
Selected architectureHistGradientBoosting
Packaged pipelineCI GENERATED
Typed input manifestREADY
Clinical deploymentBLOCKED
CI packages the fitted preprocessing pipeline and model into a versioned joblib artifact and smoke-tests guarded inference.
Next validation gate
What must happen before patient probability is unlocked
Calibration by intended useSubgroup performanceAlert-capacity targetExternal validationGovernance approval
This is deliberately stricter than a demo-only AI score because the intended domain is healthcare.
Model orchestration
Risk Router
The router chooses the correct evidence layer instead of mixing incompatible datasets.
The router never substitutes a different model merely to return a number.
Trust layer
Data quality controls
Missing and suppressed values remain meaningful states rather than silently becoming zero.
Duplicate rows reported in source analysis.
“Too Few to Report” remains suppressed/not-reported.
Measure-specific valid subsets prevent false denominators.
Start/end dates are converted to datetime fields during preparation.
AI readiness
Registered model status
Each data source has a defined role and independent readiness state.
Hospital-level analytics engineREADY
Patient-level research candidateSELECTED / LOCKED
External validation on Dubai populationSANDBOX PHASE
Clinical deployment claimNOT CLAIMED
Required patient-model evidence
ROC-AUCPR-AUCSensitivitySpecificityPrecisionF1Brier scoreCalibrationSubgroupsExternal validation
Thresholds are selected on validation data. The final test set is not used for model selection.
Auditability
How every result is produced
Source-specific data
→Data intake review
→Quality & leakage checks
→Task routing
→Registered analytics/model
→Validation status
→Result + provenance
Design principle
No unexplained score appears in the interface. Each result traces to a defined source, transformation, model version, and interpretation rule.
Data-separation principle
CMS hospital records and patient encounters are not concatenated simply to increase row count. Combining sources requires a defensible harmonization study.