Apple HealthKit - energizing the healthcare industry?

Den Howlett Profile picture for user gonzodaddy September 17, 2014
Apple HealthKit looks like a slam dunk for the health and fitness industries. Is it that straightforward? Not at all.

I was bemused when Greenmonk analyst Tom Raftery posted a story to Facebook talking about Apple HealthKit being trialled at several US hospitals.

When Tom and I met in the early summer, he was insistent that he didn't want to see health data going back to providers who were likely to sell that data. I don't have a problem with that provided it becomes part of aggregated data used to benefit myself and a wider population. To me, data sharing is vital to ensuring there are large universes of data from which useful information can be extracted. Even so, I can see the merits of Raftery's argument. This was put into sharp focus when he said  on Facebook:

The two main players in the emerging mobile health tech world are obviously Apple and Google (Android). Of the two, selling data is Google's business, not Apple's. If Apple were found to be selling health data, they'd be in huge trouble. Of the two, I'd be far more likely to trust Apple with my health data than Google.

I suspect many others will feel the same way because even if Google could argue that data sold was for the benefit of others, it doesn't have the same ring of confidence that Apple is trying to foster. If you agree with that assessment then Apple has pretty much won the perceptual argument even before the new iPhones get out to market.

Apple's Ts & C's to the rescue

Looking at Apple's terms and conditions for inclusion of new applications built upon the HealthKit, the company is unequivocal:

27.3 Apps using the HealthKit framework that store users’ health information in iCloud will be rejected
27.4 Apps may not use user data gathered from the HealthKit API for advertising or other use-based data mining purposes other than improving health, medical, and fitness management, or for the purpose of medical research
27.5 Apps that share user data acquired via the HealthKit API with third parties without user consent will be rejected
27.6 - omitted as not relevant to this discussion
27.7 Apps using the HealthKit framework must provide a privacy policy or they will be rejected
27.8 Apps that provide diagnoses, treatment advice, or control hardware designed to diagnose or treat medical conditions that do not provide written regulatory approval upon request will be rejected

That answers Raftery's concerns and those of many others I suspect.

As a side issue it also suggests that putting out a larger format iPhone is a much smarter move than people think. Larger format means the potential to show more data.

If Apple can persuade health organizations that the combination of larger format and a higher pixel density wrappered around strict development guidelines, then the potential for applications that can be used to advance medical knowledge becomes more attractive.

Is that a reality? It shouldn't be an issue given that I know plenty of instances where iPads are routinely used to send and receive healthcare data inside medical facilities. But those are mostly small or modest scale projects that are barely out of proof of concept. The HealthKit opens up an entirely different conversation that puts apps into the AppStore. But there's a gotcha.

Apple doesn't pass the risk test

I'm aware from recent conversations that healthcare providers like the idea of sharing information because they believe that everyone benefits. That would imply more emphasis on applications from the AppStore, the data for which is mediated by one or other provider. Why? Because the AppStore has automatic distribution of the kind individuals cannot expect to achieve.

However, Chris Paine has pointed out a problem with the way Apple rejects 'beta' apps where Android doesn't. This is about risk mitigation, a topic about which enterprise cares deeply:

In the Android application marketplace (Google Play) there is allowed the concept of a Beta version of application. Many popular applications (for example Chrome and Firefox) have beta versions of their software that showcase and test out new versions of UI and functionality.

This allows companies to test out new versions of software before their major install base start using it. And because the software is flagged BETA people know that there might be things different. It is a risk reduction strategy for not only the consumers of the software but also the developers. Win-Win!

Apple however in their app store submission guidelines:

2.9 Apps that are “demo”, “trial”, or “test” versions will be rejected. Beta Apps may only be submitted through TestFlight and must follow the TestFlight guidelines

...and from the TestFlight guidelines:

External Testers (Coming Soon)

Once you’re ready, you can invite up to 1,000 users who are not part of your development organization to beta test an app that you intend for public release on the App Store.

Paine summarizes:

...if you’re a SaaS developer and you want to help your customers by reducing your risk and theirs in the mobile application deployment space, build for Android, not Apple. If you care about enterprise, then be aware that risk mitigation is a big thing. The reality is that as an enterprise developer we need to deliver for both Android and Apple devices, but one of them is clearly more enterprise friendly in one particular respect.

In the short term this will be an impediment to Apple developers hoping to build health related applications for inclusion in the app store. There are workarounds in that developers are not obliged to put Apple apps into the app store but that then misses significant opportunity both commercially and  for the benefit of all. Let's add a twist to this.

Android isn't a done deal either

While Paine may be right, based upon risk mitigation factors, there are other issues that impact the Android developer community.

A developer recently told me about a testing organization inside one of his customers where they have 115 mobile devices of which 114 are Android. That harks back to the old days of UNIX where you had to test against numerous flavors of UNIX before any product was shipped. It was an expensive process. It's doubtful that any organization will test against more than a handful of devices but with a preference for Apple.


On its face, HealthKit is not just a step forward but a whole new opportunity that will drive attention  in important and emerging markets.

It must be an open question how the market shapes up because while there will be obvious commercial considerations, we can't assume that the technology of one provider trumps another. Right now, Apple has small market share but its approach to marketing HealthKit plus larger format iPhones could be compelling enough to drive momentum that outpaces Android.

A grey colored placeholder image