chevron-down Created with Sketch Beta.

The Antitrust Source

Antitrust Magazine Online | December 2021

FTC Takes Aim at Health Apps with Health Breach Notification Rule Policy Statement

Tracy Rebecca Shapiro, Haley Bavasi, and Hale Melnick

Summary

  • The FTC's recent Policy Statement purports to clarify its Health Breach Notification Rule that developers of health care apps and connected devices are covered by the Rule, and that a disclosure of sensitive health information by a Developer, without its users’ authorization, constitutes a “breach of security.” 
  • The FTC lacks the authority to significantly expand its enforcement power in digital health without the opportunity for notice and comment as required by the Administrative Procedure Act. 
  • The September 2015 Policy Statement increased enforcement risk while stifling innovation without the benefit of promoting individual privacy rights.
FTC Takes Aim at Health Apps with Health Breach Notification Rule Policy Statement
AntonioSolano via Getty Images

Jump to:

On September 15, 2021, the Federal Trade Commission issued a controversial Policy Statement (the Policy Statement) claiming to clarify the scope of the Health Breach Notification Rule (the “Rule”), with the intent of significantly expanding the FTC’s enforcement power in the area of digital health. Specifically, the Policy Statement purports to clarify that developers of health care apps and connected devices are covered by the Rule, and that a disclosure of sensitive health information by a Developer, without its users’ authorization, constitutes a “breach of security.”

The FTC’s justification for the Policy Statement rests primarily on the FTC’s determination that developers of health care apps and connected devices (collectively, “Developers”) are “health care providers” because they “furnish[] health care services or supplies.” However, this conclusion is seemingly at odds with the U.S. Department of Health and Human Services (HHS) Office for Civil Rights’ (OCR) interpretation of the term “health care provider” under the Health Insurance Portability and Accountability Act (HIPAA). OCR has long adopted a more traditional understanding of that term to cover, for example, a physician licensed to practice medicine.

The Policy Statement aims to fill a gap where HIPAA does not have jurisdiction by purportedly expanding the Rule to cover Developers who are not covered under HIPAA. Specifically, Developers, as described by the Policy Statement, do not meet the definition of a health care provider or other covered entity under HIPAA, and HIPAA does not regulate these Developers’ collection, use, or disclosure of health information provided directly to them by an individual (where the Developer is not acting as a business associate). Now that the FTC is purportedly filling this gap through the issuance of the Policy Statement, many entities who had not been considered subject to either HIPAA or the Rule may now face FTC enforcement under the Rule.

This article explains what the Rule is, how the FTC came to issue the Policy Statement, and why we believe the FTC lacks authority to issue such a major change in position through a non-binding guidance document without undertaking or completing notice and comment rulemaking procedures.

The Health Breach Notification Rule

The Rule was promulgated by the FTC pursuant to the American Recovery and Reinvestment Act of 2009 (the “Recovery Act”). As detailed below, the Rule applies to entities that maintain, offer, or provide products or services related to, “personal health records” (PHRs). The term “personal health record” is defined by the Rule as “an electronic record of PHR identifiable health information” on an individual that “can be drawn from multiple sources” and “is managed, shared, and controlled by or primarily for the individual.” Cross-referencing definitions codified in the Social Security Act (SSA), the Rule provides that PHR identifiable health information means any information that is provided by, or on behalf of, the individual that: (a) is “created or received by a health care provider, health plan, employer, or health care clearinghouse”; and (b) “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 either (i) “identifies the individual; or (ii) with respect to which there is a reasonable basis to identify the individual.” Despite the similarity of the definition of PHR identifiable health information to the definition of Protected Health Information (PHI) under HIPAA, the Rule does not apply to HIPAA-covered entities, or to any other entity to the extent that entity engages in activities as a business associate under HIPAA.

Because PHRs by definition involve health information “created or received by a health care provider, health plan, employer, or health care clearinghouse,” the FTC has generally taken the position that the Rule applies only to information that derives directly from a traditional health care entity or professional, e.g., a physician licensed to practice medicine, or an employer sponsored group health plan.

