Category: De-identification and PHI Types

Electronic Protected Health Information

Also known as: ePHI, electronic PHI

Simply put

Electronic Protected Health Information (ePHI) is protected health information that exists in electronic form, for example, health data that is created, received, stored, or sent using computers, networks, or other digital systems. It is generally the subset of protected health information that a HIPAA covered entity or business associate maintains or transmits electronically. Because ePHI is specifically electronic, it falls under the scope of the HIPAA Security Rule, which is the rule that addresses safeguards for health information in electronic form.

Formal definition

ePHI refers to information that comes within paragraphs (1)(i) or (1)(ii) of the regulatory definition of protected health information and that is created, received, maintained, or transmitted in electronic form by a HIPAA covered entity or business associate. As of the applicable regulatory text, ePHI is the category of PHI governed by the HIPAA Security Rule, which requires administrative, physical, and technical safeguards to protect its confidentiality, integrity, and availability; PHI in oral or paper form is outside the Security Rule's scope and is instead addressed by the HIPAA Privacy Rule. In related contexts, electronic health information (EHI) is considered ePHI to the extent it would be included in a designated record set. Practitioners should confirm the precise definitional cross-references and safeguard obligations against the current regulation, and note that the HITECH Act and state law may impose additional requirements.

Why it matters

Electronic Protected Health Information is the specific category of health information that triggers the HIPAA Security Rule. Because so much health data today is created, received, stored, or transmitted through computers, networks, and other digital systems, ePHI generally represents the bulk of the sensitive information that covered entities and business associates handle. Identifying what qualifies as ePHI is therefore the starting point for scoping an organization's Security Rule obligations, if data is not electronic PHI, the Security Rule's administrative, physical, and technical safeguards do not apply to it, though the Privacy Rule may still govern it in other forms.

Getting the boundaries of ePHI right matters because misclassifying data can leave gaps in a compliance program. Health information in oral or paper form falls outside the Security Rule and is instead addressed by the Privacy Rule, so organizations that treat all PHI identically may over- or under-invest their safeguards. Conversely, data that is created, received, maintained, or transmitted electronically by a covered entity or business associate, including electronic health information to the extent it would be included in a designated record set, falls squarely within Security Rule scope and must be protected for confidentiality, integrity, and availability.

Practitioners should also remember that the HITECH Act and state law may impose additional requirements beyond the HIPAA Security Rule, and that meeting a particular technical control does not by itself guarantee compliance or prevent all breaches. Because definitional cross-references and safeguard obligations can change, the precise scope of ePHI in any given situation should be confirmed against the current regulation rather than assumed from general summaries.

Who it's relevant to

Security Officers

Because ePHI defines the scope of the HIPAA Security Rule, security officers rely on an accurate inventory of electronic PHI to determine which systems, applications, and data flows must be covered by administrative, physical, and technical safeguards. Misidentifying ePHI can leave systems outside a risk analysis or leave required and addressable safeguards unaddressed.

Privacy Officers

Privacy officers work with the broader category of PHI, which includes oral and paper forms outside the Security Rule's scope. Understanding where ePHI begins helps them coordinate with security counterparts so that data is protected under the correct rule and no form of PHI is left unaddressed across the Privacy and Security Rules.

Business Associates and Subcontractors

Any vendor that creates, receives, maintains, or transmits ePHI on behalf of a covered entity generally becomes subject to Security Rule obligations, which attach through the business associate agreement. These organizations should confirm what ePHI they handle and how that flows down to subcontractors under their agreements.

IT and Cloud Operations Teams

Teams responsible for infrastructure, storage, and transmission need to know which data stores and channels contain ePHI so they can apply appropriate technical controls, such as access controls and encryption. Where cloud providers are involved, controls that protect ePHI before it leaves a device or system may be relevant, though no single control guarantees compliance.

Compliance Auditors

Auditors evaluating a HIPAA program need a clear, defensible definition of ePHI to test whether the Security Rule's safeguards have been correctly scoped and implemented. They should verify definitional cross-references and safeguard obligations against the current regulation, since these can change over time.

Inside ePHI

Electronic Form Requirement

ePHI is protected health information that is created, received, maintained, or transmitted in electronic form. This electronic characteristic is what brings it within the scope of the HIPAA Security Rule, which governs only ePHI and not PHI held in oral or paper form.

Underlying PHI Elements

ePHI consists of individually identifiable health information relating to an individual's past, present, or future physical or mental health condition, the provision of health care, or payment for care, when that information is held or transmitted electronically.

Relationship to the Security Rule Safeguards

Because ePHI is the sole subject of the Security Rule, covered entities and business associates are generally expected to protect it through administrative, physical, and technical safeguards, which include both required and addressable implementation specifications.

Applicable Parties

Obligations to protect ePHI attach to covered entities and to business associates (and their subcontractors) through defined relationships, typically formalized through business associate agreements, rather than to every vendor that may touch data.

