When the Health Insurance Portability and Accountability Act of 1996 was first drafted, the internet and electronic data were seen by many as a passing fad. In the 27 years since then, not only has the internet become a major force in most peoples’ lives, electronic Protected Health Information, or ePHI, is the primary modality for healthcare industry tracking and communication of patient data.
In this article, I’ll baseline what electronic Protected Health Information (ePHI) is, what ePHI security is, and what Covered Entities’ obligations are with respect to that data. I’ll also cover some frequently asked questions about ePHI and ePHI security.
One thing of note: where I write extensively about Covered Entities, I’m using the term interchangeably with Business Associate. While not completely technically correct, the distinction is immaterial with respect to ePHI since the passage of the HITECH Act, which amended HIPAA to clarify that all Security Rule standards applied equally to Business Associates and Covered Entities independent of the existence of a Business Associate Agreement. No one who holds PHI is exempt from compliance and the standards are identical.
What is ePHI?
ePHI and PHI
Electronic Protected Health Information is defined in the HIPAA regulations promulgated by the Centers for Medicaid and Medicare Services under the Department of Health and Human Services. Those regulations can be found in the Code of Federal Regulations, specifically at 45 CFR § 160.103. It’s a specific subset of Protected Health Information that is either transmitted via electronic media or maintained in electronic media. In short, PHI in electronic form.
While that definition is fine for identifying the “electronic” portion of electronic Protected Health Information, it still leaves a question: what is PHI? PHI is defined as a specific subset of Individually Identifiable Health Information, or IIHI.
Individually Identifiable Health Information
Critically, IIHI is health information and demographic information created under specific circumstances, by specific entities. The entities are:
- Healthcare provider,
- Health plan,
- Employer, or
- Healthcare clearinghouse.
The circumstances are that the information, which can be traced to a specific individual:
- Relates to their physical or mental health,
- Provision of their health care, or
- Payment (including future payment) for the provision of their health care.
Identifiability is key to whether something is considered Individually Identifiable Health Information. If it cannot be identified or is specifically deidentified by removing the association with an individual, then the information cannot be Individually Identifiable Health Information. In turn, that information cannot be PHI or ePHI and neither HIPAA nor its Security Rule applies to it by its terms.
De-Identification
Whether or not something is sufficiently deidentified is defined under 45 CFR § 164.514. The less common method of satisfying this standard happens with an expert opinion opining that an individual’s health information cannot be identified. That can be helpful, for example, in litigation to justify the identity of large datasets.
More typically, organizations rely on the provisions of 45 CFR § 164.514(b)(2) to determine the identifiability of information. That provision highlights 18 identifiers, any of which make a health record individually identifiable:
- Names,
- Geographic subdivisions smaller than a State,
- Dates directly related to an individual (not year only),
- Phone numbers,
- Fax numbers,
- Email addresses,
- Social security numbers,
- Medical record numbers,
- Health plan beneficiary numbers,
- Account numbers,
- Certificate/license numbers,
- Vehicle identifiers and serial numbers, including license plate numbers,
- Device identifiers and serial numbers,
- Website URLs,
- IP address numbers,
- Biometric identifiers,
- Full-face photographic images and the like, and
- Other identifiers which specifically identify an individual.
When deidentifying information, Covered Entities must endeavor to ensure that reidentification isn’t possible from just the deidentified dataset. They must also reasonably believe an individual cannot be identified from the deidentified dataset.
ePHI vs. PHI vs. PII
You may be wondering how that differs from Personally Identifiable Information (PII). According to the U.S. General Services Administration (GSA) the definition of PII is situational and some other U.S. agencies define PII to meet regulatory needs. The commonality between all definitions is the ability to identify an individual. So, arguably, PHI and ePHI would be PII. However, not all kinds of PII will be considered Protected Health Information, since PHI must be created by specific entities for specific purposes. So too, not all PHI is ePHI, where ePHI is PHI in electronic form.
Examples of ePHI
Electronic Protected Health Information (ePHI) is identical to Protected Health Information (PHI), just in electronic format. So a patient’s chart that is digitized, input into an Electronic Health Record, or otherwise stored in electronic information systems is ePHI. So too are digital records of medical devices or credit card payments for those devices. Really, anything in information systems that links a human being to some medical treatment can be ePHI if created by the right healthcare organizations.
The thing that really differentiates ePHI from PHI, in my opinion, is that there’s so much of it.
Society is so incredibly data-driven and healthcare is no exception. Data helps drive better outcomes through diagnosis and treatment, which is supported by machine intelligence and analytics, and collected through tens if not hundreds of points depending on a person’s ailments. The breadth and uses of ePHI highlight why the HIPAA Security Rule is so critical to drive ePHI security.
HIPAA’s Security Rule and ePHI
The HIPAA Security Rule, located at 45 CFR §§ 164.300, et seq., defines HIPAA security requirements and what appropriate protection of ePHI looks like. They’re not detailed security measures and there’s some flexibility when implementing them. That being said, they provide a uniform set of standards for protecting all health data that qualifies as ePHI.
The HIPAA Security Rule is divided into three main sections covering administrative safeguards (45 CFR § 164.308), physical safeguards (45 CFR § 164.310), and technical safeguards (45 CFR § 164.312). Those safeguards provide a baseline. They’re designed to outline the minimum security measures that the security rule defines as necessary for protecting and minimizing data breaches.
Those safeguards are subdivided into Addressable and Required. One might think that where there are two choices and one is “required” the other is not. That’s not quite the case.
Required means that a standard must be implemented as outlined. Some examples of required standards include:
- Implement policies and procedures to outline administrative safeguards, implement physical security procedures and implement technical security measures.
- Documenting incident management procedures.
- Implement workstation security measures to reduce potential risks to physical workstations and ensure only authorized access to data is possible.
- Enact auditable access controls so that only authorized persons, typically workforce members, can access individuals’ health information.
Addressable, on the other hand, means that a Covered Entity can review whether or not the specific objective is reasonable and appropriate. Organizations can analyze potential risks based on organizational structure and complexity to determine if a measure reduces risks to and can protect ePHI.
If the standard is reasonable and appropriate to accomplish that goal, then the Covered Entity must implement it. If the standard is not reasonable and appropriate, then the Covered Entity must 1) document why it is not and 2) implement an equivalent alternative if reasonable and appropriate.
By allowing Covered Entities this flexibility, HIPAA acknowledges that organizations of different sizes and complexities have different needs and resources. Some can implement security programs that are incredibly objectively robust to the tune of millions of dollars per year. Others need risk management programs that are less robust, but provide a reasonable and appropriate level of protection to reduce risks for themselves.
Core to this determination is whether or not the confidentiality, integrity, and availability of electronic Protected Health Information are preserved. The goal of the Security Rule is to maintain reasonable safeguards against reasonably anticipated threats and protect patient information from being improperly altered without compromising patient care delivery.
Some examples of Addressable controls include:
- Assigning and documenting security responsibilities: while HIPAA demands a security official, a sole proprietor may be that security official and may not need a fleet of security personnel to address their security needs.
- Security awareness and training or facility access controls: preserving confidentiality, integrity, and availability looks different between a solo practice, hospital, health network, or insurance provider. The information system, technology, and physical access control needs are different, as are the threats and how those organizations protect ePHI. There is no one-size-fits-all solution for objectives like those.
- Transmission security: what an electronic network looks like and how it functions varies significantly by organizational size and complexity. Some Covered Entities may need to implement hardware–and significant amounts of it–to secure their network. Others may not. Core to how transmission security is structured is a risk analysis of electronic Protected Health Information and the technical policies and infrastructure needed to ensure compliance.
This list isn’t comprehensive by any means, but hopefully provides a broad overview of what HIPAA requires of a Covered Entity. While HIPAA compliance can look between organizations, even meeting common baseline controls, there are some best practices every Covered Entity can leverage to stay on the right side of Security Rule compliance.
Best Practices for Protecting ePHI
The Health Insurance Portability Accountability Act of 1996 provides a uniform baseline for all organizations that use or maintain electronic Protected Health Information (ePHI). What that means is that it requires organizations to implement security measures as a floor to protect ePHI.
Depending on the size of the organization, meeting the HIPAA Security Rule requirements won’t be enough to protect ePHI. Even if an organization meets the HIPAA Security Rule requirements, ePHI can still be exfiltrated. A HIPAA Data Breach is a data breach. Covered Entities can still incur reputational damage, regulatory actions, fines, and liability for those breaches.
Safeguarding ePHI requires the implementation of key elements from the HIPAA Security Rule. Those elements can be implemented by adopting an industry-standard security framework like HITRUST, NIST CSF, NIST 800-171, NIST 800-53, or ISO 27001. Implementation of a framework like that is practically a must for medium to large-sized organizations.
Standards like that can also be technical, but very helpful for smaller organizations that are serious about protecting patient information. They’re technical because they’re prescriptive. That prescriptiveness makes them more useful in my opinion than simply HIPAA Security Rule compliance. That prescriptiveness is also designed to improve the chances of implementing a successful security program.
Common to all industry-standard security frameworks are three things:
- The protection of the confidentiality, integrity, and availability of data;
- The implementation of administrative, technical, and physical safeguards to achieve that protection; and
- The documentation of those safeguards in security policies.
Coincidentally, that’s also what the HIPAA Security Rule requires.
Most of those industry-standard security frameworks will outline what to put in organizational security policies. They’ll also outline, to a degree, how procedures meet and can implement policies. Overall, those procedures will govern how to protect, use, and disclose all information in physical or electronic form. That should include ePHI.
Finally, implementing a risk management program is a must. It’s impossible to discern where risks exist without quantifying those risks. So too is it impossible to address those risks once quantified without a management program.
Implementing one of those programs can be a daunting prospect. One great place to start is security and privacy training. HIPAA requires it and there are many options–even free options offered by CMS.
Responding to a Data Breach Involving ePHI
Breach response and consequent notification are typically thought of as falling under the HIPAA Privacy Rule. The obligations can be found at 45 CFR §§ 164.400, et seq. However the response is made, it typically involves a few key steps:
- Stopping the events leading to the breach
- Trying to retrieve the data and mitigate the breach
- Notification obligations
- A report to CMS
Some of those are easier said than done. A solid risk management program certainly helps with the cessation of the breach and retrieval of information.
HIPAA requires notification to affected parties of the breach within 60 days of discovery of the breach. If more than 500 individuals are impacted, a public notice must be made. Additionally, the CMS Office of Civil Rights (OCR) must be notified of the breach within 60 days of discovery.
CMS OCR will want to know some key facts: the scope of the breach, if the Covered Entity met the HIPAA Security Rule, proof of that, etc. CMS OCR has implemented enhanced fines for Covered Entities that engaged in egregious conduct, including failing to meet HIPAA standards. Make sure you implement policies and actually follow them!
Reducing Your ePHI to Reduce Obligations
Data rationalization and reduction is one way to reduce the scope of HIPAA compliance obligations: the fewer places data travels, the easier it is to contain and secure and the less infrastructure that is covered by HIPAA.
There are a few ways to accomplish that rationalization and reduction:
- Follow the Minimum Necessary standard prescribed by HIPAA and don’t transfer data where you don’t absolutely need it.
- Use data lakes or Electronic Health Record systems that aggregate data for processing instead of using many disparate systems.
- Figure out if deidentified data meets your needs. If it does, use that instead.
There are other ways to reduce the use of sensitive data, but these three will generally be the biggest bang for the buck.
Conclusion
The healthcare marketplace is awash with sensitive information. It’s critical that all Covered Entities protect that information in the way prescribed by HIPAA, namely by following the HIPAA Security Rule. It’s not only mandatory but can help avoid substantial legal and financial liability.
There’s nothing wrong with seeking help, either. It’s a fantastic idea and can go a long way towards driving successful conformance to HIPAA’s requirements and meaningfully protecting ePHI.
FAQs on ePHI
Are Tattoos Considered ePHI?
Tattoos themselves are not considered ePHI. However, if they are included in photographic or biometric scan information, they can strongly identify an individual and therefore would be included as ePHI and may make identification more complex.
What Other Items Might Contain ePHI?
Many items will contain ePHI, including:
- Medical records and charts
- Medical billing receipts
- Medical device purchase receipts
- Prescriptions and documentation from pharmacies
- Employee health records (e.g.: physicals and drug tests)
Err on the side of caution with what does and doesn’t contain ePHI. If it’s medical and identifies an individual, then unless you know it’s not PHI treat it as if it is. The consequences for failing to do so are significant.
