Pairing HIPAA and HITECH Compliance

Federal Privacy Officer Offers Insights
Pairing HIPAA and HITECH Compliance

The privacy and security provisions of the HIPAA Omnibus Rule and the HITECH Act electronic health record incentive program "dovetail together quite nicely," says Joy Pritts, chief privacy officer at the HHS Office of the National Coordinator for Health IT.

The "meaningful use" EHR incentive program "doesn't make providers do anything differently than they're already required to do under the HIPAA Security Rule," Pritts notes. But the program's rules highlight the importance of certain HIPAA compliance issues, especially the need for a risk assessment, she stresses.

Pritts also points out in an interview with HealthcareInfoSecurity (transcript below) that the EHR software certification rule for Stage 2 of the HITECH incentive program, which begins in 2014, requires that "if an end-use device maintains protected health information after that device has signed off, it must be encrypted. ... That's one of the things that's really a move forward because that's where we're having a lot of breaches right now ... devices that are lost and stolen."

Business Associates

The HIPAA Omnibus Rule "really expands the type of organizations and people that are directly responsible for protecting privacy and security of health information," Pritts notes.

"All of the contractors [business associates] of health plans and healthcare providers who are covered by HIPAA are now going to be directly responsible for following all the security rules and many of the use and disclosure rules under the [HIPAA] privacy rule," she says. "What this means is if there's a breach at the business associate level, then HHS will be able to enforce directly against the party that's responsible for it. That's a great improvement over how things are now."

In the interview, Pritts also:

  • Says that the rule for Stage 3 of the HITECH EHR incentive program likely will include guidelines for robust authentication of providers remotely accessing records;
  • Emphasizes that although the HIPAA Omnibus Rule requires providing patients with an electronic copy of their records, the patient can opt to receive their records without encryption or other security measures;
  • Discusses how the upcoming voluntary ONC guidelines for health information exchange will include tips on giving patients the opportunity to make a "meaningful choice" on whether to have their data exchanged.

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.

HITECH and Omnibus

HOWARD ANDERSON: I want to talk about how the HIPAA Omnibus Rule helps reinforce some of the privacy and security requirements of the HITECH Act electronic health record meaningful use incentive program, or vice-versa. How do they help each other?

JOY PRITTS: They really dovetail together quite nicely. One of the things that the [HIPAA Omnibus] rule does is it really expands the type of organizations and people that are directly responsible for protecting privacy and security of health information. All of the contractors [business associates] of health plans and healthcare providers who are covered by HIPAA are now going to be directly responsible for following all the security rules and many of the use and disclosure rules under the [HIPAA] privacy rule. What this means is if there's a breach at the business associate level, then HHS will be able to enforce directly against the party that's responsible for it. That's a great improvement over how things are now.

When you look at the breaches that have been reported to HHS to date, more and more of them are coming at the business associate level, and that shouldn't be surprising, given the way that things are evolving.

It segues very nicely with the [HITECH] meaningful use criteria. Meaningful use doesn't make providers do anything differently than they're already required to do under the HIPAA Security Rule. It is shining the light on some of the requirements in the security rule that providers may or may not have been aware of. For example, the security risk assessment is something that people should have been doing for many years, but time and again you see in these surveys where a good portion of providers still are not conducting a security risk assessment years after this was a requirement. We've reached a great opportunity that when people are starting to adopt clinical health information technology, they recognize, "I need to do this, and I probably should have been doing it with my billing data already." But it's a fine moment for getting people involved with this activity so that they know that they need to be doing it going forward.

Key Security Steps

ANDERSON: What are some of the key steps organizations should be taking now to prepare to meet the privacy and security requirements of Stage 2 of the meaningful use program under HITECH? Are these the same steps that should be taken to comply with HIPAA Omnibus or different?

PRITTS: There are some additional things that they should be aware of. For example, you have to use EHR technology that's been certified for the meaningful use program. One of the key components of meaningful use and the certification criteria is that if an end-user device maintains protected health information after that device has signed off from an EHR, it must be encrypted. For example, if [someone] is using a laptop to access an electronic health record and it keeps that information, that device has to be encrypted. That's one of the things that's really a move forward, because that's where we're having a lot of breaches right now - with devices that are lost and stolen. This should really help because that's going to make it much easier for the provider. They might not know about it, but in the background, if they're buying certified EHR technology, they should feel comfortable that there should be some encryption already baked in which will make their life a little easier.

HITECH Stage 3

ANDERSON: What do you think are some of the key privacy and security requirements that might be added for Stage 3? What's left that needs to be added?

PRITTS: We've heard from the policy committee that they're very interested in exploring the level of authentication that providers need to have in order to be able to access an EHR system, particularly from a remote place. That's an area that has been explored in the request for comments.

ANDERSON: So more details about authentication could be more prominent in Stage 3?

PRITTS: It's one of the recommendations that we received as to if the technology would need to enable that and that providers would need to use it. Particularly, what they're focusing on is moving toward two-factor authentication. That's where the recommendations have been headed.

ANDERSON: That's primarily for clinicians, not necessarily for patients, right?

PRITTS: Oh, yes. That's primarily for clinicians because that's how MU is set up. The meaningful use criteria focus on how the physicians are accessing the system. You raise an interesting issue about when providers in particular have to secure information when they send it to a patient. There's a lot of information in the introductory section to the Omnibus Rule about how OCR views that issue. It's a very interesting area because it's a tradeoff between security and a patient's right to access their own information. The bottom line is that if a patient is notified that sending information may not be secure, via e-mail for example, and the patient still wants to get it that way, then the provider is pretty much off the hook if they send it to the patient that way.

Health Information Exchange

ANDERSON: ONC is developing voluntary guidelines for health information exchange. What do you see as the most important steps to ensure information remains secure and the data remains private when it's exchanged?

PRITTS: We look at the governance guidelines as a way for these organizations to start really building a network of trust. One of the ways of doing that is to make sure that everybody understands what their practices actually are - not what they're legally allowed to do but what their practices actually are with respect to the information. Notice is one of the components of them.

Another piece of this is, depending on what kind of architectural model is being used, the policy committee has felt very strongly about patients having meaningful choice as to whether they participate in certain types of exchange, and that's another key element - to make sure that there's been buy-in by the patients in the system. That's an essential element of trust, that the patients that you're serving actually know what you're doing and are comfortable with it.


About the Author

Howard Anderson

Howard Anderson

News Editor, ISMG

Anderson is news editor of Information Security Media Group and was founding editor of HealthcareInfoSecurity and DataBreachToday. He has more than 40 years of journalism experience, with a focus on healthcare information technology issues. Before launching HealthcareInfoSecurity, he served as founding editor of Health Data Management magazine, where he worked for 17 years, and he served in leadership roles at several other healthcare magazines and newspapers.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing omnibus.healthcareinfosecurity.com, you agree to our use of cookies.