Security (Protection of ePHI)

 

HIPAA’s Security Rules

The Standards for Privacy of Individually Identifiable Health Information (“Privacy Rule”) and Standards for Security of Individually Identifiable Health Information (“Security Rule”), established under HIPAA, set national standards for the protection of certain health information.

The Privacy Rule addresses the use and disclosure of individually identifiable health information (called “protected health information” or “PHI”) by organizations subject to the Privacy Rule (“Covered Entities”). Covered Entities include health care providers, health plans, and health care clearinghouses. The Privacy Rule also provides for individual privacy rights with respect to use, disclosure, and access to individual PHI in the possession of Covered Entities.

The Security Rule addresses various physical, technical, and administrative safeguards that must be implemented by Covered Entities and their Business Associates for protection of the confidentiality, integrity and availability of electronic PHI (“ePHI”).

This section will address the Security Rule as it specifically relates to health plans. In addition, the Centers for Medicare and Medicaid Services also provides a decision tool for general help in determining who is a Covered Entity.

What is ePHI?

The Security Rule governs the way health plans handle “electronic Protected Health Information” (ePHI). PHI is individually identifiable health information held or transmitted by a Covered Entity or its business associate, in any form or media, whether electronic, paper, or oral.

Electronic PHI is PHI that is transmitted by, or maintained in electronic media. Electronic media is defined as:

• Electronic storage material on which data is or may be recorded electronically, including, for example, devices in computers (hard drives) and any removable/transportable digital memory medium, such as magnetic tape or disk, optical disk, or digital memory card;
• Transmission media used to exchange information already in electronic storage media. Transmission media include, for example, the internet, extranet or intranet, leased lines, dial-up lines, private networks, and the physical movement of removable/transportable electronic storage media.
• However, certain transmissions, including of paper, via facsimile, and of voice, via telephone, are not considered to be transmissions via electronic media if the information being exchanged did not exist in electronic form immediately before the transmission.

It’s worthwhile to consider some of the more subtle aspects of this definition.

• While PHI recorded on paper is not ePHI per se, it will be ePHI if the paper is a computer print-out. The key is that it was in electronic format immediately before it was transmitted to paper.
• Voice transmissions of PHI via phone are not ePHI but will become ePHI (of the recipient – but not the sender) if they are stored on a voice mail system.
• Telephone voice response and “faxback” systems are subject to the Security Rule.
• Paper-to-paper faxes of PHI are not ePHI.
• Telephone video conferencing is not subject to the Security Rule but a videotape of the conference is.
• Copies of PHI made by a copy machine are not ePHI; however, if the copy machine itself has a digital memory of what it has copied, the material stored in memory will be.

Plans Covered

The Security Rule applies to “health plans”; i.e., individual and group plans that provide or pay for the cost of medical care, including:

• Health, dental, vision, and prescription drug insurers
• Health maintenance organizations (“HMOs”)
• Medicare, Medicaid, Medicare+Choice and Medicare supplement insurers
• Long-term care insurers (excluding nursing home fixed-indemnity policies)
• Employer-sponsored group health plans
• Government and church-sponsored health plans
• Multi-employer health plans

This includes employer-sponsored medical plans and most dental, and vision care plans. Health FSAs and HRAs are also health plans covered by the Security Rule, as well as wellness programs that include screenings.

Core Security Requirements

The Security Rule, which became effective on April 14, 2003, set national standards for the protection of health information, as applied to Covered Entities. Failure to implement these standards may, under certain circumstances, trigger the imposition of civil or criminal penalties.

The Security Rule is narrower than the Privacy Rule in scope but far deeper than the Privacy Rule in the details of its implementation. The Security Rule applies only to ePHI whereas the Privacy Rule applies to all PHI. The Privacy Rule is concerned with the nature of PHI and the ways in which it can be used and disclosed. The Security Rule addresses issues of confidentiality, data integrity and availability.

The Privacy Rule requires Covered Entities to consider the process by which it will protect PHI and limit the uses and disclosures to those specified by the Rule; however, it leaves the actual process up to each Covered Entity. The Security Rule, on the other hand, incorporates an exquisitely detailed procedure that must be followed by Covered Entities and their business associates as they assess risks to ePHI and implement measures to mitigate them.

Confidentiality, Availability and Integrity

Confidentiality

Confidentiality is roughly equivalent to the concept of privacy under the Privacy Rule. It means that ePHI is protected from use by or disclosure to unauthorized individuals, entities or processes.