The Rule specifically applies to three types of related entities: “vendors of PHRs,” “PHR related entities,” and “third party service providers” (collectively, “Related Entities”). Specifically, the Rule defines these Related Entities as follows:

  • A vendor of PHRs means an entity that offers or maintains a PHR ;
  • A PHR related entity means an entity that offers products or services through the website of a vendor of PHRs, or accesses information in, or sends information to, a PHR ; and
  • A third party service provider means, generally, an entity that (i) provides services to a vendor of PHRs or a PHR related entity and (ii) processes unsecured PHR identifiable health information as a result of such services.

The Rule requires Related Entities to notify their U.S. consumers and the FTC if there has been a breach of security of PHR identifiable health information. A breach of security is defined by the Rule to mean an acquisition of PHR identifiable health information without the authorization of the individual. Unauthorized acquisition is presumed when there is unauthorized access to the information, unless the entity that experiences the breach has reliable evidence showing that there has not been, or could not reasonably have been, unauthorized acquisition of such information. The Rule also requires third party service providers to notify vendors of PHRs and PHR Related Entities of a breach of security.

Neither the Rule nor other FTC regulations prescribe precisely what constitutes “authorization of an individual.” However, the FTC provided the following illustration of what constitutes authorization in the preamble to the Rule:

Some commenters raised questions about how the extent of individual authorization should be determined. For example, if a privacy policy contains buried disclosures describing extensive dissemination of consumers’ data, could consumers be said to have authorized such dissemination?

The Commission believes that an entity’s use of information to enhance individuals’ experience with their PHR would be within the scope of the individuals’ authorization, as long as such use is consistent with the entity’s disclosures and individuals’ reasonable expectations. Such authorized uses could include communication of information to the consumer, data processing, or Web design, either in-house or through the use of service providers. Beyond such uses, the Commission expects that vendors of personal health records and PHR related entities would limit the sharing of consumers’ information, unless the consumers exercise meaningful choice in consenting to such sharing. Buried disclosures in lengthy privacy policies do not satisfy the standard of ‘‘meaningful choice.”

The FTC is empowered to seek legal and equitable remedies including injunctive relief and, in some instances, restitution. Importantly, the Rule gives the FTC the authority to seek civil penalties, up to $43,792 per violation per day. These cumulative civil penalties would be an unwelcome surprise to many entities that, prior to the Policy Statement, were outside the scope of the Rule.

HIPAA and the Health Breach Notification Rule

As previously noted, the Rule does not apply to HIPAA covered entities or their business associates. Broadly speaking, HIPAA implements privacy, security, and breach notification standards for the protection of PHI. PHI is generally defined to mean individually identifiable health information created or received by a covered entity. A covered entity is defined as a health plan, a health care clearinghouse, or “[a] health care provider who transmits any health information in electronic form in connection with a transaction covered by” HIPAA. An entity that creates or receives individually identifiable health information, but is not a HIPAA covered entity (and is not acting as a business associate to a HIPAA covered entity), is outside HIPAA’s jurisdiction.

Under the Recovery Act, Congress directed the Secretary of HHS to promulgate breach notification regulations specifically for covered entities and business associates subject to HIPAA. Congress recognized that certain vendors of PHRs and PHR related entities were collecting consumers’ health information but were not subject to the HIPAA Privacy and Security Rules, and so it directed the FTC under the Recovery Act to adopt temporary breach notification requirements for this relatively narrow activity. In the preamble to the Rule, the FTC recognized that the FTC and HHS breach notification rules should be harmonized, and that stakeholders should know which rule applies to which entity.

FTC Considers Broadening the Rule

Although the Rule became fully effective in February 2010, it has never been enforced. In that time, the FTC has received notice of a breach of security from Related Entities only four times. As the FTC explained, it had “not had occasion to enforce its Rule because . . . most PHR vendors, related entities, and service providers have been HIPAA-covered entities or ‘business associates’ subject to HHS’s rule.”

