Wearable Device-Generated Data for RWE

In plain language

Wearable device data come from sensors people wear in daily life, such as watches, patches, activity monitors, continuous glucose monitors, or pulse oximeters. They can show movement, sleep, heart rhythm, glucose, or oxygen patterns that clinic visits miss. The hard part is proving the device and algorithm actually measure the clinical thing the study claims, and handling the fact that sick or less connected patients often wear or sync devices less.

Wearable device-generated data

are digital measures produced by sensors worn on or near the body, usually through a device plus software pipeline. Examples include step count, cadence, gait speed, sleep duration, heart rate, heart-rate variability, arrhythmia flags, continuous glucose measures, oxygen saturation, tremor, falls, activity intensity, and digital mobility outcomes. In RWE, these data can be collected in pragmatic trials, decentralized trials, registries, postmarket device studies, and prospective observational cohorts to measure daily function and physiology outside clinic walls.

Wearable data are not automatically "objective" merely because a sensor produced them. A device-generated endpoint is a chain: sensor hardware, firmware, placement, user behavior, transmission, preprocessing, proprietary algorithm, aggregation rule, and analytic endpoint definition. Each link can change the result. A wrist accelerometer step count, a patch ECG arrhythmia alert, and a continuous glucose monitor time-in-range endpoint have different validation needs, missingness patterns, and regulatory status. Treating the vendor's daily summary as a clean clinical endpoint without understanding the measurement chain is the central error.

Core conceptual distinction

Wearable data are a subset of patient-generated health data when collected outside clinical settings, but they have a distinctive technical validation problem. Manual PGHD asks whether the patient reported accurately and whether non-response is informative. Wearable data additionally ask whether the sensor measured the construct correctly, whether the algorithm converts raw signals into the intended metric, and whether the metric is clinically meaningful in the target population. The V3 framework makes this explicit: verification asks whether the device measures the sensor signal as designed, analytical validation asks whether the algorithm-derived measure is accurate against a reference method, and clinical validation asks whether the measure captures the clinical concept for the proposed endpoint and population.

The analyst's unit is rarely the raw sensor stream. Most RWE teams receive minute-level, hourly, or daily summaries such as "valid wear minutes," "steps," "moderate activity minutes," "sleep efficiency," or "time in glucose range." Those summaries must carry metadata: device model, firmware, app version, algorithm version, sampling rate, timezone, battery gaps, wear detection, sync timing, and whether the device was provisioned by the study or brought by the participant. Without that metadata, an apparent treatment effect can be a firmware update, a changed sleep algorithm, differential wear compliance, or a daylight-saving-time artifact.

Pros, cons, and trade-offs

- vs site-based clinical measurements: Wearables capture dense, ecologically valid information in daily life and reduce site-visit burden. Cost: home context is uncontrolled, wear compliance is selective, and consumer algorithms may change. Prefer wearables for mobility, sleep, activity, physiologic variability, and remote safety monitoring; prefer site measurements when standardized administration and controlled conditions are essential. - vs PROs: Wearables measure behavior or physiology without asking the patient to recall or rate it. Cost: they cannot directly measure symptoms, fatigue burden, preference, or reasons for behavior. Prefer pairing wearable activity with PROs when the clinical question is function or quality of life. - vs EHR/claims: EHR and claims capture clinical care and utilization; wearables capture what happens between encounters. Cost: wearables usually lack a denominator, clinical context, and complete outcomes unless linked. Prefer linked designs where claims/EHR supply time zero, censoring, diagnoses, fills, and clinical events. - vs regulated medical-device measurements: Some wearables or functions are regulated devices; many consumer wellness features are not. A consumer heart-rate summary may be sufficient for exploratory phenotyping and insufficient for a primary endpoint. Prefer the least burdensome valid device, not necessarily the most popular device.

When to use

Use wearable device-generated data when the target construct is observable through passive or semi-passive sensing: mobility, physical activity, sleep, gait, tremor, falls, heart rhythm, heart rate, continuous glucose, oxygen saturation, or home physiologic monitoring. Strong use cases include decentralized and pragmatic trials, postmarket surveillance, rare-disease function monitoring, cardiometabolic studies, oncology functional decline, neurology motor outcomes, and safety monitoring where site visits undercapture daily variability.

When NOT to use - and when it is actively misleading

