Wearable Health ML Research
Research · iOS Development · Machine Learning · Apple HealthKit
Can standard models separate patterns in wearable cardiovascular signals?
This is a collaborative research and technical project with Johaan Mannanal. The study asks a deliberately bounded question: can standard machine-learning models separate labeled patterns in synthetic wearable-style cardiovascular signals — heart rate and heart-rate variability — and can that pipeline be built to real engineering standards: reproducible, tested, and honestly reported?
Around that core study we built a full-stack demonstration: a FastAPI backend that serves the trained models, and a SwiftUI iOS application that collects HealthKit-style metrics and displays results. I built the app and drove the project’s overall plan and architecture.
Scope and honesty. All results are on synthetic data designed to resemble Apple Watch / HealthKit signal characteristics. No real patient or device data was used, no clinical claim is made, and this is not a medical device. The research is unpublished student work.
Why the goal was inverted
Health-adjacent machine learning is easy to overclaim and hard to verify. Rather than chase a headline metric on data that could not be published, the project inverted the goal: build a pipeline whose every number a stranger can reproduce from the shipped code, on synthetic data whose limitations are stated up front.
The measure of success is the engineering — leakage-safe preprocessing, fixed seeds, cross-validation, unit tests, and a model card that says what the results do and do not mean.
The research direction grew out of work done under the guidance of Professor Jevelson Simenthy (Penn State). The public repository is an independent, synthetic-data rebuild by the authors — not an official university publication — so the work could be shared, reproduced, and judged without exposing any real health data.
The iOS application
I built the complete SwiftUI iOS front end — TelemetryHealthCare/.
- App structure and views: SwiftUI throughout — main tab navigation, analysis views, settings, launch experience — with Core Data for local persistence.
- HealthKit integration: heart rate, heart-rate variability, blood pressure, and ECG, handled through a dedicated HealthKit manager so signal access is explicit and auditable.
- Two inference paths: on-device Core ML models for immediate feedback, and calls to the FastAPI backend for the server-trained pipelines.
- Honest presentation: trends and analysis are displayed behind a prominent medical disclaimer — the app mirrors the repository’s stance that this is research, not diagnosis.
Design decisions I made
- On-device first where possible. Health signals are sensitive; Core ML inference keeps the immediate loop on the phone, with the backend as the heavier second path.
- The disclaimer is UI, not fine print. If the project’s honesty lives only in the README, the app undercuts it. The disclaimer is part of the interface.
- Meet at the backend contract. Models and API on one side, app on the other — a clean boundary that let both halves move independently.
Four model families, compared
The study (built by Johaan) compares four model families on synthetic classification and regression tasks: an SVM soft-voting ensemble, gradient boosting, a neural network (MLP), and a random-forest / GBM / XGBoost regression ensemble.
Verified, reproducible numbers
Headline results reproduced from the shipped code with seed 42:
| Model | Task | Result |
|---|---|---|
| SVM | Binary rhythm classification | 93.9% accuracy |
| GBM | Binary health-risk classification | 99.4% accuracy |
| MLP | 4-class HRV classification | 99.0% accuracy |
| Regression ensemble | Fitness / VO₂max / cardiovascular age | R² = 0.918 / 0.563 / 0.970 |
Because the data is synthetic and separable by design, these numbers measure the pipeline, not clinical performance. See the project’s model card for what they do and do not mean.
Who built what
- Project planning and overall system architecture
- The complete SwiftUI iOS front end
- HealthKit data integration — heart rate, HRV, blood pressure, ECG
- Core ML incorporation for on-device inference
- App concept and the UI framing of results and disclaimers
- End-to-end ML pipeline: synthetic data generation, feature engineering, training, evaluation, visualization
- The four model families and their comparison
- The FastAPI service that serves the trained models
- Research direction and the project’s bounded scope
- The backend contract where the app and models meet
- The project’s stance on honest reporting and limitations
The iOS app and backend are works in progress, not production systems. The exact state is visible in the public repository rather than claimed here.
Repositories
- Rhthm360/telemetry-healthcare — the main repository, including the team case study, model card, research notes, and verified metrics
- My personal case study — my perspective on the work
- Johaan’s personal case study — the ML and backend story
What the project taught me
- Wearable data is messy and sensitive. Deciding which signals to request, and being explicit about that access, is a design decision — not a checkbox.
- Software architecture is a negotiation. Defining the backend contract early is what let two people build two halves in parallel without blocking each other.
- Research methodology means bounding the claim. The most useful thing this project does is refuse to overclaim: synthetic data, stated limitations, reproducible numbers.
- Collaboration works when the seams are clear. Clean interfaces between my app and Johaan’s models mattered more than either half individually.