Health Data Does Not Become Unregulated at the HIPAA Boundary

This series examines a deceptively simple question: what protects health information when HIPAA does not apply? The subject is the boundary between HIPAA and the Federal Trade Commission’s Health Breach Notification Rule, with American Hospital Association v. Becerra showing a different limit on how HHS may interpret HIPAA in the digital environment. The practical goal is not to memorize agency names. It is to learn how to ask which actor holds the data, what product or record is involved, what happened to the data, and what remedy the relevant legal regime actually provides.

That distinction matters because modern health information moves through systems that do not resemble a traditional clinic. A person might enter medication and symptom information into a consumer app, connect the app to a wearable, and encounter advertising or analytics companies in the background. The same person might visit a hospital’s public webpage about dialysis or Alzheimer’s disease, where a third-party tool records an IP address and the page visited. Both situations involve health-related digital activity. They do not automatically raise the same legal question.

The same data can enter different legal stories

HIPAA was built around a defined healthcare ecosystem. Its protections apply to covered entities and their business associates, not to every company that offers a health-related service or receives a health-related signal. That sectoral boundary is important, but it is not a verdict that the data has become legally irrelevant. It tells us to look for another authority, another definition, or another remedy.

The Federal Trade Commission’s rule exists because Congress recognized this gap. The 2009 Recovery Act created a notification framework for vendors of personal health records and related entities that could hold consumers’ health information outside HIPAA’s privacy and security requirements. The FTC’s 2024 final rule keeps that division explicit: it does not apply to HIPAA-covered entities or to activities performed as a business associate, but it does apply to qualifying vendors of personal health records, PHR related entities, and third-party service providers.

That is a narrower proposition than “all health data is protected.” The rule is primarily about what happens after a qualifying breach. It can require notice to affected individuals, the FTC, and, in some cases, the media. The Commission expressly distinguishes this notification function from omnibus privacy protection. A company may therefore face a federal duty to disclose a breach even though the company is not a HIPAA-covered entity—and that duty does not mean the FTC rule supplies every privacy right a person might want.

This design reflects the way consumer health technology changed the problem. A personal health record can be assembled from a person’s own entries, a connected device, a location signal, or another integration. The legal question is not simply whether a company uses the word “health” in its marketing. It is whether the product creates and maintains the kind of individual-oriented electronic record that the rule describes, and whether the information is both health-related and identifiable under that rule. That structure gives the FTC a way to reach many digital-health products without declaring every health-adjacent website a regulated medical record.

It also makes the boundary consequential before any breach occurs. A company that minimizes the unsecured information it maintains, protects it through the specified security methods, or uses de-identified information may reduce the conditions that lead to notification. But the rule does not turn those choices into a general privacy guarantee. It establishes a legal response when the defined conditions are met, leaving the reader to separate what the rule requires after an event from what responsible data stewardship might require before one. The hospital webpage presents a different problem. In American Hospital Association v. Becerra, the issue was HHS’s effort to treat a particular combination of information as individually identifiable health information, or IIHI, under HIPAA. The combination connected an individual’s IP address or other identifying information with a visit to a public webpage about specific health conditions or healthcare providers. The Revised Bulletin said the combination could be sufficient when the visit related to the individual’s own health. Hospitals argued that this created a new obligation, while HHS argued that it merely explained existing law.

The district court’s June 20, 2024 opinion did not declare all tracking lawful or erase HIPAA’s protections. It held that the challenged “Proscribed Combination” exceeded the statutory definition of IIHI and that HHS had imposed a substantive legal position through guidance. The court ordered that this particular interpretation be vacated. It also made clear that its order did not limit the legal operability of other guidance in the same HHS document.

That procedural detail matters because guidance can influence behavior even when an agency calls it nonbinding. The hospitals said the bulletin changed what they had to do; HHS said it was only explaining what they already had to do. The court focused on the bulletin’s practical and legal effect rather than accepting its disclaimer at face value. In other words, the case was not only about whether a page visit reveals something sensitive. It was also about who has authority to convert an interpretation into an obligation, and how a regulated organization can challenge that move before waiting for penalties. These are different boundary-setting mechanisms. The FTC rule asks whether a non-HIPAA product and its data fit the personal-health-record framework, and whether unsecured identifiable health information was acquired without authorization. The AHA case asked whether a specific public-web metadata combination fit HIPAA’s IIHI definition and whether HHS had authority to impose that interpretation. The documents can therefore point in different directions without contradicting one another.

A boundary is not a vacuum

The most useful correction to the phrase “HIPAA does not apply” is not a new slogan. It is a sequence of questions. First, identify the actor. A hospital, a consumer app developer, a wearable maker, an analytics firm, and a cloud provider may participate in the same data flow, but their legal roles are not interchangeable. The FTC rule itself distinguishes a consumer-facing PHR related entity from a back-end service provider, and the same analytics company can occupy different roles depending on whether it is serving the app or using information for its own purposes.

