Skip to main content
HIPAA Path
Category: De-identification and PHI Types

Electronic Health Information

Also known as:
Simply put

Electronic Health Information (EHI) is a person's health information stored in electronic form, such as their medical history, diagnoses, and other details documented in the course of their care. In the context of health IT and information blocking rules, EHI is generally limited to the electronic health information that would be part of a patient's official record set. It is a concept most often discussed in connection with rules that discourage improperly blocking access to or sharing of health information.

Formal definition

EHI is defined for purposes of the information blocking framework administered under ONC (the Office of the National Coordinator for Health Information Technology) as electronic protected health information (ePHI) to the extent that it would be included in a designated record set (DRS), regardless of whether the records are used or maintained by or for a HIPAA covered entity. This definition intentionally scopes EHI to the ePHI/DRS overlap and excludes ePHI that falls outside a designated record set. Note that EHI is a health IT and information blocking construct that borrows the HIPAA terms 'ePHI' and 'designated record set' but is not itself a HIPAA Privacy or Security Rule term; the HIPAA Security Rule governs ePHI generally, while EHI is a narrower, purpose-specific subset. Practitioners should verify the current regulatory definition and any applicable scope limitations or transition provisions against the governing ONC information blocking regulations, as this construct is distinct from HIPAA compliance obligations and may interact with HITECH and state-law requirements.

Why it matters

EHI sits at the center of the information blocking framework administered under ONC (the Office of the National Coordinator for Health Information Technology), which is designed to discourage practices that improperly interfere with the access, exchange, or use of a patient's electronic health information. For compliance professionals, understanding what does and does not qualify as EHI is essential because the information blocking obligations attach specifically to this defined subset of data. Misjudging the scope can lead an organization to either over-restrict legitimate access or to overlook conduct that could be treated as information blocking.

A key source of confusion is that EHI borrows familiar HIPAA terminology, electronic protected health information (ePHI) and designated record set (DRS), without being a HIPAA Privacy or Security Rule term itself. The Security Rule governs ePHI broadly, but EHI is intentionally scoped to the overlap of ePHI and what would be included in a designated record set, and it excludes ePHI that falls outside a designated record set. Treating EHI and ePHI as interchangeable is a common error that can distort both compliance analysis and risk assessments.

Because EHI is a purpose-specific construct distinct from HIPAA compliance obligations, and because it may interact with HITECH and state-law requirements, organizations should not assume that satisfying HIPAA obligations automatically addresses information blocking concerns, or vice versa. Practitioners should verify the current regulatory definition and any applicable scope limitations or transition provisions against the governing ONC information blocking regulations rather than relying on general familiarity with HIPAA terms.

Who it's relevant to

Privacy and Compliance Officers
Privacy and compliance officers need to determine what data qualifies as EHI when evaluating requests for access, exchange, or use, and when assessing whether a practice could be considered information blocking. Because EHI is scoped to the ePHI/DRS overlap, these professionals must be careful not to equate it with all ePHI governed by the HIPAA Security Rule, and should confirm the current definition against the governing ONC information blocking regulations.
Health IT and HIM Professionals
Health information management and health IT teams are typically responsible for identifying which electronic records fall within a designated record set and therefore constitute EHI. This scoping work directly affects how systems support access and exchange, and it requires attention to the distinction between EHI as an information blocking construct and ePHI as it is used under HIPAA.
Legal and Regulatory Advisors
Legal advisors supporting healthcare organizations must recognize that EHI is a distinct construct from HIPAA compliance obligations, even though it borrows HIPAA terminology. They should account for how the information blocking framework may interact with HITECH and state-law requirements, and should verify current definitions, scope limitations, and any transition provisions against the applicable regulatory text.
Health Information Networks and Exchange Participants
Entities involved in exchanging health information across organizations rely on a clear understanding of EHI to structure lawful sharing and avoid practices that could be treated as information blocking. Because the definition applies regardless of whether records are maintained by or for a HIPAA covered entity, these participants should not assume covered-entity status alone determines their obligations.

Inside EHI

Electronic Format
EHI refers to health information that is created, received, maintained, or transmitted in electronic form. This electronic characteristic is central to the term and distinguishes it from paper or oral health information.
Relationship to ePHI
EHI overlaps substantially with electronic protected health information (ePHI), which is the subset of PHI in electronic form governed by the HIPAA Security Rule. Practitioners should note that the term EHI is also used in the ONC information blocking context, where its scope is tied to the designated record set and may differ from the HIPAA definition of ePHI; readers should verify which regulatory context applies.
Security Rule Applicability
Where EHI constitutes ePHI, it falls within the scope of the HIPAA Security Rule, which requires covered entities and business associates to protect it through administrative, physical, and technical safeguards. The Security Rule applies only to electronic information, not to oral or paper health data.
Privacy Rule Coverage
As protected health information in electronic form, EHI is generally also subject to the HIPAA Privacy Rule, which governs PHI in all forms including oral, paper, and electronic. The Privacy Rule addresses uses and disclosures regardless of format.
Custodial Relationships
EHI may be held by covered entities, business associates, or subcontractors. Obligations to protect this information attach through defined relationships, such as business associate agreements, rather than to any party that merely touches the data.

Common questions

