Introduction
Wouldn’t it be nice if an app you use to track one activity could share data with apps you use to monitor other activities? You’d then have a more complete and intelligent picture of your health. For example a calorie counter app, such as MyFitnessPal, could increase your daily food allowance automatically when you’ve been for a swim. Your activity tracker wouldn’t think you’d been slacking off all week when you’ve actually spent 2 hours a day in the pool!
Well that is the promise of Healthkit, Apple's new Health 'aggregation' framework.
This post is going to explore HealthKit from a user perspective and use our implementation of Healthkit in v3.1 of the Speedo Fit swim tracking app to illustrate different elements.
What is HealthKit?
New in iOS 8, HealthKit is a technology which app and hardware developers can use as a store for all of your health and fitness data. You ultimately control which apps are allowed to add data to this store, read data from the store and also the specific data types involved.
The idea is that developers no longer need to write special code for each other when they wish to exchange data. I’ll talk a little bit later about to what degree Apple have achieved this.
Apple envisage there being three types of apps:
- Analysis of data & graphs
- Recording of information
- Sync data with medical records
At the moment we’re mostly type (2).
Apple's Health app itself is actually just another developer app accessing HealthKit. It just has special permissions allowing it to write 'characteristics' such as gender, height and birthday. It can also allow you to change the permissions of other HealthKit apps.
How it works
I tend to think of HealthKit as being like a mixing desk in a recording studio. All the apps are the different instruments and HealthKit is responsible for managing all the inputs and outputs. Each app only has to worry about it's connection to HealthKit.
Apple have defined over 60 different data types which can be stored. The list of data types is determined by Apple, so a bit like an exclusive nightclub, if it’s not on the list it’s not going in. Data types include things such as steps, heart rate, blood pressure, resting calories (basal metabolic rate), active calories, weight, sodium consumption and sleep - so it's pretty extensive!
When recording data there is the idea of it being a sample. Each sample is tied to one data point and has a start and end time. So say you took my heart rate at 2:01pm, then recorded the average over a minute and found it was 61 bpm, you’d record a heart rate sample with a start time of 2:01pm, an end time of 2:02pm and a value of 61 bpm. Samples can really be any length of time so as part of a swim recording I might have a sample spanning half an hour with a single active calorie measurement representing the entire swim.
CC Image courtesy of choreographics on Flickr
This is a very important concept - HealthKit is essentially a huge timeline spanning your life with all of your health & fitness data laid over it with precise start times, end times and values for each sample.
Each sample has extra data attached to it. This includes the app the sample comes from as well as things such as whether the data was from a device (e.g. a heart rate or blood glucose monitor) or was manually entered, as well as unique identifiers to help the app developer manage the data their have recorded. In our case swims are manually recorded and we store our unique id for your swim so that we’re able to remove or update it within HealthKit if the swim is deleted or altered within Speedo Fit.
Workouts
CC Image courtesy of GrejGuide.dk on Flickr
Workouts are a bit more special in that they group a collection of samples together and classify what they represent as a whole. For instance when I go running I have my GPS watch, I also have a foot pod and a heart rate monitor. The data points I have from all of that include:
- distance
- duration
- active calories
- activity type
- steps
- heart rate
My watch samples all of this about every 5 seconds so I might go for a one hour run and with 12 of these samples a minute, I end up with 720 samples for the whole hour. Those samples will then all be written to HealthKit across those separate data points and provide a very rich snapshot of my body for that time period.
For Speedo Fit we don’t quite have access to the same level of detail yet, but we log still log the following information as a workout:
- distance
- duration
- active calories
- activity type
When a swim is logged we store a single sample for the active calories which spanned the whole time from the start of the swim to the end.
Active Calories
As an aside, we have added the estimation of swim calories as part of this release. We felt that it was an important addition to make your swims in HealthKit more relevant to other apps.
The generally accepted method for estimating active calorie burn is via metabolic equivalents (METs). Every activity has a MET score reflecting the amount of exertion. An MET is the number of calories burned during an activity per kilogram of bodyweight per hour.
hours x MET x kg
There are lots of charts estimating the METs of all kinds of activities ranging from hoovering to horse riding. For our first version we’ve mapped a range of 6 METs to 12 METs for swims and we scale that based on the time in the pool and the distance swum.
This allows us to add an estimation of calories when recording swims to HealthKit, provided we are either given access to your weight via HealthKit or you provide one manually within the app.
The fact that we can request your weight via HealthKit is another example of its benefit. For example I have Withings WiFi scales at home so my weight is automatically synced whenever I weight myself. This keeps my calorie estimates always as accurate as possible.
Lastly, calorie estimations are not just for HealthKit users! You will still get them if a weight is entered in your profile and you set a start and end time on your swim.
Start times, duration & historical swim data
I think one of the guiding principles of any app contributing to a users HealthKit store is that the timeline must be sacrosanct. What I mean by that is that if the data is not complete enough then it shouldn’t be added.
When swim recording was first added to Speedo Fit, we decided to just set the date of the swim and to not worry about start times or end times so as to make it as quick and easy as possible to record a swim. In Speedo Fit 3.1 we added the ability to set a duration.
Going back to the timeline concept though, this isn’t enough for HealthKit. Without a specific start and end time for each swim in your history, it’s not possible to record them. If we were to pick and arbitrary start and end time for each swim, there’s a high chance they would overlap with other activities and future apps analysing your data would get very confused.
We have therefore made start and end times mandatory when recording a swim when HealthKit is enabled.
My data is in HealthKit, now what?
This is now really up to other app developers. Any time you turn on HealthKit in another app and it requests access to read workouts and active calories, the chances are your swimming data will be contributing in some way to the view of your health data that app is giving you.
Unfortunately Apple’s Health app currently only shows distance for running and walking, not swimming. You will see your swims on the active calories graph, so don’t worry, your data is in there!
Data, Privacy and iCloud
An interesting thing about HealthKit is that the data just lives on your iPhone. Although your HealthKit store is backed up with iCloud backup it is not synced to iCloud. There’s an important distinction there. For example, if you have a work iPhone and a personal iPhone, each iPhone will have its own distinct HealthKit store. However, providing you have iCloud backups turned on, if your phone is lost or stolen or you buy a new one, restoring from an iCloud backup will restore your HealthKit store.
Apple are making quite a big deal about this. The recorded data is of an incredibly private and personal nature and they’re preventing HealthKit stores from being passed over any kind of network except as part of a secure iCloud backup. Part of the App Store submission guidelines specifically prohibits developers from storing HealthKit information in iCloud without user permission and all apps using HealthKit have to have a privacy statement explicitly saying what we do with your data.
I think the fact your phone is the central hub of information there, collecting data from apps and health devices is indicative of Apple’s vision of the future. One where your phone is a mini-portable server and you have an set of satellite devices (Apple Watch!) which you use to send and receive data. The Apple Watch, for starters, has at least two sensors which will be directly feeding into your iPhone - heart rate and accelerometer.
The Apple Watch
HealthKit and third party Hardware
I already mentioned earlier that a data sample can be tagged as being manually entered or being from some kind of device. Most modern devices are adopting Bluetooth Low Energy as their method for synchronising with your phone. Bluetooth.org have published standards for certain classifications of devices. Apple are actually supporting four of these initially so that they can be paired with your phone and their data written automatically to HealthKit whenever they are in the vicinity of your iPhone. This includes heart rate monitors, glucose sensors, blood pressure monitors and health thermometers. So long as a device implements the specification in a standard way the manufacturer will no longer have to make their own app to live on your iPhone. I suspect that other devices will be supported as more categories become established.
Wahoo Tickr X
So how do apps know when new information is available?
One of the other aspects of HealthKit is that an app can subscribe to data points. An app can choose any number of the 60+ data points and then, with permission, ask to be notified whenever there is new information.
That means that another app might wish to know whenever you go for a swim so as to remind you to hang your wet swim shorts out to dry (instead of leaving them in your gym bag for days as I often do). It could subscribe to the workouts sample type and as soon as a swim comes in it wakes up and sends you a little notification.
A more real world case is that hospitals are starting to create out-patient monitoring apps. Whenever a patient uses their blood pressure monitor, the hospital app gets notified of the new reading, sends that data to the hospital computers, a doctor might then review it, see there’s a problem and call the patient in. And of course if the patient forgets to do a reading the app could then remind them to do one.
What are the downsides?
Perhaps one of the most clever things Apple have done is offload all of the work on to app developers. HealthKit really is just a dumb repository. An example of this is Basal Metabolic Rate (BMR). This is the calorie burn of your body when at rest. There are any number of algorithms for estimating this and it really depends heavily upon your genetics, level of muscle and fitness. At the moment it’s sitting in my HealthKit as a blank data point. Despite having a number of fitness apps installed on my phone which estimate this in-app none of them have quite plucked up the courage to be the one to write this to my store.
And that’s perhaps the crux of it, most health information, despite the exact numbers, really are just estimates. Very useful estimates which can help us to make informed health related decisions. Unfortunately by recording these to a definitive central store, it’s going to make a lot of developers nervous about committing these estimates for posterity.
Lastly, Apple are holding the keys on data points. If an app wants to record something interesting not included on those data points, they’ve got two options:
- Don’t record it in HealthKit
- Appropriate a related data point and record it as custom meta-data
For a couple of examples of (2), take sleep and swimming. For sleep you can only record awake / asleep. It is not possible to record different sleep modes such as light sleep, deep sleep and REM sleep. For swimming it’s not currently possible to record the strokes or intervals in the swim.
There is a solution to those - custom metadata. Each sample can have associated data set by the developer which other apps can read. The only problem there is that we’re going to have to agree between ourselves, as developers, how exactly we store specific data there. Without agreed metadata keys everyone is going to have their own way of doing things.
Still, it’s a lot less work than having to implement an entire custom API for every service you wish to link with!
Summary
I’ve covered a lot of ground in this post. Hopefully you’ve got a better idea of how we are using HealthKit in Speedo Fit as well as the possibilities of what can be done with HealthKit as it currently stands.
I’m personally extremely hopeful that as more developers and hardware companies adopt HealthKit, we’ll begin to get a much more detailed view of our health and daily lives. In turn this will give us meaningful insights which help us to lead happier lives.
I think it’s going to be incredibly interesting to see what is done with this data and how it is going to force developers to focus on and improve each of their areas of expertise.
Speedo Fit swim app to track your swim workouts is available from US, Canada, UK, France and Mexico app stores here. Version 3.1 with HealthKit integration will be live in the app store later today (16th October).
I'm on twitter as @earltedly if you'd like to chat more about HealthKit.