Wearable Age Score Validation for Chronic Conditions

ISEF Category: Biomedical and Health Sciences

Subcategory: Other  ·  Difficulty: Advanced  ·  Setup: Home Setup  ·  Time: 1 to 2 Months

The Hook

A watch can count steps, but it can also hint at how your body is handling daily stress. That makes wearable data a tempting way to build a physiological-age score, which tries to estimate how old your body behaves, not how many birthdays you have had. The real test is whether that score shifts in sensible ways for people with chronic conditions. That gives you a health data project with a clear question and public datasets to study.

What Is It?

A physiological-age estimator is a model that turns wearable signals into one number that acts like a body-age score. Think of it like a car report. Two cars can be the same model year, but one has more wear from hard driving. A person can have the same calendar age as someone else, yet daily activity, sleep, and heart patterns can look older or younger.

Construct validity asks whether that score behaves the way the idea behind it says it should. If the score is real, people with chronic conditions should often look older on the model, or at least show a different pattern after you control for age and device type. That does not prove disease, but it does show whether the score lines up with a health story instead of random noise.

Why This Is a Good Topic

This topic works well because you can test a real claim with public data and clear numbers. You can clean wearable signals, build features, train a model, and then check whether the score separates people with and without self-reported chronic conditions. You will learn data cleaning, feature engineering, model validation, and how to think about whether a measurement really matches the idea it claims to measure.

Research Questions

• How does the wearable-age score change when you add sleep features to steps and heart rate? ? What is the effect of self-reported chronic conditions on the estimated physiological age after controlling for calendar age? ? Does the model separate participants with chronic conditions from matched participants without them? ? To what extent do device brand and missing data change the stability of the age estimate? ? Which feature group, steps, sleep, heart rate, or heart-rate variability, predicts age most accurately? ? How does the score differ across low, medium, and high sleep regularity groups?

Basic Materials

• Laptop with internet access.
• Python installed with pandas, NumPy, scikit-learn, and matplotlib.
• Spreadsheet software such as Google Sheets or Excel.
• Public wearable dataset with steps, sleep, heart rate, age, and self-reported condition labels.
• Dataset codebook or data dictionary.
• Notebook app or text editor for analysis notes.

Advanced Materials

• University-approved workstation or cloud server for larger de-identified health datasets.
• R or Python with mixed-effects, calibration, and resampling libraries.
• Secure storage approved for participant-level files.
• Additional wearable cohort data with raw timestamps and device metadata.
• Statistical consultation or lab meeting time for sensitivity checks and subgroup design.

Software & Tools

• Python: Cleans the wearable tables, builds features, and fits prediction models.
• Jupyter Notebook: Keeps code, charts, and notes together while you iterate.
• R: Runs mixed-effects models, calibration plots, and subgroup checks.
• Google Colab: Gives free cloud compute when your laptop struggles with large files.

Experiment Steps

1. Define the exact age score you will study, and decide whether you will predict calendar age, a condition label, or both.
2. Choose one dataset or a matched pair of datasets, and freeze the wearable features before you model anything.
3. Plan a participant-level split so the same person never appears in both training and test sets.
4. Build a baseline model, then add chronic-condition labels as a construct-validity check.
5. Set controls for age range, sex, device type, and missing data so the health signal is not just a data-quality signal.
6. Predefine the plots and statistics you will use to compare groups, check calibration, and test stability across subgroups.

Common Pitfalls

• Splitting records instead of people, which lets the same participant leak into both training and test sets.
• Mixing Fitbit and Apple Watch fields without checking that each signal means the same thing, which creates fake device effects.
• Ignoring missing sleep or heart-rate gaps, which can bias the score toward users with cleaner data.
• Treating self-reported chronic conditions as clinical diagnoses, which makes the validity claim too strong.
• Comparing raw age scores across datasets with different age ranges or device mixes, which can make one model look better by accident.

What Makes This Competitive

A stronger project does more than train one model. It tests whether the score still behaves well after you control for age, device type, and missing data, and whether the same pattern shows up in a held-out dataset. If you add subgroup checks and calibration plots, you move closer to a real validation study instead of a simple prediction demo. That kind of careful design is what makes the work feel serious.

Project Variations

• Use sleep regularity instead of heart rate as your main predictor and test whether the age score still separates chronic-condition groups.
• Compare Fitbit and Apple Watch datasets separately to see whether device brand changes the age estimate.
• Swap chronic-condition labels for activity-level groups and test whether the score captures health differences in another way.

Learn More

• PubMed: Search review articles on wearable biomarkers, biological age, and digital phenotyping.
• PhysioNet: Browse open physiological datasets and their codebooks for signal definitions.
• NIH All of Us Research Program: Read public materials on wearable data, survey labels, and health research design.
• MIT OpenCourseWare: Find free lectures on statistics and machine learning for model building.
• Open mHealth: Read open standards for wearable data fields, units, and signal names.