Apple HealthKit

This link will take you to the Apple Developers Kit and here are some great Video Demos of HealthKit.

Apple’s iOS 8 app is called Health, along with a HealthKit cloud API for integrating data from multiple apps and monitoring devices.

Apple’s new HealthKit cloud service logs data that’s been recorded by apps or gathered from mobile sensors and retrieve the content of that health profile. Apple wants to make its own Health app a convenient entry point to the service, but other apps will also be able to interact with the health profile.

Read this Forbes article on the Apple HealthKit.

The new Health app gives users an easy-to-read dashboard of their health and fitness data. The developers HealthKit, allows all the health and fitness apps to work together.

The first phase is to enable local storage on the iPhone of data collected by other devices.

Short term it is entirely on the phone. They do not even support HealthKit on iPad to have it work between my devices.

Apple is positioning its Health app as the point of aggregation for all the user’s different health data, and HealthKit, the development platform, to enable that integration. But critically, indications are that the health data will, for the most part, be collected by sensors (Nike+, Withings Scale, Fitbit Flex, etc) of other wearable manufacturers…. offering – i..e stay away from the hardware for now and instead provide the services & software glue to tie all the existing hardware into some sort of cohesive whole.

One reason for that might be security. The iPhone (at least the later versions) have fingerprint sensor security. If health data passes between an iPhone and an iPad how can the device(s) be sure of the user’s identity? On a single device, especially the iPhone that has fingerprint access, identity is solvable on the device.

With multiple devices, it becomes more difficult and more prone to the complexity of multiple users.

They seem to want one device to represent a single persona, says Waite, – not a bad position for a hardware vendor to take. They encapsulate your online identity for services like Twitter and Facebook onto your device, but this is primarily so that applications do not do this work themselves.

OAuth 2.0 and OpenID Connect 1.0 are likely standards for Apple to draw on, though Apple has a preference for doing identity its own way.

On the developer side of the equation, initially, Apple will be experimenting with different ways for developers to use data at different levels of permission, according to Waite:

The structure of the HealthKit is such that an application asks the user for each kind of information, and the user can opt-in or out of write and read access. For example, I might let this one hypothetical app read my steps taken and heart rate, but not my nutritional information.

The second base is to migrate some of a user’s health data to Apple’s Cloud but under the control of the user. Fadaie believes a P2P solution would provide greater security for an equal user experience going forward:

Based on the limited amount of information available, Apple’s view of eHealth is like a Dropbox for health-related information. Different apps can read/write to this “HealthBox” and Apple takes care of making the data available on the user’s different devices. If Apple’s goal is to be a provider of such a service, a P2P solution can certainly help keep this data private without storing it on Apple’s cloud (even if the data is encrypted). This will be as usable but more private for users.

The third base is the integration of the medical profession into the data stream.

Part of the challenge here is to integrate different strands of the medical profession in ways that are acceptable or satisfactory to them.

Today, the hospital or clinic would have to have a user install an app and approve it access to data. The app can then ‘siphon’ data off the HealthKit database on the phone, and upload it someplace that is accessible by the hospital/clinic.

Pharmacies, labs, hospitals, and clinics are going to want to be able to exchange data directly rather than going through apps on the user’s phone. The user is going to want to feel in control of that sort of communication as well. HealthKit today doesn’t provide that. But hopefully, it will help build momentum toward that future outcome.

Example: Health systems that use Epic will be able to integrate patient information from HealthKit into MyChart, Epic’s personal health record.

The app also holds the potential to save hospital IT teams money because mobile developers will no longer have to link with multiple apps and devices, such as fitness trackers or glucose monitors.

It will eventually include more clinical devices (a small wearable heart monitor that listens to heartbeats and reports data back in real time.)

For the healthcare industry, the most intriguing aspect of Apple’s new technologies is the potential to unite feeds from many health monitors and report back to a hospital’s electronic medical records system, making the Apple Health app a tool for patient engagement.

Discussion:

Create API’s that would be included with the eiConsole for HealthKit.

Host an eiPlatform service that would allow developers to utilize our eiPlatform engine to integrate with EHRs and Practice Mgt systems, other Devices or Equipment on a per-patient subscription cost.

Timing may be right:

“Today there is no linkage between Apple’s HealthKit and any electronic health record (EHR),” Wald says. But, he says, by next fall personal health data will be flowing from the HealthKit repository into the Mayo app, and then into the clinic’s electronic health record system.