ePHI: What Electronic Protected Health Information Means Under HIPAA

ePHI is the electronic form of protected health information, and the exact target of the HIPAA Security Rule. Nearly every clinical workflow in 2026 runs on ePHI, from electronic records and imaging archives to patient portals and connected devices.

Understanding exactly what counts as ePHI, and what does not, is the starting point for every HIPAA security decision. This guide defines ePHI, distinguishes it from PHI and PII, gives concrete examples and non-examples, explains how HIPAA protects it, and covers encryption, cloud hosting, and the newer risks that AI tools introduce. For an introduction to this topic and more, see our complete guide to the HIPAA Security Rule.

HIPAA Security Rule Update

In January 2025, HHS OCR proposed the first major overhaul of the HIPAA Security Rule in more than a decade. The proposal would drop the “required versus addressable” distinction and make encryption, multi-factor authentication, and other safeguards mandatory, giving regulated entities 240 days to comply once a final rule is issued.

After roughly 5,000 public comments, the final rule slipped from its original May 2026 target to a July 2027 target and now sits on HHS’s long-term regulatory agenda.

Until a final rule takes effect, the 2013 version of the Security Rule is the one still in place.

What Does ePHI Stand For?

ePHI is electronic protected health information, the subset of protected health information (PHI) that a covered entity or business associate creates, receives, maintains, or transmits in electronic form. The HIPAA Security Rule (45 CFR Part 164 Subpart C) protects ePHI specifically through administrative, physical, and technical safeguards.

ePHI stands for electronic protected health information, the electronic subset of protected health information (PHI) covered by the HIPAA Security Rule.

The “electronic” qualifier is what matters here.

ePHI is governed by the HIPAA Security Rule (Subpart C).
PHI in oral or paper form is governed by the HIPAA Privacy Rule (45 CFR Part 164 Subpart E).

The term first entered HIPAA regulation when the Security Rule was finalized in 2003. But the earlier Privacy Rule uses the broader term PHI. In 2009, the HITECH Act extended enforcement of ePHI protections to business associates.

ePHI vs. PHI: What’s the Difference?

ePHI is a subset of PHI. Every piece of ePHI is also PHI, but not every piece of PHI is ePHI. The difference matters because the HIPAA Security Rule applies to ePHI only, while the Privacy Rule applies to PHI in any form.

Protected Health Information (PHI): Includes protected health information in any form, whether oral, paper, or electronic.
Electronic Protected Health Information (ePHI): The electronic subset of PHI.
Personally identifiable information (PII): A broader privacy concept that overlaps with PHI but extends well beyond healthcare.

The 18 HIPAA identifiers at 45 CFR § 164.514(b)(2) determine when health information is identifiable. They include: names, geographic data smaller than a state, dates other than year, phone and fax numbers, email addresses, Social Security numbers, medical record numbers, health-plan beneficiary numbers, account numbers, certificate or license numbers, vehicle identifiers, device identifiers, URLs, IP addresses, biometric identifiers, and full-face photographs, plus any other unique identifying number, characteristic, or code.

Many organizations also handle PII outside healthcare, such as employee and contractor records.

Examples of ePHI

Examples of ePHI include any electronic record, transmission, or storage of protected health information that contains one or more of the identifiers tied to a person’s healthcare.

Clinical Records and Systems

Clinical records and systems are the most common example of ePHI. They include:

Electronic medical and health records (EMR/EHR)
Lab and pathology results
Digital Imaging and Communications in Medicine (DICOM) imaging in a picture archiving and communication system (PACS)
Clinician notes
e-Prescribing records

Patient-facing communications count too. That includes:

Portal messages
Telehealth video sessions and recordings
PHI-containing appointment reminders
Secure email

Administrative and Financial Data

Administrative and financial data counts as well. Examples include:

Electronic billing with identifiers
837 claim and 835 remittance-advice transactions in the Electronic Data Interchange (EDI) standard
Insurance verification
Eligibility checks

Mobile and consumer health data is ePHI once it reaches a covered entity or business associate. That includes:

Health-app data
Connected medical devices
Remote patient monitoring

Even administrative metadata can be ePHI, such as an audit log showing who accessed a specific patient’s record.

What’s NOT Considered ePHI

Several categories of health-related information are not considered ePHI under HIPAA. Usually, that’s because they are not in electronic form, do not identify an individual, or fall outside HIPAA’s regulatory scope.

Non-Electric Data

Information that is not electronic is not ePHI. Paper records, oral communications, and un-digitized handwritten notes are PHI but not ePHI.

De-Identified Data

De-identified data under 45 CFR § 164.514 is not PHI at all, whether it meets the Expert Determination or Safe Harbor method described in the U.S. Department of Health and Human Services (HHS) Office for Civil Rights (OCR) De-identification Guidance.

Properly anonymized research data and aggregate statistics with no identifiable element, such as mortality graphs and public-health dashboards, are likewise not ePHI.

Out-of-Scope Data

Some data sits outside HIPAA’s scope entirely. Examples include:

Employment records held by a covered entity in its employer capacity.
Family Educational Rights and Privacy Act (FERPA)-covered education records.
Health data held by entities that are neither covered entities nor business associates (such as an unaffiliated consumer app).
Deceased-individual information beyond the 50-year limit at 45 CFR § 164.502(f).

ePHI in Healthcare Settings

In healthcare settings, ePHI is the practical day-to-day form most protected health information takes. It lives in the electronic record systems, imaging archives, patient portals, and connected devices every clinical workflow now depends on.

Nearly all U.S. non-federal acute care hospitals have adopted a certified electronic health record — over 99% as of 2024 per federal data — so most protected health information now lives in electronic form. For example:

Inpatient and outpatient care center on the EHR as the primary ePHI repository, with connected bedside devices generating additional ePHI streams.
Diagnostics and imaging produce ePHI through lab information systems, PACS and DICOM imaging, and digitized pathology.
Patient engagement runs through portals for secure messaging, results, scheduling, and bill pay, plus telehealth in video, audio, and chat form.
Administrative workflows generate ePHI in 270/271 eligibility transactions and 837 claim transactions, along with prior-authorization exchanges.

How HIPAA Protects ePHI

The HIPAA Security Rule outlines specific protections for ePHI. It requires administrative, physical, and technical safeguards of every covered entity and business associate that creates, receives, maintains, or transmits ePHI.

The Security Rule sets three general objectives at 45 CFR § 164.306(a). Covered entities and business associates must:

Ensure the confidentiality, integrity, and availability of all ePHI.
Protect against reasonably anticipated threats.
Protect against reasonably anticipated impermissible uses or disclosures.

The Rule organizes protection into three safeguard categories:

Administrative safeguards (§ 164.308): The policies, procedures, and workforce measures that manage security day to day, including risk analysis, role-based access management, security training, and contingency planning.
Physical safeguards (§ 164.310): The controls that protect facilities, workstations, and hardware from unauthorized physical access, including facility access controls, workstation security, and secure disposal of devices and media.
Technical safeguards (§ 164.312): The technology controls that protect ePHI inside information systems, including access controls, audit logging, integrity controls, and encryption of data in transit.

Required vs. Addressable Specifications

Within those safeguards, each implementation specification carries one of two labels under 45 CFR § 164.306(d): required or addressable.

Required: The organization must implement the specification exactly as written, with no discretion.
Addressable: The organization decides whether the specification is reasonable and appropriate for its environment. If it is, the organization implements it. If it is not, the organization documents why and puts an equivalent alternative in place where one is reasonable.

Addressable is often misread as optional. It is not. It gives organizations flexibility in how they meet a standard, not in whether they meet it at all.

Where NIST Comes In

