Apple announced their new Health application (previously known during rumours as HealthBook) and the associated HealthKit Application Programming Interface (API) at their Worldwide Developers Conference earlier this week. A video of the associated conference presentation that focussed exclusively on it at WWDC was put up yesterday, and another that preceded it – showing how you interface low energy Bluetooth sensors to an iPhone and hence to feed it – should be up shortly.

Even though the application won’t be here until iOS 8 releases (sometime in the Autumn), the marketing folks have already started citing the already frequent use of iPhones in Health and Fitness applications here (the campaign title is “Strength” and the video lasts for exactly one minute).

Initial discoveries:

1. The application is iPhone only. No iPad version at first release (if ever).
2. A lot of the set-up work for an application provider relates to the measures taken, and the associated weight/volume metrics used. These can be complex (like mg/DL, calories, steps, temperature, blood pressure readings, etc) and are stored with corresponding timestamps.
3. The API provides a rich set of unit conversion functions (all known count, Imperial and Metric measure combinations), so these shouldn’t be needed in your application code.
4. Access to the data is authorised by class (measure type). Apple have been really thorough on the security model; users get fine grained control on which data can be accessed by each application on the handset. Even to the extent that no-one can ask “Is this user sampling blood pressure on this device”? Apps can only ask “Are there blood pressure readings that my application has permission to access please?”. The effect is that  apps can’t tell the difference between “what isn’t sampled” or “what is sampled but denied access” to them; hence inferences that the user may have diabetes is impossible to deduce from the yes/no answer given. Well thought out security.
5. There is provision for several devices taking duplicated readings (eg: having a FitBit step counter and the handset deducing step count itself from it’s own sensors). The API queries can be told which is the default device, so that when stats are mapped out, secondary device data can be used if and where there are gaps in the primary sensors data. I guess the use case is wearing your Fitbit out running when leaving your phone handset at home (or vice versa); if both are operating simultaneously, the data samples reported in the time slots mapped come only from the primary device.
6. Readings are stored in one locally held Object orientated database for all measures taken, by all monitoring devices you use. All health applications on your handset use this single database, and need to be individually authorised for each class of data readings you permit them to be exposed to. No permission, no access. This is the sort of detail tabloid newspapers choose to overlook in order to get clickbait headlines; don’t believe scare stories that all your data is immediately available to health professionals or other institutions – it is patently not the case.

The end result is that you consolidate all your health related data in one place, and can selectively give access to subsets of it to other applications on your iPhone handset (and to revoke permissions at any time). The API contains a statistics functions library and the ability to graph readings against a timeline, as demonstrated by the Health Application that will be present on every iPhone running iOS 8. The side effect of this is that the iPhone is merely acting as a data collection device, and is not dishing out advice – something that would otherwise need regulatory approvals.

Vendors/users of all manner of sensors, weighing scales, Boditrax machines, monitors, etc can add support for their devices to feed data into the users Health database on the users handset. I’m just waiting for the video of the WWDC session that shows how to do this to be made available on my local copy of the WWDC app. More insights may come once I have the opportunity to hear that through.

In the meantime, Mayo Clinic have developed an application that can message a health professional if certain readings go outside safe bounds that they have set for their patient (with the patients permission!). One provider in the USA is giving the ability to feed data – with the patients permission – directly into their doctors patient database. I suspect there are a myriad of use cases that applications can be developed for; there is already quite a list of institutions piloting related applications:

The one point to leave with is probably the most important of all. Health data is a valuable asset, and must be protected to avoid any exposure of the user to potential personal or financial prejudice. Apple have done a thorough piece of work to ensure that for the users of their handsets.

The reward is likely to be that an iPhone will cement itself even further into the daily lives of it’s owners just as they have to date – and without unwanted surprises.

Footnote: now i’ve listened to the associated Health App Devices Presentation from WWDC, i’ve added an extra blog post with more advanced information on the Health Apps capabilities and device support here.