What Is Not ePHI? Clear Examples, Edge Cases, and Compliance Tips

Knowing what is not ePHI helps you reduce risk, simplify controls, and focus resources where they matter. Below, you’ll find a clear definition, concrete examples, tricky edge cases, and practical steps to keep Health Information Privacy front and center without over-scoping your program.

Definition of Electronic Protected Health Information

Electronic Protected Health Information (ePHI) is Protected Health Information that is created, received, maintained, or transmitted in electronic form by a covered entity or its business associate. To qualify, data must both identify (or be reasonably linkable to) an individual and relate to that person’s health, care, or payment for care.

Key elements

• Contains one or more HIPAA Identifiers that can directly or indirectly identify a person.
• Describes an individual’s past, present, or future physical or mental health, care delivery, or payment status.
• Exists in electronic form (systems, emails, texts, databases, images, backups, or logs).
• Is held by a covered entity or business associate under a Business Associate Agreement.

ePHI vs. PHI

All ePHI is PHI, but not all PHI is ePHI. Paper charts and spoken information are PHI but not ePHI; they’re still protected by the HIPAA Privacy Rule but outside the HIPAA Security Rule’s technical safeguards.

Examples of Non-ePHI Data

Not every piece of health-related information falls under ePHI. Use these examples to separate true ePHI from data you can manage with lighter controls (while still being prudent):

• Employment records held by an employer in its role as employer (e.g., FMLA forms, pre-employment drug tests). These are not PHI and therefore not ePHI.
• Education records covered by FERPA (e.g., a student athlete’s injury record in a school file), which are excluded from PHI.
• Consumer-generated wellness data collected by a general fitness app that is not acting for a covered entity or business associate (e.g., step counts the user tracks privately).
• De-identified datasets that meet HIPAA De-Identification Standards via Safe Harbor or Expert Determination.
• Aggregated operational metrics that cannot identify individuals (e.g., monthly clinic visit totals without linkable details).
• Publicly available information not created or received by a covered entity in a health-care context (e.g., a news article about a public figure’s health disclosed by the individual).
• Paper-only PHI that never enters an electronic system (still PHI, but not ePHI).
• Device telemetry or error logs lacking HIPAA Identifiers and any link to an individual’s health or care episode.

Remember, non-ePHI can still be sensitive. State privacy laws, consumer protection rules, or contracts may impose controls even when HIPAA does not.

De-Identification and Anonymization Processes

To remove data from ePHI scope, you must apply recognized De-Identification Standards that make re-identification very unlikely. HIPAA recognizes two compliant paths:

1) Safe Harbor (remove all 18 HIPAA Identifiers)

• Strip direct identifiers (names, full-face photos, phone numbers, SSNs, device IDs, IP addresses, etc.).
• Generalize quasi-identifiers (e.g., keep only the year for dates; aggregate geography beyond the ZIP code rules; recode ages over 89 as 90+).
• Ensure no residual combinations can reasonably identify a person.

2) Expert Determination

An experienced statistical expert documents that the risk of re-identification is very small, considering data elements, auxiliary data, and context. The expert outlines techniques (e.g., suppression, generalization, noise) and residual risk.

Pseudonymization vs. de-identification

Pseudonymized data that can be re-linked to individuals via a key remains PHI if held by a covered entity or business associate; if electronic, it’s still ePHI. A Limited Data Set is also still PHI and requires a Data Use Agreement.

Operational checklist

• Inventory fields and map them to HIPAA Identifiers.
• Select Safe Harbor or Expert Determination based on utility and timelines.
• Apply transformations, then test for re-identification risk.
• Document methods, residual risk, and release conditions; monitor for drift as datasets change.

Identifying Edge Cases in ePHI

Borderline situations often turn on context—who holds the data, how it was collected, and whether it’s linkable to a person’s health encounter.

• Web and app tracking: Analytics or advertising tags on a patient portal can capture IP addresses, device IDs, or URLs that reveal appointment scheduling or diagnoses. When controlled by a covered entity, such data can be ePHI.
• Support tickets and chat logs: A patient’s name or email paired with symptoms in a help desk system makes the transcript ePHI.
• Call recordings and voicemails: If they include identifiers plus care details and are stored electronically, they are ePHI.
• Wearable and IoT data: If a device vendor acts for a covered entity (e.g., remote monitoring), the telemetry may be ePHI; if purely consumer-directed, it typically is not.
• Metadata and backups: Timestamps, IPs, and filenames can constitute ePHI if they identify a person’s interaction with care; encrypted backups inherit the classification.
• Research data: De-identified per HIPAA falls outside ePHI; Limited Data Sets and coded data generally remain ePHI when electronic.

Quick test

