Skip to content

[Feature] Allow an adaptive Personal Health Score based on available and enabled pillars #617

Description

@lutzkind

Summary

Allow the Personal Health Score to adapt to the health domains a user has enabled and has sufficient data to calculate, while showing exactly which pillars contributed, how they were weighted, how complete the score is, and why a score is provisional or unavailable.

Environmental and short-term contextual exposures should remain separate explanatory context rather than directly increasing or decreasing the Personal Health Score.

Problem

The current score uses a small fixed set of pillars. Missing pillars are reweighted, but a user can still have rich Apple Health or wearable data—sleep, resting heart rate, HRV, activity, respiratory signals, workouts, and body composition—without qualifying for a useful Personal Health Score.

This creates several problems:

  • Medication adherence may be irrelevant for someone without scheduled medication.
  • Mood may be unavailable because the person does not actively log it.
  • A score based on a narrow subset can look as authoritative as one based on broad, stable data.
  • Connecting a new source or enabling a pillar can cause a score jump unrelated to an actual health change.
  • Environmental conditions could be conflated with personal health unless the concepts are explicitly separated.

Goals

  1. Support a broader modular set of health pillars.
  2. Use only enabled pillars with sufficient, recent, and reliable coverage.
  3. Make effective weights and coverage transparent.
  4. Preserve longitudinal comparability when eligibility changes.
  5. Avoid a comprehensive headline score based on one narrow metric.
  6. Keep Personal Health Score distinct from readiness, recovery, validated screening, and environmental exposure.
  7. Let users disable irrelevant pillars without allowing arbitrary weighting to make the score meaningless.

Proposed pillar registry

Each pillar should define its eligible inputs, minimum coverage, source-quality requirements, staleness, normalization, confidence, update cadence, and default weight.

Potential domains include:

Cardiovascular

  • Resting-heart-rate trend relative to personal baseline.
  • HRV trend and coverage.
  • Blood pressure where available.
  • Cardio fitness / VO2 max.

Avoid double-counting multiple highly correlated heart-rate signals as independent pillars.

Sleep

  • Main sleep duration relative to a target range.
  • Sleep regularity.
  • Efficiency or fragmentation where reliable.
  • Stage composition with cautious weighting.
  • Trusted source-provided sleep score with source-aware handling.

Naps should be represented correctly and should not silently inflate nightly sleep.

Activity and fitness

  • Steps, active time, or movement relative to an individualized baseline or goal.
  • Training consistency.
  • Cardiorespiratory fitness.
  • Sedentary behavior where supported.

Avoid rewarding excessive training that degrades recovery.

Body composition

  • Weight trend.
  • Waist circumference or waist-to-height ratio.
  • Body-fat trend with source consistency.
  • BMI only as contextual input rather than a dominant universal pillar.

Metabolic and laboratory health

  • Glucose-related measurements.
  • HbA1c and relevant biomarkers.
  • Lipid, renal, liver, or other clinically defined markers.

Sparse laboratory values may update a longer-term domain rather than a daily score and must retain reference ranges, units, date, and age of result.

Respiratory and recovery stability

  • Respiratory-rate trend.
  • Oxygen saturation with device/source checks.
  • Longer-term recovery stability.
  • Breathing disturbances where available.

This must not simply duplicate the existing short-term Readiness score.

Mood and mental wellbeing

  • Mood stability and trend when enough data exists.
  • Explicitly completed validated screening instruments.

Missing mood should not block an otherwise well-covered score.

Medication and treatment adherence

  • Scheduled-medication adherence when applicable.

This pillar should be absent—not treated as zero or missing—for users without an applicable regimen. Adherence must not be presented as treatment efficacy.

Condition-specific modules

Optional domains such as diabetes, cycle/reproductive health, GLP-1 treatment, illness recovery, or clinician-defined monitoring should be explicit and should not alter the generic score invisibly.

Eligibility and coverage

Each pillar should define:

  • Required source types.
  • Minimum data points and day coverage.
  • Maximum acceptable staleness.
  • Source/device consistency requirements.
  • Baseline period.
  • Target/reference logic.
  • Confidence tier.

An ineligible pillar is omitted, not scored as zero.

The UI should distinguish:

  • Enabled and eligible.
  • Enabled but insufficient.
  • Disabled or not relevant.
  • Unsupported or unavailable.

Minimum breadth

To prevent a misleading score from one narrow signal:

  • Require at least two eligible domains for a normal headline score, or another clearly documented breadth rule.
  • Require a minimum combined coverage/confidence threshold.
  • When only one domain qualifies, show that domain’s status without calling it a comprehensive Personal Health Score.
  • Mark limited breadth as provisional, for example: 74 — provisional, based on 2 of 7 enabled pillars.

