The U.S. Department of Health & Human Services’ Office for Civil Rights (OCR) recently provided guidance (in the form of six “real-life” scenarios) to help health care app developers (“Developers”) determine whether their consumer data collection activities make them subject to HIPAA. In general, those apps offered directly to consumers for them to use to track their fitness activities, blood pressure levels, glucose levels, etc. are not required to comply with HIPAA (however, other state data protection laws might apply to the collection and use of personal information). On the other hand, apps that are offered in conjunction with a covered health care provider or a health plan are more likely to be candidates for HIPAA compliance.
The key question is whether the Developer is creating, receiving, maintaining and transmitting protected health information (PHI) on behalf of a Covered Entity. If the answer is yes, then the Developer would have to comply with HIPAA rules as a Business Associate of the Covered Entity.
OCR’s guidance states that those apps that give consumers the ability to upload a copy of their medical records that they have previously downloaded from their provider’s Electronic Health Record (EHR) will not be subject to HIPAA unless the Developers are maintaining that health information on behalf of those providers or those providers’ vendors as Business Associates of the Covered Entity. Even if a doctor recommends a specific health care app to his or her patient and the patient downloads that app, enters his or her health information and shares that information with the doctor through the app, the Developer is still not required to comply with HIPAA as long as the Developer has not contracted with the doctor to provide the app’s services. The fact that the patient used the app to share his or her information with the doctor does not, in and of itself, make the Developer a Business Associate of the doctor.
OCR specifically called out those apps that offer users the ability to connect to a health care provider’s or health plan’s EHR—where there’s an interoperability arrangement between those entities and the app developer and no other business relationship between the parties—as a scenario in which HIPAA compliance would likely not be required. However, if, for instance, at the direction of a provider, a patient downloads a health app to his or her smart phone, and the provider has contracted with the Developer for patient management services (examples are: remote patient health counseling, monitoring of patients’ food and exercise, patient messaging, EHR integration and application interfaces), and the information provided by the patient is automatically incorporated into the provider’s EHR, then the Developer would be considered a Business Associate since the app is a means for providing those patient management services.
In a more nuanced scenario, a Developer would have to comply with HIPAA rules if the app is offered by the consumer’s health plan (the example mentioned in the guidance relates to a mobile PHR that allows users to download and store health plan records and check the status of claims and coverage decisions, and also contains the plan’s wellness tools for members). However, if the Developer were to also offer a separate, direct-to-consumer version of the app, the Developer’s activities with respect to such version would not be subject to HIPAA rules (the implication being, however, that the health information collected from these two versions of the app would need to be separately stored).
The guidance document also contains a list of “Key Questions” to help Developers determine if they will be considered a Business Associate under HIPAA. As with the scenarios above, these questions are organized around the issues of who the Developer’s customers are and how much control a consumer/user has over his or her data. If you are a Developer and your customers are Covered Entities under HIPAA (e.g., hospitals, doctors’ offices, clinics, pharmacies, or other health care providers that conduct electronic transactions, health plans, wellness programs offered as part of an employer’s self-funded health plan), or Business Associates to a Covered Entity, you will need to comply with HIPAA. If you are only offering your app directly to consumers, and your users independently select your app and control all decisions as to whether to send their data to a third party, you are probably not required to comply with HIPAA—although other data protection laws will apply.
New Compliance Guidance for the HIPAA Security Rule
OCR has also published a “Crosswalk” that maps the connections between the National Institute of Standards and Technology (NIST) Framework for Improving Critical Infrastructure Cybersecurity Framework (“NIST Framework”) and the HIPAA Security Rule’s standards. The NIST Framework is a voluntary, risk-based approach that helps organizations in any industry understand, communicate and manages cybersecurity risks. Since the Security Rule’s standards are scalable and technology-neutral, this Crosswalk provides more concrete/practical guidance for “how” Business Associates (and Covered Entities) can assess their current compliance status, from a technical standpoint, and identify any possible gaps. For instance, one of the “required” standards under the Security Rule is the performance of a Risk Assessment. Within that standard, the Crosswalk sets out five subcategories that are fairly granular (e.g., asset vulnerabilities are identified and documented; threat and vulnerability information is received from information sharing forums and sources; threats, both internal and external, are identified and documented, etc.) and provides more clarity on the components of a Risk Assessment. One caveat—OCR states that compliance with the Crosswalk is not a “guarantee” of HIPAA compliance. Nevertheless, the crosswalk should go some way to making the Security Rule standards less nebulous.