What Is PHI? Protected Health Information for Founders
Protected health information (PHI) is individually identifiable health information — data tied to a specific person's past, present, or future physical or mental health, the care they received, or payment for that care — that a HIPAA-covered entity or its business associate creates, holds, or transmits. Strip the identifier or the covered relationship, and it generally stops being PHI.
Quick Answer: PHI is health information that (1) identifies a specific person and (2) is created, held, or transmitted by a HIPAA-covered entity or business associate. Remove either ingredient and it's usually not PHI — though other privacy laws can still apply to what's left.
Founders building anything health-adjacent hit this term early, usually in a nervous Slack message: "wait, is this PHI?" The honest answer is that most early-stage research data isn't — not because founders are lucky, but because PHI requires two things to line up at once, and early validation work usually only has one of them, if that. Getting the definition right upfront saves you from two expensive mistakes: freezing because you assume everything health-related is regulated, or building on data you shouldn't be touching because you assume nothing is.
This isn't a substitute for legal advice on your specific product. PHI determinations turn on facts — who collected the data, under what relationship, and how identifiable it really is — that a general article can't resolve for you. What follows gives you the shape of the concept; where your own situation is genuinely borderline, that's worth a real conversation with healthcare or privacy counsel before you build on an assumption either way.
How Data Becomes PHI: Identifiers Plus Health Context
Data becomes PHI when two ingredients combine: information about a person's health, care, or payment for care, and enough identifying detail — held in a covered context — to tie that information back to them. Miss either ingredient and the data isn't PHI, even if it clearly relates to health.
Health information is the easier half to picture: a diagnosis, a symptom, a treatment plan, a prescription, a lab result, a bill for a procedure. Identifiability is where founders get tripped up, because it's broader than "includes a name." HIPAA's de-identification standard recognizes a specific set of identifiers that, if present, generally make data identifiable even without a name attached — commonly known as the Safe Harbor list. It includes:
- Names
- Geographic detail smaller than a state, such as a street address, city, or ZIP code
- Dates tied to an individual — birth date, admission date, date of death — other than the year alone
- Phone numbers, fax numbers, and email addresses
- Social Security numbers
- Medical record numbers and health plan beneficiary numbers
- Account, certificate, and license numbers
- Vehicle identifiers and device serial numbers
- IP addresses and URLs tied to a specific person
- Biometric identifiers and full-face photographs
- Any other unique code or characteristic that could identify someone
None of these make data PHI on their own — an email address by itself is just contact information. PHI needs the health-information half and the identifying half attached to the same record, held by a covered entity or business associate. That combination is why a de-identified dataset, or a set of opinions with no health detail in them, isn't PHI even when it originated inside a healthcare system.
If you're not sure whether your company even counts as a covered entity or business associate in the first place — the relationship half of this test — our walkthrough on whether HIPAA applies to your app works through that question directly.
PHI vs. Not-PHI: Examples From Common Startup Scenarios
The fastest way to see the two-ingredient test in action is to run it against situations founders actually encounter. The table below sorts common scenarios by whether they clear both bars: identifiable, health-related, and handled in a covered context.
| Scenario | PHI? | Why |
|---|---|---|
| A user interview quote about managing anxiety, with no name attached | No | Health information alone isn't PHI without an identifier tied to it |
| An email address on a landing page waitlist for a diabetes app | No | Contact info without disclosed health detail isn't health data; interest in a category isn't a diagnosis |
| A support ticket where a named user describes their own symptoms, collected directly by a consumer app with no clinic relationship | Generally no, under HIPAA | Identifiable and health-related, but no covered entity or business associate relationship — other privacy laws can still apply |
| A patient's lab result you view or store on behalf of a clinic you're building for | Yes | Identifiable, health-related, and handled on a covered entity's behalf |
| A de-identified dataset with names, dates, and geographic detail stripped out | No | Removing the recognized identifiers takes data outside PHI, even if it originated from a covered source |
| A medical record number attached to appointment notes in a scheduling tool you run for a clinic client | Yes | Medical record numbers are a recognized identifier, and the tool is acting as a business associate |
The pattern holds across all six rows: removing the identifier, or staying outside a covered relationship, is what keeps data out of PHI — not the mere fact that it touches health. The support-ticket row is the genuine gray zone, and it's exactly the kind of fact pattern worth confirming with counsel rather than guessing, since the answer can shift with details a table can't capture.
De-Identification and Why It Matters for Validation
De-identification is the process of stripping the identifiers listed above so health data can no longer reasonably be traced back to a specific person — and once that happens, the data generally stops being PHI. For a founder, that's not a compliance footnote; it's a design choice that can keep your entire early validation process outside HIPAA's reach.
HIPAA recognizes two accepted routes to de-identification. The Safe Harbor method removes the full list of recognized identifiers from a record. Expert Determination instead relies on a qualified statistician to certify that re-identification risk is very small, even when not every identifier has been stripped. Founders rarely need to run either process formally. The more common move is simpler: never collect the identifier in the first place.
In practice, that means:
- Ask interview subjects for themes and quotes, not names attached to diagnoses
- Store survey responses without a name, email, or other identifier field
- Summarize findings across your interview pool instead of quoting one named individual's health history
- Strip dates down to a year, and locations down to a region, wherever health detail is present
This is also why sequencing matters. Early validation — the interviews, surveys, and landing pages that tell you whether a health idea is worth building — almost never needs identified health data to work. Save real, identifiable patient information for the stage where you actually need it: piloting with a real clinic or provider. Our HIPAA for startups validation guide walks through that staged sequence in full, from problem discovery through a compliant pilot.
PHI vs. PII: The Difference
PHI and PII overlap, but they aren't the same thing. PII is any data that identifies a specific person. PHI is the narrower subset of identifiable health data specifically handled by a HIPAA-covered entity or business associate. Every PHI record is PII; most PII is never PHI.
| Dimension | PHI | PII |
|---|---|---|
| Governed by | US federal health privacy law (HIPAA) | General and sector-specific privacy laws, which vary by state and country |
| What it covers | Individually identifiable health, care, or payment information | Any information that identifies a specific person |
| Who it applies to | Covered entities, business associates, and their subcontractors | Broader, and depends on the specific law — often anyone who collects personal data |
| Typical example | A named patient's diagnosis inside a clinic's records | An email address collected on a marketing signup form |
| Overlap | All PHI is PII | Most PII (contact and demographic data) is never PHI |
The practical consequence is that PII questions apply to you almost immediately — the moment you collect an email address or a name, general privacy law is in play, regardless of your industry. PHI questions only apply once you're inside a covered relationship, which most pre-launch, direct-to-consumer products aren't. Confusing the two causes both over-caution (freezing over an email signup form, which is PII, not PHI) and under-caution (assuming HIPAA is the only rule that matters, when state privacy and consumer-protection law still govern the PII you collect).
Building the habit of collecting only what you need — and treating identifiers deliberately rather than by default — is worth forming for any research program, health-related or not. Our complete guide to customer research for founders covers how to structure interviews and surveys so you capture insight without over-collecting personal data in the first place.
If your product sits close to this line — a wellness app that occasionally receives data from a clinic, for instance — don't resolve the PHI-versus-PII question by assumption. It's a genuinely fact-specific call, and a healthcare or privacy attorney can tell you where your actual data and relationships land.
Key Takeaways
- PHI needs two ingredients at once: identifiable detail plus health, care, or payment information, held in a covered context. Remove either one and it's usually not PHI.
- Identifiability is broader than a name. Medical record numbers, dates tied to a person, device serial numbers, and similar details can make data identifiable on their own.
- De-identification is a design choice, not just a compliance process. Most early validation work never needs to collect an identifier in the first place.
- PHI is a subset of PII, not a synonym for it. All PHI is PII; most PII founders collect — emails, names on a waitlist — never becomes PHI.
- The covered relationship matters as much as the data. The same identifiable health information can be PHI in a clinic's hands and outside HIPAA's direct reach in a consumer app's hands.
- Edge cases deserve a real answer, not a guess. Where your facts are genuinely borderline, confirm with healthcare or privacy counsel before you build on an assumption either way.
Frequently Asked Questions
Is an email address PHI?
On its own, no. An email address is contact information — it doesn't become PHI just because it sits inside a health-related product. It only enters PHI territory when it's tied to health, care, or payment detail about that person and held by a covered entity or business associate. Collected on a generic landing page waitlist, it's PII, not PHI.
What's the difference between PHI and PII?
PII is any information that identifies a specific person — a name, an email, a phone number — regardless of subject matter. PHI is the narrower category: identifiable health information handled by a HIPAA-covered entity or business associate. Every PHI record is also PII, but most PII, like a marketing signup or a software support ticket, never touches health information and never becomes PHI.
Does de-identified health data still count as PHI?
Generally, no. HIPAA's own de-identification standards — stripping the recognized identifiers, or having a qualified statistician certify low re-identification risk — exist specifically to take data outside PHI. Aggregated or anonymized findings from customer interviews, with no name, contact detail, or other identifier attached, typically fall into this category.
Do I need HIPAA compliance if I collect health information directly from users?
Usually not, if you're not acting on behalf of a covered entity like a clinic or health plan. A consumer app where users enter their own symptoms or health goals, with no provider relationship behind it, often sits outside HIPAA's direct reach — though other privacy laws may still apply. Confirm your specific setup with counsel if any provider, insurer, or clearinghouse relationship is involved.