If you work in healthcare, or work with healthcare organizations, you have heard the term “ePHI” hundreds of times. But when I ask clients to define it precisely, most of them hesitate. That hesitation is where compliance gaps start.
This article is the definitive explainer. We will cover exactly what electronic Protected Health Information is, how it differs from PHI in general, where you are most likely to encounter it, and what the HIPAA Security Rule demands you do about it. No fluff, no legalese you need a decoder ring for, just practical guidance from someone who has helped organizations get this right for years.
What ePHI Means, Who Must Protect It, and How
What Does ePHI Stand For?
ePHI stands for electronic Protected Health Information. It is a subset of Protected Health Information (PHI) that is created, received, stored, or transmitted in electronic form.
The distinction matters because ePHI triggers an entirely separate set of regulatory requirements. While the HIPAA Privacy Rule governs PHI in all formats, paper, oral, electronic, the HIPAA Security Rule (45 CFR Part 164, Subparts A and C) applies exclusively to ePHI. If information is protected health information and it exists in electronic form at any point during its lifecycle, the Security Rule applies.
Put plainly: all ePHI is PHI, but not all PHI is ePHI.
The Formal Definition of ePHI Under HIPAA
Under 45 CFR § 160.103, Protected Health Information 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 health care to an individual
- The past, present, or future payment for the provision of health care to an individual
That information becomes ePHI when it is created, received, maintained, or transmitted using electronic media. The term “electronic media” is also defined at 45 CFR § 160.103 and includes:
- Electronic storage media, hard drives, magnetic tape, removable storage devices, optical discs, and digital memory (such as RAM or flash drives)
- Transmission media, the internet, extranet, leased lines, dial-up lines, private networks, and the physical movement of electronic storage media from one location to another
The critical takeaway: ePHI is not limited to data sitting in your EHR. It includes data in transit across a network, data at rest on a backup drive in a locked cabinet, and data on a laptop that left the office in someone’s bag last Friday.
ePHI vs. PHI: Understanding the Difference
The difference between PHI and ePHI is the medium, not the content. The same patient record can be PHI in one context and ePHI in another.
| Scenario | Classification |
|---|---|
| A printed lab result in a patient’s paper chart | PHI (not ePHI) |
| That same lab result stored in the EHR system | ePHI |
| A physician verbally discussing a diagnosis with a nurse | PHI (not ePHI) |
| A voicemail recording of that same discussion on a digital system | ePHI |
| A faxed referral sent via a traditional analog fax machine | PHI (not ePHI) |
| A faxed referral sent via an electronic fax (eFax) service | ePHI |
| A handwritten prescription | PHI (not ePHI) |
| An e-prescription transmitted through a pharmacy network | ePHI |
Why does this matter? Because the safeguards are different. Paper PHI is governed by the Privacy Rule’s administrative requirements. ePHI is governed by the Privacy Rule and the Security Rule, which adds 54 specific implementation specifications across administrative, physical, and technical safeguard categories.
For a deeper comparison, see our complete guide on Protected Health Information (PHI).
Common Examples of ePHI
One of the most frequent mistakes I see during risk assessments is that organizations dramatically undercount the locations where ePHI exists. Here are the categories where ePHI most commonly lives:
Clinical Systems
- Electronic Health Records (EHR/EMR systems)
- Laboratory information systems (LIS)
- Radiology information systems (RIS) and PACS imaging archives
- Pharmacy dispensing systems
- Clinical decision support tools
- Patient portals and personal health record platforms
- Telehealth platforms and recorded video sessions
Administrative and Financial Systems
- Practice management software
- Revenue cycle management and medical billing platforms
- Claims processing and clearinghouse transmissions
- Insurance eligibility verification systems
- Accounts receivable databases containing patient payment records
Communication Channels
- Email messages containing patient information
- Secure messaging platforms (and sometimes insecure ones)
- Text messages with patient data, including on personal devices
- Voicemail systems that store messages digitally
- Fax server logs and eFax transmissions
Storage and Infrastructure
- Database servers (on-premises and cloud-hosted)
- Backup tapes, drives, and cloud backup repositories
- File servers and network-attached storage (NAS)
- Workstation hard drives and solid-state drives
- Laptop computers, tablets, and smartphones
- USB flash drives, external hard drives, and portable media
- Virtual machine images and container storage volumes
- Data warehouse and analytics platforms
Often Overlooked ePHI Locations
- Photocopier and printer hard drives that cache scanned documents
- Dictation and transcription system recordings
- Medical device logs (infusion pumps, ventilators, monitors)
- Building access control systems linked to patient identity
- Security camera systems in clinical areas where patient identifiers are visible
- Audit logs that contain patient identifiers alongside access records
- Temporary files, caches, and recycle bins on workstations
If you cannot account for where ePHI exists across your environment, you cannot protect it. That is not an opinion, it is the foundation of the risk analysis requirement at 45 CFR § 164.308(a)(1)(ii)(A).
Who Must Protect ePHI?
The HIPAA Security Rule applies to two categories of organizations:
Covered Entities
Covered Entities (CEs) are the organizations directly subject to HIPAA. They include:
- Health care providers who transmit any health information electronically in connection with a HIPAA-covered transaction (claims, eligibility inquiries, referral authorizations, etc.)
- Health plans, health insurance companies, HMOs, employer-sponsored group health plans, Medicare, Medicaid, and similar organizations
- Health care clearinghouses, entities that process health information received from another entity into a standard format, or vice versa
Business Associates
Business Associates (BAs) are individuals or organizations that perform functions or activities on behalf of, or provide services to, a Covered Entity that involve access to ePHI. Common examples include:
- Cloud hosting and data storage providers
- IT managed service providers
- Medical billing companies
- Claims processing firms
- EHR vendors
- Shredding and document destruction companies
- Accountants and auditors with ePHI access
- Attorneys providing services that require ePHI access
- Health information exchanges (HIEs)
Since the HITECH Act and the 2013 Omnibus Rule, Business Associates are directly liable for compliance with the Security Rule. This is not optional, and it is not something a Business Associate Agreement alone can solve. BAs must independently implement the administrative, physical, and technical safeguards required by the Security Rule.
HIPAA Security Rule Requirements for ePHI
The Security Rule (45 CFR Part 164, Subpart C) establishes the framework for protecting ePHI. It is organized into three safeguard categories, plus organizational and documentation requirements. Here is what each category demands.
Administrative Safeguards (45 CFR § 164.308)
Administrative safeguards are the policies, procedures, and management actions that govern how an organization protects ePHI. They represent the largest category of Security Rule requirements and include:
- Risk Analysis and Risk Management, You must conduct a thorough and accurate assessment of the potential risks and vulnerabilities to ePHI, then implement security measures to reduce those risks to a reasonable and appropriate level (§ 164.308(a)(1)(ii)(A)-(B))
- Sanction Policy, Workforce members who violate security policies must face appropriate sanctions (§ 164.308(a)(1)(ii)(C))
- Information System Activity Review, Regular review of audit logs, access reports, and security incident tracking (§ 164.308(a)(1)(ii)(D))
- Workforce Security, Procedures to ensure only authorized workforce members can access ePHI (§ 164.308(a)(3))
- Security Awareness and Training, Ongoing training for all workforce members, including security reminders, malware protection procedures, login monitoring, and password management (§ 164.308(a)(5))
- Security Incident Procedures, Policies for identifying, responding to, and reporting security incidents (§ 164.308(a)(6))
- Contingency Planning, Data backup plans, disaster recovery plans, and emergency mode operation plans (§ 164.308(a)(7))
- Business Associate Contracts, Written agreements that require BAs to appropriately safeguard ePHI (§ 164.308(b))
Our HIPAA Security Rule Implementation guide walks through each of these requirements in detail.
Physical Safeguards (45 CFR § 164.310)
Physical safeguards protect the physical infrastructure, the buildings, rooms, equipment, and media, where ePHI is accessed, stored, or transmitted:
- Facility Access Controls, Policies to limit physical access to electronic information systems and the facilities where they are housed (§ 164.310(a))
- Workstation Use, Policies specifying the proper functions to be performed at workstations, the manner in which they are to be performed, and the physical attributes of the surroundings (§ 164.310(b))
- Workstation Security, Physical safeguards that restrict access to authorized users at workstations that can access ePHI (§ 164.310(c))
- Device and Media Controls, Policies governing the receipt, removal, movement, disposal, and reuse of electronic media containing ePHI (§ 164.310(d))
Technical Safeguards (45 CFR § 164.312)
Technical safeguards are the technology and related policies that protect ePHI and control access to it:
- Access Controls, Technical measures to allow only authorized persons to access ePHI, including unique user identification, emergency access procedures, automatic logoff, and encryption/decryption (§ 164.312(a))
- Audit Controls, Hardware, software, and procedural mechanisms that record and examine activity in systems containing ePHI (§ 164.312(b))
- Integrity Controls, Policies and procedures to protect ePHI from improper alteration or destruction, including electronic mechanisms to corroborate that ePHI has not been altered (§ 164.312(c))
- Person or Entity Authentication, Procedures to verify that a person or entity seeking access to ePHI is who they claim to be (§ 164.312(d))
- Transmission Security, Technical security measures to guard against unauthorized access to ePHI being transmitted over electronic communications networks, including integrity controls and encryption (§ 164.312(e))
For a deep dive into access controls specifically, read our guide on ePHI Access Control Best Practices.
Encryption and ePHI
Encryption deserves special attention because it intersects with both compliance and breach notification.
Under the Security Rule, encryption is an addressable implementation specification, not a required one. That distinction confuses people. “Addressable” does not mean “optional.” It means you must assess whether encryption is a reasonable and appropriate safeguard for your environment. If it is, you must implement it. If you determine it is not, you must document why and implement an equivalent alternative measure. In practice, encryption is almost always reasonable and appropriate. The circumstances where a legitimate alternative exists are narrow.
Encryption also plays a direct role in breach notification. Under 45 CFR § 164.402, a breach is defined as the acquisition, access, use, or disclosure of unsecured PHI. The key word is unsecured. HHS defines “unsecured PHI” as PHI that has not been rendered unusable, unreadable, or indecipherable to unauthorized persons. Encryption consistent with NIST standards is one of the two recognized methods for securing PHI (the other is destruction).
What this means in practice: if ePHI is properly encrypted and the encryption key has not been compromised, an unauthorized access event is not a reportable breach. This is the single strongest reason to encrypt ePHI at rest and in transit.
For current encryption standards and requirements, see our HIPAA Encryption Requirements article.
ePHI and the Breach Notification Rule
When unsecured ePHI is breached, the Breach Notification Rule (45 CFR §§ 164.400–164.414) imposes specific obligations depending on your role.
Covered Entity Obligations
Covered Entities must:
- Notify affected individuals without unreasonable delay, and no later than 60 calendar days after discovery of the breach (§ 164.404)
- Notify HHS, for breaches affecting 500 or more individuals, notification must occur within 60 days; for breaches affecting fewer than 500 individuals, notification may be submitted annually (§ 164.408)
- Notify prominent media outlets when a breach affects 500 or more residents of a state or jurisdiction (§ 164.406)
Business Associate Obligations
Business Associates must notify the Covered Entity of a breach of unsecured PHI without unreasonable delay, and no later than 60 calendar days after discovery (§ 164.410). The BA’s obligation is to notify the CE, the CE then carries out individual notification, HHS reporting, and media notification as applicable. The Business Associate does not independently notify affected individuals or HHS. The BA’s duty under the Breach Notification Rule is limited to notifying the Covered Entity.
This is an important distinction that frequently causes confusion. During incident response, it is critical that both parties understand their respective roles and that the Business Associate Agreement clearly defines the notification timeline and required information.
De-Identification: When ePHI Stops Being ePHI
Data that has been properly de-identified under 45 CFR § 164.514 is no longer considered PHI, and therefore no longer ePHI, even if it remains in electronic form. Once de-identified, the data falls outside the scope of the HIPAA Privacy and Security Rules entirely.
HIPAA recognizes two methods of de-identification:
- Expert Determination (§ 164.514(b)(1)), A qualified statistical or scientific expert determines that the risk of identifying an individual from the data is very small.
- Safe Harbor (§ 164.514(b)(2)), Eighteen specific categories of identifiers are removed, and the covered entity has no actual knowledge that the remaining information could identify an individual.
De-identification is powerful for analytics, research, and data sharing, but it must be done correctly. Incomplete or improper de-identification leaves you fully subject to HIPAA requirements. We cover this in detail in our HIPAA De-Identification Requirements guide.
Practical Steps to Protect ePHI in Your Organization
Compliance is not just about knowing the rules, it is about operationalizing them. Here are the steps I walk clients through during HIPAA consulting engagements.
1. Conduct a Comprehensive ePHI Inventory
Before you can protect ePHI, you need to know where it lives. Map every system, application, device, and medium that creates, receives, stores, or transmits ePHI. Include cloud services, mobile devices, medical devices, and third-party integrations. This inventory feeds directly into your risk analysis.
2. Perform a Risk Analysis
The risk analysis at 45 CFR § 164.308(a)(1)(ii)(A) is the single most important Security Rule requirement. It is also the one most frequently cited in HHS enforcement actions. A proper risk assessment identifies threats and vulnerabilities to ePHI across your entire environment and evaluates the likelihood and impact of each risk.
3. Implement Risk-Based Safeguards
Based on your risk analysis findings, implement administrative, physical, and technical safeguards that reduce identified risks to a reasonable and appropriate level. Prioritize high-risk areas first. Document every decision, including decisions not to implement a particular measure and the rationale behind that decision.
4. Encrypt ePHI at Rest and in Transit
Implement encryption that meets NIST standards for all ePHI, on servers, workstations, laptops, mobile devices, portable media, backups, and all transmission channels. As discussed above, this not only satisfies the Security Rule but also provides safe harbor from breach notification requirements.
5. Enforce Access Controls
Apply the minimum necessary standard. Grant access to ePHI only to workforce members who need it for their job functions, and enforce that access through technical controls, role-based access, unique user IDs, automatic session termination, and multi-factor authentication. See our ePHI Access Control Best Practices for detailed implementation guidance.
6. Train Your Workforce
Security awareness training must be provided to all workforce members, not just clinicians and not just IT staff. Training should cover recognizing phishing attempts, proper handling of ePHI, password hygiene, reporting security incidents, and the consequences of non-compliance. Training must be ongoing, not a one-time event.
7. Establish Incident Response Procedures
Have a documented, tested incident response plan before you need one. Know who is responsible for what, how breaches are identified and reported internally, what the notification timelines are, and how forensic evidence is preserved. Our incident management services can help you build and test these procedures.
8. Manage Business Associate Relationships
Maintain a current inventory of all Business Associates. Ensure every BA relationship is governed by a compliant Business Associate Agreement. Periodically assess whether your BAs are meeting their Security Rule obligations. Remember, you cannot contractually transfer your compliance responsibilities.
9. Document Everything
The Security Rule requires policies, procedures, and documentation to be maintained for six years from the date of creation or the date when the policy was last in effect, whichever is later (45 CFR § 164.316(b)(2)(i)). If you did not document it, you cannot prove you did it. During an HHS investigation or audit, documentation is your primary defense.
Penalties for Failing to Protect ePHI
Non-compliance with ePHI protection requirements carries significant consequences:
| Penalty Tier | Description | Penalty Per Violation | Annual Cap |
|---|---|---|---|
| Tier 1 | Did not know and could not have reasonably known | $141 – $71,162 | $2,134,831 |
| Tier 2 | Reasonable cause, not willful neglect | $1,424 – $71,162 | $2,134,831 |
| Tier 3 | Willful neglect, corrected within 30 days | $14,232 – $71,162 | $2,134,831 |
| Tier 4 | Willful neglect, not corrected within 30 days | $71,162 – $2,134,831 | $2,134,831 |
Penalty amounts are adjusted annually for inflation. Figures above reflect 2024 adjusted amounts per HHS.
Beyond financial penalties, organizations face reputational damage, loss of patient trust, mandatory corrective action plans, and potential criminal prosecution for knowing violations. State attorneys general may also bring actions under HITECH, adding further legal exposure.
Frequently Asked Questions About ePHI
Is a patient’s name alone considered ePHI?
A patient’s name by itself is not ePHI. It becomes ePHI when it is combined with health information, a diagnosis, treatment record, payment information, or other health-related data, and is in electronic form. The name of a person sitting in a waiting room, without any associated health data in the electronic record being discussed, is not ePHI. But a patient’s name stored alongside their appointment record in a scheduling system is ePHI.
Are emails containing patient information considered ePHI?
Yes. Any email that contains individually identifiable health information is ePHI. This includes emails between providers discussing a patient’s treatment, emails to patients containing test results, and even email subject lines that contain patient names or medical information. Email systems that handle ePHI must comply with the Security Rule’s transmission security requirements, including encryption.
Is data stored in the cloud considered ePHI?
If the data in the cloud meets the definition of Protected Health Information and it is in electronic form, which cloud-stored data inherently is, then yes, it is ePHI. The cloud service provider is a Business Associate and must sign a BAA. The Covered Entity remains responsible for ensuring that appropriate safeguards are in place regardless of where the data physically resides.
Does ePHI include information on paper that was scanned?
Once a paper document is scanned and stored electronically, the electronic version is ePHI (assuming it contains individually identifiable health information). The original paper version remains PHI governed by the Privacy Rule. Both must be protected according to their respective applicable rules.
What happens if ePHI is texted on a personal phone?
Text messages containing patient health information on personal devices are ePHI. If the messages are not encrypted and the device is not subject to appropriate administrative, physical, and technical safeguards, the organization is likely out of compliance. This is one of the most common and most dangerous compliance gaps I encounter. Organizations need clear BYOD policies and secure communication platforms to address this.
How long must ePHI be retained?
HIPAA itself does not mandate a specific retention period for ePHI or medical records, that is governed by state law, which varies. However, the Security Rule requires that documentation of policies, procedures, and security actions be retained for six years (45 CFR § 164.316(b)(2)(i)). As long as ePHI is retained in any form, it remains subject to the Security Rule. Disposal of ePHI must also follow proper procedures under the device and media controls standard at 45 CFR § 164.310(d).
Conclusion
ePHI is not a complex concept, but the obligations that flow from it are substantial. Every electronic system that touches individually identifiable health information, from your EHR to your email server to the smartphone in your clinician’s pocket, falls under the HIPAA Security Rule’s requirements. Understanding what ePHI is, where it exists in your environment, and what the Security Rule demands is the non-negotiable starting point for meaningful compliance.
If you are unsure whether your organization is adequately protecting ePHI, or if you need help conducting a risk analysis, building out your safeguard framework, or responding to an incident, One Guy Consulting can help. We provide practical, no-nonsense HIPAA compliance consulting for covered entities and business associates. Schedule a risk assessment or reach out directly to start the conversation.
Sources
- U.S. Department of Health and Human Services. “Summary of the HIPAA Security Rule.” https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
- 45 CFR Part 160, General Administrative Requirements. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160
- 45 CFR Part 164, Security and Privacy. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164
- HHS Breach Notification Rule. 45 CFR §§ 164.400–164.414. https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html
- HHS Guidance on HIPAA & Cloud Computing. https://www.hhs.gov/hipaa/for-professionals/special-topics/cloud-computing/index.html
- NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices. https://csrc.nist.gov/publications/detail/sp/800-111/final
Disclaimer: This article is provided for informational and educational purposes only. It does not constitute legal advice. HIPAA compliance requirements are complex and fact-specific. Consult with a qualified attorney or compliance professional for guidance tailored to your organization’s specific circumstances. One Guy Consulting provides compliance consulting services but does not provide legal representation.