What a Health App Should Explain Before It Gives You a Score

A score needs a short explanation

I do not treat a health score as self-explanatory. A number is a compressed output, not a direct view of the body. Before I use it to guide a decision, I want to know what was measured, what was calculated, what was inferred, and what the system did not know.

This is not a demand for source code. An app can protect its implementation while still explaining the operational facts a reader needs. A score should come with enough context to answer a practical question: what does this number describe today, and how much confidence should I place in it.

Without that context, a score can look comparable when it is not. A value based on a full overnight record may not mean the same thing as a value based on a partial record. A value updated in the afternoon may not be a revision of the morning score; it may be a different estimate with a different input set.

Start with the input list

The first disclosure should be the input list. The app should say whether the score uses sleep, heart rate, heart-rate variability, movement, respiratory signals, user entries, or other sources. It should distinguish information that comes directly from a sensor from information imported from another service.

The list does not need to overwhelm the reader. It should identify the inputs that can materially move the result and show when one is unavailable. A score that depends on overnight data should not be presented with the same confidence after a gap without a clear warning.

Input ownership also matters. If several sources record the same metric, the app should tell the reader which record has priority and why. A duplicate may have a different timestamp, sampling method, or completeness. A practical guide to choosing a primary health-data source helps show why source priority is part of interpretation.

Show the time window and update time

Every score has a time window even when the interface does not show one. The window might be an overnight period, a rolling set of hours, a recent workout, or a longer baseline. If the window is hidden, the reader cannot tell whether two scores are actually answering the same question.

The update time is just as important. A score shown at breakfast may reflect data processed earlier. A later value may incorporate more movement or a refreshed estimate. The app should display when the calculation ran and identify which new input caused a change when that is possible.

I also want a clear distinction between a baseline score and an intraday update. A morning estimate may summarize overnight recovery. An afternoon update may be a response to accumulated activity or a new data point. Neither is automatically better; they are useful for different decisions.

Explain the baseline

A score compared with what. That question should have an explicit answer. The reference may be a person's recent pattern, a longer personal history, a population range, or a combination. A score can be stable when the baseline is changing, or it can move because the reference period moved even when today's raw measurement did not.

The baseline window should be stated in plain language. If the system needs several comparable observations, it should say so. If a new device, changed wear time, or software update can disrupt the comparison, the app should flag the transition instead of silently continuing the old scale.

A baseline is also not a diagnosis. It is a comparison rule. An evidence framework for wearable measurement explains why the chosen reference measure, study conditions, and analysis affect what a reported value can support.

Label missing data instead of smoothing it away

Missing data can arise from non-wear, poor contact, low power, interrupted sync, movement artifacts, or a source that did not record the relevant period. A transparent app should identify whether it excluded the gap, estimated through it, carried forward an earlier value, or withheld the score.

The user should not have to infer a missing input from a strange number. If a score is available despite incomplete data, the interface should communicate the limitation in proportion to its importance. A small note is not enough when the absent input is central to the calculation.

I prefer a visible “not enough data” state to a confident-looking fallback. Withholding an output is not a failure when the alternative is false precision. It is a sign that the system recognizes the boundary of its evidence.

Separate measured, calculated, and inferred layers

A sensor may record an optical or electrical signal. Software may calculate a rate or interval from that signal. Another model may infer sleep stage, recovery, readiness, or coaching advice. These layers are related but not interchangeable.

The interface should label each layer. “Measured” should describe the direct observation as the system defines it. “Calculated” should describe a derived value created by a stated method. “Estimated” or “inferred” should describe a model output that depends on assumptions and training data. “Recommended” should identify an action rather than a body measurement.

This vocabulary gives the user a better mental model. It also limits the temptation to treat a downstream score as if it were a laboratory result. General-wellness guidance distinguishes low-risk wellness functions from medical claims, which is a useful reminder that a health-oriented label does not settle the claim by itself. Read the current low-risk wellness policy for the distinction between general wellness functions and medical-device claims.

Explain what a score can and cannot decide

The app should name the decision the score is designed to inform. It may help a user choose between planned activity options, review a data gap, or notice a trend. It should not quietly expand that purpose into diagnosis, treatment, or a guarantee about performance.

Limits should be specific. A generic disclaimer that the output is not medical advice does not explain when the score is unreliable. The user needs to know how symptoms, unusual circumstances, missing inputs, or persistent changes alter the interpretation.

The recommendation should also include a stopping rule. If the pattern persists, if symptoms appear, or if the input quality falls below a threshold, the user should know what to do next. The distinction between wellness guidance and clinical decision support provides useful context for reading the stated purpose of a digital health function.

My transparency checklist

Before I trust a score, I look for six answers: what inputs were used, what time window was analyzed, what baseline was applied, what data were missing, when the score last updated, and what decision the output is meant to support. I then ask whether the number is measured, calculated, or inferred.

If an app cannot answer those questions, I treat the score as a prompt for review rather than a directive. A score can still be useful, but its role is narrower than the interface may imply.

Transparency also needs to survive change. When an algorithm, sensor, source, or baseline changes, the app should mark the break in continuity. A user should not have to discover an unexplained trend shift weeks later.

Explain changes without pretending to expose everything

Transparency does not require publishing every line of code. It requires naming the variables that matter to the user. A short explanation can state that the score changed after a new overnight record, a missing segment was restored, or the comparison baseline moved. If the reason cannot be isolated, the app should say that the output was recalculated rather than inventing a cause.

The explanation should also survive a changed device or source. A new signal path can create a break in the time series even when the user's behavior is unchanged. A reader should be able to mark that transition and avoid treating it as a personal health change.

The score should disclose its uncertainty

Uncertainty can be communicated through a label, range, confidence state, or simple warning. The exact format matters less than whether it reflects the quality of the input. A score based on a complete, comparable period should not look identical to one based on a partial record.

When the app shows a recommendation, the uncertainty should influence the wording. A tentative observation should not be followed by an absolute command. The user should be able to tell whether the score is a stable summary, a provisional estimate, or an unavailable result. Guidance on clinical decision support reinforces the value of making the software function and its output understandable to the intended user.

This is also a safeguard against false precision. If the number is more exact than the evidence, the display should be rounded, banded, or paired with a clear limitation. The goal is a decision that matches the evidence, not an interface that looks mathematically impressive.

This is also a safeguard against false precision. If the number is more exact than the evidence, the display should be rounded, banded, or paired with a clear limitation. The goal is a decision that matches the evidence, not an interface that looks mathematically impressive. A score should state its intended purpose and show when the underlying record is incomplete.

FAQ

Why does the same health score change during the day?

It may use a different time window, add new measurements, update a baseline, or recalculate after a delayed sync. The app should disclose which of these occurred rather than presenting every update as a simple correction.

What is the most important thing to know about a health score?

Know what decision it is meant to support and which inputs drive it. Without that information, the number has no reliable meaning outside the interface that produced it.

Is a health score a measurement?

Usually it is a calculated or inferred summary built from measurements and assumptions. The app should label the layers so the user does not mistake a score for a direct physiological observation.