HITECH Stage 2: Assessing Risks Is Key

The best way to prepare to comply with the HITECH Act electronic health record incentive program's Stage 2 privacy and security requirements is to conduct a thorough risk assessment, says federal privacy officer Joy Pritts.

See Also: Take Inventory of Your Medical Device Security Risks

A risk assessment helps hospitals and physicians "identify potential areas of their administrative, physical and technical environments that are vulnerable and that they may need to mitigate," says Pritts, chief privacy officer at the Office of the National Coordinator for Health IT. The assessments should focus on using encryption to protect data, she stresses in an interview with HealthcareInfoSecurity (transcript below).

Protecting Stored Information

The HITECH Act electronic health record incentive program is providing billions of dollars in incentives to hospitals and physicians for using EHRs. The meaningful use rule for Stage 2 of the program specifically requires that hospitals and physicians conduct a risk analysis that addresses "the encryption/security of data stored in CEHRT [certified electronic health records technology]" (see: HITECH Stage 2 Rules Unveiled).

The HIPAA Security Rule already requires a risk assessment, but stops short of an explicit encryption mandate. And the Stage 2 rules don't alter the HIPAA requirements, Pritts stresses in the interview.

The Stage 2 software certification rule, which sets standards for EHRs that qualify for the program, requires that the software be designed to encrypt, by default, electronic health information stored locally on end-user devices. This encryption requirement "gives healthcare providers a tool" to make sure stored data is protected, Pritts says.

In the interview, Pritts also explains why:

• The Stage 2 rules emphasize encrypting data at rest.
• Federal officials determined that it was premature to mandate the use of specific authentication technologies in Stage 2;
• The Stage 2 meaningful use rule stresses the importance of giving patients secure access to their records.

Pritts joined ONC, a unit of the Department of Health and Human Services, in 2010 as the office's first chief privacy officer. In that role, Pritts provides advice to the HHS secretary and the National Coordinator for Health IT about developing and implementing ONC's privacy and security programs under HITECH. Pritts also works closely with the Office for Civil Rights and other divisions of HHS, as well as with other government agencies, to help ensure a coordinated approach to key privacy and security issues. Before joining ONC, Pritts held a joint appointment as a senior scholar with the O'Neill Institute for National and Global Health Law and as a research associate professor at the Health Policy Institute, Georgetown University.

Software Certification Rule

MARIANNE KOLBASUK MCGEE: What are the most significant security and privacy provisions in the Stage 2 software certification final rule, and how were those provisions modified in the final rule compared with the proposed version of that rule?

JOY PRITTS: ONC sees all of the certification criteria for security as equally significant. One of the prime criteria for security is that EHR technology that is designed to locally store electronic health information on end-user devices must encrypt such information after the use of the information stops on the device. So what this basically does is, it says that an end user device, like a smart phone or a laptop, has to be able to encrypt the data if it is stored on that device. And that is an important factor.

Some of the other criteria in the Stage 2 rule include audit log certification criteria where we adopted the standards of the American Society for Testing and Materials, or ASTM Standards. And finally, we adopted an amendment certification criterion, which is new for the 2014 edition of certification criteria. These criteria require that EHR technology be able to support corrections and amendments to a patient record in an effort to facilitate provider's compliance with the individual's right to amend [their record] under the HIPAA privacy rule.

For the most part, the criteria that are specified in the final rule are substantially the same as they were in the proposed rule, although there were a few little tweaks with the language just to clarify in response to some of the comments that we did receive.

Meaningful Use Rule

MCGEE: What are the most significant security and privacy provisions in the Stage 2 Meaningful Use incentive rule, and how are those provisions modified in the final version compared with the proposed version of that rule?

PRITTS: Stage 2 Meaningful Use requires eligible providers and hospitals to conduct a security risk assessment as required by the HIPAA Security Rule, and it requires participants implement security updates if necessary and correct identified security deficiencies as part of the risk management process. As explained in the preamble to the final rule, these provisions don't change the HIPAA Security Rule requirements. They don't require anything different than is required under HIPAA. The requirements in the meaningful use rule only emphasize the importance of conducting a risk analysis and assessing the reasonableness and appropriateness of encrypting electronic protected health information as a means of securing it.