In May 2020, the FTC began to revisit the Rule’s scope. It published a request for public comment on the Rule, noting that as consumers turn towards direct-to-consumer technologies for health information and services—such as mobile health apps, virtual assistants, and platforms’ health tools—more companies may be covered by the Rule. In particular, the FTC sought comment on whether the definitions of “vendor of PHRs,” “PHR related entity”, or “third party service provider” needed to be modified in order to reach these mobile health apps, and what the implications are (if any) for enforcement of the Rule raised by direct-to-consumer technologies such as health apps.

Following issuance of the request for comment, but prior to any formal agency action, Commissioner Rebecca Kelly Slaughter and then-Commissioner Rohit Chopra advocated for the FTC to use the Rule in its action against health app developer Flo Health, Inc., a mobile application that functioned as an ovulation calendar, period tracker, and pregnancy guide. According to the FTC’s complaint, Flo Health “encourage[d] women to input vast quantities of health information into the Flo App” and then improperly shared the users’ health information with marketing and analytics firms. The Commission’s four Commissioners voted in support of the complaint and settlement order based on Flo Health’s unfair or deceptive acts or practices. But two Commissioners, Slaughter and Chopra, issued a joint statement arguing that the FTC should have included a count in its complaint under the Rule for failing to notify users that it shared their health information with third parties without users’ authorization. Commissioners Slaughter and Chopra argued that mobile health apps are covered under the Rule and that the unauthorized disclosure of user health information amounted to a breach of security. However, lacking the necessary votes, the FTC ultimately declined to enforce the Rule against Flo Health.

Just two months after the FTC settled its case against Flo Health, three Democratic members of Congress sent a letter to the FTC urging the Commission to start enforcing the Rule against health apps that share personal health information with third parties without consumer authorization, citing Flo Health as an example.

FTC Issues September 15, 2021 Policy Statement

On September 15, 2021, the Commission held its third Open Commission meeting where it voted 3-2 along party lines to release the Policy Statement. The Policy Statement, which purported “to clarify the scope of the Rule,” interpreted three elements of the Rule that, collectively, would have the effect of significantly expanding the FTC’s enforcement authority in the area of digital health. First, the FTC clarified that Developers are health care providers because they “furnish[ ] health care services or supplies.” Second, the FTC clarified that an app constitutes a PHR if it: (i) is capable of drawing health information “from multiple sources, such as through a combination of consumer inputs and application programming interfaces (APIs)”; or (ii) draws information from multiple sources, even if the consumer’s health information comes from only one source. And third, the FTC clarified that a breach of security is “not limited to cybersecurity intrusions or nefarious behavior,” but also includes instances in which the app shares covered information without an individual’s authorization.

The decision to issue the Policy Statement was along partisan lines. Republican Commissioners Christine Wilson and Noah Phillips both voted against issuing the Policy Statement and suggested during the open meeting that the Policy Statement is inconsistent with existing agency guidance. They issued dissenting statements in which they argued that the majority was attempting to circumvent the administrative rulemaking process by issuing the Policy Statement. Both dissenting statements referenced the ongoing rulemaking proceeding for the Rule and noted that the Commission had not completed its review of the public comments submitted as part of that proceeding.

The Policy Statement Goes Beyond the FTC’s Authority

For a number of reasons, we believe that the FTC lacks authority to issue such a significant change to the Rule through a guidance document, without undertaking or completing notice and comment rulemaking procedures.

The FTC’s Conclusion that Developers are Health Care Providers is Procedurally Invalid.

First, the FTC’s determination that Developers are health care providers arguably violates the Administrative Procedure Act (APA). In general, the APA requires administrative agencies like the FTC to provide the public with notice and an opportunity to comment on proposed rules. Agencies are exempt from this requirement in limited circumstances, such as when they are issuing interpretative rules, general statements of policy, or rules of agency organization, procedure, or practice. When an agency promulgates a rule “without observance of [the] procedure required by law,” the APA instructs reviewing courts to “hold unlawful and set aside [the] agency[’s] action, findings, and conclusions.”