Availability

Availability means that information must be accessible and useable upon demand by an authorized entity. It is concerned with threats ranging from denial of service attacks to data loss through things like equipment failure and disaster recovery planning to make sure data is always available when needed.

Integrity

Integrity means that the data being stored or transmitted is valid. It protects against risks such as the unauthorized modification, insertion and deletion of data.

Administrative, Physical and Technical Safeguards

The rule requires that plans protect the confidentiality, integrity and availability of ePHI through a series of administrative, physical and technical measures.

Administrative Safeguards

Administrative safeguards are administrative actions, and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect ePHI and to manage workforce conduct in relation to the protection of that information. This includes (but is not limited to):

• Appointment of a security officer who is responsible for the development and implementation of security measures.
• Procedures for authorizing individuals to access all the ePHI they need (but only the ePHI they need) to do their jobs; and for terminating that access.
• Virus protection, log-in monitoring and password management.
• Procedures for handling security incidents.
• Data back-up, disaster recovery and emergency mode operation plan.

Physical Safeguards

Physical safeguards are physical measures, policies, and procedures to protect electronic information systems (the hardware) and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion. This includes (but is not limited to) matters such as:

• Contingency operations.
• Protection from unauthorized physical access.
• Access control for authorized personnel.
• Workstation use.
• Device and media controls.

Technical Safeguards

Technical safeguards are the technology and the policy and procedures for its use that protect ePHI and control access to it. This includes (but is not limited to):

• Technical controls on access such as assigning a unique ID for each user.
• Technical measures needed to allow access in case of an emergency.
• Automatic log-off.
• Encryption and decryption.
• The ability to record and examine system activity.
• Electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner.
• Procedures to verify that a person seeking access to ePHI is who he or she claims to be.
• Measures to guard against unauthorized access to ePHI that is being transmitted over an electronic communications network.

Note that a common element in all three of these requirements is the existence of “policies and procedures.”

Policies and Procedures

It’s not enough for a plan simply to have administrative, physical and technological safeguards that through good fortune or generic good business practices result in adequate protection of ePHI. Rather, a plan must have documents that specifically address the concerns raised by the Security Rule.

These are the ubiquitous “policies and procedures”. Policies and procedures must be:

• Written (although this includes electronic documents.)
• Maintained for six years from the date they were last in effect.
• Available to the persons who need to implement them.
• Reviewed periodically and updated as needed.

Documentation must be detailed enough to communicate the security measures taken and to facilitate periodic evaluations.

What Else Do We Have to Worry About?  So, let’s say you have a nice, thorough and detailed written set of security measures. You know that because you have downloaded someone’s security policy from the internet. You’ve substituted your company’s name in the appropriate spots and you’re actually following the document. Are you good to go?  Unfortunately, no. Under the Security Rule, the process by which a plan decides what it needs to do to protect ePHI is just as important the policies and procedures themselves. This is the risk assessment.

Risk Assessment

The Security Rule expressly requires entities to conduct a written analysis of the risks specific to that entity’s operation. It views this analysis as foundational and essential to meaningful implementation of security measures. Thus, while the Security Rule does not tell an entity what it must do to protect the security of its ePHI, it imposes an elaborately detailed regimen on how to make decisions about those protections. A full discussion of that regimen is well beyond the scope of this article; however, a brief overview will give some idea of the breadth and complexity of the process.

Scope

It’s easy to focus on the risk of unauthorized acquisition of ePHI. It’s the lost laptops and hacked databases that are always in the news. However, equally important to the analysis are the risks to data integrity and availability. This includes things like unauthorized modifications to data, accidental errors, omissions in data and unauthorized or inadvertent creation or deletion or data.

There is likewise a tendency to think about risks in terms of threats or vulnerabilities caused by humans. The Security Rule also requires analysis of threats from natural disasters such as floods and earthquakes and environmental threats such as fire, power outages, equipment failure or obsolete software. This includes concerns such as data back-up and emergency operating plans.

How to Do It

The details depend on the particular operations of each organization. However, viewed from the highest level, there are some steps that every organization will need to take. These include the following:

• Identify where and how ePHI is created, received, maintained, processed, or transmitted. In small organizations, one person may have this information but in larger ones, it may be necessary to ask several people. Those people will need to know what ePHI is in order to respond. Don’t forget:
  • Cell phones
  • Removable media
  • Telecommuters
