carekit

Apple CareKit: What it means for Patient Privacy


Apple held their latest product unveil earlier this week and of course there was the obligatory newest iPhone announcement. What was more interesting to me was the announcement of Apple CareKit, a framework for developers to build apps designed to let us manage our own well being. This follows on from Apple’s previous announcements in their healthcare eco-system play – HealthKit and ResearchKit.

With CareKit we can expect an explosion of new healthcare apps for our iPhones that will enable us to monitor our medications and symptoms. As we put more of our valuable data online, what does this mean for privacy and data security? Interestingly this comes at a time when OCR has issued new guidance targeted at Application Developers.

I was recently interviewed by AIS Health’s Report on Patient Privacy, who wanted to understand the implication of the OCR guidance in the medical app space. A key element of the guidance is who falls into the definition of a Business Associate. My take is that this may lead app developers to decide that if they’re not Business Associates (BAs), they don’t need to be as focused on strong security safeguards.

Why OCR’s new App Guidance shouldn’t mean App Developers are off the HIPAA hook

There are so many apps, mobile devices and other tools for both consumers and health providers it is understandable people get confused over the nuanced definition of whether an app developer is a Business Associate or not. I applaud OCRs attempt to clarify the regulations with simple to understand use cases. But our goal should be to focus on protecting privacy and securing sensitive data, and not just whether a specific regulation applies or a particular agency has jurisdiction. Ultimately, the privacy and security of the data your app helps create, store or transmit should be your objective, whether HIPAA applies or not. These use case highlight again the need for cross agency guidance.

From a Covered Entity’s (CE’s) point of view, protecting all of their data is simply part of a good risk management strategy. So if you plan to work with a CE, touching PHI or PII, you’re going to be asked to prove you’re taking the right steps for data privacy and security.

OCR provides six scenarios to illustrate when an app developer is or is not a BA. It is worth reading.

For my part there are a 3 simple tests, each of which must prove true for HIPAA to be applicable:

  1. Is the data health related? Typically for the treatment, diagnosis or payment of care.
  2. Is the data identifiable? Either via direct identifiers or in combination with easily researchable data
  3. Are you providing the service on behalf of a CE? If you have a contract to provide the service for a provider or plan, as opposed to the user simply signs up for your service directly.

Critically, circumstances prevail when it comes to the BA definition – you may or may not be depending upon yours. And this is the problem. You can answer yes to 1 and 2 above but if the answer to 3 is NO, then HIPAA does not apply, regardless of how sensitive the data is. However, BA or no BA, the imperative of data privacy and security should reign supreme. So whether HIPAA applies or not, raise the bar and protect the data you come in contact with, no matter how you think you’d be defined. It can only work in your favor.

 

Follow-on to “New OCR App Guidance Shows Need for CEs to Insist on Safeguards from Vendors” published in Report on Patient Privacy, Volume 16, Number 3, March 2016.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *