HITECH Stage 2 Rules: An Analysis

Deven McGraw Describes Privacy, Security Provisions
HITECH Stage 2 Rules: An Analysis

The proposed rules for Stage 2 of the HITECH Act electronic health record incentive program contain strong provisions encouraging encryption and other security measures, explains consumer advocate Deven McGraw.

See Also: Cyber Insurance Assessment Readiness Checklist

McGraw serves on the Health IT Policy Committee, which drafted recommendations for both rules. She's also co-chair of the committee's Privacy and Security Tiger Team.

The Department of Health and Human Services is accepting comments on the proposed rules through May 7. The tiger team is continuing to work with the policy committee to draft comments (see: Stage 2 HITECH Rules Under Microscope ).

The strongest encryption provision, McGraw says, is a requirement in the proposed EHR software certification rule that the software "needs to be able to demonstrate the capacity to encrypt [data on] mobile devices in circumstances where the EHR technology manages the data flow on the mobile device," she explains in an interview with HealthcareInfoSecurity's Howard Anderson (transcript below).

That means, for example, that if an EHR system manages data that's stored on a laptop, that data must be automatically encrypted, and the encryption function must be set up so that it cannot be turned off by the average user, McGraw explains. "This comes about as close as you could get" to an encryption mandate, she adds (see: What's New in EHR Certification Rule?).

The other proposed Stage 2 rule, setting guidelines for demonstrating that a hospital or physician practice is a meaningful user of certified EHR software, requires conducting a risk assessment that specifically addresses "the encryption/security of data at rest" (see: Stage 2 HITECH EHR Rule Unveiled).

The idea behind this provision, McGraw says, is to "shine a spotlight" on the existing requirement in the HIPAA security rule, which states data at rest should be encrypted unless it's not "reasonable and appropriate." Under HIPAA, if encryption is not applied, providers must demonstrate other safeguards, such as physical security, are in place. Encryption, especially of data on mobile devices, is a vital safeguard, McGraw says, pointing to the many major health information breaches that have involved the loss or theft of unencrypted devices.

Complete Analysis

In the interview, McGraw also:

  • Explains why the Centers for Medicare and Medicaid Services, which finalized the meaningful use rule, would not have approved an outright encryption mandate;
  • Emphasizes that the proposed Stage 2 meaningful use rule continues a Stage 1 requirement to conduct a risk assessment and take action to mitigate risks;
  • Describes two new requirements in the proposed Stage 2 meaningful use rule. One requires hospitals and physician practices to demonstrate that at least 10 percent of patients have securely viewed, downloaded or transmitted portions of their EHR, such as through a patient portal. The other requires physician practices to verify that at least 10 percent of their patients are using secure messaging to communicate with their doctors.
  • Outlines how the proposed Stage 2 software certification rule would require the creation of logs that track who has accessed an individual's records through a patient portal. A patient portal also would have to indicate the source of each component of a patient's records by using metadata. And the rule also would require accommodation of patient amendments to their records, such as to correct errors.
  • An attorney, McGraw is director of the health privacy project at the Center for Democracy & Technology, a Washington-based, not-for-profit civil liberties organization. She focuses on developing and promoting policies that ensure the privacy of personal health information that is electronically shared.

    Stage 2 Meaningful Use Rule

    HOWARD ANDERSON: Let's talk about the proposed Stage 2 meaningful use rule. The rule spells out how physicians and hospitals must meaningfully use certified EHR software to qualify for a second round of incentive payments. As in the Stage 1 rule, the proposed Stage 2 rule would require conducting a risk assessment and taking steps to mitigate risks identified, but the proposed Stage 2 rule goes beyond the Stage 1 rule to include more details on encryption, but not a specific mandate. Have I got that right?

    DEVEN MCGRAW: You've got it right, yes. Essentially what CMS [Centers for Medicare & Medicaid Services] did in the proposed Stage 2 rule was to take a recommendation from the Health IT Policy Committee and insert it almost word-for-word into the proposed rule. What's been proposed for meaningful users to do in Stage 2 is to attest that they have addressed implementation of encryption of data at rest - so stored either in a data center or stored in portable media. And this is already a provision in the HIPAA security rule, which doesn't require encryption per se, but it does require you ... to address how you're going to deal with physical security and to implement encryption, unless it's not reasonable or appropriate for you to do so, and in which case you can pursue alternative security - physical security - mechanisms.

    So again, it's not a per se requirement to do encryption of data at rest, but it's basically what we call "shining a spotlight" on the requirement to address and consider what you're going to do with respect to encryption of data at rest. The reason for this is because so many of the breaches that we know have taken place since the breach notification requirement went into effect have been breaches of portable media that have not been encrypted. The hope here is to get the meaningful use program to support the idea of encrypting data where it's possible to do so.

    Patient Access to Health Information

    ANDERSON: The proposed Stage 2 meaningful use rule also includes beefed up requirements for providing patients with secure online access to their health information. Can you describe that requirement for us?

    MCGRAW: This is a great requirement in my view. This is a requirement to provide patients with the ability to electronically view and download, and actually even be able to transmit to a third party, key pieces of their health information, like lab results, clinical summaries after an office visit or discharge instructions if they've been admitted to the hospital. The requirement applies both to physicians and hospitals participating in the meaningful use program.

    And what's really important and probably a bit controversial is that both providers and hospitals are going to be measured not just on their making this capability available to patients, but also they're going to be judged on whether or not their patients use it. So, they have to have at least 10 percent of patients actually viewing the information through this mechanism or downloading it or transmitting it through another party, which is going to require them to do some work to promote it with their patient base and for physicians and nurses and other staff to be actively talking with patients about how to use it and teaching them how to use it, etc. As a policy committee member, we felt strongly about [it] because we didn't think that it was likely that many patients would actually take advantage of this capability if they weren't encouraged to do so by their healthcare providers.

    Secure Messaging

    ANDERSON: The rule also includes a requirement that physician practices begin to use secure messaging to communicate with patients. Describe that provision a bit.

    MCGRAW: This is another provision in the patient engagement category for meaningful use, and for this one it's actually trying to encourage physicians to promote the use of e-mail communication with patients in a secure way. This is another one where providers are going to be measured based on whether their patients take this up and take advantage of it. It applies to only physicians participating in the meaningful use program, and at least 10 percent or more of their patients have to be engaging in secure e-mail communication. ... Again, because the physician is being measured based on the behavior of patients rather than just the physician's own behavior, it's going to take some effort from healthcare providers to really promote this service actively in order for them to be assured of meeting their 10 percent threshold.

    ANDERSON: So what else does the proposed Stage 2 meaningful use rule include on privacy and security issues?

    MCGRAW: Well for meaningful use, it's really only two elements. It's having to either perform or review the security risk assessment and address any deficiencies that are uncovered as part of that assessment, and then to shine a spotlight on encryption of data at rest by requiring attestation by providers and hospitals that they've actually addressed that provision. It's really just those two pieces. In the proposed rule, CMS made very clear that they consider compliance with HIPAA to be separate from the meaningful use program, so the expectation is that most of the privacy and security requirements on providers participating in this program come through the HIPAA privacy and security rules, and the meaningful use program layers on a few additional criteria, but not very many. That's very consistent with where CMS was headed in Stage 1.

    Meaningful Use: What's Missing?

    ANDERSON: Was there anything left out of the meaningful use rule that you would have liked to have seen included? What about a mandate for encryption in certain cases?

    MCGRAW: I think it would have been a tough, heavy lift for the policy committee to have gotten much more out of CMS on meaningful use than we were able to get in this rule and I'm personally quite pleased with what's in there. ... Why there's this strong reluctance not to ... have greater requirements for privacy and security as part of the condition of receiving federal funds for adoption of electronic health record technology, I don't know. ...

    Personally, I think we've went about as far as we could on this encryption issue. The certification [rule] sort of upped the ante a little bit, but I don't think we would have gotten a hard-core requirement to use encryption, particularly since the HIPAA security rule doesn't set the bar that high.

    Certification Rule

    ANDERSON: The proposed Stage 2 certification rule sets the standards for EHR software that qualifies for the incentive program. It includes some new encryption details. Why don't you describe that for us?

    MCGRAW: ... Essentially certified EHR technology needs to be able to demonstrate the capacity to [apply encryption on] mobile devices in circumstances where the EHR technology manages the data flow on the mobile device ... [Otherwise, there must be] a capability to ensure that the device doesn't actually store any data.

    So in other words, if you're using a device - the laptop is the example that's most often pointed to in this category - that connects into a certified electronic health record system, and that EHR is the manager of the data that can be accessed on that laptop, the expectation is that the data on the laptop will be encrypted. And not only that, but ... the encryption won't be able to be turned off by the average user of the technology. It can only be disabled by a small class of, say, administrative users who are managing the technology on behalf of the healthcare providers.

    [It's] this idea that you have to demonstrate an ability to encrypt data on a mobile device, which has been one of the big problems [causing breaches] - mobile devices that have data on it that are not encrypted. You have to demonstrate the capacity to encrypt the data and it can't be disabled by the average user. It really does raise the bar on the likelihood the data on mobile devices that are connected to certified EHR technology will have encryption on it - and it will most likely be encryption that's enabled. So not withstanding that we don't have requirements either in meaningful use or in the HIPAA security rule to encrypt information, this comes about as close as you could get.

    ANDERSON: Well it sure sounds like it. Again, this is just for mobile devices and not all devices, is that right?

    MCGRAW: That's right, and it's for classes of mobile devices where the data on the device is managed by certified EHR technology. A laptop that connects into a certified electronic health record system is an obvious example of one that could qualify, but an example of one that would not qualify is a portable USB drive, where the data on that drive is highly unlikely to be managed by a certified EHR. Holding the certified EHR technology responsible for demonstrating its ability to encrypt data on a thumb drive or an USB drive is not possible. They don't go that far.

    Some mobile devices will have that encryption capability kind of hard-wired in, and that will all have to be demonstrated as part of the certification process. But it doesn't mean that if you pick up a mobile phone from your mobile phone store around the corner and it's not part of your certified EHR system that it necessarily becomes required to be encrypted in some way. It will have its limitations, but it's certainly a significant step toward getting greater utilization of encryption of data at rest in mobile technology by the healthcare community.

    ANDERSON: Would this requirement apply to laptops, as well as tablets, if they're running the EHR system?

    MCGRAW: Yes. Again, if they're part of the EHR technology that the provider is using or intending to use for demonstrating meaningful use, they need to get it certified. If it's all part of a single system, then they have to demonstrate as part of the certification process the capability of encrypting any data that would end up being stored on that mobile device. Now my understanding is that with respect to tablets that they often don't store data. They enable access to data that's stored elsewhere, like on a server or in a cloud, but they don't store very much data on the actual tablet, versus laptops, which tend to have a lot of storage capability and do in fact store a lot of data.

    ANDERSON: So for the same reasons, most smart phones wouldn't be included in this then?

    MCGRAW: I think it depends on what you're using the smart phone for. This is a certification program for EHR technology that's intended to be utilized to meet meaningful use objectives. So, if the smart phones are part of the technology that a healthcare system is using to meet meaningful use, it has to be certified and this certification requirement may come into play if, in fact, there's data being stored on the phone.

    Privacy and Security Requirements

    ANDERSON: What other new privacy and security requirements are included in the proposed Stage 2 certification rule?

    MCGRAW: There are several certification functionalities related to the new patient view and download-and-transmit capabilities, including, for example, a requirement that EHR technology has a log of access through the portal and that the patient needs to be able to see a copy of that log on a regular basis. When you use your view-and-download functionality in your provider's EHR through the portal, the idea is that you can click on a button and be able to get a log of who else has been in your portal, which is something that the Health IT Policy Committee and the Standards Committee recommended and HHS picked it up.

    Similarly, to be able to download that information in a secure fashion, it's something that is expected of the EHR technology, so that's a pretty important thing. They do have functionalities that will perpetuate amendments to data in order to comply with the provisions of the HIPAA privacy rule that require covered entities to be able to make amendments to patient's data that the patient requests because there's a dispute about the data or the patient sees an error and wants it corrected. There are a number of standards that are required in certification for that purpose. Those are just two.

    A whole lot of what the policy and standards committees had recommended be in Stage 2 is in there, again, with respect to the patient portals, [for example,] the ability to know through metadata where a particular date element came from. So if the patient, in fact, does take advantage of the capability of downloading or transmitting that information to a third-party, the recipient entity on the other end can know where that data came from in terms of knowing whether to trust it or not.

    Patient Portal

    ANDERSON: Just to clarify, the log of access through the portal, that would log what kind of folks looking at the data in a portal? Is that a physician portal or a patient portal?

    MCGRAW: No, the patient portal. There is already an audit log requirement for certified EHRs that has been in effect for provider users that has been in effect since Stage 1 and they tinkered with that a little bit in Stage 2, but frankly I don't see much of a distinction between the Stage 1 requirement and the Stage 2 requirement for general audit logs of use of a certified EHR by users on the provider end. This is about the log through the patient portal, so who's coming in through the portal and accessing that data? If the patient suspects that someone has been in his/her portal who wasn't supposed to be there, he/she will be able to figure that out.

    Critiquing Certification Rule

    ANDERSON: Is there anything missing from the certification rule proposal that you would have liked to have seen included in there?

    MCGRAW: Yes there are a few things. There's not very much in the certification rule in order to promote accurate matching of patient data that's being exchanged. The Health IT Policy Committee had a number of recommendations, many of them really geared at standards for demographic data fields that would promote or increase the likelihood of an accurate match between data shared from one institution to another. Since the requirements for health information exchange in Stage 2 are much more robust then they are in Stage 1 - at least in the proposed rule - there's an expectation that provider entities will share summary of care documents when there are transitions of care, such as when somebody gets discharged from a hospital or is referred from one provider to another, such as primary care to specialist.

    The expectation is that there's lots of information that's going to need to be shared to coordinate care under the accountable care organization program, the Medicare Shared Savings Program. Many of the programs that are being established under healthcare reform really depend on the sharing of patient data. Meaningful use Stage 2 has some very specific requirements to share data, and yet we do not have an acknowledgement in either one of these rules - Stage 2 meaningful use or the certification rule - of the sort of components that can improve the rate of matching accuracy for exchange purposes.

    Again, the policy committee had a lot of recommendations about standardization and demographic data fields and the need to collect demographic information in order to ensure matching, and none of it got picked up. ... There's a little bit of mention about the use of metadata in the header of the summary of care document that they're proposing to be used ... to send summaries of patient information when there are transitions in care, but it's not entirely clear to me what kind of information is available about patient identity to enable matching. In fact ... in the certification rule ... ONC asks for comment on the possibility of EHR technology being potentially required in certifications to have some sort of automated functionality for doing the matching of patients, such as when a summary of care document is transmitted into your facility, making sure that you put it in the right patient's file; and is there a way for the technology to do that in some sort of automated fashion? ...

    Then I think the other one that ... I need to get more information on is the change in how EHR modules are treated in certification. You have an option, as a healthcare provider, to purchase a complete certified electronic health record with all the bells and whistles that you need to meet meaningful use. Or you can cobble one together by buying separate modules. As long as you have what you need to meet meaningful use and it's certified - that was sufficient. Since Stage 1, there have been a number of security functionalities that certified EHR technology has been required to have and in Stage 1, even the EHR modules were required to demonstrate the capability to meet each and every one of the privacy and security requirements, unless they could either demonstrate that they as a module were part of a bundle package of modules and one of the other EHR modules was responsible for providing the privacy and security for all of the rest of them and then the certification bodies could test that, or they could demonstrate to the satisfaction of the certifying bodies that it would be impractical for that EHR module to incorporate all of the privacy and security criteria.

    If they could satisfy either one of those criteria, then they did not have to meet the privacy and security criteria that were required for Stage 1; otherwise they would. The default expectation was, "You have to do this unless you can meet one of those two exceptions." Well in Stage 2, what they have proposed is that modules would not have to meet the privacy and security criteria. There's a new concept in the proposed Stage 2 rule of the "base EHR" and everyone has to have the components that make up a base EHR, which allow you to meet most of the basic requirements of meaningful use. But you can also purchase modules that allow you to meet some of the meaningful use criteria, say [some] that are specific to your particular type of practice. Those modules, if they're not part of the base EHR, don't have to meet the privacy and security criteria.

    My concern with this is that if those modules store data in any way and they're not required to demonstrate how there are privacy and security functionalities that will protect that data, either as part of that module or as part of the base EHR that somehow gets extended to the data in the module, it just feels like a big hole to me, but I guess we need to explore this more with other members of the policy and standards committees to see what they think about this. ...

    About the Author

    Jeffrey Roman

    Jeffrey Roman

    News Writer, ISMG

    Roman is the former News Writer for Information Security Media Group. Having worked for multiple publications at The College of New Jersey, including the College's newspaper "The Signal" and alumni magazine, Roman has experience in journalism, copy editing and communications.

    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 healthcareinfosecurity.com, you agree to our use of cookies.