Although dressed up as an interpretive rule for the FTC’s own regulation, the FTC’s Policy Statement in fact announced a new statutory interpretation that should be subject to the APA’s notice and comment requirements. The Policy Statement explains that “[u]nder the definitions cross-referenced by the Rule, the developer of a health app or connected device is a ‘health care provider’ because it ‘furnish[es] health care services or supplies.’” But the definition of health care provider is contained in the SSA, not the Rule itself. The Rule simply incorporates the SSA’s definition for individually identifiable health information, which in turn relies on the SSA’s definition of health care provider. In short, to arrive at the interpretation that Developers are health care providers, the FTC looked beyond its own regulation and instead interpreted provisions contained in the SSA.

The interpretation that Developers are health care providers is critical to the FTC’s Policy Statement. To qualify as a vendor of PHRs or a PHR related entity, the Developer must maintain individually identifiable health information, defined by the SSA to mean that the information was “created or received by a health care provider, health plan, employer, or health care clearinghouse.” If the health information maintained by a Developer derives instead from the individual (for example, if an individual uploads their information directly to an app offered by the Developer), then the Developer cannot qualify as a vendor of PHRs or PHR related entity unless the Developer itself is a “health care provider, health plan, employer, or health care clearinghouse,” as defined by the SSA. Nevertheless, in its Policy Statement, the FTC concluded without explanation that Developers are health care providers as defined by the SSA because they “furnish[] health care services or supplies.”

The FTC’s statutory interpretation goes beyond the APA’s narrow exceptions to notice and comment rulemaking. Courts that have considered similar actions have explained that “[i]t is well-established that an agency may not escape the notice and comment requirements . . . by labeling a major substantive legal addition to a rule a mere interpretation.” Rather, where “an agency[, among other things,] acts as if a document issued at headquarters is controlling in the field, . . . [or] if it bases enforcement actions on the policies or interpretations formulated in the document,” the rule must satisfy the APA’s notice and comment requirements. Here, the FTC was explicit that it “intends to bring actions to enforce the Rule consistent with [its] Policy Statement.” Because the Policy Statement’s conclusion that Developers are health care providers broadens the Rule’s applicability, and because the FTC intends to bring enforcement actions to that effect, the Policy Statement amounts to a binding rule change subject to the APA’s notice and comment requirements. The FTC’s failure to provide the public with notice and an opportunity to comment on this substantive change amounts to a procedurally invalid rule promulgated in violation of the APA.

Moreover, prior to issuing its policy statement, the FTC implicitly agreed that it lacked the authority to unilaterally reinterpret the Rule by seeking public input on the Rule’s future with respect to direct-to-consumer health and wellness technologies. In particular, in its still ongoing May 2020 Request for Comment, the FTC asked:

“6. Should the definitions of ‘PHR related entity’ in § 318.2(f), ‘Third party service provider’ in § 318.2(h), or ‘Vendor of personal health records’ in Section 318.2(j) be modified in light of changing technological and economic conditions, such as the proliferation of mobile health applications (‘apps’), virtual assistants offering health services, and platforms’ health tools? If so, how, consistent with the Act’s requirements?”

“10. What are the implications (if any) for enforcement of the Rule raised by direct-to-­consumer technologies and services such as mobile health apps, virtual assistants, and platforms’ health tools?”

Instead of considering and responding to the public’s comments (there were 26 public comments in total, none of which received a response), the FTC sidestepped its statutory requirements by attempting to preemptively settle these questions through the Policy Statement.

The FTC’s Interpretation is Contrary to the SSA and Longstanding OCR Guidance.

Second, the FTC’s determination that Developers are health care providers is contrary to the plain language of the SSA and differs from OCR’s longstanding guidance regarding the same statutory provision.

Based on the types of services and entities contemplated by the SSA, the FTC’s interpretation that Developers are health care providers is a stretch at best. The SSA provides:

The term “health care provider” includes a provider of services [defined as a hospital, critical access hospital, rural emergency hospital, skilled nursing facility, comprehensive outpatient rehabilitation facility, home health agency, hospice program, or teaching hospital], a provider of medical or other health services [defined as physicians’ services and other services provided in the traditional health care setting, like certified nurse-midwife services and qualified psychologist services], and any other person furnishing health care services or supplies.

Developers clearly do not fit the “provider of services” or “provider of medical or other health services’’ classifications because they do not provide traditional health care services as contemplated by the numerous examples provided in the statute. Developers, for example, are not hospitals or physicians licensed to practice medicine. Moreover, it would be a stretch to classify Developers as “any other person furnishing health care services or supplies.” According to the canon of statutory interpretation ejusdem generis, “when a general word or phrase follows a list of specifics, the general word or phrase will be interpreted to include only items of the same class as those listed.” Here, the extensive listing of examples of health care providers paints a very stark picture of “health care provider” as a traditional health care entity and which excludes Developers.

Guidance issued by OCR, which interprets the same SSA provisions for purposes of the HIPAA Privacy Rule, further supports that Developers are not health care providers. For example, OCR describes “health care providers” on its website to include “doctors, clinics, psychologists, dentists, chiropractors, nursing homes, and pharmacies.” Notably absent from that list is any entity that remotely resembles a Developer.

Furthermore, OCR’s published guidance for app developers clearly indicates that OCR does not view Developers as health care providers. For example, OCR provides the following scenario:

Scenario. Consumer downloads a health app to her smartphone. She populates it with her own information. For example, the consumer inputs blood glucose levels and blood pressure readings she obtained herself using home health equipment.

Based on the Facts Presented in the Scenario, Is App Developer a HIPAA Business Associate? No. Developer is not creating, receiving, maintaining or transmitting protected health information (PHI) on behalf of a covered entity or another business associate. The consumer is using the developer’s app to help her manage and organize her information without any involvement of her health care providers.

Because OCR does not consider a Developer’s app that manages and organizes health information to involve health care providers, it would be inconsistent for the FTC to take a contrary position. As the FTC recognized in the preamble to the Rule, the FTC and HHS breach notification rules should be “harmonized,” and stakeholders should know which rule applies to which entity. Given that the Policy Statement directly conflicts with the HIPAA Privacy Rule and established OCR guidance, the Policy Statement could, as Commissioner Wilson noted, “have implications for our sister agencies, the [SSA] and HHS.” By way of illustration, consider that if OCR adopted the FTC’s definition of “health care provider” under the Policy Statement, it would lead to a counterintuitive result. A covered entity health care provider under HIPAA is generally prohibited from disclosing an individual’s PHI without the individual’s authorization. However, an exception exists where the health care provider shares the individual’s PHI with other covered entities for treatment, payment, and health care operations. Therefore, if OCR adopted the FTC’s interpretation of the Recovery Act such that a Developer is a health care provider, then the Developer and other HIPAA covered entities could potentially share individuals’ PHI with each other without the individual’s authorization and without a business associate agreement.

PHRs Must Draw Electronic Records of PHR Identifiable Health Information from Multiple Sources.

The Policy Statement’s interpretation of the definition of PHR is also problematic. The Rule defines a PHR as “an electronic record of PHR identifiable health information on an individual that can be drawn from multiple sources and that is managed, shared, and controlled by or primarily for the individual.” In interpreting the definition of PHR, the Policy Statement provides:

The Commission considers apps covered by the Rule if they are capable of drawing information from multiple sources, such as through a combination of consumer inputs and application programming interfaces (“APIs”). For example, an app is covered if it collects information directly from consumers and has the technical capacity to draw information through an API that enables syncing with a consumer’s fitness tracker. Similarly, an app that draws information from multiple sources is covered, even if the health information comes from only one source. For example, if a blood sugar monitoring app draws health information only from one source (e.g., a consumer’s inputted blood sugar levels), but also takes non-health information from another source (e.g., dates from your phone’s calendar), it is covered under the Rule.

The FTC’s position runs counter to the Rule because the Rule specifies that a PHR is an electronic record of PHR identifiable health information on an individual that can be drawn from multiple sources. In other words, the Rule explicitly states that the information provided by multiple sources must be PHR identifiable health information. The FTC is therefore attempting to change the Rule’s defined terms through a purportedly non-binding guidance document.

Further, as Commissioners Phillips and Wilson noted in their dissenting statements, the FTC guidance issued prior to the Policy Statement—which still lives on the FTC’s website—contemplated a scenario very similar to the examples provided in the Policy Statement yet reached the opposite conclusion. That prior guidance provided, “if consumers can simply input their own information on your site in a way that doesn’t interact with personal health records offered by a vendor – for example, if your site just allows consumers to input their weight each week to track their fitness goals – you’re not a PHR-related entity.” The FTC’s prior guidance underscored that the phrase “multiple sources” referred to actual entities, and not to other data sources on the consumer’s mobile or connected device, such as calendar dates. The guidance therefore demonstrated that the FTC did not consider the Rule to apply to apps that did not draw PHR identifiable health information from multiple devices, and if they were to adopt a contrary position, they should have gone through (and completed) notice and comment rulemaking.

An Unauthorized Disclosure Does Not Constitute a “Breach of Security.”

The Policy Statement also adopts a very broad definition of the term breach of security, that, at the very least, distorts the meaning of the term under the Rule and the Recovery Act. The Policy Statement clarifies that a “breach of security” includes “the Developer’s sharing of covered information without an individual’s authorization.” Such interpretation of the term “breach of security” goes beyond the text of the Rule and the Recovery Act. For example, HIPAA contemplates that an unauthorized disclosure of PHI could constitute a breach, but it defines a breach as “the acquisition, access, use, or disclosure of protected health information in a manner not permitted under [the HIPAA Privacy Rule] which compromises the security or privacy of the protected health information.” In contrast, the Rule is limited to enforcement of breaches of “security,” which does not include an entity’s intentional sharing of consumer information with a third party. The Recovery Act delegated to the FTC enforcement of breaches of security, not privacy, and the unauthorized sharing of information is the domain of privacy.

Moreover, by interpreting a “breach of security” as a Developer’s sharing of covered information without an individual’s authorization, the FTC seeks to significantly expand its enforcement power to regulate the flow of PHR identifiable information. However, the FTC itself recognized in the preamble to the Rule that general or comprehensive privacy and security rules for PHRs were beyond the scope of its rulemaking power under the Recovery Act. The FTC should not now attempt to expand its authority in such a significant manner, as it purports to do through its Policy Statement, without completing notice and comment rulemaking procedures.

Conclusion

The FTC’s Policy Statement purporting to clarify the Health Breach Notification Rule rests on shaky grounds. Through this Policy Statement, the FTC seeks to significantly expand its enforcement power in the area of digital health without giving stakeholders the opportunity for notice and comment as required under the APA. Because the Policy Statement has far reaching consequences and is based on questionable interpretations of law, transparency is particularly critical in this case. Until those interpretations are formally challenged, developers of health care apps and connected devices will face a looming, amorphous threat of enforcement by the FTC that could carry significant costs. Unfortunately, the entities most likely to be swept into FTC’s purported jurisdiction will be those on the cutting edge of innovation in health care. These emerging companies tend to lack the resources of later-stage, established entities necessary to challenge this attempted expansion of power. As a consequence, the Policy Statement carries a significant risk of stifling much-needed innovation without a clear benefit to promoting the privacy rights of individuals.

The authors would like to acknowledge the many hours Laura Ahmed, Erin Delaney, and Megan Kayo contributed to this article

    Authors