Make your practice more efficient. Get in touch with our Sales team today at (415) 993-4977.
Contributing Writer · Feb 7, 2012

mHealth Challenges Around Privacy and HIPAA

Emerging technologies are beginning to blur the traditional, clear distinctions around privacy and health data – this is especially true with mobile health (mHealth) solutions. Those involved in regulatory circles are trying to develop a cohesive framework that will encourage innovation, while at the same time protect consumer privacy.

A little background…
General consumer privacy around Personally Identifiable Information (PII) is addressed by a set of rules that affect everyone. At the federal level, PII is defined in certain standards (NIST SP 800-122), and protects confidentiality of PII in information systems from inappropriate access and disclosure. Some types of personal identification numbers, such as social security numbers or bank account numbers, are particularly sensitive (can be used to commit identity theft and steal money from bank accounts). Best-practices, particularly using Internet banking products, focus on protecting this kind of information.

Health information has an additional layer of regulation – HIPAA protects Personal Health Information (PHI) from being disclosed without a patient’s consent. HIPAA privacy and security was initially defined in the Health Insurance Portability and Accountability Act of 1996, and revised in the 2009 HITECH portion of ARRA (the same legislation that enacted the federal EHR Incentive Program, or “ meaningful use”).

HIPAA defines “covered entities” (CEs) – health care providers (including doctors, hospitals and laboratories), insurers, and certain kinds of intermediaries. It also covers “business associates,” who manage PHI on behalf of CEs, and requires that Business Associate Agreements be in place to codify that the PHI is managed in a way that maintains security and privacy.

Consumer-generated health information vs. PHI
We are seeing an explosion of consumer-generated health data on the Internet, as well as in the mobile app space. A myriad of sites offer tools to help individuals track various health-related statistics, and perhaps share them socially with their friends. Things like pedometers or FitBit devices help track healthy walking and activity. Self-entered calorie counters help manage eating habits. In fact, a whole Quantified Self movement is emerging where self-tracking tools are believed to be an important feedback loop that helps enthusiasts improve their health status.

Such consumer-originated data, even though it is “health data,” is not PHI as covered by HIPAA. No HIPAA-defined CE holds this data. It is PII, and is covered by general privacy rules about that, but it is not PHI.

Now when that health data is shared with a CE – with a doctor, hospital, insurance plan, or other HIPAA-defined CE – then it becomes PHI. From the consumer side, the self-created data can be shred with anyone that individual wants – even posted on Facebook, if desired. However, the data that is shared with the doctor is PHI, and the doctor cannot share it with anyone else without the patient’s consent.

This kind of distinction makes the security requirements around data sharing a little asymmetrical. If a consumer wishes to disclose data to someone else, it can be done in a less-secured way – a regular email (which is not secure enough to meet HIPAA requirements) can state “my blood sugar this morning was 103!” and can be sent to a friend, or whomever. Sending such an email to one’s doctor, however, is a little more dicey – the doctor is a HIPAA-defined CE, and receipt of such an email would need to be protected once it is received (it becomes PHI on the doctor’s end). Better to use a secure way, such as a secure web-mail portal requiring login and password, for sending that kind of information – that way the doctor won’t need to secure the received message manually and destroy the original unsecured message.

Communication from a doctor to a patient is PHI, given that the context of the communication implies a therapeutic relationship – it thus needs to be secured. If a doctor wants to tell a patient “your blood sugar this morning was 103,” then that message needs to be protected in a way consistent with HIPAA security (a secure message, not an unencrypted email).

Where it gets fuzzy
A number of mHealth applications are emerging that bridge the gap between consumer-generated simple health data and PHI. For example, let’s consider a potential application that prompts people on maintenance medications dose-taking – it will create an alert that says “take your medication.” For the sake of example, let’s say that this smartphone app also collects some information from the patient – questions are asked like “did you take your med?” and “if not, why not?”. Or even, “would you like to see some information on alternatives?” (and render ads if answered “yes”) – or maybe not even ask for permission and offer ads for alternatives anyway.

If such a postulated app were generally available directly to the consumer, downloaded by the consumer, and used to collect one’s own health data, then it would simply be consumer-based health data – even if the data is associated with a specific cell phone number (not technically PII).

However, if that same app were “prescribed” by a HIPAA-defined CE (such as a doctor, an insurance company, or an independent pharmacy drugstore), then a therapeutic relationship is implied. If the app were designed to send that data back to its originator – back to the insurance company, or the doctor, or the retail pharmacy – then the sent-back data is PHI, and needs to be protected at HIPAA-security levels. Further, the patient needs to be able to opt-in about whether the data can/should be sent back to the CE – keeping the data oneself maintains it as simple “consumer health data” but sending it back to a CE makes it PHI.

Emerging technology dances the line between consumer health data and PHI. The HIPAA implications of such technology should not be feared – only taken into account when designing such systems.

When the distinction between consumer health data and PHI is clear, then the levels of security and permission that are appropriate can be built into these new products. Innovation in the mHealth space should be encouraged – after all, dramatic advances in the health of the country can emerge from such new technology. It needs to be done right, however. This is an area where early consultation around HIPAA and data privacy and security would certainly be worthwhile. We will likely see the emergence of such consultative services more and more as this new field of technology evolves.