Apple recently announced Health and Healthkit as part of iOS 8, and initial responses have been mixed.
At one extreme, the (highly biased) CEO of Mayo Clinic called Apple Health “revolutionary.” At the other, cynical health IT pundits claim that Apple Health is a consumer novelty and won’t crack the enigmatic healthcare system. As a cynical health IT pundit myself, I’m more inclined towards the latter, but have some optimism about Apple’s first steps into healthcare.
For the uninitiated, Apple Health is a central dashboard for health related information, packaged for consumers as an iOS app. Consumers open the app and see a broad array of clinical indicators (e.g. as physical activity, blood pressure, blood glucose, sleep data). You can learn more about Health and Healthkit from Apple.
The rest of this post assumes significant understanding of modern health IT challenges such as data silos, EMPIs, HIEs, and an understanding of what Health and Healthkit can and can’t do. I’ll address what Apple Health does well, ask some questions, and then provide some commentary.
Apple Health does a few things well:
1) Apple Health acts as a central dashboard for consumers. Rather than switching between five different apps, Health provides a central view of all clinical indicators. In time, Health could help patients understand the nuances of their own data. By removing friction to seeing a variety of indicators in a single view, patients may discover correlations that they wouldn’t have observed before. With that information, consumers should be able to adjust behaviors to lead healthier lifestyles.
2) Apple Health provides a robust mechanism for health apps to share data with one another. Until now, health app developers needed to form partnerships with one another and develop custom code to share information; now they can do this in a standardized way with minimal technical or administrative overhead. This reduces app lock-in by enabling data liquidity, empowering consumers to switch to the best health app or device and carry data between apps. This is a big win for consumers.
1) How does Apple Health actually work? Apple provided virtually no details. Does the patient need the Epic MyChart app on their phone? Is there custom code integrating iOS to Epic MyChart? Is there a Mayo Clinic app that is separate from Epic MyChart? If not, how does Apple Health know that the consumer is a Mayo patient? Or a Kaiser Permanente patient? Or a Sutter Health patient?
2) Does the patient give consent per data value, or is it all or nothing? How long does consent last? Must consent be taken at the hospital, or can the patient opt in or out any time on their phone? Who within the health system can access the consented data?
3) Given that there are hundreds of EpicCare silos and dozens of CareEverywhere silos, how does Apple Health decide which silo(s) to interface with? Does data go to an HIE or to an EMR? If to an HIE, can all eligible connected providers access the data with consent? If a patient has records in multiple HIEs and EMRs (which they likely do), how does Apple Health determine which HIE(s) to push and pull data from?
4) Does Apple Health support non-numerical data such as CCDAs? What about unstandardized data? For example, PatientIO allows providers to develop customized care plans for patients that can include almost any behavioral prescription. Examples include water intake, exercising at a certain time of the day, taper schedules, etc.
5) Can providers write back to a patient’s Health profile? Given that open.epic doesn’t allow Epic to send data out, how could Apple Health receive data from Epic?
7) How will Apple handle competing health apps installed on the same consumer’s phone? For example, if I tap “more diabetes info” in Apple Health, will it open Mayo Clinic’s app (and if so, to the right place in the Mayo Clinic app?) or the blood glucose tracking app that came with with my blood glucose meter? Or my iTriage or WebMD app?
8) Is Apple Health intended to function as a patient-centric HIE? If so, what standards does it support? CCDA? FHIR? Direct?
1) The Apple-Epic partnership is obviously built on open.epic, which Epic announced in September of 2013. It’s likely that Apple and Epic reached an agreement around that time, and asked the public for ideas on how to shape the program to get a sense of what developers wanted.
2) The only way to succeed in health IT is to force the industry to conform to one’s standards, or to support a hybrid of hybrids approach. Early indicators show Apple (predictably) trending toward the former. Unfortunately, Apple’s perennially Apple-centric approach inhibits supporting the level of interoperability necessary to power an effective consumer health strategy. Although Apple provides a great foundation for some basic functions, the long term potential based on the current offering is limited. What Apple has produced to date provides for sexy screenshots, but appears to fall short of addressing the core interoperability and connectivity issues that plague chronic disease management and coordination of care.
3) In a hypothetical world at some indeterminate point in the future, there would be a patient-facing, DNS-like lookup system for provider organizations (Direct eventually?). Patients should be able to lookup provider organizations and share their data with providers selectively. Apple Health provides a great first step towards that dream world by empowering patients to see and, to some extent, control their own data.