The Problem
HeartAI explored a careful software question: how can a full-stack AI prototype present heart-disease risk predictions with enough context for a user to understand the model behavior, while avoiding the claim that a coursework demo is a clinical diagnostic tool?
This case study is intentionally sanitized. The repository is private, deployment URLs and cloud identifiers are withheld, and the project is presented as educational/research software rather than medical advice or clinical validation.
What I Built
I built a full-stack HeartAI prototype with a form-based prediction workflow, an explainability view, a dashboard-style monitoring surface, and containerized local/deployment setup. The backend loaded trained model artifacts, accepted structured health-feature inputs, returned ensemble prediction output, and exposed explainability data for the frontend.
Project Overview
HeartAI was built as a graduate AI coursework project. Public details are limited to sanitized architecture, recreated visuals, and evidence-backed implementation claims.
My Contribution
- Built the Next.js and React interface for risk-input forms, prediction results, explainability views, and dashboard-style summaries.
- Implemented a FastAPI backend that served prediction, explanation, health-check, database-check, and demo-test workflows.
- Developed the coursework ML pipeline around preprocessing, logistic regression, a TensorFlow neural network, ensemble probability output, and SHAP-based explanation support.
Full-Stack Workflow
Sanitized HeartAI workflow
A recreated view of the educational full-stack flow from sample inputs to model output and explanation.
No private repository URL, deployment endpoint, credential, cloud identifier, log, or source-code excerpt is published.
Recreated product snapshot
A public-safe visualization of the form, prediction result, and explanation workflow.
Sample risk inputs
Ensemble result
Feature explanation
Visual uses safe sample data created for this portfolio page.
Technical Decisions
Pair an interpretable baseline with a neural network and explanation layer.
- The coursework goal was to compare traditional machine learning and deep learning while making predictions easier to inspect.
- The application needed shared preprocessing, serialized model artifacts, and a separate explanation workflow rather than a single opaque prediction call.
- The prototype could return an ensemble prediction and show feature-contribution context without presenting the output as clinical advice.
How I Work
Engineering Challenge
- Medical AI demos can easily overclaim by sounding like validated diagnostic products.
- I compared the source archive, user manual, paper, presentation, model artifacts, frontend pages, API route structure, Docker setup, and deployment notes.
- I kept the public case study focused on software architecture, model workflow, explainability, and sanitized deployment learning, while excluding endpoints, credentials, logs, source code, and clinical claims.
- The page communicates full-stack AI engineering depth without implying production medical use, FDA approval, patient outcomes, or clinical validation.
Quality & Testing
Quality Evidence
Product engineering evidence
- Local evidence includes predefined demo-test workflows and generated sample test-output records. These support software behavior only, not clinical validation.
- Docker, Docker Compose, and AWS deployment scripts/docs were reviewed for deployment learning. Private URLs, credentials, account details, and resource identifiers are withheld.
- Evidence verifies a Next.js/React/TypeScript frontend, FastAPI/Python backend, PostgreSQL service, serialized scikit-learn and TensorFlow model artifacts, and SHAP explanation support.
Public page quality
- The public visual is recreated SVG with accessible title and description through the shared case-study components.
- The case study uses shared responsive portfolio layouts and scalable diagrams.
- No raw source code, local filesystem path, credential file, .env value, deployment URL, cloud identifier, or medical record is bundled.
Results & Impact
HeartAI demonstrates a complete educational AI application: data preprocessing, model training, ensemble prediction, explainability, API design, frontend workflow, Dockerized local setup, and cloud-deployment practice. Published performance numbers are intentionally omitted because the submitted evidence contains conflicting reported values, and none of the evaluation represents clinical validation.
What I Learned
The most important engineering lesson was how much framing matters in AI for health. A useful portfolio story can show model and product engineering while clearly stating the limits: HeartAI is an educational prototype, not a medical device, diagnostic tool, or substitute for professional care.