"Patient engagement is the holy grail of healthcare,"1 according to one hospital executive. Indeed, there is real money in the development of products and systems that support the patient's involvement in his or her healthcare. The mHealth marketplace is teeming with solutions that promote patient engagement by harnessing technology to enhance the patient's ability to communicate with his or her provider. For example, an mHealth product may permit a patient to email, text or video chat with the provider, or receive lab and other results. It is unlikely to come as a surprise that particular privacy, security and other legal risks and requirements arise any time a patient becomes more directly involved in his or her care, especially in the mHealth arena. This article offers a sampling of some of these requirements. Please keep in mind that the specific use of the mHealth solution will determine what laws apply.
Electronic Health Records
Many mHealth products are intended to interact with electronic health records (EHRs). The Health Information Technology for Economic and Clinical Health Act of 2009 (HITECH) allocated roughly $20 billion to provide financial incentives to hospitals, physicians and others for the adoption of EHRs. To be eligible for incentive payments, an eligible entity must demonstrate that it is a "meaningful user" of EHR technology by satisfying certain objectives and standards. The intent of the EHR initiative under HITECH is that by incentivizing hospitals, physicians and others key healthcare entities to adopt meaningful use EHR technology, ultimately all providers and payers (e.g., skilled nursing homes, commercial payers, etc.) would have to use the same technology.
On September 4, 2012, the U.S. Department of Health and Human Services (HHS) issued the Stage 2 Meaningful Use Regulations that include several core objectives to promote patient engagement through EHR technology. Specifically, under the Stage 2 Meaningful Use Regulations, a provider must demonstrate that its EHR is able to perform certain tasks with a defined percentage of its patients: 1) to send messages to and from the patient; 2) the permit the patient to view online, download and transmit his or her health information within certain time frames; and 3) to identify patient-specific education resources and provide those resources to the patient. Ultimately, a provider's EHR technology will have to be able to meet these core objectives for all of its patients. HHS will add further meaningful use requirements over the next few years.
Those mHealth solutions that are designed to operate with EHRs have to comply with the certification standards, specifications and criteria specifically established for EHRs by regulation. With respect to secure messaging, this means that the product must encrypt and hash health information according to certain National Institute of Standards and Technology (NIST) standards. Therefore, any mHealth solution that falls under the EHR regulations must ensure compliance.
HIPAA protects the use and disclosure of protected health information (PHI) by hospitals, payers and billing companies, as well as their third-party business associates. PHI includes any data that clearly identifies (names, addresses, Social Security numbers, etc.) or could be used to identify an individual (images or medical record numbers). Virtually any time one of these entities uses or shares PHI, including to permit patient engagement with a provider through a mobile solution provided by a third party, the HIPAA standards apply.
Potential HIPAA privacy and security issues arise when a provider engages with a patient by allowing him or her to access medical records or through secure messaging. The biggest risk is that a person who is not the patient gains access to the patient's medical records, or messages with the provider. HHS will have to spell out how a provider can satisfy these privacy concerns while meeting the Stage 2 Meaningful Use Regulations' patient engagement objectives.
The HIPAA security standards impose specific requirements on the use and disclosure of electronic protected health information (ePHI) that would include any information transmitted wirelessly through an mHealth product. Although the HIPAA security standards do not specifically require encryption, it is implicitly recommended. Further, data that are breached but that are encrypted according to NIST standards adopted by HHS are not subject to the cumbersome HIPAA data-breach reporting rules. Strong encryption protection would ensure that hackers do not access the ePHI through a patient engagement feature of an EHR system. However, the system would still need to address the issue of how to verify the patient's identity in the case to guard against the practical concern that even if an individual has the tools necessary to access the ePHI or communicate with the provider, that individual may not be the patient (e.g., a person accessing the records of his or her spouse without permission).
It may also be worthwhile to keep in mind other key HIPAA standards, such as requirements for privacy statements, passwords, audit controls and many others. Any entity that is subject to HIPAA, including an mHealth developer that is a business associate to a healthcare provider or plan, should consider how to ensure that the PHI does not get into the wrong hands if a device is stolen. In 2006, HHS issued Security Rule Guidance on Remote Access to PHI that imposes a high standard of compliance on remote users. Until the guidance is replaced or amplified, all mHealth products should be reviewed against the guidance, as well as HIPAA in general, to potentially minimize any HIPAA risks.
Non-Healthcare Specific Privacy Issues for Mobile Apps and Devices
Any mHealth solution, including one in which the patient and the provider interact, is governed not just by the laws and guidance applicable to the healthcare industry but also to the mobile industry. Under its authority to monitor unfair and deceptive practices, the Federal Trade Commission (FTC) is very active in enforcing mobile privacy policies on a number of fronts. Pursuant to HITECH, the FTC oversees enforcement with respect to the protection of personal data held in personal health records, those electronic and other records maintained by the patient (that the patient may choose to share with the provider). In September 2012, the FTC issued a guide to help mobile app developers observe truth-in-advertising and basic privacy principles called "Marketing Your Mobile App: Get It Right from the Start." Recently, the Government Accountability Office has recommended to Congress that the FTC issue guidance on the appropriate actions for mobile companies related to protecting mobile location privacy.
Other oversight bodies have weighed in on mobile privacy for consumers (including patients), notably the Attorney General of California. The California Online Privacy Protection Act requires that mobile app providers conspicuously post and adhere to privacy policies that inform the user how his or her data are being used. In late October 2012, California Attorney General Kamala Harris issued a statement that she would begin fining violators.
In conclusion, any mHealth developer or entrepreneur whose solution enhances the ability of the patient to interact with a provider may want to carefully consider the privacy and security requirements imposed on EHRs, and under HIPAA and other laws and regulations. Although the mHealth legal landscape is far from mature, there are significant risks of noncompliance with existing laws and guidance. No one wants to be that developer (and no one wants to be the investor in that developer) whose solution is targeted by the HHS, the FTC or any other governmental body for unlawful, or anti-patient/anti-consumer behavior, with possible fines and penalties. A governmental investigation or an enforcement action would likely be the death knell for a new mHealth product or service.