As if we needed any reminders, Apple has introduced a countdown clock for its September 9th “special event” at which most observers believe the company will launch new versions of its iPhone, as well as a wearable device many are calling the iWatch.  True to form, Apple is not providing any formal pre-event details about the content of the announcement, but over the past few months a number of industry insiders have published nuggets of information purporting to outline certain functionalities of Apple’s new offerings, including the new iOS, HealthKit, the Health app, and the iWatch itself.

One thing seems clear from this steady drumbeat of information:  Apple is going all in on health and fitness.   

To be sure, there are a variety of other players in the wearable space trying to capture that market as well, but as Fred Wilson pointed out several months ago, when Apple decides to do something, we should “pay attention to what Apple does. It is more important than you think.”  We could not agree more.

Of course, we’ve written previously about the opportunities for Apple and other companies in the mobile healthcare space, and have speculated with the rest about what Apple may do.  But now that Apple has signaled its entry into healthcare (by a cannonball into the pool, as some might suggest), we thought we’d take a step back and assess a few key issues and challenges that we think will come to the forefront very quickly not just for app developers, but also for Apple.

For starters, we’d be remiss if we did not comment on Apple’s navigation of certain regulatory challenges relating to FDA regulation of mobile medical apps.  We’re not privy to the amount of discourse between the two, but in our view, it appears that Apple has been downright masterful in facilitating the creation of a more flexible and pragmatic regulatory environment.  Look no further than FDA’s evolving views on the types of apps that will be subject to FDA approval and oversight, as well as FDA’s proposed guidance issued last June to deregulate medical device data systems (MDDS).

The end result, of course, is that it appears that Apple has paved the way for the development of a health and wellness ecosystem that will allow and encourage individuals to aggregate health and wellness data from multiple iPhone and iWatch apps.  So get ready for an explosion not just in the development of health and fitness apps, but also in the volume of patient generated healthcare data arising from those apps.  All signals point to Apple’s belief that a “health revolution” can be founded upon a data-centric platform, where its Health app will provide a dashboard for health and fitness data, and HealthKit will allow cross-app access and sharing of a user’s health data, with the overarching goal of empowering users to better understand and manage their health and wellness.

And therein lies one set of critical challenges for Apple and the app developer community.

Again, we go back to Fred Wilson and some comments he made about Apple at TechCrunch Disrupt last May:  “Their stuff in the cloud is largely not good.  I don’t think they think about data and the cloud.”  Uh oh.  

Irrespective of whether Fred Wilson is right or wrong, his statement highlights a fundamental question about the potential challenges for an app ecosystem designed largely around the creation and sharing of health data, one of the more highly regulated data sets not just in the US but around the world.

To be sure, the world will likely find out more on Tuesday about Apple’s approach to leveraging HealthKit and its Health app and how it thinks about healthcare data, most likely by reference to some its collaborations with pilot partners like Mayo Clinic and Epic.  But we also view Tuesday’s event as the beginning of a slower process that will determine whether Apple’s approach to healthcare data will give app developers such as hospitals, physicians and other health care providers the comfort they need to push them to participate in the ecosystem and be a part of Apple’s health revolution.    

There is no question that Apple will sell a lot of iWatches packed with sensors that can measure or track a variety of personal health data points.  The larger issue is whether app developers will find HealthKit and its developer terms friendly enough and not overly burdensome or confusing so that they engage in the ecosystem and create apps to leverage users’ health care data.  While Apple appears to have successfully navigated the regulatory waters at FDA for the time being, healthcare data privacy laws such as HIPAA and similar state privacy laws present an entirely new paradigm for Apple to maneuver.  In many ways, Apple is in uncharted waters.  

By way of background, let’s start with some basics around healthcare data privacy.  As an initial matter, the restrictions in HIPAA regulating the use and/or disclosure of certain individually identifiable health information, known as “protected health information” or PHI, generally apply only to “covered entities” like health care providers, health plans or health care clearinghouses and the so-called “business associates” of covered entities (third parties that perform certain functions on behalf of covered entities).

Many existing companies with wearables or health apps like Map My Run and Fitbit are not “covered entities,” are not specifically subject to HIPAA, and therefore are not bound by HIPAA’s restrictions on the use and disclosure of health data.  That said, however, many app developers attempt to be sensitive to user privacy, and have implemented policies that they will not use, disclose or sell any identifiable user information to third parties.  This does not mean that the wearable company or app developer will not disclose any information to a third party, but rather that the company or app developer can disclose, if it wishes, “de-identified” information about users.

To “de-identify” health data, many app developers look to HIPAA’s de-identification standards as a benchmark.  Under HIPAA, PHI can be de-identified in one of two ways: (i) through an expert determination by a statistician; or (ii) by the removal of 18 types of identifiers. See this chart from CMS for a good description of the two approaches.

In our experience, if app developers seek to de-identify user data, they generally rely on the second method above, which is generally referred to as the de-identification “safe harbor.”

