What Counts as PHI on a Website? IP Addresses, URLs and Form Fields

Almost every conversation about PHI on a website starts with someone reciting the eighteen identifiers. Names, dates, phone numbers, email addresses, IP addresses, and so on down the list. It is the most quoted document in this area and it is the wrong tool for the job, because that list was never written to define protected health information. It was written to describe how to strip it out of data you already know is protected.

Reading it as a definition produces two opposite errors. It makes practices treat harmless data as radioactive because it contains an email address, and it makes them ignore genuinely sensitive data because it happens to contain none of the eighteen. The definition that actually governs is shorter and lives one regulation earlier.

The two-part test for PHI on a website

Protected health information is individually identifiable health information held or transmitted by a covered entity. Unpack the middle term and you get two requirements that must both be satisfied by the same body of data.

Two prongs. Relates to health, and identifies a person. A data element that satisfies only one of them is not protected health information, no matter how sensitive it feels. This is the entire framework, and once you hold it properly most website questions answer themselves.

The eighteen identifiers, and why the list misleads

The eighteen identifiers come from 45 CFR 164.514, the Safe Harbor method for de-identification. The logic runs one direction only: if you have PHI, and you remove all eighteen categories, and you have no actual knowledge the remainder could identify anyone, the result is no longer PHI.

That is a removal checklist. It presumes you started with protected health information and tells you how to stop. It says nothing about how data becomes protected in the first place, which is why using it as a definition produces nonsense in both directions.

Data can be PHI while containing none of the eighteen, because the identifying half can be satisfied by a reasonable basis to identify rather than by a listed identifier. Data can contain several of the eighteen and not be PHI at all, because nothing about it relates to health. A newsletter list of email addresses collected at a trade show is full of identifiers and is not protected health information.

The phrase doing the quiet work is reasonable basis to believe the information can be used to identify. It is deliberately broader than the enumerated list, and it is the reason a cookie identifier matters even though no regulation names it. A random string in a browser identifies nobody in the abstract. The moment it is joined to a record that carries a name, whether by the site operator or by the vendor receiving it, the reasonable basis exists and it existed retroactively for every request that string ever appeared in.

This is also why "we only send anonymous data" is rarely an accurate description of what a third-party tag does. Anonymity is not a property of a single field. It is a property of a field considered against everything else the recipient already holds, and a large advertising platform holds a great deal. The question is never whether the identifier is meaningful to you. It is whether it is resolvable by whoever receives it.

What each element actually is

Here is the element-by-element version for the data a typical tracker sends. The useful column is the last one, because it names the thing that changes the answer.

Read down the table and the pattern is hard to miss. Almost nothing in a web request is protected on its own. The identifying elements carry no health meaning, and the health-meaning elements identify nobody. Exposure is created by combination, and a single network request is a combining machine.

Where PHI on a website usually comes from

In practice the combinations arise in three places, and they are not equally common or equally defensible.

The submitted form. This is the clearest and the most frequently overlooked. A consultation request that asks for a name, an email, a phone number and what the patient would like to discuss has assembled both prongs in a single submission, by design, because that is what the form is for. If an advertising tag is present on that page and configured to capture form interactions, it is receiving volunteered health information attached to a named person.

The authenticated session. Behind a login the operator already knows who the visitor is and already holds their record. Every page view in that session relates to an identified individual's care. This was never seriously contested and remains the strongest case.

The inferred visit. A visitor reads a treatment page while a tag records the URL, an IP address and a cookie id. Nobody submitted anything. This is the combination that a federal court examined in American Hospital Association v. Becerra and vacated in June 2024, holding that an IP address collected from a public, unauthenticated page fails both prongs. We cover what did and did not survive in the full walkthrough of the guidance.

Reasoning about PHI on a website you are unsure of

When a specific page is in question, three questions settle it faster than reaching for the identifier list.

Does the visitor tell you something about their health here? If there is a form asking about a condition, a symptom, a procedure of interest or a reason for the visit, the answer is yes and the analysis is short.

Do you already know who this visitor is? If the page sits behind a login, or the visitor arrived from an email link carrying their record id, the identifying prong is satisfied before the page even renders.

Does the address itself state a health fact? A path that names a treatment supplies health context to every request made from that page, including requests you did not author and cannot see.

What makes that last one uncomfortable is that URL structure is usually decided years earlier by whoever built the site, for reasons that had nothing to do with privacy. Descriptive paths are good practice for search, so the same instinct that produces a well-organised site produces a set of addresses that announce a health topic on every request. Renaming them is not the fix, and it would cost real search equity. Controlling what gets to read them is.

One further caution about scope. The analysis above is about the Privacy Rule, and a page can be clear of PHI while still creating obligations elsewhere. State consumer health data statutes attach to a much broader category, defined by whether information is linkable to a consumer and identifies their health status, with no covered-entity requirement at the front of the test. A cash-pay aesthetics practice that concludes it holds no PHI has answered the HIPAA question correctly and has not answered the state question at all.

If any of the three is yes, treat what leaves that page as sensitive and decide deliberately what is allowed to load. That decision is what a consent gate implements: non-essential tags are held until a visitor agrees, so the combination never leaves the browser by default. Consent gating is the mechanism, and the reason it sits in front of the tag rather than inside it is that a tag configured to behave cannot be audited, while a tag that never loaded can.

Two footnotes worth carrying. HIPAA only reaches you if you are a covered entity in the first place, which is a separate question covered in does HIPAA apply to your website. And HIPAA is a floor, not a ceiling: Washington and Nevada regulate consumer health data on terms that do not ask whether you are a covered entity at all, which state privacy detection covers.