The Security Rule is deliberately technology-neutral. Rather than naming specific tools or algorithms, it sets objectives. That framing keeps the framework durable, but it also leaves covered entities asking what “reasonable and appropriate” actually looks like — especially against modern threats.

To close that gap, HHS points to NIST SP 800-66 Rev. 2, the official companion guide that maps each Security Rule standard to concrete, current safeguards.

ePHI Encryption

ePHI encryption is the process of converting ePHI into unreadable ciphertext, so that only someone with the decryption key can access it. Under the HIPAA Security Rule, encryption is an addressable implementation specification rather than a strict requirement.

In practice, however, encryption is often the single most important control most organizations can apply. The Rule sets two encryption specifications, both addressable:

Encrypt ePHI at rest (i.e., stored on servers, databases, endpoints, and backups), per § 164.312(a)(2)(iv).
Encrypt ePHI in transit, per § 164.312(e)(2)(ii).

For each addressable specification, an organization must do one of three things:

Implement the specification as written.
Implement a documented, equivalent alternative.
Document why implementation is not reasonable and appropriate.

Skipping encryption without that documentation is what draws enforcement.

Enforcement on Encryption

Historically, OCR has treated missing encryption on lost or stolen devices as an aggravating factor, and its recent focus has shifted toward ransomware and risk-analysis failures. Recent settlements reflect that shift, and both turned on a missing risk analysis rather than a single lost device:

BST & Co. CPAs, LLP: A New York accounting firm and HIPAA business associate paid $175,000 in August 2025 after a 2019 Maze ransomware attack that started with a phishing email and encrypted the protected health information of roughly 170,000 people. OCR faulted the firm for never conducting an accurate, thorough risk analysis. It was OCR’s 15th ransomware settlement and 10th action under its Risk Analysis Initiative.
Top of the World Ranch Treatment Center: An Illinois substance use disorder provider paid $103,000 in February 2026 after a 2023 phishing attack reached one workforce member’s email account and exposed the ePHI of 1,980 patients. OCR again cited the failure to perform a proper risk analysis, its 11th action under the same initiative.

Under HITECH § 13402(h) and the Breach Notification Rule at § 164.402, encrypted ePHI is not “unsecured.” So, losing an encrypted laptop or drive generally does not trigger breach notification at all. In other words, no other single control does more to limit breach exposure.

For examples of what strong encryption looks like, HHS points to NIST:

At rest: NIST SP 800-111 with FIPS 140-3-validated cryptographic modules. FIPS 140-2 certificates move to historical status on September 21, 2026, so validate new deployments against FIPS 140-3.
In transit: NIST SP 800-52 Rev. 2 for Transport Layer Security, setting TLS 1.2 as the minimum and requiring support for TLS 1.3.
Key management: NIST SP 800-57 Part 1 Rev. 5 is the de facto reference. Encryption without documented key management is not defensible.

ePHI Hosting and Cloud Storage

ePHI can be stored or hosted with any provider that meets the HIPAA Security Rule’s safeguard requirements. The provider must be a business associate with a signed BAA, and the implementation must satisfy the encryption, access-control, and audit-control standards regardless of hosting model.

According to 2016 HHS OCR Cloud Computing Guidance, cloud service providers that handle ePHI are business associates and must comply with the Security Rule directly. A BAA must be in place before ePHI moves through the cloud, and provider-side encryption alone does not exempt the covered entity or business associate from the Rule.

Best practices include verifying HIPAA-eligible service status before deployment, using customer-controlled encryption keys where the model allows, configuring provider-side audit logging, and reviewing cloud configuration periodically. But the newest risk surface is AI.

ePHI in Modern Contexts: AI, Chatbots, and More

Modern ePHI risk extends beyond traditional EHR and email scenarios into AI assistants, clinical chatbots, large language model (LLM) tools, and consumer-grade collaboration platforms that healthcare workers routinely encounter in 2026.