• Identify security measures currently in place. This includes an assessment of whether those measures are actually being observed and if so, how effective they are.
• Identify vulnerabilities and threats.
  • Threats are events or circumstances that compromise the confidentiality, integrity or accessibility of ePHI. Examples include:
    • Theft
    • Hacking
    • Human error
    • Human mischief
    • Failure of organizational resources such as improperly maintained or configured hardware or software
    • Natural and man-made disasters
  • Vulnerabilities are system weaknesses that are susceptible to threats. So, for example:
    • Poor building security exposes ePHI to theft
    • Bad coding exposes ePHI to hacking
    • Inadequate access controls expose ePHI to both human error and human mischief
    • Failure to install software updates exposes ePHI to a failure of organizational resources
    • Poor data backup practices expose ePHI to loss through natural and manmade disasters
• Assess the likelihood that a particular threat will exploit a given vulnerability. This includes the real-world experience of the organization itself. It should also include available information regarding organizations in similar business as well as organizations using similar systems (e.g., particular internet browsers or email systems.)
• Determine how potential threats would affect the organization if they were to occur.
• Determine how effective the organization’s current security measures are with respect to the anticipated threats.

It’s easy to see how a matrix or chart can be created for each threat which characterizes (qualitatively or quantitatively) the likelihood of the threat, the consequences of the occurrence of the threat and the effectiveness of existing security measures. Of course, the assessment process can take other forms as well but the key point is that the assessment must be in writing.

Risk Management

With the Risk Assessment in hand, an organization can then make decisions about whether, how and when to deal with threats to its ePHI. This is the Risk Management Plan and, like the Risk Assessment, it is required by the Security Rule and it must be in writing.

The Rule articulates an elaborate set of standards related to each set of risks. Each standard may or may not include separate implementation specifications. The standards that do not include implementation specifications contain all the necessary instructions for implementation. If a standard does include separate implementation specifications those specifications are described in the Rule as either “required” or “addressable”.

A required specification is just what the name suggests: it must be met.

An addressable specification is actually more than what the name might suggest. An organization does not have the option of simply ignoring it. Rather, the organization must:

• analyze the specification in relation to its likely contribution to protecting ePHI; and
• either:
  • implement the specification if it is reasonable and appropriate to do so; or
  • document why implementation is not reasonable and appropriate and adopt an equivalent alternative measure (if reasonable and appropriate).

An illustration may be useful. Let’s consider the technical safeguards. The Rule contains five standards:

1. Access controls to ensure that only authorized users can access ePHI.
2. Audit controls that record and examine system activity.
3. Integrity policies to protect ePHI from improper alteration or destruction.
4. Authentication controls to verify that a person seeking access to the system is the person claimed.
5. Transmission security to protect ePHI that is being transmitted electronically against unauthorized access.

The Rule includes implementation specifications for items (1), (3) and (5).

So for item (2), which does not have any further implementation requirements, an organization must ensure that its systems can track who is doing what to which data and allow appropriate persons to review that activity. The Rule is not concerned with how an organization does this as long as the standard is met.

On the other hand, Item (1), relating to access controls, contains four implementation specifications.

• First is the assignment of a unique ID for identifying and tracking each user. This is a required specification. This means that an organization must assign unique user IDs even if there might be a way to control access without assigning a unique ID.
• Second is creation of an emergency access procedure. The Rule doesn’t say what that procedure must be, but it is a required specification so an organization needs to have the ability to get needed data in the face of an emergency.
• Third is an electronic process that automatically terminates access after a predetermined time of inactivity. This is addressable. This means that an organization must implement automatic termination unless it can demonstrate and document why it is not reasonable and appropriate to do so. And even if it can make this demonstration, it must adopt an alternative process that accomplishes the same goal to the extent it is reasonable and appropriate.
• Fourth is encryption and decryption. This is likewise addressable. Accordingly, an organization must encrypt ePHI unless it can show why it is not reasonable and appropriate to do so and must adopt reasonable and appropriate alternative measures.

Each element in the Security Rule breaks down in similar ways.

The Security Rule is intended to be flexible and scalable. This means that each entity can design security measures that take account of that entity’s unique circumstances. Those circumstances include:

