Data Visualization : Jawbone UP

ScreenShot1

IMG_0432What originally drew me to the UP back in 2013, was the offer of access to my own data. I was hoping to get sensor data. The actual discrete time stamped measurements from the accelerometer and the stop watch. Instead what I got was daily aggregations. I suspect Jawbone retain the meta data from the phone app like geotags,  network details etc.

Downloading the aggregated data from the website involves finding link buried at the bottom of the Accounts section of the User Profile page.

JBScreenshot

Interpreting the column headings required some hunting around the Jawbone Support Forums. These community Forums have since disappeared form the Jawbone website. So the table below may be the only data dictionary still floating around the internet!

It to have been deciphered by an enthusiastic user rather than an official spec from Jawbone. I’d link to the forum post and credit the user but I couldn’t find them even in Google Cache.

Essentially, this is what’s available in the CSV files.

Column name

Type

Description

e_calcium

meal

calcium content in milligrams

e_calories

meal

energy content in kcal

e_carbs

meal

carbohydrates content in grams

e_cholesterol

meal

cholesterol content in milligrams

e_fiber

meal

fiber content in grams

e_protein

meal

protein content in grams

e_sat_fat

meal

saturated fat content in grams

e_sodium

meal

sodium content in milligrams

e_sugar

meal

sugar content in grams

e_unsat_fat

meal

unsaturated fat (monounsaturated + polyunsaturated) content in grams

m_active_time

movement

total number of seconds the user has been moving

m_calories

movement

total number of calories burned in the day

m_distance

movement

total distance in meters

m_lcat

movement

longest consecutive active time in seconds

m_lcit

movement

longest consecutive idle time in seconds

m_steps

movement

total number of steps in the day

m_workout_count

movement

number of workouts in the day

m_workout_time

movement

total number of seconds the user has workedout

o_count

mood

number of workouts in the day

o_mood

mood

total sum of mood ratings in the day

s_asleep_time

sleep

number of minutes, since previous midnight, when the user fell asleep (first time the user fell into light or sleep mode).

s_awake

sleep

seconds the user was awake

s_awake_time

sleep

number of minutes, since previous midnight, when the user woke up (either the band was taken out of sleep mode, or the beginning of the last awake period)

s_awakenings

sleep

number of times the user woke up

s_bedtime

sleep

number of minutes, since previous midnight, when the user set the band into sleep mode

s_deep

sleep

number of seconds the user was in deep sleep

s_duration

sleep

total number of seconds the user slept

s_light

sleep

number of seconds the user was in light sleep

s_quality

sleep

quality score (0-100)

n_asleep_time

nap

number of minutes, since previous midnight, when the user fell asleep (first time the user fell into light or sleep mode).

n_awake

nap

seconds the user was awake

n_awake_time

nap

number of minutes, since previous midnight, when the user woke up (either the band was taken out of sleep mode, or the beginning of the last awake period)

n_awakenings

nap

number of times the user woke up

n_bedtime

nap

number of minutes, since previous midnight, when the user set the band into sleep mode

n_deep

nap

number of seconds the user was in deep sleep

n_duration

nap

total number of seconds the user slept

n_light

nap

number of seconds the user was in light sleep

n_quality

nap

quality score (0-100)

I chose to explore this data visually with D3.js and Crossfilter.js. You could just have easily done the same in MS Excel or Google Sheets.

IMG_0076My experience suggests my band’s distance estimates are off by about +20% when running. Consequently, this overestimates the speed (mph) calculations performed by the app. It’s true, I could calibrate it to my own running cadence and stride. I didn’t.

Given what I know about my own Basal Metabolic Rate (BMR) and Total Energy Expenditure (TEE), I assume the calorie expenditure estimates to be equally flattering (about 15% over estimated).

I believe the band assumes approximately 2,000 steps per mile. This would be consistent with prevailing average estimates. Hence, the further you are from “average” height and weight, the higher your margin of error.

If you’re an athletic outlier (skinny distance runner or a stocky body builder) these measurements are not useful for improving performance. If you’re “average” (overweight and inactive) you’ll get more accurate measurements out of the box. Which I suppose says a lot about who this was designed for.ScreenShot2

In performing this simple visual exploration, I was unable to learn anything I didn’t already know.

  1. I’m more active on the weekends. Not a surprise given my desk job.
  2. I sleep better at the weekends. Not a surprise given I’m more active.
  3. I appear to be more active in the warmer months. Not a surprise given I live in SD.
  4. I’m not close to the mean. Not a surprise given my heritage and genetics.

No unexpected patterns emerged. No ah-ha moments. In fact, I suspect I was happier during the missing data periods when I wasn’t wearing a band to obsessively measure my runs, workouts, sleep, vitals, macro-nutrients etc.

I’ve owned at least six UP bands (if not eight). To be honest, I’ve lost count. None lasted beyond the 90 day warranty period and all except the first were replacements. While the customer service has been excellent the durability of the hardware was disappointing. This reflects heavily in the data and what you can do with it.

Replacement bands typically take 2-3 weeks to arrive, explaining the lengthy gaps in the illustrations. My apparently choppy performance (wide swings from the mean in the horizon charts) is a device reliability issue rather than inconsistent lifestyle choices or behavior patterns.

ScreenShot3

The UP band is unlikely to have any long lasting impact on my overall fitness, health or wellbeing. I’m pretty confident in saying, it won’t improve my Quality Adjusted Life Years. At best, the inactivity warnings remind me how much of a sedentary slob I can be.

If you’ve had better luck with your Jawbone UP and are interested in trying this analysis for yourself, my source code can be found on my Github repository.

Health Care Analytics & Joining the Dots.

After a series of obscure posts it’s time to join the dots. I feel compelled to do this after a recent post leached it’s way into my LinkedIn feed. It was most probably user error on my part but there’s no getting the genie back in the bottle now.

These posts are little more than engineering notes for me and my small team. They’re solutions that work for our use cases and environment. They were not intended to be packaged for public consumption (hence the informal language and sloppy grammar).

So, I explained how to coerce Microsoft SQL Server 2012 into exporting JSON and setting it up as a Stored Procedure or Agent job. I then showed how to access it via PowerShell or PHP.

Ok, not rocket science. No big deal. So what?

Well, our use case is Instrumentation for Clinical Decision Support. One example is this Sankey Diagram illustrating in near real time, the flow of patients through an integrated health system. These are pretty standard techniques in most industries. They’re very uncommon in US Health Care and work like this sets my team apart from our peers. The only people doing anything like this (that I’m aware of) is IBM with their Patient Care & Insights product.

Capture

Largish Hospitals and Health Systems tend to spend seven figures buying BI platforms to integrate with their EHR/EMR. I’m fortunate to work for a health system that realizes that 80% of such functionality doesn’t fit any existing use case. They’re offering to support decisions our clinicians are not currently trying to make. They’re offering to answer questions we haven’t even thought of. While they may provide insight, we’re not yet equipped to handle or respond to such insight. Our senior clinical leaders are the first to say, “Cool, but so what?”.

The clinical decisions they’re asking me to support can be answered easily with some basic TSQL. I can communicate answers very simply and inexpensively with SQL Server Reporting Services and D3.js.

Learning Data Driven Documents (D3.js) is proving to be quite some journey. It’s one of the few tools that makes data visually beautiful by default. It offers Extrinsic Rewards over and above the Intrinsic Value of our analysis and synthesis.

Earlier posts have shown how to do some of this with SSRS. The next few posts will be recipes and tuts explaining how to to do some of what we’re doing with D3 in a Healthcare Setting.