Every HIPAA scoping conversation eventually reaches the same question: is this data PHI? The answer decides which systems need Security Rule safeguards, which vendors need a business associate agreement, and which incidents might become reportable breaches. Teams often answer it by instinct, and the instinct tends to be wrong in both directions.
The definitions are in 45 CFR 160.103, and they are more specific than most people expect. Whether information is PHI depends on what it is, who holds it, and in what capacity. Whether it is ePHI depends only on the medium. This article walks through both definitions, the exclusions, and the cases that come up most in software companies.
The definition, in three layers
HIPAA builds PHI out of three nested definitions.
Health information is any information, including genetic information, that relates to the past, present, or future physical or mental health of an individual, the provision of health care to them, or payment for that care. It counts when it is created or received by a health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse.
Individually identifiable health information is health information, including demographic information, that is created or received by a provider, health plan, employer, or clearinghouse, and that identifies the individual. It also counts if there is a reasonable basis to believe it could be used to identify them.
Protected health information is individually identifiable health information transmitted or maintained in any form or medium, subject to the exclusions below. HHS's summary of the Privacy Rule describes it as such information held or transmitted by a covered entity or its business associate.
The "relates to" test is broad. The fact that a person is a patient of a particular provider relates to the provision of care. A clinic's appointment list of names and times is PHI, even with no diagnosis on it. Billing and payment records are PHI because they relate to payment for care.
Who holds it matters as much as what it is
HIPAA regulates covered entities and their business associates. Health data outside that relationship is not PHI, however sensitive it is.
Consider the same blood pressure reading in three places:
In a hospital's records system, it is PHI. The hospital is a covered entity.
In a remote monitoring platform the hospital uses for its patients, it is PHI. The platform handles it on the hospital's behalf, as a business associate.
In a consumer fitness app the individual downloaded and uses on their own, it is usually not PHI. No covered entity is involved.
HHS has published guidance on health app scenarios that follows this logic. The question is whether the app is provided by, or on behalf of, a covered entity. If it is not, HIPAA generally does not apply, but other federal and state laws may. Consumer health data laws vary, so confirm with counsel which apply to a product outside HIPAA.
The same applies inside one organization. A covered entity also acts as an employer, and records it holds in that role are not PHI. That leads to the exclusions.
What the definition excludes
PHI excludes individually identifiable health information in four categories:
Education records covered by FERPA. Student health records held by a school subject to FERPA, such as a school nurse's records, fall under FERPA instead. The exclusion also reaches certain student treatment records that FERPA describes. If you sell to schools, FERPA for edtech vendors covers that side, and the FERPA framework page summarizes it.
Employment records held by a covered entity as employer. A hospital's file on its own employee's sick leave is an employment record, not PHI. The same employee's chart from treatment at that hospital is PHI.
Information about a person who has been dead for more than 50 years.
De-identified information. Data de-identified under one of the two methods in 164.514, Safe Harbor or Expert Determination, is not PHI.
The de-identification exclusion is the one teams reach for, and it is narrower than it looks. Removing names is not de-identification. The Safe Harbor list of identifiers includes items such as dates more specific than the year, geographic units smaller than a state with limited exceptions, device identifiers, URLs, and IP addresses. Aggregate statistics built from PHI are not automatically de-identified either. Treat them as PHI unless they meet one of the two methods.
ePHI: where the Security Rule's scope ends
Electronic protected health information is PHI transmitted by electronic media or maintained in electronic media. Every piece of ePHI is PHI. Not every piece of PHI is ePHI.
The distinction sets the boundary between rules:
| Rule | Applies to |
|---|---|
| Privacy Rule | PHI in any form: electronic, paper, or spoken |
| Security Rule | ePHI only |
| Breach Notification Rule | Unsecured PHI in any form |
Electronic media covers storage, such as disks, memory, and removable media, and transmission, such as the internet, private networks, and the physical movement of removable media. The definition carves out two cases: paper faxed from a paper original, and voice calls, are not transmissions by electronic media if the information did not exist electronically immediately before. Once information is stored electronically, such as a voicemail saved to a system or a fax received into a fax server, treat it as ePHI.
For a SaaS company, almost all the PHI you handle is ePHI. The paper and spoken cases matter mainly for support calls, printed reports, and anything your staff write down.
The edge cases SaaS teams hit
These are the classification questions that come up most in scoping. The answers assume you are a business associate handling data for a covered entity customer.
User accounts for the customer's staff. Names and emails of clinicians who log in to your product are not PHI. They identify workforce members, not patients.
Patient identifiers with no clinical data. A patient's name, email address, or record number in your system is PHI. It sits there because the person is a patient or member of your customer.
Logs and error reports. If a log line includes a patient identifier, a URL with a record ID, or a request body with clinical fields, the log holds PHI, and so does every system that stores it.
Support tickets and screenshots. A screenshot of a patient record attached to a ticket is PHI in your help desk.
Test and staging data. A copy of production is PHI. Synthetic data is not, and real data with names removed probably still is.
Analytics events. An event carrying a patient ID is PHI. An event carrying only a customer account ID and a feature name usually is not.
Data you keep after the contract ends. Your obligations follow the data, not the contract. PHI retained under the infeasibility clause in your agreement stays PHI.
When the answer is unclear, the conservative move is to classify the data as PHI and keep the record of why. Getting it wrong in that direction costs safeguards. Getting it wrong in the other direction can cost a breach notification, as HIPAA breach notification: timelines and thresholds explains.
Build the inventory once
Classification only helps if it is written down per system. Start a data inventory that lists each system, whether it holds PHI, whether that PHI is electronic, who can reach it, and which vendor runs it. The same inventory is the scope for your HIPAA risk analysis and the source list for the business associate agreements you need. Review it whenever a new system or vendor appears. The HIPAA framework page lists the safeguards each system on it will need.