This is why asking only who collected the information can mislead. The company with the consumer relationship may have to notify the person, while a back-end provider that discovers a breach may have to alert the vendor or related entity instead. A device maker may be part of the regulated ecosystem when its readings flow into an app, but its role depends on what it offers and what information it sends. The data path, not just the first touchpoint, determines which questions must be asked. Second, identify the product and record. The FTC rule does not cover every health-adjacent webpage simply because someone can read it. A personal health record must be an electronic record of an individual’s PHR identifiable health information, have the technical capacity to draw information from multiple sources, and be managed, shared, and controlled by or primarily for the individual. Those conditions can bring many health apps into the rule, but they also impose limits. A purely informational health site or an ordinary retailer’s purchase app is not automatically a personal health record.

The technical-capacity point prevents a company from changing the answer merely by leaving an integration dormant. An app that can connect a depression-management record to a wearable sleep monitor may fit the multiple-source condition even when a particular user never turns on the connection. At the same time, the record must remain primarily for the individual. An incidental analytics connection does not, by itself, convert every online service into a personal health record. Coverage is broad enough to follow current product design, but bounded enough to require a qualifying record rather than a loose association with wellness. Third, identify the data and the legal definition doing the work. The FTC rule’s PHR identifiable health information can include familiar items such as diagnoses and medications, as well as certain information generated through app interactions or inferred from data such as location or purchases. But the definition has elements; an identifier or a health-related inference alone does not settle the question. The AHA opinion illustrates the corresponding caution on the HIPAA side: a plausible inference from metadata is not necessarily information that identifies a particular person’s health condition under the statutory IIHI test.

The difference is easy to miss because both systems use ordinary words such as “identifiable” and “health.” Under the FTC rule, information must fit the specified relationship to health or healthcare, come from a listed kind of source, and be provided by or on behalf of the individual, in addition to the identifiability condition. Under the AHA court’s reading of HIPAA, the challenged public-page metadata did not establish the visitor’s own health-related purpose, and the missing purpose was not information the provider or tracking vendor necessarily received. Similar vocabulary does not mean identical legal tests. Fourth, identify the conduct. A cybersecurity intrusion is not the only event that can matter under the FTC rule. The rule says a breach can include an unauthorized disclosure, including voluntary sharing that conflicts with a company’s representations to consumers. That makes the purpose and context of a data transfer important. It also means that a company cannot answer a breach question only by saying that no hacker entered its system.

The reverse is important too: the rule does not say that every transfer is automatically unauthorized. Sharing with a provider that is necessary to operate the app can be treated differently when the purpose is clearly disclosed, the provider is limited by contract, and the use remains tied to the service the person requested. A transfer to an advertising or profiling company for its own economic purposes raises a different question. The relevant analysis follows the person’s reasonable expectations and the company’s actual representations, not a one-word description such as “analytics.” Finally, identify the remedy. One regime may create a notification duty. Another may impose privacy obligations on a covered entity. A court may review whether an agency has exceeded its statutory authority and vacate a particular interpretation. Those outcomes are not interchangeable. Notice can create visibility and accountability without preventing the underlying collection. Vacatur can remove an unlawful agency position without granting a general license to disclose health information.

This distinction keeps the reader from asking a legal system to do work it was not designed to do. The FTC rule gives affected people information about what happened, what kinds of data were involved, what the organization is doing, and how to make contact. It does not promise that the collection never should have occurred. The AHA decision protects the statutory boundary against one overbroad interpretation, but it does not decide every future dispute involving a tracking tool, a public webpage, or information that genuinely identifies a patient’s health. A sound conclusion must name the protection and its limit together. The map below keeps these paths separate:

flowchart LR A["Digital health event"] --> B["Identify actor and product/record"] B --> C["Non-HIPAA personal health record ecosystem"] B --> D["HIPAA-covered public webpage and tracking metadata"] C --> E["FTC breach and authorization analysis"] D --> F["HIPAA IIHI and agency-authority analysis"] E --> G["Notification duty"] F --> H["Case-specific judicial remedy"] G --> I["Not omnibus privacy protection"] H --> I

This framework also explains why the title’s question cannot be answered from a product label or a single data point. If the answer stops at “not HIPAA,” it may miss the FTC’s notification route for a qualifying health app. If it starts with the assumption that any health-related page visit is a patient fact, it may treat an inference as HIPAA IIHI without checking what information was actually received and what the statute requires.

The better conclusion is more precise: HIPAA coverage is one boundary in a layered system, not the edge of legal consequence. The FTC rule supplies a defined, limited route for accountability outside HIPAA. American Hospital Association v. Becerra supplies a case-specific warning that HHS cannot expand a statutory definition through an unsupported categorical interpretation. To understand what follows from either boundary, the next question is what a health app must actually be—and how its record draws information from multiple sources.

References