A Participant Already Owns a Different Wearable Than My Protocol. Now What?

You have written a protocol around a specific wearable. You have validated your pipeline against it, budgeted for it, and built your consent language around it. Then a participant arrives at enrollment already wearing something else, and asks a reasonable question: can they just use the device they already own? This post explains why that request is more consequential than it looks, what the peer-reviewed evidence says about mixing devices, and how to decide, systematically, when to say yes.

The practical question

Allowing participants to bring their own device (BYOD) is tempting. It removes a hardware line item, shortens the path to first data, and meets people where they already are. The largest digital-health cohorts in existence were built this way: the NIH All of Us Research Program has assembled Fitbit data from tens of thousands of participants spanning more than a decade, with tens of millions of sleep observations, precisely because it let people contribute the device they already wore.

The problem is that “let them use what they have” quietly changes the measurement instrument from one participant to the next. In a study designed around a single device, a substituted device is not a minor logistical exception. It is a second, uncharacterized instrument measuring your primary endpoint, and depending on the endpoint, its output may not be comparable with your protocol device at all.

Why device heterogeneity is a measurement problem, not a nuisance

Three mechanisms turn “a different device” into measurement error and confounding.

Different raw sensing. Consumer wearables sample photoplethysmography (PPG) and accelerometry at different rates and dynamic ranges. Even on a mechanical shaker table, where there is no biology to disagree about, inter-device reliability varies by brand, and some devices show only moderate concordance with the reference motion. Hardware differences alone introduce bias before any algorithm runs.

Proprietary, black-box scoring. Most consumer-grade devices do not expose the true raw data their sensors collect, and the algorithms that turn signal into sleep stages and other indices are largely closed. As the Sleep Research Society state-of-the-science review put it, these processing algorithms are effectively black boxes. You cannot inspect, standardize, or reproduce a computation you cannot see, which means two brands can score the same physiology differently for reasons you can never fully audit.

Firmware and algorithm drift. Vendors update scoring algorithms silently. Estimates from the same device across time can shift due solely to changes in the underlying algorithm, and a manufacturer can revise its scoring partway through a study with little or no warning. Now imagine two vendors, each drifting on its own schedule, inside one dataset.

Statistically, this shows up as systematic between-device bias (one device chronically over-reads a stage, for example) layered on top of wider random error. If device type is unevenly distributed across your arms or strata, device becomes correlated with both exposure and outcome. That is the textbook setup for confounding, and even when it is balanced, it inflates variance and erodes power.

What the validation evidence actually says

The comparability question does not have a single answer. It depends entirely on which metric you are pooling.

Sleep versus wake: reasonably portable

For the two-state problem of distinguishing sleep from wake, modern devices do well. In a seven-device comparison against polysomnography (PSG), epoch-by-epoch sensitivity for detecting sleep was uniformly high across devices (all at or above 0.93), although specificity for detecting wake was low to moderate (roughly 0.18 to 0.54), the familiar pattern of devices assuming you are asleep when you are lying still. Total sleep time, which follows from sleep-versus-wake classification, is correspondingly one of the more portable outputs across brands.

Sleep staging: inconsistent and device-specific

Staged sleep is where cross-device pooling breaks down. In the same seven-device work, stage-level comparisons were mixed and degraded further on nights of disrupted sleep. Across the literature, four-stage sensitivity commonly lands anywhere from roughly 50 to 86 percent depending on device and stage, and the direction of error is not consistent: one device may overestimate light sleep and underestimate deep, while another does the reverse. The practical consequence is that on the same person on the same night, two devices can disagree on staged sleep by more than an hour, versus roughly fifteen to twenty minutes for total sleep time. Stage percentages are not interchangeable across brands.

Nocturnal heart rate and HRV: the strong exception

At rest, overnight, PPG-derived cardiovascular metrics are excellent. Resting heart rate typically sits within about one beat per minute of electrocardiogram (ECG) reference, and in a multi-night comparison against ECG, the best ring devices reached Lin’s concordance correlation coefficients around 0.97 to 0.98 for resting heart rate (mean absolute percentage error under 2 percent) and 0.97 or higher for HRV (rMSSD), while other form factors fell to concordance nearer 0.82 to 0.91. Two lessons follow. First, nocturnal heart rate and HRV are far more portable across devices than staged sleep. Second, even here devices are not fully interchangeable: some wrist devices take intermittent spot HRV samples rather than a continuous beat-to-beat value, so the underlying quantity is not the same number, and during motion PPG heart rate error rises sharply and between-device spread widens.

BYOD carries a hidden selection bias

Comparability is only half the concern. Who owns a device in the first place is not random. In the All of Us BYOD substudy, roughly 70 percent of contributing participants identified as White non-Hispanic and only about 4 percent and 3 percent as Black and Asian respectively, with more than 90 percent not Hispanic or Latino, an almost exact inversion of the parent program, where the large majority of participants come from groups historically underrepresented in biomedical research. The authors attribute this imbalance directly to the BYOD design.

That pattern tracks the underlying digital divide. National survey data show wearable ownership skews toward higher-income, younger, more educated, and urban populations, with substantially lower ownership among older and lower-income adults.⁷ Provisioning a device is therefore not only a comparability control. It is one of the few levers that restores representativeness, which is why surveys of underserved clinic populations find high interest in wearables despite low ownership. Letting only the already-equipped participants use their own hardware quietly narrows your sample toward the people who were easiest to reach.

The pivot: raw signal access changes the calculus

Here is the distinction that determines whether a substitute device is a liability or a non-issue. If you can obtain the raw signals, raw tri-axial accelerometry and beat-to-beat intervals (BBI), from every device a participant might bring, you can run them all through one validated pipeline. When you do that, the between-device algorithm confound largely disappears, because there is no longer a second algorithm in the loop. The disagreement was never mainly in the sensors; it was in the closed scoring layered on top of them.

The accelerometry literature supports this directly. When raw files from two different accelerometer brands are processed through the same open pipeline, derived outcomes such as wear time, activity, and sleep reach intraclass correlations above 0.96, with acceleration magnitude agreement near 0.99. Work reconstructing sleep and wake from the raw acceleration and PPG of a consumer wearable, prior to any manufacturer processing, reaches roughly 90 percent epoch-level accuracy against PSG using a fully open pipeline, and explicitly notes that raw sensor signal can be extracted before the manufacturer algorithm touches it, whereas the manufacturer scoring itself is closed and the raw data rarely accessible.

This is the structural fault line between an SDK and an API. A software development kit that streams raw accelerometry and beat-to-beat intervals gives you the substrate to reprocess. The Garmin Health Companion SDK, for example, exposes information at the beat level rather than only an aggregate such as RMSSD or SDNN, which lets you inspect and include or exclude individual low-confidence beats and run every device’s data through your own method. An API-only platform returns metrics already computed by the manufacturer’s closed algorithm. Oura is a common structural example of the API-only access model, and this is a comment on the data-access architecture rather than a criticism of the product. Vendor-processed outputs are the end of a pipeline, not a substrate: there is no raw signal left underneath them to re-run through a common method, so they cannot be harmonized with another brand’s processed outputs after the fact.

One honest caveat. The component evidence is strong, high cross-brand agreement on raw-derived metrics, and explicit inaccessibility of proprietary outputs, but a single head-to-head study directly contrasting “raw-derived between-device variance” against “proprietary-derived between-device variance” in the same participants does not yet exist, and recent methods work names exactly this as an open need.¹⁰ Treat raw reprocessing as the best-supported strategy, not a closed case.

A staged decision framework

Use the endpoint to decide how far toward provisioning you must move. The more your primary outcome depends on a proprietary algorithm, the less room you have to accept a substitute device.

Stage 1: Design, before recruitment

• Default to provisioning the protocol device for the primary endpoint, and justify any deviation explicitly. This is the cleanest guarantee of comparability, longitudinal stability, and representativeness.
• If the primary endpoint is a proprietary metric, staged sleep, a readiness score, any vendor composite, provisioning is effectively mandatory. Do not let a substitute device contribute to that endpoint.
• If you anticipate BYOD, require SDK-level raw access as a device eligibility criterion, so every participant’s data can be reprocessed through one pipeline. If a candidate device is API-only, plan to treat its outputs as a separate, non-poolable stream rather than folding them into your primary analysis.

Stage 2: Collection, when mixing is unavoidable

• Restrict primary endpoints to metrics with proven portability: sleep versus wake, total sleep time, resting and nocturnal heart rate, and nocturnal HRV. Move proprietary stage percentages to exploratory status.
• Run a co-wear calibration substudy. Have participants wear both the protocol device and their own device for several nights so you can estimate device bias and derive cross-walk equations rather than assuming interchangeability.
• Freeze firmware where the vendor supports research builds, and log any mid-study algorithm change as a breakpoint or covariate.

Stage 3: Analysis and reporting

• Model device explicitly. Enter device make and model as a fixed effect when there are few device types, or as a random effect in a mixed model when there are many, and pre-register device-stratified sensitivity analyses.
• Report between-device agreement for your own sample, not only prior validation: Bland-Altman bias and limits of agreement, ICC or concordance, and for staging, epoch-by-epoch sensitivity, specificity, and Cohen’s kappa.
• Document every device fully: make, model, hardware generation, firmware and app version, SDK or API and version, sampling rates, whether the metric is raw or processed, and the pipeline version. This is what CONSORT-eHEALTH, STROBE, and the Digital Medicine Society V3 framework expect for a fit-for-purpose measure.

