Heart Disease Risk Prediction

The problem

Clinical risk scores are useless to a clinician who cannot see why they were produced.

Approach

End-to-end production ML system: feature engineering, model selection with cross-validation, and hyperparameter tuning, deployed as a FastAPI REST API with a Streamlit clinician dashboard. SHAP explainability makes each risk output interpretable, with MLflow experiment tracking and Docker deployment.

How it works

• A Random Forest over 13 clinical attributes plus 22 engineered features, reaching 88.5% accuracy and ROC-AUC 0.954 on the UCI Heart Disease dataset.
• Served as a FastAPI REST API with a Streamlit dashboard aimed at clinicians rather than engineers.
• SHAP produces a per-prediction explanation, so a risk score arrives with the factors that drove it.
• MLflow tracks experiments; Docker and a CI/CD pipeline handle deployment.

Key decisions

Explainability is the deliverable, not a feature

A clinician cannot act on a bare risk score. SHAP values ship with every prediction so the output is a reason as much as a number.

CI/CD on a project that did not strictly need it

Adding pipeline checks, pytest with property-based tests, and GitHub Actions to a single-model project surfaced the operational failure modes that later became the feature store and lineage work.

What the measurements showed

• Random Forest at 88.5% accuracy, ROC-AUC 0.954, precision 86.2%, recall 89.3%, F1 87.7%.
• 13 clinical attributes expanded to 35 with 22 engineered features, on the UCI Heart Disease dataset.
• Recall deliberately sits above precision: a missed at-risk patient costs more than a false alarm.

Running it

Full setup, configuration and API reference are in the repository README.

Stack

• Python
• scikit-learn
• FastAPI
• Streamlit
• SHAP
• MLflow
• Docker

Written up in

• I Added CI/CD and Monitoring to My ML Project. Here's What I LearnedDataDrivenInvestor