How a Health App Becomes a Regulated Personal Health Record
This chapter focuses on the Federal Trade Commission’s test for deciding when a non-HIPAA health app or connected service is a personal health record, or PHR. That question supports a concrete judgment: before asking whether a company mishandled health information, first determine whether the product creates the kind of individual-oriented record that the FTC Health Breach Notification Rule covers. A health-related label is a clue, not the answer. The result depends on the record, its sources, the information it contains, and the relationship between the product and the person using it.
The product test comes before the breach test
The FTC rule begins with a product category, not with every isolated fact that might reveal something about someone’s health. A personal health record is an electronic record of PHR identifiable health information about an individual that has the technical capacity to draw information from multiple sources and is managed, shared, and controlled by or primarily for that individual. An entity that offers or maintains such a record can be a vendor of personal health records under the rule, unless it is a HIPAA-covered entity or is acting as a business associate within the excluded activity.
Each part of that definition does work. The record must be electronic and connected to an individual. A webpage that gives general advice about asthma, diabetes, or depression may contain health information, but it is not automatically a PHR merely because a visitor reads it. The rule’s examples distinguish a purely informational health site from a site that lets a logged-in person record symptoms and receive possible diagnoses. The second site has an individual record of health information; the first does not.
The second site still may not be a PHR. If the symptom tracker receives information only from the person who types into it, it may lack the required technical capacity to draw from multiple sources. That result can seem counterintuitive because the site holds individualized health information. But the PHR definition is not a synonym for “digital health record.” It adds a structural condition: the record must be capable of bringing together information from more than one source.
The 2024 amendments make the capacity point explicit. The question is not how many users activate a particular integration or whether a feature is popular. It is whether the product has the technical means to draw information from multiple sources. An app that accepts a person’s mental-health entries and has an available connection to a wearable sleep monitor can meet that condition even if the person never turns on the connection. Otherwise, a company could change the legal analysis simply by leaving an integration dormant or by designing the product so that only a small number of people use it.
This is a rule about a product’s capabilities, not a claim that every possible future capability counts. The Commission says an undeveloped feature that would require changes to the app’s design or underlying code does not count if the developer has not implemented those changes. By contrast, an existing integration that can draw PHR identifiable health information can count even when it is unused, unpublicized, in testing, or not yet widely adopted. The distinction is between an implemented technical capacity and a mere possibility that someone might build one later.
The sources do not make multiple-source capacity sufficient by itself. The record must still contain PHR identifiable health information, and it must be managed, shared, and controlled by or primarily for the individual. That last condition prevents the rule from treating every back-end data system as a PHR just because it can receive information from several places. A personal health record is oriented toward the individual’s access, management, tracking, control, or participation in their own care.
The Commission’s examples show how the conditions interact. Consider a health-advice site with a symptom tracker. If the site accepts symptoms from a user but has no other source, it may be an electronic record of identifiable health information without being a PHR. If it also collects the user’s geolocation through an application programming interface, or API, it has technical capacity to draw from the user and the location service. The Commission treats that combination as a personal health record when the other conditions are met. If the site instead connects the user’s record to a data broker so it can make more accurate diagnostic suggestions, the same multiple-source logic can apply.
The source of the second input need not be another medical chart. The FTC gives an example of a diet and fitness app that combines health information supplied by the user with calendar information, location, or time-zone information drawn through a phone API. The app still needs at least one source of PHR identifiable health information, but the additional source can be non-health information. This matters because digital products often construct a health-related profile by joining an explicit health entry to ordinary device or account data.
That approach also explains why the FTC chose “technical capacity” rather than actual usage as the operative phrase. A product’s architecture can shape whether information is collected, linked, or exposed later. Looking only at current user behavior would make coverage depend on adoption statistics and create incentives to suppress, hide, or artificially limit integrations. Looking only at theoretical possibilities would be too broad. The Commission’s distinction—implemented capacity, plus a qualifying record and individual-oriented control—tries to occupy the space between those extremes.
The practical consequence is that a coverage analysis should begin with the record’s design. Ask what the product actually lets a person do, what connections are implemented, and whether the record is maintained for that person. Do not begin with the assumption that the presence of a health topic proves coverage, or that the absence of a hospital relationship proves the opposite. HIPAA status is relevant, but the FTC rule’s own product definition does the next part of the work.
The data test keeps the category broad but bounded
Once the product appears to be a qualifying PHR, the next question is whether the information inside it is PHR identifiable health information. The final rule defines that information through several elements. It must relate to an individual’s past, present, or future physical or mental health or condition, the provision of health care, or payment for health care. It must identify the individual or provide a reasonable basis to believe it can be used to identify that individual. It must be created or received by a covered health care provider, a health plan, an employer, or a health care clearinghouse. With respect to an individual, it also includes information provided by or on behalf of that individual.
The definition reaches more than a diagnosis typed into a form. The Commission says it can cover traditional information such as medications, health conditions, or treatment, but also information generated by a person’s interactions with an app or another online service. A customized record of pages or features used in an app may matter. Health information inferred from non-health data, such as location or recent purchases, may also fall within the definition when the other elements are satisfied. A persistent device or advertising identifier can be part of PHR identifiable health information when it is combined with health information and can identify or re-identify the person.
That does not mean every inference is automatically regulated. The rule keeps identifiability as a separate condition. The Commission describes an objective question: is there a reasonable basis to believe the information can be linked to an individual? If the data has been de-identified under the relevant HHS standards and there is no reasonable basis to identify the person, it does not meet this element of the FTC definition. The existence of a sophisticated data ecosystem may make re-identification a serious concern, but concern alone does not replace the rule’s required link to an individual.
The phrase “provided by or on behalf of the individual” is another boundary. The Commission declines to replace it with the broader phrase “about the individual,” while recognizing that much information about a person begins with information that the person supplies. A person’s entry, device reading, or requested service may generate later records and inferences. But the legal definition still asks how the information entered the system and whether the record can reasonably be connected to the individual.
The term “covered health care provider” can create its own confusion. In this rule, the Commission defines it to include traditional providers and “any other entity furnishing health care services or supplies.” It then defines health care services or supplies to include online services—websites, mobile applications, and internet-connected devices—that provide mechanisms to track diseases, diagnoses, testing, treatment, medication, vital signs, symptoms, bodily functions, fitness, fertility, sexual health, sleep, mental health, genetic information, diet, or other health-related services or tools.
The Commission deliberately uses a broad, technology-neutral description. Health apps do not need to look like electronic hospital records to furnish a health-related online service. A fertility tracker, sleep tool, connected blood-pressure monitor, and diet application can serve different purposes while still fitting the rule’s conception of health care services or supplies. But the Commission also renames the term “covered health care provider” to make clear that this is a definition for the FTC rule. It does not determine what “health care provider” means in every other regulation enforced by another agency.
The boundaries become clearer through counterexamples. A health-advice website that only presents information and has no mechanism for an individual to track or record information is not a PHR in the Commission’s example. A symptom tracker that creates a record for a logged-in person may have individualized health information, but it is not a PHR if it cannot draw information from multiple sources. Add an implemented geolocation API, and the analysis can change because the record now has the required technical capacity. Add a data-broker integration used to tailor suggestions, and the same result may follow for a different reason.
A general retailer illustrates the other side of the line. An app that lets customers buy products and review their purchases is not automatically a vendor of personal health records merely because a purchase—such as a pregnancy test—might reveal something about health. The Commission says an offering must relate to health more than tangentially. A retailer could become a vendor if it offers features that are sold, marketed, or promoted as addressing, improving, tracking, or informing matters about a consumer’s health. The ordinary purchase function alone does not settle that question.
There is an additional physical-versus-electronic distinction. A purchase made at a brick-and-mortar store, without an app, website, or online service that lets a person access or track the information electronically, is not a personal health record under the rule. The purchase may be sensitive in an everyday sense, but the rule’s PHR category requires an electronic record with the defined structure. That is an example of why data sensitivity and legal coverage should not be treated as identical concepts.
The coverage decision is therefore fact-intensive. A product description may suggest the answer, but it cannot replace evidence about how the service works. A careful reader would want to know whether the relevant record is individual-specific, whether at least one source supplies PHR identifiable health information, whether another implemented source is technically available, whether the record is managed primarily for the individual, and whether the information can reasonably be linked to that person. Evidence that a connection exists in production could change the answer; evidence that a proposed connection requires unimplemented code changes could change it in the other direction.
The decision path looks like this:
The word “potential” in the final box is deliberate. The diagram is a way to organize the rule’s threshold questions, not a product-specific legal determination. A qualifying PHR vendor still has to face a separate question about the event: was the information unsecured, and was it acquired without the individual’s authorization? Coverage tells us which regulatory path may be available. It does not itself prove that a breach occurred.
That separation is the chapter’s central lesson. A health app becomes relevant to the FTC rule through the interaction of product architecture, individual control, identifiable health information, and the status of the actor. The FTC’s approach is broad enough to follow the way digital products combine user entries with devices, APIs, and other data, but it is not a declaration that every health-related trace is a personal health record. Once the record passes this threshold, the next question is not what the app is called. It is what happened when the app handled the information.