Apple, what are your intentions with my health care?
With their health records API, Apple is poised to become a critical player in health care
This was originally published as a part of the weekly Healthcare Handout newsletter: a discussion of the business of healthcare. To see more and subscribe, visit healthcarehandout.com
This January, Apple announced a new feature to be introduced in iOS 11.3: your clinical health records, on your iPhone. Specifically, if you own an iPhone (or iOS device), and use one of the 500 or so hospitals and clinics Apple has relationships with for your health care services, you’d be able to extract your health data from those providers and store and view it on your phone.
The response was muted. It drew strong comparisons to failed and underutilized personal health records of the aughts like Google Health and Microsoft HealthVault. It begged the question: how interested is the general population in holding close their health data? The most glowing endorsement came from former CTO of the US Aneesh Chopra in a Wired article where he, along with hospital CIO Shafiq Rab argued that the most important part of Apple’s health announcement is that they would be using the FHIR standard for transferring health data. Apple, as tech industry behemoth, cemented FHIR as the standard for health data interoperability. At least they found a silver lining.
Apple upped the ante this Tuesday. They announced in a session at their World Wide Developer Conference that they’ll be opening up an API to their health records service. Developers will now be able to build apps that can draw upon the clinical health data users are storing on their phone.
I’ve been holding off on delving too deeply into Apple’s health care moves, frankly because I didn’t think there was much going on there. Now I’m seeing the smoke, and where there’s smoke there’s fire (or FHIR).
The Why of Apple
Apple is a device company. This used to be much easier to say when they made all their money selling iMacs and PowerBooks, but as they’ve gotten deeper into services like the App Store, Apple Pay, and Apple Music, analysts have begun to wonder if Apple might be morphing into services company.
Ben Thompson, writing about Apple in its middle age, grappled with this very issue. After noting that Tim Cook has held true to Apple measuring success in terms of active devices rather than active users, Thompson says:
“If companies are what they measure, then what matters to Apple is the number of devices sold, not the number of users. Indeed, the user is a means to the end of selling a device — and ideally more than one at a time!”
Apple uses services as a means to enrich and deepen the experience for users on their devices. Without the App Store, your iPhone would be a very pretty device for making phone calls.
We must, then, evaluate Apple’s health care moves in the context of how they’ll help Apple sell more devices.
The Health Data Middleman
The world of health data, specifically Electronic Health Records, is terribly fragmented. Each hospital, health system, and clinic has its own data, and each of these utilizes systems provided by a slew of vendors. For a single patient who has seen three doctors in three different clinics (not a wild scenario by any measure), it’s possible there are three EHR records on three different systems, all containing pieces of that patient’s complete health history.
Apple’s health record API could have two key effects:
A truly patient-centered health record
Due to the above fragmentation, it’s nigh impossible for patients to extract their health record data from all their providers (especially historically) and compile it in a single place. By going out to providers themselves, utilizing what will become the industry standard FHIR, and setting themselves up as the central repository, Apple, with their dogged focus on the user experience, has created the first application that has a reasonable shot of being a worthwhile personal health record. By reducing the friction of adding patient data to the repository, Apple opens it up to a much wider set of users.
Apple is also reducing friction by offering this as a built-in tool for their device users. Your health data is now an additional benefit of being an iPhone user.
But, as Google and Microsoft discovered with their PHRs, storage of health data isn’t a huge selling point. The value comes from being able to easily gather health data that already exists. Apple is reducing the difficulty (by an order of magnitude) of getting that health data, and then they’re going to help users wring extra value from it by opening it to developers.
Opening health records, and patients, to developers
Just as the value of the iPhone is magnified by the vibrant community of developers building interesting applications, the utility of a patient’s health data is enhanced by applications that can interpret, contextualize, and wring insight from that data.
Developers hoping to build applications for health have been stymied by fragmentation. Developers can build an application that feeds off EHR data to provide insights to patients, but they have to build ad-hoc interfaces with EHRs, and garner permission from providers to access and use their patient data. This creates a process that, while possible, is complicated and full of barriers for utilization.
By taking on the tough and expensive work of creating those relationships with providers, Apple has dramatically reduced complexity for developers. This allows developers to offload complexity to Apple by simply connecting to their API. They can focus instead on building rich applications that solve problems for users.
In their announcement, Apple touted Medisafe, the first (and only) app to use the health record API so far. Medisafe founder Omri Shor in mobihealthnews:
“A real difference is [this integration] does not require us to sign documents with the hospital,” Shor said. “The approval process is simple. Because Apple is the middleware between the two of us, that does not require us to do all of those processes that we have to do with a hospital. And you know the signatures and processes, that is something that slows innovation dramatically.”
“You have a toggle inside Apple that will keep it always on,” Shor said. “The moment the physician switches you from one drug to another, Medisafe immediately gets a notification remind the user to change that. So no matter what changes in your regimen, you’re current and up to date throughout the entire process.”
Apple’s HealthKit thus becomes a platform within a platform. Health systems and providers supply patient data to offer their patients a richer experience, and developers use it to access the data they’d otherwise have a hard time acquiring, and users. Apple stands in the middle, earning revenue through traditional app store sales of health apps, and deepening the richness of the user experience on Apple devices.
It’s a long-term strategic bid for user lock-in. Abandoning an Apple device for Android means leaving behind your unified health record, not to mention the ignominy of becoming a green bubble in iMessage. You also forfeit all of the apps that help you interpret that health data. By being the health data middleman, Apple makes you more likely to stay in the Apple ecosystem by purchasing more Apple devices.
In short, Apple does the heavy lifting of creating provider relationships for data movement, gives developers a de-risked shortcut for creating health-focused applications, and creates a much deeper lock-in for patients using these apps that, because of the network effects Apple is building, will only be on iOS (for at least a little while).
And because of the network effects between developers, hospitals, and patients, it will only get easier for Apple to recruit more developers, hospitals, and patients. An addition in any cohort increases the overall value of the network to all.
The addition of this health record API moves Apple from being a tech company dallying in health care, to one that could become a serious player relatively quickly. I’ll certainly be taking Apple’s health care talk more seriously going forward.