So, what essentially this rule does is it reiterates the requirements from the Stage 1 requirement that providers and hospitals attest to the fact that they've actually done this security risk assessment as required by the HIPAA Security Rule. And it shines a light, in particular, on this encryption aspect. Have they looked at encrypting their data? Have they addressed it? Have they ...made an analysis as to whether they are capable of doing that and, if not, do they have another means of protecting the information in place - which is essentially what is required under the security rule. They also need to document why they've made that determination if they can't encrypt the information.

So the final rule here doesn't change, as I said, the security rule requirements at all, but it does ask providers to really look at this element. One of the reasons why we focused on this element, the encryption element in particular, is because the Health IT Policy Committee thought that it was a really important factor to highlight in our current regulations.

Encryption and EHRs

MCGEE: Why was it important to require that EHR applications can encrypt data stored on end-user devices?

PRITTS: Well, information must be protected, regardless of where it is stored or transmitted. So we understand that some information is stored on servers and some information is stored on end-user devices. If you lose the data, it can really have a devastating impact on, not only the delivery of care, but also on the trust that patients have in the evolving electronic health record systems. So it is really essential that this information be protected.

We've issued guidance in the past on how to render unsecured protected health information unusable, unreadable or indecipherable to unauthorized users. This is some of the criteria that we set out that you can use to meet to avoid having to report a security incident where it looks like your information might be breached. If it is rendered unusable, unreadable, or indecipherable then you get the free pass and you don't have to report it as a breach.

One of the acceptable means of rendering information unusable, unreadable, or indecipherable is encryption. You can see that there is a pattern here of our focusing on encryption. The reason for that is that encryption is really one of the best practices from the industry's perspective of protecting health information in making sure that if somebody who is unauthorized gets ahold of some sort of an end-user device like a laptop or a smart phone, that they're not able to read the information that is on it. We've always had a general requirement in the meaningful use rules that EHRs be able to encrypt data in order for the adoption of this technology. But in meaningful use Stage 2 we really focus on the requirement to be able to do so in the end-use device.

Protecting Stored Data

MCGEE: Why does the rule call special attention to protecting data at rest?

PRITTS: The Health IT Policy Committee recommended a focus on end-use devices and in particular data at rest in end-use devices. After analyzing the data breaches that have been reported to the Department of Health and Human Services, a large percentage of the breaches that have been reported to us can be attributed to loss or stolen unencrypted devices. This demonstrates the vulnerability of data at rest. So we believe that by requiring the capability to encrypt data at rest as part of a certified electronic health record, that it will help providers offer better security for their patient's health information. It will give them the tools that they need to make this happen.

Patient Access

MCGEE: What are the key steps involved in making sure privacy is protected when providing patients with access to their records?

PRITTS: Patient access to their health records is an important aspect of patient care and engagement. ONC believes firmly that this kind of patient engagement is one of our high priorities as you can tell by some of the provisions in the meaningful use rule, and that information should be secured. Using EHR technology that can properly establish a secure channel through which this health information can be viewed, downloaded and transmitted is important. And that is one of the reasons that provision is included as part of the certification criteria. We also believe that authenticating patients - verifying that the patient is who they say they are when they request access online - is a key step to protecting privacy.

But we recognize that right now there are significant innovations taking place with respect to authentication. There is an administration effort called the National Strategy for Trusted Identities in Cyberspace, which is working on identity solutions for individuals in a more general way, but which might be able to be used in this healthcare sector. So we have not required a particular form or level of authentication in the Stage 2 rule because right now we feel that it is a little premature to do that.

Stage 2 Preparation

MCGEE:What are the most important steps that hospitals and physician groups should be taking now to prepare for complying with these Stage 2 requirements?

PRITTS:The most important step for a provider to do right now is to familiarize themselves as much as possible with the regulations as quickly as possible. ONC and CMS have provided ... instructional guidance and fact sheets to assist with this effort. And a key step in compliance particularly with the security provisions is to conduct a security risk analysis. This will help these providers identify the potential areas of their administrative, physical and technical environment that might be vulnerable and that they might need to mitigate before they actually go live with their EHR systems.