Commentary Addressing Risks and Opportunities Through the Lifecycle of Data, Technology, Advertising and Innovation

Data Counsel

Home | Data Counsel

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 <a href="https://www.bakerdatacounsel.com/blogs/ftc-vastly-expands-reach-of-the-health-breach-notification-rule/">Part 1 of our blog post</a>. 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.

core/paragraph

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 <a href="https://www.ssa.gov/OP_Home/ssact/title18/1861.htm">https://www.ssa.gov/OP_Home/ssact/title18/1861.htm</a>). 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.

core/freeform

§ 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. &nbsp;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.

core/list

core/list-item

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).

A health app that has integrations for analytics or advertising, presumably because the analytics or advertising provider operates as an additional source of information.

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. &nbsp;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:

Applicable definition according to the FTC

Remote blood pressure cuffs, connected blood glucose monitors and fitness trackers to the extent individuals sync them with a health app (PHR vendor) and send or access unsecured PHRIHI to or from that app

This example is pretty straightforward and simply mirrors the definition of PHR-related entity.

A grocery delivery service that sends information about food purchases to a diet and fitness app but does not access unsecured PHRIHI in a personal health record

Neither a PHR-related entity nor a third-party service provider

This is a corollary to the preceding example and again appears to align to the definitions.

A web tracking vendor to a PHR vendor that collects PHRIHI and uses it for the web tracking vendor’s own purposes

This example takes something that traditionally would be viewed as a service provider but converts it into a PHR-related entity because the vendor is not restricted in its use of data and can use the data for its own purposes (a limitation that does not appear in the Rule itself).

A search engine that integrates a search bar branded with its logo into a health tracking app

In this example, according to the FTC, because the search bar is branded with its maker’s logo, it is “consumer-facing” and that fact converts it from being a service provider to a PHR-related entity. This is so not because the definition contains any consumer-facing requirement (it affirmatively does not), but instead as a matter of policy – namely the FTC’s view that in the event of a breach, a consumer would not be surprised to receive a breach notice from an entity with which it interacts (albeit only through a search engine integrated into another company’s app).

A search engine that only provides back-end services

The only distinction from the preceding example is that the integration here is not “consumer-facing” and therefore the policy view supports the opposite conclusion – that this entity should be treated as a service provider; otherwise the consumer would be surprised to receive a breach notice from an entity with which it does not directly interact.

A firm providing an attribution and analytics services to a health app

Presumably, this is the case if the firm is limited in its use of data to only that which is necessary to render the services to the health app.

core/table

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.

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. &nbsp;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.

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.

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.”

Diving Deeper into the Revised Health Breach Notification Rule