Health-data provenance answers a practical question: where did this value come from, and what changed it? A total can pass through a device, a platform store, an application transformation and a user correction. Keeping that lineage makes debugging and user explanations more reliable than retaining only the final number.
The contract to define first
Represent source identity, measurement interval, import time and transformation version alongside the value. Keep manual corrections distinguishable from device observations. Access controls must apply to provenance as well as the main record because source metadata can still be sensitive. Prefer the minimum lineage needed for the product and its support workflows.
A worked scenario
A synthetic daily value changes after an imported record is corrected. With provenance, support can identify the source record and transformation that produced each version. Without it, the change may look like a random dashboard inconsistency and invite an unsupported explanation.
An implementation and review sequence
- Define the minimal lineage fields for each metric
- Track manual changes and transformations explicitly
- Restrict provenance access with the underlying record
Failure cases worth testing
| Condition or input | Expected behavior |
|---|---|
| Source data is corrected | Derived lineage identifies the changed input |
| User edits a value | The manual origin remains distinguishable |
| Unauthorized coach requests metadata | Provenance is protected with the metric |
Download the illustrative acceptance checklist (JSON)
Tradeoffs and limits
Complete raw-data retention is not a requirement for useful lineage. A compact record reference and transformation history may provide enough traceability with a smaller retention footprint.
Use the result to make a decision
The practical output is straightforward: define source device and transformation metadata for each metric. Keep the assumptions with the artifact so a product owner, implementer or prospective partner can review the same decision. A useful handoff states the supported scope, the evidence collected and the remaining dependency instead of treating a successful demonstration as proof of every operating condition.
Continue with related implementation detail
Related guide: Wearable partnerships: the integration evidence to bring to the table
Manual versus wearable health inputs
Wearable data freshness indicators
References and current platform requirements
Android: synchronize Health Connect data
Platform capabilities, programme terms and access conditions can change. Check the linked primary references against the version and account you actually use; the patterns above do not establish a provider approval, certification or universal compatibility guarantee.
Discuss the workflow
Bring the supported devices, required metrics, and your current sync failure examples.
Explore the relevant AptixLabs service
What provenance should a health metric retain?
Health-data provenance answers a practical question: where did this value come from, and what changed it? Complete raw-data retention is not a requirement for useful lineage.
Which failure cases should be included in the review?
Include these explicit cases: Source data is corrected: derived lineage identifies the changed input; User edits a value: the manual origin remains distinguishable; Unauthorized coach requests metadata: provenance is protected with the metric.