The general rule is simple: Never paste ePHI into a public-tier LLM chatbot.

Consumer AI tools like ChatGPT, Gemini, and Claude do not provide a BAA and do not satisfy the Security Rule. Here, even a single ad-hoc paste of patient data creates a reportable incident.
Clinical AI tools that handle ePHI by design, such as ambient scribes and AI-assisted coding, operate under a BAA with documented safeguards.

Compliance comes from the BAA and the vendor’s implementation, not from the AI capability alone. So, AI-generated content derived from ePHI may itself be ePHI.

Four risk surfaces recur most often in 2026:

Workers pasting patient context into public chat tools.
Portal-embedded chatbots retaining ePHI in conversation history.
Telehealth AI transcription deployed before a BAA is in place.
Shadow-IT use of consumer collaboration apps.

Oversight now reaches beyond OCR. The HHS Artificial Intelligence Strategy directs covered entities to comply with HIPAA when AI systems process ePHI, and the FTC AI Chatbot Inquiry opened a September 2025 review of consumer AI chatbot vendors.

This adds three requirements to a HIPAA program:

Workforce training must cover AI and chatbot rules.
The vendor inventory must capture every AI tool that handles ePHI.
The risk analysis must treat AI-tool deployment as an in-scope system.

ePHI Breach Examples

An ePHI breach occurs when unsecured ePHI is acquired, accessed, used, or disclosed in a manner not permitted under the HIPAA Privacy Rule. Unless the organization demonstrates a low probability of compromise through the four-factor risk assessment, breach notification is triggered.

Scenario	Is it a Breach of ePHI?	Why
Unencrypted laptop with patient records lost	✅ Yes	Unsecured ePHI, encryption safe harbor not met
Email with patient info sent to the wrong external recipient	✅ Yes	Unauthorized disclosure, risk assessment required
Customer lab results on a computer accessed by an unauthorized user	✅ Yes	Unauthorized access of ePHI
Completed electronic health insurance claim viewed by unauthorized staff	✅ Yes	Unauthorized access of ePHI
Ransomware encrypting EHR systems (CE locked out)	✅ Yes	OCR treats as access, a breach unless low probability of compromise is shown
Stolen unencrypted backup tape with patient records	✅ Yes	Unsecured ePHI
Lost paper chart (not electronic)	PHI breach, not ePHI	Privacy Rule scope, still reportable as a PHI breach
Encrypted laptop with patient records lost	Usually No	Encryption renders ePHI “not unsecured” per HITECH § 13402(h)
Public-health surveillance report with no identifiers	❌ No	No identifiers, not ePHI
Mortality graph aggregating de-identified data shared publicly	❌ No	De-identified per 164.514, not PHI/ePHI

How to Protect ePHI

Protecting ePHI under the HIPAA Security Rule comes down to five core safeguards. They are:

Encryption: Encrypt ePHI at rest and in transit (§ 164.312(a)(2)(iv) and (e)(2)(ii)).
Access controls: Enforce unique user identification and multi-factor authentication (§ 164.312(a)(2)(i) and (d)).
Audit controls: Maintain current audit logs with a documented review cadence (§ 164.312(b)).
Risk analysis: Run an annual risk analysis and remediate the findings (§ 164.308(a)(1)(ii)(A) and (B)).
Business associate agreements: Maintain BAAs with every vendor that handles ePHI (§ 164.308(b)(1)).

For the full breakdown of the federal Breach Notification Rule, including the four-factor assessment and OCR settlement patterns, see the HIPAA security breach spoke and the HIPAA security audit guide.

How to Simplify HIPAA Compliance

Simplifying HIPAA compliance starts with knowing where ePHI lives. A single, current inventory of the systems, applications, and vendors that handle ePHI keeps risk assessments and business-associate oversight manageable.

