The HIPAA implications for mobile health
Recently, the Institute of Medicine (IOM) and the Health and Human Services department (HHS) held a Health Data Initiative Forum to encourage the public use of data and innovation to improve health.
We had the opportunity to participate and present Practice Fusion at this conference. I also had the opportunity to be a panelist in a session on Privacy and HIPAA Implications for Application Developers (with an eye on web and mobile health applications). Some of the issues that came from this panel discussion are worth reviewing in more detail.
One point to recognize is that HIPAA is not synonymous with health data – health data, when it is collected voluntarily by consumer input (many consumer-facing web applications do this) is outside the narrow definition of HIPAA. However, when health data is held by a consumer’s physician (therefore the consumer becomes a patient), and that data is held electronically (which includes electronic billing submission), then the physician becomes custodian of that patient’s data and cannot disclose or share it without the patient’s consent. This is what HIPAA addresses.
There is both a security obligation and a privacy obligation about Protected Health Information (PHI). The physician has the security obligation of safekeeping the data – and there are processes for disclosing when (or if) that data becomes breached, as well as penalties for failure to follow the disclosure process. The physician also has the privacy obligation to ensure that no one has inappropriate access to a patient’s PHI without permission – there is also the concept of a “limited data set” that states that “only the information needed for the intended use” is disclosed (e.g. only that which is needed to pay a bill is submitted to an insurance plan, or all the information needed for direct patient care in the case of a referral to another healthcare practitioner or hospital).
Guarding the PHI data source is a central issue to application developers. Traditional enterprise applications are built to house the medical data (PHI) locally in a hospital or clinic, and rely on a locally-installed system to create a protected environment to shield that data from outside the walls of the clinic (network security and operating systems, encrypted local WiFi, firewalls that may have a few special holes poked in them to allow for remote access from outside the local area network via Remote Desktop, VPN or Citrix systems – with the secure tunneling protocols needed to assure security in transmission). This kind of setup is common, and risks HIPAA breach if local machines housing PHI (including data backup devices) are lost or stolen. “Encryption at rest” is a recommended approach (and the encryption keys are not stored on the same machine or device where the PHI is stored), so that theft of those devices yields indecipherable data – there is a Safe Harbor from HIPAA notification if this is in place.
Web applications (like Practice Fusion) relieve the burden from the local practitioner of having to set up a secure local network. The data security burden (including data backup) is borne by the vendor, which (by virtue of being centralized) can be at a level beyond what a local practice could likely afford. Data transfer between the local Internet-connected computer and the web service can be highly encrypted (at a level equivalent to Internet banking access). One of the domains of Certification for Meaningful Use (which Practice Fusion, as well as all other Certified products must meet) addresses the high level of security needed to meet Federal standards.
Mobile applications have a similar challenge. If they are consumer-facing-only (like a personal pedometer logging one’s walking or running activity, or a glucometer that stores blood sugar readings), then the data collected does not become PHI until it is presented to (and accepted into) a physician’s EHR. Like the model of web-vs.-local EHRs, developers need to minimize (or eliminate) the storage of PHI on a mobile device – cell phones/smartphones are much more commonly lost or stolen than computers, and the risk of PHI breach is more significant. If there is PHI stored locally, it must be encrypted and the encryption keys should not be stored on the same device (“remember my password” should not be an option). Most of the data displayed by mobile apps, however, is not housed in the local phone – the device interacts with a web-based store of data. The same rules should be followed for hosting that data as is needed for Certified EHR products.
Sharing PHI – a patient’s personal data for which the physician is custodian – is done only by permission. Some specific local and state laws, in fact, have specific exclusions about what kind of data can be shared requiring explicit permission (like HIV lab results, chemical dependency data, treatment of sexually transmitted diseases, family planning, mental health, and some genetic testing).
More generally – and this was brought out at the IOM conference – any communication between physicians and patients implies that a therapeutic relationship exists, and is therefore “technically” PHI. This includes such non-sensitive communication such as email appointment reminders, or pill-taking reminder mobile apps, or emails stating “your doctor has a message for you – log in to your PHR to see the message.”
It is not practical to encrypt all these kinds of communications, which do not contain health-content data, nor is it common practice. So, even though an emailed appointment reminder is, technically, PHI, it can be done routinely if there is consent by both parties to do so. A patient must be allowed the ability to opt-out of email reminders – application developers need to include this, and not build something that forces a blanket approach for everyone. In fact, setting “patient contact preferences” (email, phone, regular mail) is a Meaningful Use and Certification requirement, and addresses this issue. So long as there is mutual understanding and consent to use unencrypted email for certain “non-health data” communications, then such a feature is ok (despite “technically” being PHI).
This is important to mobile application developers. Reminder notifications (e.g. by text messaging) are an emerging type of app for smartphones – so long as there is an ability for a patient to opt-out from physician-originated messages, then there should be no hindrance. After all, these emerging kinds of health applications – mobile health, or mHealth – stand the potential to significantly improve the health of the overall population.
The workings of HIPAA, the definition of PHI, and the protection of such PHI (both at rest and in transit) are all considerations to make as this field evolves. Security of data, and privacy (permissions) of sharing that data are things that application developers need to take into account. However, when done right, what will emerge will be an array of applications and health tools that will truly improve U.S. health care, while maintaining safety, privacy and security of that data. It is a balancing act, but not insurmountable. HHS, on the one hand, wants to encourage innovation and use of health data to improve health, and at the same time wants to make sure that HIPAA is followed and PHI is protected. That is the line which application developers must walk.