Common Storage and Transmission Contexts

ePHI generally encompasses health information residing on or moving through electronic media such as servers, workstations, portable devices, and electronic transmissions, wherever that data remains individually identifiable.

Common questions

Answers to the questions practitioners most commonly ask about ePHI.

Is all protected health information considered ePHI?

No. ePHI refers specifically to protected health information that is created, received, maintained, or transmitted in electronic form. PHI that exists only in oral or paper form is still protected under the HIPAA Privacy Rule but does not fall within the definition of ePHI. This distinction matters because the HIPAA Security Rule generally applies only to ePHI, while the Privacy Rule covers PHI in all forms. Readers should verify scope against the current regulatory text.

Does encrypting ePHI mean an organization is Security Rule compliant?

No. Encryption is one measure that can help protect ePHI, but it does not by itself establish compliance with the Security Rule. The Security Rule generally requires a combination of administrative, physical, and technical safeguards, and encryption is typically treated as an addressable implementation specification within the technical safeguards. Addressable does not mean optional; it means an entity must assess whether the measure is reasonable and appropriate and, if not, implement an equivalent alternative or document why it is not applicable. No single control guarantees compliance or prevents all breaches.

How do we identify what counts as ePHI within our systems?

Organizations typically identify ePHI by mapping where health information that can identify an individual is created, received, maintained, or transmitted electronically. This generally includes databases, email systems, mobile devices, backups, cloud storage, and portable media. A data inventory or data flow analysis is a common starting point. Because ePHI can move across systems and vendors, the scope of this exercise often extends beyond primary clinical systems. The specifics depend on each environment and should be validated against current regulatory guidance.

Do our vendors that handle ePHI have direct HIPAA obligations?

HIPAA obligations generally attach through defined relationships rather than to any vendor that merely touches data. A vendor that creates, receives, maintains, or transmits ePHI on behalf of a covered entity is typically a business associate, and its obligations flow through a business associate agreement. Subcontractors of business associates that handle ePHI may also be bound through downstream agreements. The precise obligations depend on the relationship and the terms of the applicable agreement, which should be confirmed against current regulation.

What should we consider when ePHI is stored or processed in the cloud?

When ePHI is stored or processed with a cloud service provider, that provider is generally treated as a business associate, and a business associate agreement is typically required. Organizations often consider how administrative, physical, and technical safeguards are allocated between the entity and the provider, since responsibility for controls may be shared. It is important to note that a provider's certifications, such as HITRUST CSF certification, may support a compliance program but do not by themselves establish HIPAA compliance. Verify specific arrangements and responsibilities against current guidance.

How does ePHI relate to breach notification obligations?

The Breach Notification Rule, enforced by HHS OCR, generally addresses unsecured PHI, which includes ePHI that has not been rendered unusable, unreadable, or indecipherable through methods such as encryption consistent with applicable guidance. Whether a particular incident involving ePHI triggers notification depends on a risk assessment and the definitions in the current rule. State laws and the HITECH Act may impose additional or differing requirements. Specific thresholds, timelines, and methods should be confirmed against current regulatory guidance.

Common misconceptions

ePHI covers all protected health information, including paper and spoken information.

ePHI refers specifically to PHI in electronic form. PHI in paper or oral form is protected under the HIPAA Privacy Rule, but only ePHI falls within the scope of the Security Rule.

Because certain Security Rule specifications for protecting ePHI are labeled 'addressable,' they can simply be ignored.

Addressable does not mean optional. An addressable implementation specification generally requires an entity to assess whether the measure is reasonable and appropriate, implement it, or document why it is not and adopt an equivalent alternative where appropriate.

Achieving HITRUST CSF certification means an organization's ePHI is automatically HIPAA compliant.

HITRUST is a private organization and its CSF is a certifiable control framework, not a legal requirement. Certification may support a compliance program but does not by itself establish HIPAA compliance for ePHI, which is enforced by HHS OCR.

Best practices

Inventory where ePHI is created, received, maintained, and transmitted across systems, devices, and transmission channels, since accurate scoping is generally the foundation for applying Security Rule safeguards.

Apply administrative, physical, and technical safeguards to ePHI, and for addressable implementation specifications, document your reasonableness assessment and any equivalent alternative measures adopted.

Ensure business associate agreements are in place with vendors that handle ePHI, and extend appropriate flow-down obligations to subcontractors, since protection obligations attach through these defined relationships.

Maintain documentation distinguishing which protections apply to ePHI under the Security Rule versus PHI in all forms under the Privacy Rule, to avoid conflating the two scopes.

Treat any HITRUST CSF or other framework certification as a supplement to, not a substitute for, a HIPAA compliance program, and verify specific control requirements against the current HITRUST CSF version.

Confirm current regulatory requirements, citations, and any applicable state law or HITECH Act obligations against the current authoritative text, as these may impose requirements beyond baseline HIPAA and are subject to change over time.