The denominator should reflect intentionally enabled pillars, not punish users for modules they disabled as irrelevant.

Weighting

  • Maintain evidence-reviewed default weights by domain.
  • Redistribute weight only among eligible enabled pillars.
  • Show effective weights used for the current score.
  • Allow disabling irrelevant pillars.
  • Prefer limited goal presets over completely arbitrary numeric weights.
  • Cap any single pillar’s effective contribution after reweighting.
  • Avoid double-counting correlated submetrics within a pillar.

If custom weighting is allowed, HealthLog should state that the resulting score is no longer directly comparable with the default configuration.

Longitudinal comparability and versioning

The score must remain interpretable when a source is connected, a pillar becomes eligible, medication applicability changes, the algorithm changes, or a user changes configuration.

Recommended safeguards:

  • Version the algorithm and pillar configuration.
  • Preserve pillar composition and effective weights for each historical score.
  • Mark composition/configuration changes on the chart.
  • Do not narrate a configuration-only jump as health improvement or deterioration.
  • Provide a comparable-subset trend where feasible.
  • Use an explicit policy for historical recomputation.

Separation of concepts

HealthLog should clearly distinguish:

  • Personal Health Score: broader, relatively stable outcome/status domains.
  • Readiness/recovery: short-term physiological state.
  • Validated screening: named instruments with their own thresholds and limitations.
  • Environmental exposure: heat, pollution, pollen, UV, smoke, daylight, pressure.
  • Behavioral/contextual factors: alcohol, caffeine, nicotine, meals, exercise timing, medication events, illness, and travel.

Environmental and behavioral context may explain or predict changes, but should not directly penalize the score merely because exposure occurred. The score should not moralize behavior or geography.

Profile integration

The structured profile proposed in #614 may help determine relevance and presentation, for example:

  • Exclude medication adherence when no regimen applies.
  • Do not offer smoking-related score components to a never-smoker.
  • Prioritize respiratory context for a user who reports asthma.

Self-reported risk factors should not silently become diagnoses or direct score deductions.

UI proposal

Show:

  • Overall score when breadth requirements are met.
  • Coverage label: complete, partial, or provisional.
  • Eligible, insufficient, and disabled pillar counts.
  • Pillar values and status.
  • Effective weights.
  • Data age and source coverage.
  • What changed since the previous score.
  • Whether a change came from health data or configuration/composition.
  • A clear explanation when no overall score is available.

Example:

Personal Health Score: 78
Coverage: 4 of 6 enabled pillars

Sleep                 82   effective weight 25%
Cardiovascular        74   effective weight 30%
Activity/Fitness      80   effective weight 20%
Body composition      76   effective weight 25%
Mood                  insufficient data
Medication adherence  disabled/not applicable

Coach behavior

Coach may explain score changes only from stored pillar evidence:

Your score rose mainly because sleep regularity and resting-pulse trend improved. Medication adherence was not applicable, and mood was omitted because there were not enough entries.

Coach must not:

  • Invent missing pillars.
  • Describe an unavailable pillar as poor.
  • Attribute a score change to environmental exposure without separate evidence.
  • Recommend treatment changes based on the score.
  • Present the score as a diagnosis or clinical risk prediction unless a separately validated model supports that claim.

Privacy and control

  • Pillar enablement is user-visible.
  • Sensitive modules remain opt-in.
  • No hidden use of questionnaire answers.
  • Score evidence is exportable.
  • Deleting a source updates eligibility transparently.
  • Operator module restrictions are respected.
  • AI receives only the bounded score evidence needed for the current explanation.

Acceptance criteria

  • The score uses a modular pillar registry rather than only a fixed hard-coded set.
  • Every pillar defines eligibility, coverage, staleness, source quality, normalization, and update cadence.
  • Ineligible pillars are omitted rather than scored as zero.
  • Users can disable irrelevant pillars.
  • Effective weights and coverage are visible.
  • A normal headline requires at least two eligible domains or another documented breadth rule.
  • Limited scores are marked provisional.
  • Historical score points retain algorithm/configuration and pillar-composition metadata.
  • Configuration-only changes are distinguishable from health-data changes.
  • Readiness, screening, environmental exposure, and contextual factors remain separate concepts.
  • Environmental conditions do not directly penalize the Personal Health Score.
  • Coach explanations are grounded in bounded pillar evidence.
  • Tests cover eligibility, reweighting, dominant-pillar caps, missing data, source changes, disabled pillars, provisional state, historical versioning, configuration changes, and Coach explanation grounding.

Related issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions