Participants can consent to share their Fitbit data, including heart rate, sleep, activity, and device data, with the All of Us Research Program. You can access the Fitbit data in the All of Us Researcher Workbench.
Note: The All of Us Research Program provides Fitbit data as generated by Fitbit webAPI, and no additional cleaning and processing has been completed on the data. You should keep this in mind as you start using and analyzing Fitbit data.
Fitbit data collection
Participants can share Fitbit data in two ways:
- Bring your own device: Participants self-consent to share their Fitbit data by agreeing to share via the All of Us Participant Portal.
-
Wearables Enhancing All of Us Research (WEAR) Study: As part of the All of Us Research Program, the WEAR Study invited eligible All of Us participants to take part in the study by wearing a Fitbit device.
Note: Fitbit devices were provided to eligible participants at no cost. To be eligible for the WEAR Study, participants had to be enrolled in the program and identify with one or more communities underrepresented in biomedical research. Additional requirements included completing The Basics survey and having access to a smartphone or tablet.
Fitbit data types
Fitbit data types include heart rate, sleep, activity, and device data. These data types are organized into multiple BigQuery tables within the All of Us Researcher Workbench.
For additional information about each table, view the “Wearables” tab under the most recent Data Dictionary or explore the relevant Fitbit webAPI links.
DATA TYPES | BIGQUERY TABLES | FITBIT WEB API LINK |
HEART RATE |
heart_rate_summary |
Fitbit webAPI |
heart_rate_minute_level | Fitbit webAPI | |
SLEEP | sleep_daily_summary | Fitbit webAPI |
sleep_level | Fitbit webAPI | |
ACTIVITY | activity_summary | |
steps_intraday | ||
DEVICE | device |
Heart rate
You can access participant-level heart rate data measured using Fitbit devices on daily summary as well as on intraday basis via the heart_rate_summary and heart_rate_minute_level BigQuery tables.
heart_rate_summary table
- We recommend visiting the Fitbit web API to gain more understanding around data elements provided in heart_rate_summary table.
-
In this table, we provide heart rate values by zone names. Currently, the possible values for heart rate zone are: out of range, fat burn, cardio, and peak. More information on these default heart rate zone names can be found via Fitbit. On a high level, here’s the brief summary definitions of the zone names available to researchers. Zones are defined as a percentage of maximum heart rate, which is (220 - Age).
- Fat Burn Zone: Between 50% and 69% of participant’s maximum heart rate. In the fat burn zone, participants are likely in a moderate activity such as a brisk walk.
- Cardio Zone: Between 70% and 84% of your maximum heart rate. In the cardio zone, participants are likely doing a vigorous activity such as running or spinning.
- Peak Zone: Greater than 85% of your maximum heart rate. In the peak zone, participants are likely doing a short, intense activity that improves performance and speed, such as sprinting or high-intensity interval training.
- Out of range Zone: below fat burn zone, i.e. anything below 50% max heart rate. In this out of range zone, participants’ heart beat at a slower pace.
heart_rate_minute_level table
- We recommend visiting the Fitbit web API to gain more understanding around data elements provided in heart_rate_minute_level table.
- Currently, we provide intraday heart rate value for 1 minute interval if the src_id = Participant Portal: vibrent and for 1 second interval if the src_id = Participant Portal: careevolution.
-
In a future release, the “heart_rate_minute_level” table in Fitbit data will be renamed “heart_rate_intra_day”. This change is a result of differing heart rate level resolutions for differences in data portal sources (PTSC s and CE).
-
- As we add Fitbit data from other sources, these changes will evolve to accommodate differences by portal.
- Once renamed, “heart_rate_minute_level” will no longer be functional in future datasets.
-
Sleep
You can access participant-level sleep data measured using Fitbit devices on daily summary as well as on sequence level via the sleep_daily_summary and sleep_level BigQuery tables.
sleep_daily_summary and sleep_level tables
- We recommend visiting the Fitbit web API to gain more understanding around sleep data.
-
Read the Fitbit article on sleep stages to better understand each sleep stage measured by Fitbit devices. The possible values for the sleep stage are light, deep, rem, and wake.
- LIGHT: The body processes memories and emotions, and metabolism regulates itself. Breathing and heart rate typically decrease slightly.
- DEEP: The body becomes less responsive to outside stimuli. Breathing slows, muscles relax, and heart rate usually becomes more regular.
- REM: The body experiences the most dream state, and eye moves rapidly in different directions. Heart rate increases, and breathing becomes more irregular.
-
Fitbit generates 2 kinds of sleep levels data based on whether the user’s device is set to ‘classic’ or ‘stages’. If device is set to ‘classic’ then the following levels are tracked:
-
-
- restless
- asleep
- awake
-
-
If the device is If set to ‘stages’ then the following levels are tracked:
-
- deep
- light
- REM
- wake
-
-
In the Researcher Workbench you may see different values depending on device settings. If the participants device is set to ‘classic’ then the ‘stages’ fields will appear null. If set to ‘stages’ then the ‘classic’ field of asleep will be 0, awake will be imputed accurately, and the ‘restless’ field will be null. None of this is done in the All of Us Research Program ETL pipeline--any imputation is done by the Fitbit API before we receive the data. We do is expand the classic levels and stages data to each have their own field in the final dataset.
-
- The fields minute_awake comes from the ‘awake’ classic level, and minute_wake comes from the ‘wake’ stages level. When the user device is set to ‘classic’, minute_awake is accurate and minute_wake is null. When set to ‘stages’, minute_awake and minute_wake are both accurate (minute_wake is tracked and minute_awake is imputed from that).
-
-
-
Read the Fitbit article for an overview on how Fitbit tracks sleep. There are a few scenarios where you might see sleep pattern (i.e., time asleep, restless, and awake) instead of sleep stages.
-
If the device owner slept in a position that prevented the device from getting a consistent heart rate reading or if the device is worn too loosely.
- For best results, the device should be worn higher on the wrist (about 2-3 finger widths above wrist bone). The band should feel secure but not too tight.
- If the device owner used the Begin Sleep Now option in the Fitbit app, instead of simply wearing the device to bed.
- If the device owner slept for less than 3 hours.
- If the device’s battery is critically low.
-
If the device owner slept in a position that prevented the device from getting a consistent heart rate reading or if the device is worn too loosely.
Activity
You can access participant-level activity data measured using Fitbit devices on daily summary as well as on intraday basis via the activity_summary and step_intraday BigQuery tables.
activity_summary table
- We recommend visiting the Fitbit web API to gain more understanding around activity data.
- Currently, all Fitbit data are generated via AOI, where the accept-language header = en_US is used, meaning the unit for elevation is feet.
- The Floors API does not return a measurement of elevation, instead only a count of how many floors the Fitbit device counted as the device owner ascended in elevation.
- The elevation traveled for the day displayed in the units defined by the data source. Specifically, when src_id = ‘vibrent’, accept-language header = en_US and when src_id = ‘careevolution’, accept-language header = Metric. Therefore, When src_id is 'vibrent', the unit is feet. When src_id is 'careevolution', the unit is meters (reference:
https://dev.fitbit.com/build/reference/web-api/developer-guide/application-design/#Unit-Systems) - The floors provide only the count of how many floors the Fitbit device counted as the user ascended in elevation. The researcher can determine how many "feet" or "meters" the user climbed as the device determines a floor every time the user ascends 10 feet (3 meters). Essentially 1 Floor = 10 Feet (3 Meters).
- The number of calories burned for the day during periods the device owner was active above sedentary level. This includes both activity burned calories and basal metabolic rate (BMR).
steps_intraday table
- We recommend visiting the Fitbit web API to gain more understanding around data elements provided in the steps_intraday table.
- Currently, we only provide activity intraday values for step counts, and the time interval is 1 minute.
Device
device table
You can access participant-level device data measured using Fitbit devices via the device BigQuery table.
- We recommend visiting the Fitbit web API to gain more understanding around device data.
- Read the Data Dictionary for a list of data elements available in the device table.
Ways to pre-process Fitbit data
Currently, the Fitbit data provided through the Researcher Workbench does not involve any specific and additional pre-processing or cleaning. The data simply represents what is being generated by the Fitbit device.
When using the Fitbit data in your research, you may want to consider pre-processing or cleaning the data to account for different types of biases present in wearables data. One of the most common biases is adherence bias as Fitbit can’t always be collecting data, either due to the device owner forgetting to wear the device or having removed the device to charge or to take a shower.
Read detailed information and considerations to keep in mind when using Fitbit data in your research.
Heart rate algorithm
Heart rate algorithm is one of the approaches you can use to account for adherence bias. This algorithm uses the concept of “daily adherence level” that is derived using minute-level heart rate data.
Specifically, daily adherence level is calculated by dividing the total count of minute-level heart rate data collected within a day by total number of minutes (e.g., 1,440 minutes in a day). The optimal threshold for filtering can then be selected based on the data type in use to avoid extensive data loss and to conserve variance in the data.
Step compliance definition
Evidence suggests that wear time of 10 or more hours defines a valid day to estimate daily physical activity such as daily step counts during waking time.
Therefore, another approach to account for adherence bias is to define whether the day is valid or not. Valid days can then be defined as the device owner wearing the Fitbit for at least 10 hours per day and reporting at least 100 steps per day.
This approach has been implemented in a prior study that leveraged All of Us data. You can refer to the "Wearables and the Human Phenome" featured workspace to find out coding details on how to implement this algorithm on Researcher Workbench.
Comments
0 comments
Please sign in to leave a comment.