Why Feature Eligibility Should Be Visible Beside Every Health Result

A result needs an eligibility label

A health result is easier to interpret when the app also explains whether the person, device, software, permissions, and account can use the feature that produced it. Without that context, an unavailable feature can look like a missing measurement, a blank history, or a change in the body. Eligibility belongs beside the result because it helps answer the first question: was this feature available to collect or calculate anything here?

The word “available” can cover several separate conditions. A feature may require a compatible sensor, a particular operating system version, a supported account setting, a permission, enough valid readings, or authorization in a particular jurisdiction. These conditions do not all mean the same thing. A result that is missing because a person declined access is different from one that the device could not collect, and both differ from a feature that is not offered for that account or location.

This distinction is not cosmetic. It protects the meaning of the health data. A feature label should describe the function and its limits, rather than implying that every health feature behaves alike.

Availability is not a health reading

Suppose a result card is empty. A person could reasonably infer that the metric was measured and came back as zero, that the body did not produce a signal, or that a trend fell below a display threshold. But the feature might simply be unsupported by the current device or software. An app that leaves these possibilities visually identical asks the reader to guess at the data pipeline before interpreting the health result.

A clear interface names the state directly: “not supported on this device,” “permission needed,” “not enough valid data,” or “feature unavailable for this account.” These are different causes, and none means normal, abnormal, absent, or zero.

Platform rules show why permission status deserves its own label. The health-data access documentation describes fine-grained authorization and explains that people can choose the data types an app may read or share. It also notes that an app may not be able to distinguish denied access from some forms of unavailable history. That is a system privacy boundary, not proof that no record exists. Product wording should avoid turning limited visibility into a claim about the person’s underlying data.

The health-permission guidance for connected data recommends presenting an understandable state when an app does not have sufficient access. The practical lesson is broader than one platform: when access is incomplete, show the limitation where the person encounters the affected result. A settings screen can offer a way to manage consent, but it should not be the only place that explains why a metric is blank.

Separate device, software, and account requirements

Device compatibility is the most visible condition, but not the only one. A feature may rely on a specific sensor, minimum software version, or supported phone-and-wearable combination. If a prerequisite is missing, it might not appear, collect new readings, or show a full history.

When the product can identify the cause, the result card should say, for example, “This device does not include the required sensor” or “Update the app to continue collecting this metric.” If it cannot tell which condition failed, it should say eligibility is unconfirmed instead of guessing.

Account conditions can also matter, including plan level, age range, account type, or parental controls. The interface should explain an account restriction before an empty chart looks like a data gap, and distinguish it from a feature that recently stopped working.

Eligibility may also depend on location. For features that need local authorization or regulatory clearance, availability can vary across jurisdictions. A current feature-availability notice illustrates how a health function can list supported devices and supported locations separately. It also makes clear that a feature not supported in a location should produce an availability message. This example is specific to one product; it is not a universal map of health-feature rules. The design principle is that region status should appear as product availability, not as a biological result.

Keep eligibility beside the affected result

Put the eligibility label beside the result title, chart, or empty state. A short summary can link to details, but it should still name the main reason: incompatible device, unsupported software, missing permission, account requirement, location limitation, or insufficient data.

A useful label also says when the status was checked. Eligibility can change after a software update, a new device connection, an account change, or a feature release. Showing “checked today” or “last checked with the latest sync” helps distinguish a current status from an old cached state. If the app cannot verify a condition because it is offline, it should say that the check is pending rather than displaying a definitive unavailable state.

Status language should distinguish three broad cases. First, a feature may not be eligible for this setup. Second, it may be eligible but inactive because a permission or setup step is missing. Third, it may be active but lack sufficient data for a valid result. These states can all produce an empty card, yet they call for different explanations. In the third case, the app should state the collection requirement and show whether any data were received. In the first case, it should not tell the person to wait for more readings if no reading can be collected on that setup.

The availability guidance for a health-data service helps illustrate that software support itself can depend on the device environment. An app can check whether a service is present and usable, then present an appropriate message when it is not. People should not be expected to infer that from a missing graph. Availability checks should be repeated when the person returns to the feature, because the device or connection state may have changed.

Explain eligibility without exposing unnecessary details

A good status message gives the reason at the level needed for action. “This result requires access to sleep records” is more useful than “data unavailable.” It is usually unnecessary to expose internal error codes, backend service names, or implementation details. The interface should explain what information is missing, whether the person can resolve it, and whether the app will try again automatically.

Eligibility is also different from accuracy. A compatible device may still produce incomplete or uncertain data; a person who meets every setup condition can still have a poor sensor signal. The device-labeling requirements discuss clear directions and conditions for use for regulated devices. While consumer wellness functions do not all fall under the same labeling rules, the distinction is useful: being eligible to use a feature does not guarantee that every output is complete or reliable.

Likewise, a feature being offered in an area does not mean it is appropriate for every person or purpose. Regulatory availability, device compatibility, technical readiness, and clinical suitability are separate questions. The software policy for mobile health functions describes oversight in relation to a function’s intended use and risk. A product should not imply that geographic availability itself validates a result or that eligibility replaces professional judgment when that is relevant.

Keep the language neutral. Do not say “your body is not eligible” when the limitation is a product rule. Say “this feature is not supported on the connected device” or “this feature needs permission to read this data type.”

A simple eligibility review

When a health result is blank or missing, first look for an eligibility label beside it. Check whether the feature is supported on the connected device and software, whether the required account or location conditions apply, and whether the app has permission to use the relevant data. Then check whether the feature was active and had enough valid input to calculate a result.

If the app still does not explain the state, treat the blank as unknown rather than assuming it means zero or no physiological signal. A support page may explain how to check setup, but the product itself should carry the essential reason into the result view. This is especially important when someone is comparing dates: a feature that was unavailable last month cannot be assumed to have recorded nothing about the body during that period.

A well-designed result shows both the health information and the conditions that made it possible to produce. The eligibility label provides a boundary around what the card can tell the reader. It makes the distinction between no result, no data, and no access visible at the moment that distinction matters. For a related example, see why missing hours should remain visible in a health timeline.

FAQ

Does an unavailable feature mean my health metric was zero?

No. Unavailable usually describes a device, software, account, location, permission, or setup condition. It does not establish a zero measurement or a health finding.

Why can a health feature appear on one device but not another?

Features may depend on specific sensors, software versions, supported combinations, account conditions, or local requirements. The app should identify the relevant condition beside the result.

What should I check when a result card is blank?

Read the status label, check whether the feature is supported and active, review its data permissions, and confirm whether enough valid data were collected. If the cause remains unclear, treat the result as unknown and consult the product’s support guidance.