Answers to the questions practitioners most commonly ask about EHI.

Is Electronic Health Information (EHI) the same thing as electronic protected health information (ePHI) under HIPAA?
No. These terms originate from different regulatory frameworks and should not be treated as interchangeable. ePHI is a HIPAA Security Rule concept referring to protected health information created, received, maintained, or transmitted in electronic form, and it is tied to HIPAA's definitions of PHI and covered relationships. EHI is a term used in the context of the ONC information blocking framework under the 21st Century Cures Act. While the two concepts overlap substantially, their definitions, scope, and governing authorities differ. Readers should verify the applicable definition against the specific regulation being applied rather than assuming equivalence.
Does complying with HIPAA automatically mean an organization is meeting its EHI obligations?
Not necessarily. HIPAA compliance and obligations relating to EHI arise under distinct regulatory regimes, so meeting one does not by itself establish compliance with the other. The information blocking provisions that reference EHI impose requirements that are separate from, and in addition to, HIPAA's Privacy and Security Rules. An organization can be a HIPAA-covered entity or business associate and still have separate responsibilities in the EHI context. Organizations should assess each framework independently and confirm requirements against current regulatory guidance.
Which safeguards apply when an organization handles EHI that also qualifies as ePHI?
When EHI also meets the definition of ePHI, the HIPAA Security Rule generally applies, requiring the administrative, physical, and technical safeguards it specifies, including both required and addressable implementation specifications. Note that addressable does not mean optional; it means the organization must assess whether the specification is reasonable and appropriate and, if not, implement an equivalent alternative or document why it is not needed. Because a data set may fall under multiple frameworks simultaneously, organizations should map their safeguards to each applicable rule and verify the current regulatory text.
How should an organization determine whether particular electronic data falls within the scope of EHI?
Scope determination generally requires reviewing the applicable definition under the governing framework and mapping it against the specific data the organization holds. Because the EHI concept and its defined scope have been established and refined through regulatory action, organizations should not rely on general assumptions about what is included. It is advisable to consult current ONC and HHS guidance, and where the data also implicates HIPAA, to evaluate it against HIPAA's PHI definitions as well. State law or other frameworks may impose additional considerations, so a single-framework analysis may be incomplete.
What documentation practices help demonstrate appropriate handling of EHI?
As with other regulated data, maintaining records of how EHI is identified, accessed, disclosed, and protected is typically advisable to support accountability. Where the same data is also ePHI, HIPAA generally calls for documented policies, risk analysis, and safeguard decisions, including the rationale for how addressable implementation specifications were handled. Documentation practices should be tailored to the frameworks that actually apply to the data in question, and organizations should confirm current documentation expectations against the applicable regulations rather than relying on generic checklists.
Can a HITRUST CSF certification satisfy an organization's obligations related to EHI?
No. HITRUST is a private organization and the HITRUST CSF is a certifiable control framework, not a legal requirement. Achieving HITRUST certification may help an organization structure and demonstrate certain security and privacy controls, but it does not by itself establish compliance with HIPAA or with obligations arising in the EHI context. Regulatory requirements are enforced by the applicable government authorities, and organizations should treat certification as a supporting tool rather than a substitute for verifying compliance against the current regulations and the current HITRUST CSF version.

Common misconceptions

EHI and ePHI are always identical terms that can be used interchangeably.
While they overlap significantly, the terms can differ in scope depending on the regulatory context. ePHI is defined under HIPAA as electronic PHI subject to the Security Rule, whereas EHI is a term also used in the ONC information blocking framework with a scope tied to the designated record set. Readers should confirm which definition applies to their situation and verify against the current applicable regulatory text.
Because EHI is electronic, only the HIPAA Security Rule applies to it.
When EHI is PHI in electronic form, it is generally subject to both the Security Rule and the Privacy Rule. The Security Rule addresses safeguards for electronic information, while the Privacy Rule governs permissible uses and disclosures of PHI in all forms. The two rules have distinct scopes and are not interchangeable.
Any vendor that handles a healthcare organization's EHI is automatically regulated under HIPAA.
HIPAA obligations attach through defined relationships rather than to every party that touches data. A vendor typically becomes subject to HIPAA obligations as a business associate or subcontractor, generally through a business associate agreement, not merely by virtue of handling electronic health information.

Best practices

Determine which regulatory context governs the EHI in question, as the HIPAA definition of ePHI and the ONC information blocking definition of EHI may differ; verify the applicable scope against the current regulatory text.
Apply Security Rule safeguards to EHI that constitutes ePHI, addressing administrative, physical, and technical categories, and remember that addressable implementation specifications are not optional but require documented evaluation.
Do not rely on electronic format alone to determine applicable rules; assess both Privacy Rule and Security Rule obligations, since the Privacy Rule covers PHI in all forms.
Establish and maintain business associate agreements with vendors and subcontractors that create, receive, maintain, or transmit EHI, since HIPAA obligations attach through these defined relationships.
Check whether state law or the HITECH Act imposes additional requirements beyond HIPAA for the handling of electronic health information.
Recognize that no framework, including HITRUST CSF certification, by itself establishes HIPAA compliance; confirm current obligations against the applicable regulation and, where relevant, the current HITRUST CSF version.