Isora GRC, the GRC Assessment Platform™, builds that inventory through Inventory Management with data classification. Teams catalog every system, application, and vendor product that handles ePHI, with its data-classification context attached. That same inventory then feeds three HIPAA workflows:

Risk assessment: the asset-inventory step under § 164.308(a)(1)(ii)(A).
Business-associate oversight: a vendor list that flags each entry’s ePHI-handling status.
Audit readiness: classification context that travels with each asset into every assessment.

Download the HIPAA Security Rule Crosswalk for a control-by-control mapping of the safeguards that protect ePHI.

See how Isora GRC supports HIPAA Security Rule compliance →

Key Takeaways

ePHI is the electronic subset of PHI. It is any protected health information a covered entity or business associate creates, receives, maintains, or transmits electronically, and it falls under the HIPAA Security Rule (45 CFR Part 164 Subpart C).
The 18 HIPAA identifiers define it. Information becomes ePHI when it is electronic and tied to one of those identifiers.
Three safeguard categories protect it. Administrative, physical, and technical safeguards work together, and each specification is either required or addressable.
Encryption is the highest-leverage control. Encrypted ePHI counts as “not unsecured,” which creates a breach-notification safe harbor.
Risk analysis drives enforcement. Recent OCR settlements have turned on the failure to run a thorough, current risk analysis.
AI is the newest risk surface. ePHI never belongs in a public-tier LLM without a BAA and documented safeguards.

See the GRC Assessment Platform™ in action →

ePHI FAQs

What is ePHI?

ePHI is electronic protected health information: the subset of protected health information (PHI) that a covered entity or business associate creates, receives, maintains, or transmits in electronic form. The HIPAA Security Rule at 45 CFR Part 164 Subpart C governs it.

What does ePHI stand for?

ePHI stands for electronic protected health information. The “e” marks the electronic form that separates ePHI from paper or oral PHI, which the HIPAA Privacy Rule covers.

What is the difference between PHI and ePHI?

PHI is the broad category covering health information in any form: oral, paper, or electronic. ePHI is the electronic subset. The Security Rule applies only to ePHI, and the Privacy Rule applies to PHI in every form.

What are some examples of ePHI?

Examples include electronic medical records (EMR/EHR), lab results in patient portals, electronic billing data, telehealth video sessions, patient portal messages, mobile-app health data sent to a covered entity, e-prescribing records, and connected medical device data.

Which of the following is NOT considered ePHI?

Several categories fall outside ePHI. A paper medical record is PHI in non-electronic form, so it falls under the Privacy Rule. De-identified data under 45 CFR § 164.514 is neither PHI nor ePHI. Employment records a covered entity holds as an employer are excluded, and so are FERPA-covered education records.

Does the HIPAA Security Rule focus on protections specifically for ePHI?

Yes. The Security Rule protects ePHI specifically, through administrative, physical, and technical safeguards. The Privacy Rule covers all PHI in any form.

Is ePHI considered PII?

Often, yes. ePHI is PII whenever it carries identifiers such as a name, Social Security number, address, or date of birth, which most ePHI does. PII is the broad privacy concept, and ePHI is the healthcare-specific HIPAA subset. Many records are both.

Where is ePHI allowed to be stored?

ePHI may be stored anywhere that meets HIPAA Security Rule safeguard requirements, including on-premises, in a private cloud, or in a public cloud, provided the hosting provider is a business associate with a signed BAA. Consumer file-sharing services without a BAA are not allowed.

What’s the difference between ePHI and PII?

PII is personally identifiable information, a broad privacy concept for any data that identifies a person. It is governed by frameworks like NIST SP 800-122 and privacy laws including state statutes, GDPR, and CCPA. ePHI is the healthcare-specific subset: electronic PHI under HIPAA. In healthcare settings, ePHI is usually a subset of PII.

This content is for informational purposes only and does not constitute legal or compliance advice. See our full disclaimer.

HIPAA & ePHI: Complete Guide [2026]