• The entity’s size, complexity, and capabilities.
• The entity’s technical infrastructure, hardware, and software security capabilities. This is not a term that is defined in the Rule. It is unlikely that the plan will be able to rely on the mere inclusion of contractual language to meet this obligation. Rather, some degree of due diligence would be required. The manner in  which a plan evaluates a third party vendor’s assurances is presumably subject to the reasonable and appropriate standard, which is to say it can vary depending on the factors outlined above. For example, the process for vetting a large, nationally-known service provider receiving a minimal amount of ePHI (say, eligibility information) may not be the same as the one for vetting a small, local vendor handling a lot of sensitive ePHI (such as claim data).
• The costs of security measures.
• The probability and criticality of potential risks to ePHI.

Organizational Requirements

Group health plans that disclose ePHI to the sponsoring employer have a special set of organizational standards that must be met.

Except when the only ePHI disclosed to a plan sponsor is summary health information or pursuant to an authorization, a group health plan must ensure that its plan documents provide that the plan sponsor will reasonably and appropriately safeguard electronic protected health information created, received, maintained, or transmitted to or by the plan sponsor on behalf of the group health plan. This standard is accompanied by a set of required implementation specifications.

The plan documents of the group health plan must be amended to incorporate provisions to require the plan sponsor to:

1. Implement administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of the ePHI that it creates, receives, maintains, or transmits on behalf of the group health plan;
2. Ensure that the adequate separation between the plan and plan sponsor is supported by reasonable and appropriate security measures;
3. Ensure that any agent to whom it provides ePHI agrees to implement reasonable and appropriate security measures to protect the information; and
4. Report to the group health plan any security incident of which it becomes aware.

Does this mean that an employer must go through the same process that applies to a health plan? The Security Rule does not expressly answer that question. It is worth noting however that the language used to describe the standard applicable to the employer (i.e., that it will “reasonably and appropriately protect” ePHI) is essentially the same as the language used over and over in the Rule to describe the standard applicable to the plan itself.

In addition, the preamble to the Security Rule expressly calls out the similarity between the standard applicable to employers and that applicable to business associates to whom the Security Rule is directly applicable.

Then What?  Do it all again. Not necessarily immediately or even on a pre-determined schedule. However, the Security Rule does require plans to review and modify its security measures as needed to continue provision of reasonable and appropriate protection of ePHI and update documentation of such those measures.

Business Associates

Relationships with Business Associates

Employers often use third-party service providers to assist with the administration of their health plans. If that assistance requires the third-party to handle PHI, it will be a “business associate” of the health plan and the Privacy Rule strictly regulates that aspect of the business relationship between the third party and the employer.

See the ComplianceDashboard material on the Privacy Rule for additional information on business associates generally.

There are similarities and differences between the way that HIPAA treats business associates for purposes of the Security Rule versus the Privacy Rule. A person who is a business associate under the Privacy Rule will necessarily be a business associate under the Security Rule if the business associate deals with ePHI (and vice versa). A plan is prohibited from disclosing ePHI to a business associate unless it has a written agreement with that business associate that meets the requirements of the Privacy Rule.

This includes a requirement that the plan obtain “satisfactory assurances” from the business associate that it will appropriately safeguard the information as required by the Security Rule.  Specifically, the business associate must promise that it will:

• Implement administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of the ePHI that the business associate creates, receives, maintains, or transmits on behalf of the covered entity.
• Ensure that any subcontractors or agents who deal with ePHI on behalf of the business associate similarly comply with the Security Rule.
• Report to the covered entity any security incident of which the business associate becomes aware, including breaches of unsecured PHI under the breach notification rule.

Perhaps the biggest difference in the way that the Security Rule treats business associates is that the latter are directly regulated by the Rule and therefore are required to go through the same kind a security analysis and risk mitigation process that applies to covered entities themselves.

Noncompliance

HIPAA imposes civil penalties for violations:

• If the violator did not know (and by exercising reasonable diligence, would not have known that violation occurred), each violation ranges from $114 to $57,051 with a cap of $1,711,533 for identical violations during the calendar year.
• If the violation was due to reasonable cause, each violation ranges from $1,141 to $57,051 with a cap of $1,711,533 for identical violations during the calendar year.
• If the violation was due to willful neglect (and timely corrected), each violation ranges from $11,410 to $57,051 with a cap of $1,711,533 for identical violations during the calendar year.
• If the violation was due to willful neglect (and not timely corrected), each violation ranges from $57,051 to $1,711,533 with a cap of $1,711,533 for identical violations during the calendar year.

 Additional Resources

Department of Health & Human Services Web Site.

A sample business associate contract language is available on the Office for Civil Rights (OCR) website.

HIPAA Privacy Rule and Health Information Technology (HIT).

Online Form for Submitting Notice of Breach to HHS.