As we previously reported, the Federal Trade Commission (FTC) recently announced its final changes to the Health Breach Notification Rule (HBNR), vastly expanding the scope of the Rule’s coverage. For a refresher on what the HBNR requires, you’ll want to review Part 1 of our blog post. In this Part 2, we’ll dive deeper into the commentary on four key aspects of the Rule, noting some surprising examples from the FTC, and offer some considerations and next steps for developers of apps or websites in the health and wellness space.

1. Covered health care provider.

The expansion of the HBNR’s definition of what companies qualify as a “health care provider” is a bit of an onion: there are layers of definitions, the impact of which are, well … eyewatering.

At the heart of the HBNR is the protection of “PHR identifiable health information.” In the prior iteration of the HBNR, PHR identifiable health information was individually identifiable health information “provided by or on behalf of the individual.” The HBNR incorporated by reference the definition of individually identifiable health information (IIHI) found across a few sections of the Social Security Act (SSA). The SSA’s definition of IIHI included that it had to be created or received by a health care provider, health plan, employer, or health care clearinghouse.

While the new HBNR adopted that language (now explicitly spelled out in the HBNR’s definition of PHR identifiable information instead of by reference to the SSA), there is one significant difference. The SSA’s definition of health care provider was lengthy, and envisioned traditional clinical services and supplies (see https://www.ssa.gov/OP_Home/ssact/title18/1861.htm). That kept the scope of the Rule narrow – only applying if there was, essentially, a licensed provider of some kind who had their hands on the health information.

The HBNR, however, expanded the scope by adding to the end of the definition of “covered health care provider” the following phrase: “or any other entity furnishing health care services or supplies.” § 318.2(f). The HBNR then adds a new definition of “healthcare services or supplies,” as follows:

Health care services or supplies means any online service such as a website, mobile application, or internet-connected device that provides mechanisms to track diseases, health conditions, diagnoses or diagnostic testing, treatment, medications, vital signs, symptoms, bodily functions, fitness, fertility, sexual health, sleep, mental health, genetic information, [or] diet, or that provides other health-related services or tools.

§ 318.2(e). In other words, if a website or app provides any type of disease or health tracking, it is a covered health care provider. Consider this change within the definition of PHR identifiable information by replacing “healthcare provider” with “the application itself”:

(i) PHR identifiable health information means information that:

(1) Relates to the past, present, or future physical or mental health or condition of an individual, the provision of health care to an individual, or the past, present, or future payment for the provision of health care to an individual; and

(i) identifies the individual; or
(ii) with respect to which there is a reasonable basis to believe that the information can be used to identify the individual; and

(2) Is created or received by []:

(i) [the application itself];
(ii) [a] health plan (as defined in 42 U.S.C. 1320d(5));
(iii) [an] employer; or
(iv) [a] health care clearinghouse (as defined in 42 U.S.C. 1320d(2)); and

(3) with respect to an individual, includes information that is provided by or on behalf of the individual.

Under this new definition, there is no longer a need for any clinical involvement with information to render it PHR identifiable information. By simply receiving the information, the application itself transforms the information from just consumer health data to data covered by the HBNR. In case that wasn’t clear, subsection 3 of the definition drives the point home: PHR identifiable information “includes information that is provided by or on behalf of the individual.”

In the commentary to the HBNR, the FTC addresses public comments expressing concern that the new definition of “health care services or supplies” would result in the Rule covering “retailers of general-purpose items like tennis shoes, shampoo, or vitamins.” The FTC noted that would only be the case if the retailer offered a personal health record, which must relate “more than tangentially to health.” The FTC noted that “there may be scenarios where a general-purpose retailer … may become a vendor of personal health records under the Rule [if] the retailer offers an app with features or functions that are sold, marketed, or promoted as more than tangentially relating to health.”

Thus, while a record of a purchase of health supplies would be considered PHR identifiable health information, the retailer would not be a PHR vendor unless the retailer’s app or website also provides the consumer with tracking of the consumer’s health or wellness. Retailers collecting information about consumers’ physical activity in their mobile app in order to reward consumers with discounts or products based on such activity may be a PHR vendor by virtue of that rewards program.

While there are some other requirements that also must be met in order for the application to be considered a PHR vendor, as discussed below, the requirements are so technically insignificant that few entities meeting the expanded definition of health care provider will be excluded by other requirements.

2. Expanded definition of PHR: technical capacity to pull information from multiple sources.

One significant change in the Rule is to the “multiple source” prong of the definition of PHR. Previously, it was understood that to be a PHR, an app or website had to draw health information from multiple sources. The final Rule changes that in two ways: (1) by providing that only one of the multiple sources needs to be health information; and (2) by stating that the app or website need only have the “technical capacity” to draw information from multiple sources, even if it is infrequently or never used.

The following examples provided in the FTC’s commentary of activities that may make something a PHR highlight the expansive nature of the “multiple source” language:

• A website or app that provides a symptom tracker to individuals who log in to an app or website with a username or password where individuals input their symptoms and receive potential diagnoses.
  • According to the FTC, the entity providing the website or app is a covered health provider because it is furnishing a health care service in the form of a mechanism to track symptoms. (See discussion above.)
  • The health information (symptoms) is input by the individual and is individually identifiable because of the use of a username and password.
    • If the individual is the only source of the information and the site or app does not have the technical capacity to draw information from multiple sources, it does not qualify as a PHR.
    • However, if the same site or app collects geolocation information from an API, it would qualify as having the technical capacity to draw information from multiple sources and would qualify as a PHR. Presumably, the same conclusion would be reached if the app or website had the technical capacity to draw information from an external health information database in order to display information to the consumer about potential conditions associated with their symptoms.
• A depression management app that accepts consumer inputs of mental health states and has the technical capacity to sync with a wearable sleep monitor, even if some customers choose not to sync a sleep monitor with the app.
• A diet and fitness app that allows users to input their own information (e.g., name, weight, height, age) and either sync their app with third-party wearable fitness trackers to pull information (e.g., user’s name, miles run, heart rate) or pull non-health information from the user’s phone calendar (e.g., calendar entry info, location, time zone).
  • As noted, simply having the technical capacity to draw information from multiple sources is sufficient to bring the app into the Rule’s coverage, i.e., in this example, even if some users do not actually connect to either the fitness tracker or the calendar.
• A health app that has integrations for analytics or advertising, presumably because the analytics or advertising provider operates as an additional source of information.

Considerations and next steps:

• Assuming your website or app otherwise qualifies as collecting PHRIHI, work with your development team to understand the integrations and APIs utilized by your website or app, specifically whether and to what extent they have the technical capacity to draw information from multiple sources. This will help determine your potential coverage under the Rule as a PHR. But as the dissenting statement and commenters noted, “virtually every app has the technical capacity to draw some information from more than one source,” and therefore this is likely not a high bar to meet.

3. Lack of clarity around the distinction between a PHR-related entity and a service provider.

As noted in our earlier blog, the Rule’s requirements primarily apply to two types of entities – PHR vendors and PHR-related entities – as distinct from third-party service providers. While the FTC provided commentary and examples attempting to distinguish a PHR-related entity from a third-party service provider, unfortunately, the FTC’s commentary raises more questions than it answers. The challenges that entities will face in determining whether and how the definitions apply to them are underscored by the examples provided by the FTC:

As alluded to above, neither the definition of PHR-related entity nor that of third-party service provider says anything about a technological integration having to be “consumer-facing” or requiring restrictions on data use, but the FTC appears to have read into the definitions of both of these requirements. And while the final Rule has added qualifying language to the definition of service provider, it does so in a completely unhelpful way. Specifically, the final Rule adds that “[w]hile some third-party service providers may access unsecured PHR identifiable health information in the course of providing services, this does not render the third-party service provider a PHR-related entity.” Unfortunately, though, the Rule provides no additional context and fails to explain where the line is in converting something from a service provider to a PHR-related entity.

In sum, entities reading the plain wording of the definitions will find it difficult to understand whether they qualify as PHR-related entities, third-party service providers, or both. This has practical implications under the Rule, as PHR-related entities have an affirmative obligation to notify their third-party service providers of their status as an entity covered by the Rule. As the dissent noted, companies risk being in “perpetual noncompliance” if they don’t know which entity qualifies as which.

Considerations and next steps:

• If you traditionally view yourself as a service provider, consider whether you could be covered under the Rule as a PHR-related entity to the extent that you access unsecured PHRIHI through a health app. Consider whether the use of your technology in a given app or website is “consumer-facing” and/or whether you are able to use the information for your own purposes, such as product improvement or advertising purposes.
• If you determine you are a PHR-related entity, consider whether you have appropriate restrictions and oversight of your vendors’ use of your data.
• Explore means to secure access to PHRIHI to limit the Rule’s applicability.

4. Expanded definition of unauthorized disclosure.

As we noted in Part 1, the final Rule expands the definition of “breach of security” to include disclosures not authorized by the consumer and takes an expansive view of what would be considered unauthorized. Through its commentary, the FTC appears to take the position that authorized disclosures are only those that are (1) necessary to provide the PHR to the consumer; (2) adequately disclosed to the consumer; (3) “consistent with consumer expectations” (query whether and how that is materially different from being disclosed to consumers); and (4) in some cases, subject to protections like service provider agreements that limit the use of data for purposes of providing services and not for the third party’s independent purposes, including for advertising purposes.

The FTC’s commentary provides examples of certain disclosures and its views on whether they are considered authorized or not:

• A medication appthat allows users to track information about prescription medication history and health conditions and voluntarily discloses PHRIHI to third-party companies for advertising and advertising-related analytics. In one example, the disclosure is in violation of the app’s affirmative privacy representations; in the other, the app’s privacy policy omits information about the disclosure. In both cases, the third parties receiving PHR identifiable health information can use the information for their own business purposes, such as to improve the third party’s own products and services, to infer information about consumers, or to compile profiles about consumers for use in targeted advertising.
  • According to the FTC, these disclosures are unauthorized because they were not adequately disclosed in, or are contrary to, the app’s privacy policy. Additionally, these disclosures are inconsistent with consumer expectations because, according to the FTC, a consumer would not expect that third party to be able to use the data for their own economic benefit.
  • The FTC further stated that disclosures to contracted service providers for activities related to cloud storage, payment processing, refill reminders, certain analytics vendors, and security and fraud detection would be authorized.
  • With respect to analytics, the FTC clarifies its view that those disclosures to analytics vendors are appropriate only where related to the proper functioning of the app, such as tools to assist with crash reporting or to assess usage patterns, but not for advertising and marketing purposes.

Clearly, the FTC is very hostile to the use of health information for advertising purposes without clear consent. We have seen this repeatedly in the FTC’s recent enforcement actions and it is now reiterated in the HBNR, essentially saying that such use doesn’t align with consumer expectations and is an instant breach.

Considerations and next steps:

• Review policies to ensure that disclosures of data to third parties are adequately disclosed to the user (coupled with obtaining consent as appropriate).
• Review terms and agreements with third parties to determine whether they include limitations around use of data.
• Consider any disclosures to third parties that the FTC could view as unauthorized, and make a risk-based decision on whether a notice of breach is warranted. As the FTC noted, “whether a disclosure is authorized under the Rule is a fact-specific inquiry that will depend on the context of the interactions between the consumer and the company; the nature, recipients, and purposes of those disclosures; the company’s representations to consumers; and other applicable laws.”

[View source.]