Tip

How to interpret and apply federal PHI security guidance

Richard E. Mackey, Contributor

The main purpose of the Health Information Technology for Economic and Clinical Health (HITECH) Act is to encourage the adoption of information technology to improve the efficiency and accuracy of health information exchange,

Requires Free Membership to View

but it also includes stricter definitions for what constitutes secured versus unsecured protected health information (PHI). The first half of this article summarizes the definitions and guidance provided by the U.S. Department of Health & Human Services (HHS), and provides advice regarding how organizations should address regulatory requirements and PHI security. The second half will outline how PHI security requirements should be applied to a health care organization's business associates.

In the original Health Insurance Portability and Accountability Act of 1996 (HIPAA), a covered entity -- such as a health care provider, health care clearinghouse or health plan -- was required to hold business associates contractually responsible for securing electronic protected health information, or ePHI. In other words, covered entities were responsible for policing their business associates.

The HITECH Act broadens the direct applicability of HIPAA compliance, making a covered entity's business associate directly responsible for data protection and compliance with the HIPAA privacy and security rules as well -- and directly liable for damages incurred from a breach.

Interestingly, while the HITECH Act has cast a wider legal net, it has not increased compliance requirements substantially for business associates; it has only brought them more into the regulatory spotlight. In other words, an organization that operated as a covered entity in the past should have been compliant with the HIPAA requirements all along. The HITECH Act, however, has clarified how all organizations -- covered entities and business associates alike -- can exempt themselves from breach notification rules in cases where exposed ePHI was protected with approved encryption technologies.

Breach notification is required only when "unsecured" information is exposed to unauthorized parties. The HHS defines unsecured PHI as having not been "rendered unusable, unreadable, or indecipherable to unauthorized individuals through the use of a technology or methodology specified by the [HHS] Secretary in guidance."

HHS initially issued its PHI security guidance in its August 2009 breach notification interim final rule (see sidebar). The agency submitted a final rule to the Office of Management and Budget for review in May 2010, but withdrew that final rule shortly thereafter, citing a need to further consider the issue -- though the interim rule remains in effect. A final rule, with additional guidance on PHI security, is expected this year.

Is it necessary to encrypt protected health information?

On reading the HHS guidance, one might be led to believe that HIPAA and the HITECH Act require organizations to encrypt data at rest and in motion. This is not the case, however. The guidance is not meant to instruct organizations in how to protect information. Instead, it is meant to describe how data must be treated so organizations can avoid being held responsible for a breach. If health information that has been encrypted according to the guidelines is accessed by unauthorized parties, the covered entity or business associate is not liable.

Ensuring that protected health information is 'secured' according to the HHS definition may go a long way toward reducing the risk of a health care data breach.

In fact, the HHS guidance from the breach notification interim final rule included the following statement:

"We emphasize that this guidance does nothing to modify a covered entity's responsibilities with respect to the [HIPAA] Security Rule, nor does it impose any new requirements upon covered entities to encrypt all protected health information. The Security Rule requires covered entities to safeguard electronic protected health information, and permits covered entities to use any security measures that allow them to reasonably and appropriately implement all safeguard requirements. Under [ePHI security standard] 45 CFR 164.312 … a covered entity must consider implementing encryption as a method for safeguarding electronic protected health information; however, because these are addressable implementation specifications, a covered entity may be in compliance with the Security Rule even if it reasonably decides not to encrypt electronic protected health information and instead uses a comparable method to safeguard the information."

Achieving true HIPAA compliance

Ensuring that protected health information is "secured" according to the HHS definition could go a long way toward reducing the risk of a health care data breach. Nevertheless, any organization that processes ePHI will need to deal with the data in unprotected form at some point. That means that all organizations need to take full HIPAA compliance seriously.

HIPAA compliance requires organizations to have a full security program that includes formal governance, risk assessment and management, education and training, and access controls to ensure that only authorized people gain access to the protected information. Many of the measures the security rule specifies are "addressable," not "required;" but prudent organizations will consider the effectiveness of various controls and implement those that will have the best chance of preventing breaches.

Any organization that handles protected health information should watch for proposed PHI security guidance from HHS. In the meantime, organizations should implement the National Institute of Standards and Technology's recommended encryption methods, as well as strong identity management and access controls. Organizations also must work closely with business associates to ensure data is protected when it is shared.

Richard E. Mackey, vice president of Sudbury, Mass.-based SystemExperts Corp., is an authority on enterprise security architecture and compliance. Let us know what you think about the story; email editor@searchhealthit.com.

This was first published in January 2011

Join the conversation Comment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.