Three thresholds should change your decision. If a metric’s between-device limits of agreement exceed your minimal clinically important difference, do not pool that metric across devices. If device type is unevenly distributed across exposure or outcome strata, escalate from covariate adjustment to either provisioning or raw reprocessing. And if a minority device type, whose exclusion moves your primary estimate, makes up a meaningful share of the sample, report that instability prominently rather than burying it.

Where Centralive fits

The reason this question is usually framed as an unavoidable tradeoff, comparability versus recruitment, is that most teams only have access to vendor-processed outputs, where a substitute device really is a dead end. Centralive is built on the other side of that fault line. By ingesting raw signals through the Garmin Health Companion SDK and the Apple SDK, raw accelerometry and beat-to-beat intervals rather than pre-scored summaries, Centralive lets you run every participant’s data through a single validated pipeline regardless of which supported device is on the wrist. Garmin in particular sits as a first-class research platform here: raw BBI and accelerometry, no subscription dependency, and an accessible hardware price point that makes provisioning to underrepresented strata financially realistic. That combination is what turns “the participant owns a different device” from a threat to internal validity into a manageable, and often fully resolvable, design decision.

References

1. Master H, et al. The All of Us Research Program’s wearables dataset. Nature Medicine. 2026. https://doi.org/10.1038/s41591-026-00000-0 (Verify DOI, volume, and author list against the published record before citation.) Back
2. White J, et al. Reliability and validity of raw accelerometry across consumer and research devices on a mechanical shaker table. medRxiv preprint. 2023. doi:10.1101/2023.05.25.23290556. https://www.medrxiv.org/content/10.1101/2023.05.25.23290556 (Preprint; confirm peer-reviewed status before citation.) Back
3. de Zambotti M, et al. State of the science and recommendations for using wearable technology in sleep and circadian research. SLEEP. 2024;47(4):zsad325. doi:10.1093/sleep/zsad325. https://doi.org/10.1093/sleep/zsad325 Back
4. Chinoy ED, et al. Performance of seven consumer sleep-tracking devices compared with polysomnography. SLEEP. 2021;44(5):zsaa291. PMID: 33378539. doi:10.1093/sleep/zsaa291. https://doi.org/10.1093/sleep/zsaa291 Back
5. Dial MB, et al. Validity of consumer wearables for nocturnal heart rate and heart rate variability compared with electrocardiography. Physiological Reports. 2025;13:e70527. doi:10.14814/phy2.70527. https://doi.org/10.14814/phy2.70527 (Recent; verify author list and article number before citation.) Back
6. Cho S, et al. Demographic imbalances resulting from the bring-your-own-device study design. JMIR mHealth and uHealth. 2022;10(4):e29510. doi:10.2196/29510. https://doi.org/10.2196/29510 Back
7. Pew Research Center. About one-in-five Americans use a smart watch or fitness tracker. 2020. https://www.pewresearch.org/short-reads/2020/01/09/about-one-in-five-americans-use-a-smart-watch-or-fitness-tracker/ Back
8. Rowlands AV, et al. Raw accelerometer data analysis with GGIR R-package: does accelerometer brand matter? Medicine & Science in Sports & Exercise. 2016;48(10):1935-1941. PMID: 27183118. doi:10.1249/MSS.0000000000000978. https://doi.org/10.1249/MSS.0000000000000978 Back
9. Walch O, et al. Sleep stage prediction with raw acceleration and photoplethysmography heart rate data derived from a consumer wearable device. SLEEP. 2019;42(12):zsz180. PMID: 31579900. doi:10.1093/sleep/zsz180. https://doi.org/10.1093/sleep/zsz180 Back
10. Do movement summary metrics produce comparable outputs across different accelerometer brands in free living? Journal for the Measurement of Physical Behaviour. 2026;9(1). doi:10.1123/jmpb.2025-0024. https://doi.org/10.1123/jmpb.2025-0024 (Recent; verify author list and pagination before citation.) Back
11. Goldsack JC, et al. Verification, analytical validation, and clinical validation (V3): the foundation of determining fit-for-purpose for biometric monitoring technologies (BioMeTs). npj Digital Medicine. 2020;3:55. doi:10.1038/s41746-020-0260-4. https://doi.org/10.1038/s41746-020-0260-4. See also Eysenbach G; CONSORT-EHEALTH Group. CONSORT-EHEALTH. J Med Internet Res. 2011;13(4):e126. doi:10.2196/jmir.1923. Back

---

Sign up for the Centralive Newsletter: https://newsletter.centralive.health/signup