Following on from my introductory post yesterday, i’ve now downloaded and viewed another of the WWDC videos – and have some more information about the Health APIs capabilities as far as device support is concerned.

Four specific Accessory Device types that follow bluetooth.org Low Energy Bluetooth GATT Specificiations have immediate built in pairing and data storage capability with the iPhone HealthKit capabilities in iOS 8 out of the box:

• Heart Rate Monitors
• Glucose Sensor
• Blood Pressure Monitor (including the optional Heat Rate data – including energy expended metadata – if provided by the device)
• Health Thermometer

For these, no specific application needs to be supplied to work with these four device types. There are a set of best practices to implement optional characteristics (eg: to confirm a chest heart monitor is in contact and is able to supply data). There are also optional services that should be implemented if possible, such as a battery service to notify the user if the device is running out of power.

Apple showed a few screenshots of the Health App during their devices presentation, which included these as an indication of what will be provided by default – if there is a set of sensors to feed this data into it:

and when you dip into the Vital Signs option:

Other accessories can be associated with an application that communicates with the device via the iOS ExternalAccessory framework, CoreBluetooth, USB or via WiFi, but can use the HealthKit framework APIs to store the data from your app into the HealthKit database. Withing’s WiFi Bathroom Scales one such example!

There is capability to put associated yes/no user requests on the Notifications screen via the Apple Notification Center Service (ANCS) where appropriate. For example, to confirm a provide an on/off which or similar binary change in the handset notifications, if this is desired.

The recommended bedtime reading for HealthKit accessory interfacing are (a) the Bluetooth Accessory Design Guidelines for Apple Products (in the Bluetooth for Developers site) and (b) documentation relating to Apples MFi program (MFi – “Made for i-devices” I guess – contains the same set of interface guidelines used by HomeKit and to add Hearing Aid Audio Transport to Apple iOS devices).

Apple also list a specific site for iBeacon, which has possibilities for handshaking applications with iPhone handsets based on local proximity – but really there for different location-based services (like a security guard being checked in and out as they patrol a building, or a health visitor attending an at-home patient – without having to rely solely on relatively power-hungry GPS co-ordinate sampling). But that’s a much wider story.

In the meantime, applications that:

• monitor or record food intake (like the excellent www.weightlossresources.co.uk site i’ve been feeding data into daily now for over 12 years)
• notify a health professional of defined “out of band” data readings from a patient
• emergency contact (outside of the “in case of emergency” sheet available on the lock screen in iOS 8)
• anything with the ability to share/download health data with the end users specific permission to a GP or Hospital (the user can subset this down in fine detail)
• any approved diagnostic aid, having been subjected to regulatory approval

are the scope of individual application developers code. All share the same, heavily secured database.

With this, Apples good work should ensure a vibrant community of use to further embed iPhone handsets into their users lives. All we need now is further devices – iWatch anyone? – that can make full use of the capabilities in the Health App. It all looks very ready to go.