PII is any information that identifies a person; PHI is health information tied to a person and held by a covered entity or its business associate; ePHI is PHI in electronic form. Covered entities are health plans, healthcare clearinghouses, and providers who bill insurance electronically. The Privacy Rule covers all PHI. The Security Rule covers only ePHI.

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 and Differences
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. Many federal and state rules and guides use the idea. Examples include FTC enforcement under the FTC Act, the Privacy Act of 1974 (which covers records held by federal agencies), NIST SP 800-122, and 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 number.
- 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 health information that identifies a person, or could reasonably be used to. The rule calls this individually identifiable health information. It can be in any form: paper, spoken, or electronic. HIPAA protects it when a covered entity or its business associate holds it. A covered entity is a health plan, a healthcare clearinghouse, or a provider who bills insurance electronically. The information 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 the 18 identifiers below is PHI. That is true when a covered entity or business associate holds it.
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 lists 18 identifiers. To make health data de-identified (no longer tied to a person) under the Safe Harbor method, you remove all 18. You remove them for the patient and for their relatives, employers, and household members. Any one of them tied to health information can make that information identifiable:
- Name.
- Geographic data smaller than a state.
- Dates (except year) related to an individual (birth, admission, discharge, death).
- Phone number.
- Fax number.
- Email addresses.
- Social Security number.
- Medical record number.
- Health plan beneficiary number.
- Account number.
- Certificate/license number.
- Vehicle identifiers and serial numbers, including license plate numbers.
- Device identifiers and serial numbers.
- Web URLs.
- IP addresses.
- Biometric identifiers, including finger and voice prints.
- Full-face photographs and any comparable images.
- Any other unique identifying number, characteristic, or code.
Say a covered entity or business associate holds health information. If any one of these identifiers is tied to it, that information is PHI. The Privacy Rule covers it in every form. The Security Rule covers it when it is electronic.
What Regulates PHI?
PHI is defined and regulated under 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). Some states have stricter health privacy laws. Those can also apply on top of HIPAA (45 CFR 160.203). 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 administrative, physical, and technical 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. For a focused breakdown, see our complete guide to ePHI. 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 PHI that is sent or stored in electronic form. 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, and encryption and decryption. The last two are “addressable.” That means you put them in place if they are reasonable and appropriate for your practice. If not, you write down why. Then you use an equal alternative, if that is reasonable and appropriate.
- 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 | The Security Rule’s encryption rules cover only electronic PHI (see ePHI) | Addressable under the current rule, which means you decide if it fits your practice and write down why. The January 2025 proposed rule (not final) would make it required |
| 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 most practices today, much of the PHI they hold 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 still exists, but it is often only part of the picture.
So for many organizations, the Security Rule’s safeguards cover a large share of the 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 is likely to trigger 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, there are two ways to de-identify PHI. The first is the Safe Harbor method. You remove all 18 identifiers, and you have no actual knowledge that what is left could identify the person. The second is 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 film.
- 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 regulation.
- 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). Encryption is addressable today, which means you decide if it fits your practice and write down why.
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, 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 determines that the risk of re-identification is very small and writes down how they reached that). 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.
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. An OCR investigation can bring those gaps to light.
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 a practical 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 proposed Security Rule changes (published January 2025, not yet final), 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.
Key point: PII and PHI overlap, but different laws govern them. A Social Security number is PII under state breach notification laws. Link that same SSN to a medical diagnosis, and it is PHI under HIPAA when a covered entity or business associate holds it. Healthcare organizations may have to follow both sets of rules at once. HIPAA generally lets a stricter state health privacy law still apply (45 CFR 160.203).
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.
Related Reading
- HIPAA Privacy Rule Requirements.
- Notice of Privacy Practices Guide.
- HIPAA Authorization Form Requirements.
- HIPAA Minimum Necessary Rule.
- Patient Rights Under HIPAA.
- What Is ePHI? Definition and Compliance.
- Is ChatGPT HIPAA Compliant?.
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.