Health care apps are one of the most important and growing segments in the ecosystem known as the Internet of Things (IoT). After the recent amendments to the Health Insurance Portability and Accountability Act (HIPAA) that—among other things—broadened the definition of a “Business Associate,” many technology companies found themselves wondering whether they were, or were not, subject to HIPAA. Health and Human Services (HHS) recently issued some guidance, Health App Use Scenarios & HIPAA, that attempts to provide some clarity on these issues for app developers.
HIPAA, while broad in some ways, is actually somewhat narrow in its application. It does not apply to all medical information. Instead, it primarily focuses on “Covered Entities,” or CEs. A CE is a health care provider that conducts certain transactions in electronic form, a health care clearinghouse, or a health plan. If your company does not meet those criteria, then it is not a CE, and not subject to HIPAA as a CE.
While that analysis is an important step, it is not the final step in assessing whether HIPAA impacts your app. A company that does not meet the definition of a CE can still be a “Business Associate,” or BA—in essence a service provider for a CE—if it receives, maintains, or transmits Personal Health Information (PHI) on behalf of a CE. As we will see, the “on behalf of” language is critical.
In the emerging realm of health care apps, another distinction with its own set of acronyms is also important—the difference between an EHR and a PHR. Electronic Health Records (EHRs) are electronic records that are, in essence, created or maintained by a CE or a BA. They are official records that facilitate medical treatment, and they are subject to HIPAA and other medical record requirements. At their core, they are provider-centric records.
Personal Health Records (PHRs) are a related but distinct concept. PHRs are medical records that typically are electronic, but consumer-facing and not necessarily part of a patient’s medical file. While related to EHRs and interoperability (that is, the ability of all necessary health care providers to be able to review and place a patient’s medical information into an electronic chart), the purpose of PHRs is to inform patients rather than to serve as the basis for treatment, which is the purpose of an EHR. This distinction is important in understanding the guidance that HHS recently provided.
The first scenario that HHS evaluates in its guidance is one that is becoming increasingly common:
A consumer downloads a health app to her smartphone. She populates it with her own information. For example, she inputs blood glucose levels and blood pressure readings that she obtained herself using home health equipment.
In this scenario, HHS concludes that the app developer is not a BA, and therefore HIPAA doesn’t apply, because the consumer is using the app to create a PHR, and the health care providers are not involved. This scenario is common in the personal health space, and likely applies to some of the health and fitness trackers on the market.
The second scenario is also a common one, but it has more of a connection to health care providers:
A consumer downloads a health app to her smartphone that is designed to help her manage a chronic condition. She downloads data from her doctor’s EHR through a patient portal, onto her computer and then uploads it into the app. She also adds her own information to the app.
Despite the connection to an EHR, HHS does not believe that the app developer is a BA within HIPAA, even though it is receiving PHI from a CE. In this case, the app developer was not hired by the CE to “provide or facilitate” the service; hence, it is not operating “on behalf of” the CE, and in essence the EHR information becomes a PHR once transmitted to the app.
The third scenario moves closer to the HIPAA line, but still does not cross it:
A doctor counsels a patient that his BMI is too high, and recommends a particular app that tracks diet, exercise, and weight. The patient downloads the app to his smartphone and uses it to send a summary report to his doctor before his next appointment.
Despite the transmission of medical information to a CE, and the doctor’s recommendation of the app, HHS does not believe this app developer is a BA. This is again due to the “on behalf of” language in the definition of a BA. In sum, the transmission of information to a CE, by itself, does not make the app developer a BA.
Interoperability is a key issue with EHRs, and at times entities will enter into Interoperability Agreements, as explained by HHS in the next scenario:
A consumer downloads a health app to her smartphone that is designed to help her manage a chronic condition. A health care provider and the app developer have entered into an interoperability arrangement at the consumer’s request that facilitates the secure exchange of consumer information between the provider EHR and the app. The consumer populates information on the app and directs the app to transmit the information to the provider’s EHR. The consumer is able to access test results from the provider through the app.
Despite the transmission of medical information to a CE, as well as an interoperability agreement, the app developer in this case is still not a BA because the agreement was initiated by the consumer. Therefore, even in this scenario, the transmission is not “on behalf of” a CE.
The next scenario presented by HHS moves past an agreement initiated by the consumer, and into a scenario that does trigger HIPAA, according to HHS:
At direction of her provider, a patient downloads a health app to her smartphone. The provider has contracted with app developer for patient management services, including remote patient health counseling, monitoring of patients’ food and exercise, patient messaging, EHR integration and application interfaces. Information that the patient inputs into the app is automatically incorporated into provider EHR.
The key factor for HHS in this scenario is that the provider contracted with the app developer for patient management services that involve creating, receiving, and transmitting PHI, and the app is part of those services.
Finally, HHS provided a scenario that is essentially a split or hybrid scenario:
A consumer downloads to her smartphone a mobile PHR app offered by her health plan that offers users in its network the ability to request, download and store health plan records and to check the status of claims and coverage decisions. The app also contains the plan’s wellness tools for members, so that they can track their progress in improving their health. The health plan analyzes health information and data about app usage to understand effectiveness of its health and wellness offerings. App developer also offers a separate, direct-to-consumer version of the app that consumers can use to store, manage, and organize their health records, to improve their health habits and to send health information to providers.
In this case, the portion of the app that is offered by the health plan triggers HIPAA and the developer is a BA, but this does not extend to the direct-to-consumer side of the business. If the app developer keeps the data separate, then, according to HHS, “the developer does not need to apply HIPAA protections to the consumer information obtained through the ‘direct-to-consumer’ app.” It appears that HHS is unofficially recognizing a hybrid designation for app developers, though the concept is, in actual terms, one more appropriately applied to CEs.
HHS offered a series of questions that app developers who are not CEs can ask to determine whether they are a BA:
HHS offered a series of questions that app developers who are not CEs can ask to determine if they are or are not a BA:
- Does your health app create, receive, maintain, or transmit identifiable information?
- Who are your clients? How are you funded?
- Are your clients covered entities?
- e.g., hospitals, doctor’s offices, clinics, pharmacies, or other health care providers who conduct electronic transactions;
- health insurance issuers; health or wellness program related to a health plan offered by an employer
- Were you hired by, or are you paid for your service or product by, a covered entity? Or another business contracted to a covered entity?
- Does a covered entity (or a business associate acting on its behalf) direct you to create, receive, maintain or disclose information related to a patient or health plan member?
- Are your clients covered entities?
Even though an app developer may not be covered by HIPAA, HHS notes other existing guidance regarding apps, including direction from the Federal Trade Commission. This guidance, as well as any applicable laws, should be considered if HIPAA is not applicable.
As the IoT becomes more ubiquitous, novel apps will appear allowing us to gather and process more health information. App developers who wish to create health-related apps should factor this guidance in early so that they can understand the rules of the road and determine whether HIPAA applies.