• Entity: Is a covered entity or business associate involved?
• Context: Does the event relate to health, care, or payment?
• Linkability: Could any HIPAA Identifiers or combinations reasonably identify a person?

Best Practices for HIPAA Compliance

Even when you confirm data is not ePHI, a strong baseline protects trust and reduces surprises. These measures help you apply proportional safeguards while maintaining Health Information Privacy:

• Data minimization: Collect only what you need; drop unnecessary identifiers early.
• Clear scoping: Tag systems and datasets as ePHI, PHI, non-PHI, and de-identified to avoid control creep.
• Business Associate Agreements: Execute BAAs with vendors that create or receive ePHI; ensure downstream obligations are explicit.
• Data Encryption Requirements: Use strong encryption in transit and at rest; manage keys separately and rotate them regularly.
• Retention and disposal: Set short, defensible retention periods; verify secure disposal of media and backups.
• Incident response: Maintain playbooks for ePHI exposure, including internal escalation and notification steps.
• Privacy-by-design: Embed De-Identification Standards into analytics pipelines and AI workflows.

Implementing Risk Assessments and Access Controls

Structured Risk Assessment Procedures let you right-size controls for ePHI and non-ePHI alike, and robust Access Control Mechanisms prevent drift back into overexposure.

Risk assessment procedures

• Scope and inventory: List systems, data flows, and vendors; identify which datasets are ePHI, PHI, or non-ePHI.
• Threats and vulnerabilities: Consider misuse, re-identification risk, third-party failures, and shadow IT.
• Likelihood and impact: Score risks, including legal, operational, and reputational effects.
• Mitigations: Prioritize encryption, segmentation, vendor controls, and data minimization.
• Plan and monitor: Record owners, timelines, and metrics; reassess after system or vendor changes.

Access control mechanisms

• Least privilege and role-based access: Grant only what each role needs; review entitlements regularly.
• Attribute-based controls: Add context (location, device posture, time) for sensitive tasks.
• MFA and SSO: Require multi-factor authentication and centralized sign-on for systems that may touch ePHI.
• Segmentation: Separate ePHI from non-ePHI environments; restrict admin paths and service accounts.
• Audit logging: Capture access, changes, and exports; alert on anomalies and bulk downloads.
• Data Encryption Requirements: Enforce TLS for data in motion and strong algorithms (e.g., AES) at rest; protect and rotate keys.

Training Staff on ePHI Handling

Your workforce is the control surface. Practical training reduces misclassification and accidental exposure, especially in gray areas.

• Scenario-based modules: Walk through edge cases (web analytics on portals, support emails with symptoms, exporting “anonymized” reports).
• Minimum necessary: Teach staff to redact HIPAA Identifiers and avoid oversharing in tickets or chats.
• Vendor awareness: Instruct teams to route new tools through security review and BAAs when applicable.
• Secure communications: Standardize encrypted channels for anything that could contain ePHI; bar copy-paste into unsanctioned apps.
• Verification rituals: Before sharing a dataset, confirm classification, recipients, and purpose.
• Measure and reinforce: Track completion, test with simulations, and coach on near-misses.

Conclusion

Data is not ePHI when it lacks HIPAA Identifiers, falls outside a covered entity/business associate context, or meets De-Identification Standards. Apply crisp scoping, strong Access Control Mechanisms, and routine Risk Assessment Procedures so you can protect true ePHI, treat non-ePHI responsibly, and uphold Health Information Privacy without unnecessary burden.

FAQs.

What types of information are excluded from ePHI?

Employment records kept by an employer, education records subject to FERPA, consumer wellness data collected outside a covered entity/business associate relationship, de-identified datasets, aggregated statistics that can’t identify individuals, and paper-only PHI are excluded from ePHI. They may still be sensitive but fall outside HIPAA’s Security Rule for electronic data.

How does the de-identification process affect data classification?

If you successfully de-identify per HIPAA’s Safe Harbor or Expert Determination, the result is no longer PHI and therefore not ePHI. Pseudonymized or Limited Data Sets remain PHI because re-identification is possible or certain identifiers are retained; if stored electronically, they are still ePHI.

When can data without direct identifiers still be considered ePHI?

When context links it to an individual’s health encounter and indirect identifiers remain. For example, an IP address captured on a patient portal that reveals appointment activity can be ePHI. If a business associate handles telemetry for remote monitoring, device metadata may also be ePHI even without names.

What compliance steps help protect non-ePHI information?

Classify data, minimize collection, encrypt at rest and in transit, limit access via least privilege, vet vendors and use Business Associate Agreements when needed, set short retention, and maintain incident response. These steps uphold Health Information Privacy while preventing non-ePHI from drifting into ePHI scope.