What Developers Need to Know About Apple’s HealthKit and HIPAA Compliance

Apple gave the world a glimpse at the next wave of digital innovation at their annual WorldWide Developers conference with the launch of HealthKit and companion app Health. Both instantly turn the iPhone into arguably the largest digital health platform in the world. While wearables have captured attention and interest, from the Nike Fuelband to Google Glass, Apple’s 500 million iPhones have instantly made the promise and potential pitfalls of mobile health mainstream. 

With more than 40,000 personal health applications in app stores already, the idea of the iPhone as a personal health device is not new.  What is new, however, is that with HealthKit, Apple intends to make collected health information readily available and accessible to healthcare providers right from the device. In the States, this personally identifiable health information, once shared with an entity like a hospital or doctor is subject to the Health Information Portability and Accountability Act (HIPAA) protections and compliance requirements.  

While the HealthKit API makes the promise of collecting health information and sharing it seamlessly with healthcare providers a reality, developers face some important regulatory hurdles that need to be accounted for in order to develop apps that take full advantage of the API without getting into regulatory hot water. 

HIPAA has strict confidentiality requirements that need to be met in order to stay on the right side of the law. Any developer who builds an application that intends to use the HealthKit API to track, store, share or manage personally identifiable health information needs to be aware of what’s required of them. 

Before we dive in, there are three terms that developers need to be aware of when it comes to dealing with HIPAA: covered entities, protected health information and business associates. 

Covered Entities are the health care providers and payers that people use to get and pay for health services. From doctors, to clinics, hospitals and insurers, these organizations provide and pay for healthcare. 

Protected Health Information (PHI) is the personally identifiable health information that patients share with covered entities in the course of care. PHI can be everything from test results, to MRI scans, to something as simple as appointment schedules and phone logs. 

Business Associates are the companies and third parties that manage protected health data on behalf of covered entities in the process of providing service to patients. Business associates include the application developers building new apps for Apple’s HealthKit, hosting providers that handle PHI, and other offline service providers. If you’re building an application that handles, or could handle PHI, you are considered by law - whether you want to be or not - a Business Associate.

In September of 2013 the Final Omnibus Rule passed which required that all Business Associates now be HIPAA compliant. The United States Health & Human Services department, the administrators of HIPAA announced their intent to survey 1,200 covered entities and business associates to determine compliance audits in 2014. 

The tricky part with HIPAA is that it was written nearly twenty years ago and pre-dates the iPhone itself by a decade. Even with recent amendments, the law is not as easy to deal with as some of its legal counterparts that developers may be more familiar with, such as PCI compliance for managing credit card data and the DMCA, which deals with copyright material on the Web. 

Unlike PCI compliance, HIPAA does not have a recognized third party certification entity. While compliance is required, HIPAA states that application creators alone are responsible for ensuring compliance with the law. There are companies that will certify companies as HIPAA compliant, but their certification is not legally recognized as proof of compliance. 

And unlike the DMCA, there is no ‘safe harbor’ provision for the inclusion of protected health information in an application. Even if an application isn’t designed to collect or share personal health information the developer is still responsible for it if PHI makes its way into the application. That’s a far cry from the safe harbor that has shielded YouTube and countless others from severe copyright penalties under the DMCA. 

HIPAA requires three types of data safeguards under the HIPAA Security Rule. These aren’t either/or. Applications subject to HIPAA oversight need to be compliant in all three areas: administrative, physical, and technical. 

Administrative safeguards refer to the documented policies, procedures, training, and operational roles that are documented and maintained to limit access to protected health information only to essential staff. 

Physical safeguards are the data protection measures that limit access to hosting facilities, racks and servers, as well as mandate the data redundancy and media destruction required to ensure access and protection of PHI. A HIPAA compliant hosting provider usually covers these requirements.

Technical safeguards are the application-specific measures that developers will most likely deal with. They include things like data encryption and decryption, logging and data audits, user authentication, data transmission integrity and more.

In addition to the items we’ve already mentioned throughout the article, there are some specific things that developers will want to pay particular attention to when building for HealthKit and iOS8. While we can’t cover them all here, below are a selection of critical issues. The Developers Guide to HIPAA Compliance is a more comprehensive resource. 

The very first thing is to determine whether the application will or may eventually collect or share PHI. Remember, apps can collect consumer health information and not require HIPAA compliance. It’s only when PHI will be shared with a covered entity that it becomes subject to HIPAA compliance. 

A run of the mill calorie tracker or pedometer likely won’t need to be compliant. Tracking blood sugar levels for a diabetic to share with their endocrinologist? Compliance is absolutely necessary.

As a developer, this is where the thorny predicament of edge cases requires critical consideration. Because there isn’t a safe harbor provision, an app can end up with PHI in it, even if it’s not part of an intended use case. 

Imagine a messaging application that provides health advice from doctors based on anonymous symptoms reported by users. The anonymous part, the part that avoids HIPAA oversight, can be shattered any number of ways by users who accidentally include personally identifiable details. 

If there’s a non-trivial chance that PHI will end up in the application, developers are probably safer meeting HIPAA compliance guidelines ahead of time. The penalties for breaches are just too expensive.

iOS notifications and user communication is another area that many developers need to pay particular attention to. With the prevalence of application notifications in iOS and other mobile OS’s it’s essential that developers don’t publish PHI to push notifications. These notifications can appear on lock screens and therefore can be public without the user’s consent or intent. That’s a red flag. The same goes for email and SMS, which are not HIPAA compliant unless implemented via a specified HIPAA-compliant provider.

Application data sharing. One of the newest features of iOS 8 is the ability for applications to share data with one another. While this has been a long-desired feature for developers, it’s important to ensure that if you’re building a HIPAA compliant app that you aren’t sharing PHI data with non-compliant applications. PHI should never be pushed to email clients, messaging or social applications where it can be unintentionally made public.

High availability and redundancy is essential for HIPAA compliant applications. The law’s emergency recovery requirements demand robust failover protocols and data backup. Remote data management is also a requirement. Can the app wipe PHI from local storage on the phone in case the phone is lost? It’s important to be clear on those use cases in order to meet HIPAA standards.

Data storage and HIPAA compliance. Even if the application does handle PHI, not all of the data needs to be stored in a HIPAA compliant environment. PHI can be sent to and stored with a compliant host, while non-PHI data is managed in a traditional application database. 

Additionally, it’s important to note that simply using a HIPAA compliant hosting provider for the application data does not make a HealthKit-enabled application HIPAA compliant. The whole system needs to meet the compliance requirements - HIPAA hosting providers typically only cover one of the three safeguard mandates.

While HIPAA compliance can seem daunting application developers don’t have to do it alone. There are companies, such as TrueVault—a HIPAA compliant API and health data store—and Accountable that provide compliance as a service, making HIPAA compliant application development easier. 

Building compliant apps is worth the effort. Collecting data on a user’s phone is one thing; but data without context and the ability to affect behavior change has far less value than data that can be shared and acted upon with a user and their healthcare provider. There are plenty of digital pedometers in the market today, their standalone valuable is questionable. It’s the combination of data and expertise that will create the true value promised by mobile health. 

The world needs more developers and apps who can fulfill the vision of data collection that actually empowers its users and creates real improvement in patient outcomes. That doesn’t happen when the data sits trapped in the device. Learning HIPAA guidelines and building for HealthKit represents a major opportunity for developers to improve the lives of the people using their software. This reality alone makes managing the complexities of HIPAA well worth the effort.