So, while many current health app developers may already have a passing knowledge of HIPAA and standards for de-identifying user information, app developers seeking to utilize HealthKit and the purported iWatch will need to get comfortable with Apple’s evolving view on data privacy and security.  In fact, Apple already has issued some important guidance as to its views on data privacy and security and how app data can be accessed and disclosed by developers. 

From what we have observed in published reports about HealthKit, however, we think there are some lurking legal and regulatory landmines that may cause some critical developer segments – like hospitals, physicians and other healthcare providers – to be extremely cautious about developing apps to participate in Apple’s proposed healthcare ecosystem. 

The more significant challenge in our view relates to iCloud and how it will interact with HealthKit and the healthcare data generated by apps utilizing HealthKit APIs. While Apple’s new App Store terms and conditions indicate that HealthKit cannot be used to store users’ health information in iCloud, Apple’s revised developer agreement and iCloud addendum takes a more nuanced approach that may cause confusion among the developer community. 

In particular, except with Apple’s permission, Apple’s new iCloud addendum prohibits developers from using iCloud to receive, transmit or maintain any individually identifiable health information (including “protected health information”) or use iCloud in a way that would make Apple the developer’s or any other third party’s “business associate” for purposes of HIPAA.  Essentially, this provision means that Apple will not commit to complying with the privacy and security requirements of HIPAA relating to protected health information.  Nor will it sign a business associate agreement with a “covered entity,” such as a hospital, physician or other health care provider, that would require it to comply with HIPAA. 

Apple’s reluctance to provide such HIPAA assurances likely will give some potential “covered entity” app developers (like hospitals) pause about developing or utilizing apps leveraging HealthKit or iCloud. It should come as no surprise to Apple that potential developers that are also health care providers would be concerned about HIPAA compliance, particularly in light of the recent data breach involving Community Health Systems in which certain information for 4.5 million patients was compromised by hackers. 

But it is worth noting too, however, that Apple’s iCloud addendum appears to permit app developers to use iCloud to store, receive, transmit or maintain user health information that is not individually-identifiable.  So it appears that app developers can use iCloud to store, maintain, transmit or back up any de-identified health data generated by their apps.  

In light of Apple’s distinction between “individually identifiable” and non-individually identifiable health information, we question whether additional restrictions imposed upon developer use of HealthKit data would apply to user health data that is de-identified by app developers.  As most readers are likely aware, recent reports have detailed Apple’s changes to certain provisions of its iOS developer license agreement to prohibit developers from doing a number of things, including (i) selling health information collected through HealthKit “to advertising platforms, data brokers or information resellers,” (ii) from using user health information from HealthKit for purposes other than providing the health or fitness function or services relating to the app, and (iii) from disclosing health information collected through HealthKit to any third party without the user’s consent, and then only for the purpose of enabling the third party to provide health or fitness services to the user. 

However, the precise parameters of these restrictions are ambiguous, as it is unclear whether app developers are permitted to utilize de-identified data, as many currently are doing.  To inject further ambiguity into an already murky framework, if Apple intends to permit app developers to use HealthKit data that is de-identified, we question whether some of the data is capable of de-identification in accordance with de-identification methods typically utilized by app developers and related parties. 

As we noted above, most developers in our experience de-identify individually identifiable information through the de-identification “safe harbor” process (i.e., the removal of 18 types of identifiers), as opposed to through an expert determination, which can be a lengthy and costly undertaking.  Importantly, of the 18 types of identifiers that must be removed to render health information suitably de-identified within HIPAA’s standards, app developers would be required to remove “biometric identifiers, including finger and voice prints.”

Of potential concern to app developers, the list of potential biometric identifiers is not exhaustive, and conceivably could include identifiers based upon health care data measured by an app, like a user’s heart beat for example.  If an app developer were forced to remove the very health data that her app measured or tracked in the course of de-identifying the data, it would entirely defeat the purpose of the app and the developer’s incentive to develop within the Apple healthcare ecosystem.     

While we all hope to learn more about Apple’s plans to develop its health app ecosystem on Tuesday, Apple will need to address two basic issues relatively quickly:  (i) because the success of Apple’s entry into the healthcare space depends largely upon the ability of the app developer ecosystem to build apps that leverage HealthKit, developers will need to have clarity and comfort with the data use and/or security requirements that Apple is imposing upon them, and (ii) in light of Apple’s imposition of certain data security requirements on developers, it will need to have a framework in place to monitor whether app developers are in compliance with those data security requirements.   

As we said many months ago, we think Apple has a unique opportunity to transform how consumers think about their own health, fitness and wellness, how they interact with their healthcare providers, and ultimately, to redefine how healthcare is delivered.  

But as those opportunities depend upon Apple’s ability to create the necessary data security foundation to work with and leverage multiple health data sources, the success of its strategy may hinge on whether users, as well as app developers, are comfortable with Apple’s efforts to address data privacy and security in a meaningful way.

We’ll find out more tomorrow.