The Layered Answer to 'Does HIPAA Apply?'

The central subject of this series is the boundary between HIPAA and the Federal Trade Commission’s Health Breach Notification Rule, not the abstract idea that health data is “sensitive.” The final question is what a reader should conclude when a health app, a hospital webpage, or a technology vendor handles information outside a familiar legal category. The answer is direct but qualified: HIPAA may not apply while another regime still creates meaningful obligations, and a court’s rejection of one HIPAA interpretation does not make every digital health practice lawful.

A reliable judgment requires more than a yes-or-no label. The relevant actor, product, record, data, conduct, and remedy have to be considered together. The FTC rule and American Hospital Association v. Becerra provide two source-backed examples of why. The FTC rule creates a breach-notification route for qualifying non-HIPAA personal health record ecosystems. The AHA opinion limits HHS’s attempt to classify a particular public-web metadata combination as HIPAA individually identifiable health information, or IIHI, through a guidance document. These are not competing answers to one definition. They are different legal tests operating at different points in the health-data system.

A single event has to pass several gates

Start with the actor and the product. A hospital, consumer health app, wearable maker, analytics firm, and cloud provider can all participate in one transfer without occupying the same legal position. The FTC rule’s vendor, PHR related entity, and third-party service-provider categories follow what each participant offers, receives, sends, maintains, or uses. The person who operates the consumer-facing record may have the duty to notify the individual. A back-end provider may have to alert the vendor instead. An analytics firm may support the app in one function and use information for its own purposes in another.

Then ask what record exists. The FTC rule’s personal health record is not any database containing a health-related fact. It is an electronic record of an individual’s PHR identifiable health information that has the technical capacity to draw information from multiple sources and is managed, shared, and controlled by or primarily for the individual. The multiple-source requirement is about implemented capacity, not how many users activate an integration. The individual-control requirement prevents an incidental connection from turning every general-purpose system into a PHR.

The data must then pass its own definition. Under the FTC rule, PHR identifiable health information relates to an individual’s health or condition, healthcare, or payment for healthcare; identifies the individual or can reasonably be used to identify them; is created or received by one of the listed kinds of provider or organization; and includes information provided by or on behalf of the individual. The Commission says that app interactions, persistent identifiers combined with health information, and some information inferred from location or purchases can fit the definition when the other elements are present. The possibility of an inference is not the same as proof that every inference qualifies.

Next comes the conduct. Even after a product and data pass the coverage test, the FTC notification rule asks whether unsecured PHR identifiable health information was acquired without the individual’s authorization. A breach can result from a cybersecurity intrusion, but it can also result from an unauthorized disclosure or a use that exceeds the original authorization. The organization’s privacy representations, the recipient’s purpose, the person’s reasonable expectations, and the quality of the person’s choice all affect the analysis. The rule’s authorization inquiry is contextual, not a universal requirement that every operational transfer use the same affirmative-consent screen.

Finally, assign the consequence. A qualifying breach can lead to notice to individuals, the FTC, and sometimes the media, with different routes for third-party service providers and different timing for larger and smaller incidents. A violation can carry civil penalties under the FTC rule’s enforcement provision. None of that means the FTC rule is an omnibus privacy code. It creates a defined response to a defined breach in a defined PHR ecosystem.

The unified path is therefore not “health data, then HIPAA.” It is closer to this:

flowchart LR A["Health-data event"] --> B["Identify actor and product/record"] B --> C{"Non-HIPAA PHR with PHR-identifiable health information?"} C -->|"Yes"| D["Test unsecured data, acquisition, and authorization"] D --> E["Assign vendor, related-entity, or service-provider role"] E --> F["FTC notice and enforcement path"] C -->|"Not this FTC PHR path"| G["Identify any other governing context, including HIPAA when applicable"] G --> H["Apply the relevant HIPAA/IIHI definition"] H --> I["AHA's narrow public-web metadata holding, if applicable"] I --> J["Case-specific remedy; other laws or guidance may remain relevant"] F --> K["Qualified conclusion: not HIPAA or nothing"] J --> K

The diagram is a decision aid, not a claim that the two branches exhaust every health-data law.