PHI — protected health information — is the single most important term in HIPAA, and also the most misunderstood. People imagine it means "medical secrets" or "especially sensitive records," and then get surprised when a shipping address, an appointment reminder, or a server log turns out to be PHI too. The definition is narrower and more mechanical than the intuition suggests: PHI is health information that can be linked to a specific individual and is held by a party HIPAA regulates. Get that sentence into your bones and almost every "is this in scope?" question answers itself.
What PHI Actually Is
The formal definition has three moving parts, and all three have to be present. PHI is individually identifiable health information that is created, received, maintained, or transmitted by a covered entity or business associate. Break that down and it becomes concrete: the information has to relate to health (a physical or mental condition, the care provided, or the payment for that care); it has to be identifiable (linkable to a specific person); and it has to sit with a party HIPAA actually regulates.
That last part matters more than people expect. The exact same health fact can be PHI in one context and not in another, depending entirely on who is holding it and why. A heart-rate reading inside a hospital's records is PHI. The same reading inside a consumer fitness app that has no relationship with a healthcare provider generally is not — because the app isn't a covered entity or acting as a business associate. HIPAA regulates a relationship as much as a data type, which is why understanding covered entities and business associates is inseparable from understanding PHI.
Health Detail + Identifier
The most useful way to hold PHI in your head is as a simple formula: a health detail plus an identifier equals PHI. Neither half is protected on its own. "Type 2 diabetes" sitting in a list of conditions with no names attached isn't PHI. "Priya Sharma" on its own is just a name. Put them together — "Priya Sharma, Type 2 diabetes" — held by a provider or their vendor, and you have protected health information.
The identifier half is what the famous list of 18 HIPAA identifiers enumerates: not just names and Social Security numbers, but dates, ZIP codes, email addresses, account numbers, device IDs, IP addresses, biometrics, and a catch-all for any other unique code. Any single one of them, attached to a health detail, supplies the link that makes the whole record PHI. Which means the surface area is far larger than most product teams assume.
An identifier alone isn't PHI — a mailing list of names and addresses isn't health information. It becomes PHI when the very fact of being in your data set reveals something about a person's health: a list of names is neutral, but a list of names of patients at an oncology clinic is PHI, because membership itself is a health detail.
PHI vs Not PHI: Examples
Definitions get slippery fast, so here is the same test applied to concrete scenarios. Notice how the answer turns on the two-part formula and on who holds the data, not on how "medical" it feels.
| Scenario | PHI? | Why |
|---|---|---|
| A lab result stored with the patient's name at a clinic | ✓ Yes | Health detail + identifier, held by a covered entity |
| An appointment reminder text with a name and a date | ✓ Yes | The appointment implies care; name and date are identifiers |
| A server log capturing IP addresses on a patient portal | ✓ Yes | IP is identifier #15, tied to use of a health service |
| "1,200 flu cases this week" with no identifiers | ✗ No | Aggregate, de-identified — no link to any individual |
| A hospital's payroll and sick-leave record of its own staff | ✗ No | Held by the entity as an employer, not a provider |
| Step counts in a consumer fitness app (no provider link) | ✗ No | The app isn't a covered entity or business associate |
The pattern is consistent: identifiability plus health context plus a regulated holder equals PHI. Remove any one leg and it falls out of scope — which is exactly the mechanism de-identification exploits.
ePHI: The Electronic Subset
You will constantly see the term ePHI, and it is simpler than it looks: ePHI is just PHI in electronic form — anything stored, processed, or transmitted by computers, servers, cloud platforms, phones, or portable media. Every byte of ePHI is PHI; it is a subset, not a separate thing.
The reason the distinction exists at all is that HIPAA's two central rules split along it. The Privacy Rule governs PHI in every form — including a conversation at a reception desk or a printed chart. The Security Rule applies specifically to ePHI, and it is where the technical safeguards live: access controls, encryption, audit logging, transmission security. For a software company, essentially all the PHI you touch is ePHI, so the Security Rule is where most of your engineering effort goes. We unpack that split in the Privacy, Security, and Breach Notification rules explained.
What Isn't PHI
Knowing what falls outside the definition is just as valuable, because it stops you from over-restricting harmless data — and from wrongly assuming HIPAA covers something another law actually governs.
✓ Is PHI
- Identifiable health data held by a provider, plan, or clearinghouse
- The same data held by their vendors (business associates)
- Billing and payment records for care
- Any ePHI in your app, database, or logs
✗ Is Not PHI (under HIPAA)
- De-identified data with all 18 identifiers removed
- Employment records an employer holds as an employer
- Student health records covered by FERPA
- Consumer app health data with no covered-entity link
A word of caution on the right-hand column: "not PHI" does not mean "not regulated." Consumer health data can fall under the FTC Health Breach Notification Rule or state privacy laws; personal data of EU or Indian users is governed by GDPR and the DPDP Act. HIPAA is one lane, not the whole road — a point we draw out in HIPAA vs GDPR vs DPDP.
Where Teams Get It Wrong
Almost every PHI mistake traces back to forgetting one leg of the definition. Three patterns account for most of them:
- "We don't store medical records, so we're fine." PHI isn't only charts and diagnoses. An appointment time, a pharmacy address, an insurance ID, or a portal login all become PHI in a health context. The mundane fields are still in scope.
- "We stripped the names, so it's anonymous." Removing names is not de-identification. Dates, ZIP codes, and rare combinations can still single out a person, and until all eighteen identifiers are gone (or an expert certifies the risk is tiny), the data is still PHI.
- "The tracking script only sees technical data." IP addresses, device IDs, and URLs are identifiers. A pixel or session recorder on a page that shows health information is very likely shipping PHI to a third party with no agreement — one of the most common and expensive HIPAA errors software teams make.
Regulators have made clear that online tracking technologies on health websites and apps can disclose PHI when they capture an identifier alongside health-related activity. If a page reveals a condition, a provider, or an appointment and a third-party script is watching, treat that data flow as PHI and put an agreement — or the tracker's removal — in place.
Final Thought
PHI is best understood not as a scary category of data but as a state that ordinary health information enters the moment it becomes identifiable in the hands of a regulated party. That reframing is liberating, because it turns a vague fear into a precise test you can run against any field in your system: is there a health detail, is there an identifier linking it to a person, and are you a covered entity or business associate holding it. Three yeses and you are handling PHI, whatever your product is called.
The test: take the least "medical-looking" piece of data in your health product — an IP in a log, a shipping address, an appointment slot — and run the two-part formula on it. If it survives as PHI, you have just found the data most teams forget to protect.
Frequently Asked Questions
PHI — protected health information — is health information that can be tied to a specific person and is held or transmitted by a HIPAA covered entity or business associate. In practice it is a health detail (a diagnosis, treatment, or payment for care) combined with an identifier such as a name, date, or account number. The health fact alone isn't PHI; the link to an individual is what makes it protected.
ePHI is simply PHI in electronic form — stored, processed, or transmitted by computers, servers, cloud services, phones, or portable media. All ePHI is PHI. The distinction matters because HIPAA's Security Rule applies specifically to ePHI and sets the technical safeguards, while the Privacy Rule covers PHI in every form including paper and spoken word.
De-identified data (with all eighteen identifiers removed), health data held by an employer in its role as an employer, student records covered by FERPA, and health data collected by consumer apps that aren't acting for a covered entity generally fall outside HIPAA's definition of PHI. Health information only becomes PHI when it is identifiable and held by a covered entity or business associate — though other laws may still apply.
No. A name by itself is an identifier, not health information. It becomes PHI only when it is connected to a health detail — a condition, treatment, appointment, or payment for care — held by a covered entity or business associate. PHI always requires both halves: the identifier and the health context.