Problem
Case study / v1.0.0 released educational prototype
Heart Analysis
An educational health-risk exploration workflow with explanations and explicit non-diagnostic limits.
Target user
Learners exploring how inputs affect an educational risk model—not patients seeking diagnosis.
Solution
A Flutter and Flask application presents validated inputs, risk exploration, explanations, history, and reports with visible safety language.
Personal contribution
Implemented and verified backend analysis paths, Flutter interfaces, explanation/report workflows, tests, build guidance, and portfolio evidence.
Architecture
Boundaries before buzzwords.
- Flutter web/mobile client
- Flask analysis API
- SQLAlchemy history boundary
- Explanation and report layer
Main workflow
State moves with a reason.
- 01
Enter validated educational inputs
- 02
Run the bounded analysis
- 03
Review explanation and limitations
- 04
Inspect history or report
Technical decisions
The trade-offs that define the system.
- Non-diagnostic language is part of the product boundary
- Checks run per package because nested Flutter roots conflict
- Sensitive deployment requires a separate threat model
Difficult engineering challenge
The product had to make model output understandable without turning an educational risk estimate into medical advice.
Verification
Evidence and boundaries.
Testing
- 19 backend tests
- 2 Flutter widget tests
- 2 Chromium workflows
- Ruff clean and Flutter web release build
Security and privacy
- Educational, non-diagnostic use only
- No real patient deployment is claimed
Known limitations
- No clinical validation
- Overlapping Flutter package structure remains technical debt
Focused future work
- Designate one canonical mobile package and add browser accessibility coverage
Verified demonstration
Rendered product behavior.
Loading video metadata…