Three acronyms show up constantly in healthcare compliance conversations: PHI, PII, and ePHI. They get used interchangeably in meetings, vendor pitches, and even internal policies. That is a problem, because they are not the same thing. Each term has a distinct legal definition, falls under different regulatory frameworks, and triggers different compliance obligations.
If your organization handles health data in any form, confusing these terms is not just sloppy. It creates real gaps in your compliance program. You end up protecting the wrong data with the wrong safeguards, or worse, failing to protect data that HIPAA specifically requires you to secure.
This article breaks down each term, shows where they overlap and diverge, and explains what these distinctions mean for day-to-day compliance. If you have not yet mapped the data your organization handles, a HIPAA risk assessment is the place to start.
PHI, PII, and ePHI Definitions, Differences, and Compliance Requirements
What Is PII (Personally Identifiable Information)?
PII stands for Personally Identifiable Information. It is the broadest of the three terms and is not specific to healthcare.
PII refers to any information that can be used to identify, contact, or locate a specific individual. The term is used across multiple federal and state regulatory frameworks, including the FTC Act, the Privacy Act of 1974, NIST SP 800-122, and various state data breach notification laws.
Common Examples of PII
- Full name
- Social Security number
- Date of birth
- Home address
- Email address
- Phone number
- Driver’s license number
- Passport number
- Financial account numbers
- Biometric data (fingerprints, facial recognition)
- IP addresses (in certain contexts)
What Regulates PII?
There is no single federal PII law in the United States. Instead, PII is governed by a patchwork of sector-specific federal laws (GLBA for financial data, FERPA for education records, COPPA for children’s data) and state-level privacy statutes. The NIST definition in Special Publication 800-122 is widely referenced but is guidance, not binding regulation.
The key point for healthcare organizations: PII and PHI are not synonyms. A patient’s name is PII. A patient’s name attached to a diagnosis is PHI. The regulatory obligations are different for each.
What Is PHI (Protected Health Information)?
PHI stands for Protected Health Information. Unlike PII, PHI has a precise legal definition under HIPAA.
Under 45 CFR 160.103, PHI is individually identifiable health information that is created or received by a covered entity or business associate and relates to:
- The past, present, or future physical or mental health condition of an individual
- The provision of healthcare to an individual
- The past, present, or future payment for the provision of healthcare to an individual
The critical element is the link between an identifier and health information. A diagnosis by itself is not PHI. A name by itself is not PHI. A diagnosis linked to a name, date of birth, or any of HIPAA’s 18 identifiers is PHI.
For a deeper breakdown of what qualifies as PHI and the 18 identifiers, see our complete PHI guide.
The 18 HIPAA Identifiers
Under 45 CFR 164.514(b)(2), HHS defined 18 specific identifiers that, when combined with health information, create PHI:
- Names
- Geographic data smaller than a state
- Dates (except year) related to an individual (birth, admission, discharge, death)
- Phone numbers
- Fax numbers
- Email addresses
- Social Security numbers
- Medical record numbers
- Health plan beneficiary numbers
- Account numbers
- Certificate/license numbers
- Vehicle identifiers and serial numbers
- Device identifiers and serial numbers
- Web URLs
- IP addresses
- Biometric identifiers
- Full-face photographs and comparable images
- Any other unique identifying number, characteristic, or code
When any one of these identifiers is connected to health information, the result is PHI, and HIPAA’s Privacy Rule and Security Rule apply in full.
What Regulates PHI?
PHI is regulated exclusively by HIPAA (the Health Insurance Portability and Accountability Act of 1996) and the HITECH Act (Health Information Technology for Economic and Clinical Health Act of 2009). Enforcement is handled by the Office for Civil Rights (OCR) at the U.S. Department of Health and Human Services.
The HIPAA Privacy Rule (45 CFR Part 164, Subpart E) governs the use and disclosure of PHI. The HIPAA Security Rule (45 CFR Part 164, Subpart C) governs the technical and administrative safeguards required for electronic PHI specifically.
Understanding what counts as PHI is not only relevant in traditional healthcare settings. If your organization uses AI tools or automated systems that process patient data, those inputs may contain PHI even if no one intended to include it. Our article on what counts as PHI in AI prompts covers this increasingly common scenario.
What Is ePHI (Electronic Protected Health Information)?
ePHI stands for Electronic Protected Health Information. It is not a separate category of data. It is PHI that is created, stored, transmitted, or received in electronic form.
Under 45 CFR 160.103, ePHI is defined as individually identifiable health information that is transmitted by or maintained in electronic media. Electronic media includes computer hard drives, removable storage (USB drives, CDs), networked systems, cloud storage, email, and any transmission over the internet or an intranet.
What Is Not ePHI?
PHI that exists only on paper or is communicated verbally is not ePHI. A printed patient chart in a file cabinet is PHI, but it is not ePHI. A doctor verbally sharing a diagnosis with a nurse is PHI, but it is not ePHI.
The distinction matters because the HIPAA Security Rule (45 CFR Part 164, Subpart C) applies specifically to ePHI. Paper and verbal PHI are covered by the Privacy Rule, but the technical safeguard requirements of the Security Rule, including access controls, audit controls, transmission security, and integrity controls, apply only to ePHI.
Why ePHI Gets Its Own Rule Set
The Security Rule exists because electronic data carries risks that paper records do not. ePHI can be:
- Copied instantly and distributed at scale
- Accessed remotely by unauthorized parties
- Intercepted during transmission
- Stored in multiple locations simultaneously (backups, caches, logs)
- Difficult to fully destroy
These risks demanded a dedicated regulatory framework. The Security Rule at 45 CFR 164.312 requires covered entities and business associates to implement:
- Access controls (45 CFR 164.312(a)(1)): Unique user IDs, emergency access procedures, automatic logoff, encryption and decryption mechanisms
- Audit controls (45 CFR 164.312(b)): Hardware, software, and procedural mechanisms to record and examine access to ePHI
- Integrity controls (45 CFR 164.312(c)(1)): Policies and procedures to protect ePHI from improper alteration or destruction
- Person or entity authentication (45 CFR 164.312(d)): Verification that a person or entity seeking access to ePHI is who they claim to be
- Transmission security (45 CFR 164.312(e)(1)): Technical measures to guard against unauthorized access to ePHI during electronic transmission
For practical guidance on implementing these controls, see our articles on ePHI access control best practices and HIPAA encryption requirements in 2026.
PHI vs PII vs ePHI: Comparison Table
| PII | PHI | ePHI | |
|---|---|---|---|
| Full Name | Personally Identifiable Information | Protected Health Information | Electronic Protected Health Information |
| Defined By | NIST SP 800-122, various federal and state laws | HIPAA (45 CFR 160.103) | HIPAA (45 CFR 160.103) |
| Scope | Any data that identifies an individual | Health data linked to an individual identifier | PHI in electronic form |
| Sector | All industries | Healthcare (covered entities and business associates) | Healthcare (covered entities and business associates) |
| Primary Regulator | FTC, state attorneys general, sector-specific agencies | HHS Office for Civil Rights (OCR) | HHS Office for Civil Rights (OCR) |
| Governing Rule | No single federal law; patchwork of statutes | HIPAA Privacy Rule (45 CFR Part 164, Subpart E) | HIPAA Security Rule (45 CFR Part 164, Subpart C) |
| Format | Any format | Any format (paper, verbal, electronic) | Electronic only |
| Breach Notification | State breach notification laws (varies by state) | HIPAA Breach Notification Rule (45 CFR Part 164, Subpart D) | HIPAA Breach Notification Rule (45 CFR Part 164, Subpart D) |
| Encryption Required? | Depends on applicable law | Addressable under current rule; likely required under 2026 NPRM | Addressable under current rule; likely required under 2026 NPRM |
| Example | John Smith, 123 Main St, SSN 555-12-3456 | John Smith was diagnosed with Type 2 diabetes on 03/15/2025 | The same diabetes diagnosis stored in an EHR system |
Where PHI, PII, and ePHI Overlap
These categories are not mutually exclusive. In fact, most healthcare data falls into multiple categories simultaneously.
All PHI Contains PII
By definition, PHI must include an identifier linked to health information. Those identifiers (names, dates, SSNs, etc.) are also PII. So every piece of PHI contains at least one piece of PII. But not every piece of PII is PHI. Your name and address in a hotel loyalty program is PII, not PHI, because there is no health information attached.
All ePHI Is PHI
ePHI is a subset of PHI. Every piece of ePHI is, by definition, PHI. The reverse is not true. A handwritten note in a paper chart is PHI but not ePHI.
The Practical Overlap
In modern healthcare, most PHI is ePHI. Electronic health records, billing systems, patient portals, lab interfaces, telehealth platforms, email communications, and even text messages all create and transmit ePHI. Paper-only PHI is increasingly rare outside of legacy archives and certain specialty settings.
This means that for most organizations, the Security Rule’s technical safeguard requirements apply to the vast majority of PHI they handle.
Why These Distinctions Matter for Compliance
Getting the definitions wrong has tangible consequences. Here are the most common mistakes and what they cost.
Mistake 1: Treating All PII as PHI
Some organizations apply HIPAA safeguards to every piece of PII they handle, regardless of whether health information is involved. This sounds cautious but it is wasteful. It spreads limited compliance resources across data that does not require HIPAA-level protection, while potentially leaving actual PHI underprotected.
The fix: Map your data. Know which information contains health data linked to identifiers (PHI) and which is plain PII. Apply HIPAA safeguards to PHI and ePHI. Apply appropriate but potentially different protections to PII based on the laws that actually govern it.
Mistake 2: Ignoring PII That Is Not PHI
The opposite mistake is also common. Organizations focus entirely on PHI and forget that PII has its own compliance requirements under state laws, FTC regulations, and sector-specific statutes. A breach of employee Social Security numbers that are not linked to health data may not trigger HIPAA, but it almost certainly triggers state breach notification requirements.
The fix: Your compliance program should address both PHI and non-health PII. Different rules, different safeguards, different notification requirements.
Mistake 3: Failing to Distinguish PHI from ePHI
Organizations sometimes apply only Privacy Rule protections to electronic data, missing the Security Rule’s technical requirements entirely. The Privacy Rule tells you when and to whom you can disclose PHI. The Security Rule tells you how to protect ePHI from unauthorized access, alteration, and destruction. You need both.
The fix: Identify every system, device, and transmission pathway that creates, stores, or transmits ePHI. Apply the Security Rule’s administrative, physical, and technical safeguards to each one. This is a core component of a thorough risk assessment.
Mistake 4: Assuming De-Identified Data Is Always Safe
Under 45 CFR 164.514, PHI can be de-identified by removing all 18 identifiers (Safe Harbor method) or through expert statistical determination. Once properly de-identified, data is no longer PHI and HIPAA no longer applies to it.
The risk is in the word “properly.” Incomplete de-identification leaves residual identifiers that can be re-linked to individuals. Data you thought was de-identified turns out to still be PHI, and you have been handling it without HIPAA protections.
The fix: Follow the de-identification standards precisely. Our article on HIPAA de-identification requirements walks through both methods in detail.
Practical Steps for Getting Your Data Classifications Right
Knowing the definitions is one thing. Applying them across your organization is another. Here is a practical approach.
Step 1: Inventory Your Data
List every system, application, device, and workflow that handles personal or health data. Include EHR systems, billing platforms, email, cloud storage, mobile devices, paper files, voicemail systems, fax machines, and any third-party services with access to patient information.
Step 2: Classify Each Data Element
For each system and workflow, identify what type of data it handles:
- PII only (no health information attached): Employee HR records without health data, vendor contact lists, marketing databases
- PHI (non-electronic): Paper charts, printed lab results, verbal communications, physical X-ray films
- ePHI: EHR records, electronic billing data, patient portal messages, emailed lab results, scanned documents stored digitally, telehealth recordings
Step 3: Map Regulatory Requirements to Each Category
- PII only: Determine applicable state privacy laws, FTC requirements, and any sector-specific regulations
- PHI: Apply HIPAA Privacy Rule requirements (use and disclosure limitations, minimum necessary standard, patient rights)
- ePHI: Apply HIPAA Security Rule requirements in addition to Privacy Rule requirements (access controls, audit controls, encryption, transmission security, integrity controls)
Step 4: Identify Gaps
Compare your current safeguards against the requirements for each data category. Where are the gaps? Common ones include:
- ePHI stored on unencrypted devices
- No BAA in place with a cloud vendor that stores ePHI
- Access controls that do not enforce minimum necessary
- Audit logs that are not reviewed
- Paper PHI stored in unsecured areas
- PII breach notification procedures that do not account for state-specific requirements
Step 5: Remediate and Document
Close the gaps. Document what you did, when you did it, and why. HIPAA compliance is a documentation exercise as much as a technical one. If OCR comes knocking, they want to see policies, procedures, risk assessments, training records, and evidence that you are doing what you say you are doing.
Frequently Asked Questions
Is a patient’s name PHI by itself?
No. A name alone, without any connection to health information or a healthcare context, is PII but not PHI. However, a patient’s name on an appointment schedule, in a medical record, or on a billing statement is PHI because it is linked to healthcare provision or payment. In practice, if you encounter a name within any healthcare system or process, treat it as PHI.
Does HIPAA apply to PII?
HIPAA applies to PHI and ePHI, not to PII generally. If personal information is not linked to health data and is not held by a covered entity or business associate in a healthcare context, HIPAA does not govern it. That said, PII may be subject to other federal and state privacy laws depending on the industry and jurisdiction.
What is the difference between PHI and ePHI in terms of compliance obligations?
Both PHI and ePHI are subject to the HIPAA Privacy Rule, which governs how health information can be used and disclosed. ePHI carries an additional layer of compliance obligations under the HIPAA Security Rule (45 CFR Part 164, Subpart C), which requires specific administrative, physical, and technical safeguards. These include access controls, audit controls, integrity controls, authentication mechanisms, and transmission security. If your PHI is electronic, which in most modern healthcare settings it is, you must comply with both the Privacy Rule and the Security Rule.
Can ePHI exist in cloud storage?
Yes. Any PHI stored in cloud-based systems, including cloud EHRs, cloud-hosted email, cloud backup services, and SaaS platforms, is ePHI. The covered entity or business associate must have a signed Business Associate Agreement (BAA) with the cloud provider, and the Security Rule’s safeguards must be applied to the data in that environment. The cloud provider does not get to decide whether it is a business associate. If it stores, processes, or transmits ePHI on your behalf, it is one, and a BAA is required under 45 CFR 164.502(e) and 164.504(e).
Does de-identified health data count as PHI?
No. Under 45 CFR 164.514, data that has been properly de-identified is no longer PHI and is not subject to HIPAA. De-identification can be achieved through the Safe Harbor method (removing all 18 identifiers and having no actual knowledge the remaining data could identify an individual) or the Expert Determination method (a qualified statistical expert certifies the risk of re-identification is very small). Improperly de-identified data that retains residual identifiers is still PHI.
If I collect a patient’s email address for appointment reminders, is that ePHI?
It depends on context. An email address by itself is PII. An email address collected within a healthcare system for the purpose of communicating about that patient’s care or treatment is linked to healthcare provision, which makes it PHI. If that email address is stored electronically, and in a healthcare scheduling system it always is, it is ePHI. Apply Security Rule safeguards accordingly.
Conclusion
PHI, PII, and ePHI are not interchangeable labels. Each term carries a specific legal definition, falls under a distinct regulatory framework, and demands a different set of protections. Treating them as synonyms creates compliance gaps that OCR will find.
The practical takeaway: know what data you have, classify it correctly, and apply the right safeguards to each category. PHI requires Privacy Rule compliance. ePHI requires Privacy Rule and Security Rule compliance. PII requires compliance with whatever federal and state laws apply to your industry and jurisdiction.
If you are not sure where your organization stands, start with a risk assessment. It is the single most effective way to identify what data you hold, where it lives, and what you are doing (or not doing) to protect it.
One Guy Consulting helps covered entities and business associates get their data classifications, policies, and safeguards right. If you need help mapping your data, building compliant workflows, or preparing for the 2026 rule changes, our HIPAA consulting services are built for small and mid-sized healthcare organizations that need practical, actionable guidance without the overhead of enterprise consulting firms.
Get the definitions right. Get the protections right. The rest of compliance follows from there.
Sources
- HIPAA Privacy Rule: 45 CFR Part 164, Subpart E
- HIPAA Security Rule: 45 CFR Part 164, Subpart C
- HIPAA Breach Notification Rule: 45 CFR Part 164, Subpart D
- Definition of PHI: 45 CFR 160.103
- De-identification standard: 45 CFR 164.514
- Security Rule technical safeguards: 45 CFR 164.312
- Business Associate requirements: 45 CFR 164.502(e), 164.504(e)
- NIST SP 800-122: Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)
- HHS Guidance on De-identification: https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html
- HITECH Act: Public Law 111-5, Title XIII
This article is for informational purposes and does not constitute legal advice. Consult with a qualified HIPAA compliance professional or attorney for guidance specific to your organization.