Do not use a wearable-derived endpoint without a fit-for-purpose validation argument for the specific device, algorithm, endpoint, population, and context of use. Do not compare data across device models, firmware versions, or algorithms unless the versions are harmonized or adjusted. Do not treat missing wear time as zero activity; that biases against patients who are sicker, hospitalized, cognitively impaired, digitally excluded, or annoyed by the device. Do not let a proprietary black-box metric become a primary endpoint unless the sponsor can preserve the algorithm version, audit trail, and documentation. It is actively misleading to call a decline in step count a clinical deterioration if it is actually caused by device non-wear, battery failure, a new phone, or a firmware update.

Data-source operational depth

- Provisioned study wearable: Best control over model, firmware, placement, training, and support. Failure modes are shipment delays, non-wear, charging gaps, skin irritation, and protocol deviations. Require device accountability, wear-time thresholds, and tech-support logs. - Bring-your-own-device (BYOD): Improves convenience and scale, but device heterogeneity and socioeconomic selection are major threats. Device ownership, model, and upgrade patterns correlate with age, income, disease, and geography. Analyze only harmonizable metrics or stratify by device class. - Continuous glucose monitor or regulated sensor: Stronger clinical interpretability for specified measures, but still requires sensor-wear rules, calibration rules where applicable, warm-up/exclusion windows, and device replacement handling. - Linked wearable + EHR/claims: Necessary for RWE questions that need diagnoses, treatment starts, comparator arms, hospitalization, death, or censoring. Wearable data supply the digital endpoint; EHR/claims supply the clinical frame and denominators.

Worked example

Question: does a pulmonary rehabilitation program improve real-world mobility at 12 weeks among COPD patients in an EHR-linked prospective cohort? (1) Device: provision the same wrist-worn accelerometer model to all participants; freeze firmware and algorithm version. (2) Time zero: date of program start from the EHR referral/order table. (3) Baseline window: days -14 to -1 before start; require at least 10 valid hours per day on at least 10 days. (4) Follow-up window: days 70 to 84; same wear-time rule. (5) Endpoint: mean valid-day steps at follow-up minus mean valid-day steps at baseline. (6) Missingness: classify non-valid days as non-wear, sync failure, hospitalization, device loss, or unknown using device logs and linked EHR/claims. (7) Analysis: do not impute non-wear as zero; model change among valid windows and run sensitivity analyses that penalize participants with hospitalization-linked missingness. (8) Reporting: include device model, algorithm version, wear-time rule, valid-day counts, and completion by age, sex, baseline severity, and digital-access strata.

Worked example

Scenario

COPD patients receive a study-provisioned wearable before starting pulmonary rehabilitation. The analyst compares baseline and 12-week step counts, but only after applying valid-day and algorithm-version rules.

Dataset

Simplified daily wearable summaries for two COPD patients.

Steps

• Freeze the acceptable algorithm version before analysis.

• Define valid wear days using wear minutes, not step count.

• Average valid days inside the baseline and follow-up windows.

• Do not treat P002's low-step non-wear day as immobility.

• Link EHR/claims to classify missing or non-wear periods near hospitalization.

Result

P001 contributes to the 12-week mobility endpoint. P002's follow-up day shown here is excluded as non-wear; whether P002 contributes depends on whether enough other valid follow-up days exist.

Runnable example

import pandas as pd

VALID_MINUTES = 600
REQUIRED_DAYS = 10
ALGO = "v4.1"

def wearable_step_endpoint(daily, index):
    df = daily.merge(index, on="person_id")
    df["date"] = pd.to_datetime(df["date"])
    df["index_date"] = pd.to_datetime(df["index_date"])
    df["day"] = (df["date"] - df["index_date"]).dt.days
    df["valid_day"] = (
        (df["wear_minutes"] >= VALID_MINUTES)
        & (df["algorithm_version"] == ALGO)
        & df["steps"].between(0, 100000)
    )

    def summarize_window(lo, hi, label):
        w = df[df["day"].between(lo, hi) & df["valid_day"]]
        s = (w.groupby("person_id")
               .agg(valid_days=("date", "nunique"),
                    mean_steps=("steps", "mean"))
               .reset_index())
        s[f"{label}_complete"] = s["valid_days"] >= REQUIRED_DAYS
        return s.rename(columns={"valid_days": f"{label}_valid_days",
                                 "mean_steps": f"{label}_mean_steps"})

    base = summarize_window(-14, -1, "baseline")
    follow = summarize_window(70, 84, "followup")
    out = base.merge(follow, on="person_id", how="outer")
    out["endpoint_complete"] = out["baseline_complete"].fillna(False) & out["followup_complete"].fillna(False)
    out["step_change"] = out["followup_mean_steps"] - out["baseline_mean_steps"]
    return out