Why Source Labels Matter When You Move Wearable Data

A moving value needs a label

When wearable data move from one app to another, the number may look unchanged. The source can still be lost. Without a source label, a later reader may not know which device recorded the value, which system calculated it or whether the value was imported, estimated or manually corrected.

I keep source labels beside the value because they preserve its meaning through export, import, device switches and dashboard changes.

The health-data source guidance describes source as part of the information exchanged between systems. The same principle applies to a personal health timeline.

Source is more than an app name

Record the sensor or device, the original service, the export file and the system that currently displays the value. If a value came from a manual entry or an estimate, say so. If the source is unknown, preserve that uncertainty instead of inventing a label.

This chain helps distinguish direct observations from transformations. It also prevents two copies of the same record from being counted as independent measurements.

Keep the timestamp and time zone

A source label without a timestamp is incomplete. Preserve the original date, time, offset and the time zone rule used to assign an overnight record. A converted timestamp can be useful, but it should sit beside the original.

This matters when combining sleep, heart rate, activity and energy. A shifted date can make one source appear to precede or follow another when the event order was different.

Keep units and definitions

Write the unit and definition with every value. A heart-rate number may be a spot reading, resting average or overnight minimum. A sleep value may be time in bed, estimated sleep or a score. A source label tells you where the value came from; the definition tells you what it means.

The common health-data exchange overview shows why structured fields are needed when systems share information. A personal record can use plain language fields and still preserve the same distinctions.

Mark measured, estimated and imported

Use a status field such as measured, estimated, imported, manual or unknown. Do not hide an import event simply because the new dashboard renders the value beside current data. The history should reveal when a value crossed a system boundary.

An estimated value may be useful for a trend. It should not be presented as if the sensor directly captured the underlying state. Source and status together make that difference visible.

Preserve transformations

If a value was converted, filtered, rounded, merged, corrected or reclassified, record the operation. Keep the original where possible. A transformation can improve consistency, but it should be reversible or at least explainable.

The provenance overview provides a general model for describing an entity, an activity and the agent involved in a change. A health log can implement the idea with a short note and a timestamp.

Source labels prevent false comparisons

Two systems may both report resting heart rate while one uses a morning sample and the other an overnight average. Without source labels, the values appear to form one trend. With labels, the difference becomes visible before it is mistaken for a physiological change.

The wearable-validation literature reinforces why metric and intended use matter. A familiar category name does not make the sources equivalent.

An existing guide on keeping a primary source when apps record the same metric provides a practical rule: choose the source that owns the trend and keep other records as context.

Preserve the source when exporting

Before export, check whether the file includes source, timestamp, unit, method, coverage and missing-data fields. If it does not, add a companion manifest. The exported number alone is not a complete record.

On import, compare the source manifest with the fields the new system accepts. If the destination drops a field, keep it in a local note and mark the loss. A transfer can be useful even when it is incomplete, provided the incompleteness remains visible.

Audit the first and last records

Check the boundary records after a transfer. Confirm that the first imported date and last imported date are correct, that the source label survives, and that the units and definitions did not change. Boundary errors can create a false step in a trend.

If the new system applies a new baseline or calculation, note that too. The date of import is not necessarily the date on which the underlying observation occurred.

Do not let a dashboard hide the path

A polished chart can remove the details needed to understand a change. Open the record view or export when a value looks surprising. Check whether the chart combines direct readings, imported history and model outputs under one line.

The review of wearable-data limitations supports looking at how each metric was obtained and processed. A smooth visual is not proof of a single consistent source.

Source labels support cautious decisions

When a trend changes, source labels let you ask whether the body changed or the measurement path changed. That question is especially important after a software update, device switch, account migration, time-zone change or manual repair.

Do not use a source label to dismiss a value automatically. Use it to select the right comparison and decide how much confidence the record deserves.

Keep wellness boundaries clear

Wearable data can support personal tracking and questions for a clinician. They do not establish a diagnosis because the source label is detailed. The general wellness-device guidance provides the appropriate limit.

If symptoms or a concerning change are present, use professional medical advice rather than relying on a data-transfer audit.

Use a small source manifest

For each exported metric, keep a row with the original field name, source device, source system, timestamp and time zone, unit, definition, status, coverage and transformation. Add the destination field name after import. The manifest can live beside the data file and does not need to be complex.

If the destination drops a field, record the loss. If it changes a field name, record the mapping. If it applies a calculation, record the rule or mark it unknown. This small discipline prevents a later reader from treating a transformed copy as raw history.

Mark duplicates and corrections

Moving data can create duplicate rows. A source label, original identifier and timestamp help distinguish a duplicate from a second observation. Manual corrections should retain the original value and include a reason and correction time.

Do not deduplicate only by visible value. Two equal numbers can come from different sources or different windows, while two different numbers can be duplicate records that were transformed during import.

Use provenance at the point of transfer

The best time to write the source note is when the export or import happens. Later reconstruction is often incomplete. Save the file name, export date, source period, destination and any mapping or filtering performed.

This record also makes future device changes easier. A new system can be evaluated against the manifest rather than against memory of how the old dashboard worked.

Interpret trends after the audit

Once the source path is clear, decide which records can form a trend. You may use only direct values, or include estimates with a visible status, or keep several source-specific series side by side. The rule should be explicit before the comparison is made.

If the audit shows that a step change aligns with a transfer, do not call it a biological change without independent support. The transfer itself is a plausible explanation that must be considered.

Keep the audit result with the chart. A future review should be able to see why the comparison includes or excludes an imported segment.

The chart and its reasoning should travel together.

When an export is reused, compare its manifest with the copy now in use. Confirm that the original source name, destination field, unit, method and transfer date remain attached. If a field was renamed or dropped, record the mapping instead of making the value appear native to the destination. This small check makes it easier to trace a discrepancy without assuming that the measurement itself changed.

Store the manifest beside the export and include a version or date when mappings change. That gives a later review a clear comparison point if the same file is transferred again.

That makes later review safer and faster.

A source label protects the future reader

The person reviewing a record later may not remember which device was worn, which app calculated a score or whether a value was imported. A source label preserves that context. Add the source, timestamp, unit, method, status, coverage and transformations at the time of capture or transfer.

The record then remains explainable when the dashboard changes. It can show what was observed, what was estimated and what was changed, without pretending that all values are equivalent.

FAQ

What should a wearable source label include?

Include the original device or sensor, source system, timestamp and time zone, unit, metric definition, measured or estimated status, coverage and any transformation.

Why keep the original value after converting it?

The original protects the audit trail. A converted or rounded value may be useful for comparison, but it should remain visibly derived from the source record.

Can imported data still be useful if source details are missing?

Yes, for limited qualitative review. Mark the missing details and avoid precise comparisons or claims that depend on a definition you cannot verify.