Here is latest monthly blog from the HIMSS Privacy and Security Committee…entitled PSST! Keep reading to learn more about this month’s topic – Meaningful Use Stage 2 – Final Rule Impact to Privacy and Security, by HIMSS P&S Committee member Kristopher Kusche, CISSP, CPHIMS, FHIMSS, Vice President, IS – Technology, Albany Medical Center. Lisa Gallagher
by Kristopher Kusche, CISSP, CPHIMS, FHIMSS
With the Meaningful Use Stage 2 (MU2) encryption requirement, we now need to think of the states of patient data after the use of electronic health record applications. That is, how data is cached, how/where it is stored and how well the EHR applications do clean-up.
When the original HIPAA deadlines were upon us in 2004, privacy and security professionals needed to assure their organizations were aware of, and putting in place, much of this foundation-level policy, procedure and technology. While providing “belts and suspenders,” HIPAA lacked specificity for:
- security technology standards,
- mandate to audit, and
- penalty to organizations that did not comply.
With the release of the ARRA several years later (2009), the HITECH provisions solved the question of enforcement by providing the structure for a government oversight program and fines for non-compliance. But, the legislation still left certain aspects of security implementation (such as, encryption technology and audit) unclear for most organizations.
Fast forward to 2012 and release of the final rule for MU2: The new final rules certainly clarify what organizations should do to encrypt data in all states on end-user devices and what it means to collect data for auditing purposes.
All this is nicely done within the framework of existing industry and governmental standards that will help those responsible professionals and their organizations take ambiguity out of their implementations, which I would say have been fuzzy at best. And yes, this is all done with risk assessment at the core of compliance and with the clear requirement to actually fix those items identified as risks.
Encryption: To start with encryption, the final rule clarifies encryption must be explicitly addressed for all end-use devices that store electronic health data. As part of their application for MU incentive funds, organizations must specifically attest they have “addressed”* encryption as part of their risk analysis.
As noted in the final rule, “due to the number of breaches reported to HHS involving lost or stolen devices, the HIT Policy Committee recommended specifically highlighting the importance of an entity’s reviewing its encryption practices as part of its risk analysis. It is for these reasons that we specifically call out this element of the requirements under [HIPAA] for the meaningful use measure.”
Per the final rule, a requirement will not be created to go beyond HIPAA: “We did not propose to change the HIPAA Security Rule requirements, or require any more than is required under HIPAA. We only emphasize the importance of an EP or hospital including in its security risk analysis an assessment of the reasonable and appropriateness of encrypting electronic protected health information as a means of securing it, and where it is not reasonable and appropriate, the adoption of an equivalent alternative measure.”
However, clearly, CMS wants to see this security control explicitly addressed by each organization, with the goal of protecting health data that is increasingly being stored on end-user devices.
While HIPAA always talked encryption for transport, the subtlety with the MU final rule is this: we now need to think of how EHR applications leave data when those applications are no longer in use.
This should automatically start your organization thinking about:
- how data is cached,
- how it is stored, and
- how well the health record applications do clean-up.
This guidance implies organizations will be required to take a tougher stance at implementing encryption technologies on devices, such as mobile devices, and even, stationary desktops, based on the limitations of the application clean-up. Needless to say, encryption on mobile devices, such as laptops and removable USB devices, is necessary.
Encryption also includes assuring secure transport of data between health information exchanges as well as during communications with patients (i.e., secure messaging).
As expected, the NIST encryption standards are the basis for compliance with both encryption (AES or better) and hashing (SHA-1 or better). While organizations may spend project dollars for implementation, many operating system-based methods and third-party applications work for compliance.
Audit: Perhaps the biggest change and technical challenges relate to what and how organizations need to audit access to protected data.
Organizations must collect date, time, patient identification, user identification, and what specific activity occurred whenever “electronic health information is created, modified, accessed, or deleted.” This requirement nicely sets the stage for the ability to audit activity in the EHR at each step in the data use cycle.
The obvious implication, since most EHR applications are proprietary vendor applications, indicates organizations will likely be reliant on their application vendors to implement auditing with enough specificity to comply with the final rule. This data set functionality is also required when reporting out disclosures, in addition to the disclosure detail, consistent with normal treatment, payment and operations activities.
Lastly, the final rule requires establishing measures to assure integrity of the encryption and audit mechanisms by:
- setting the technical standard for time synchronization within and among electronic health record systems; and
- calling for the recording of all changes to encryption status on end-use devices as well as audit log status within the electronic record applications.
The Good News…As always, the devil of the policy is in the details required for implementation. It appears the final rule for MU2 has successfully provided the needed clarity to help organizations secure health data.
For the complete final rule documents, follow the links to:
The CMS MU2 final rule and The ONC final rule for EHR Certification – 2014.
We hope that you found this month’s topic for PSST! encouraging in the important work you do. Please share these thoughts with others and share your comments here on the HIMSS Blog.
Have an idea for a future “PSST!”? Contact Lisa Gallagher, senior director, privacy and security, at HIMSS, lgallagher@himss.org.
________________________________________________________________
*The HIPAA Security Rule states that if requirement is “addressable” then the covered entity must:
1. Assess whether the specification is a reasonable and appropriate safeguard in its environment and is likely to contribute to protecting the entity’s electronic protected health information.
2. Implement the specification or document why it would not be reasonable and appropriate and implement an equivalent alternative measure if reasonable and appropriate.
It is absolutely imperative that PHI is encrypted at rest and in transit fromm a point of orign to any remote location, including across a HISP to HISP connection. To do otherwise is foolhardy. It opens the NHIN to hacker attacks and significant vulnerability thus significant risk.
Sabatini –
From a strict security perspective, yes, encryption and hashing are just two of the measures we as professionals should consider to assure the availibility, integrity and confidentiality of our individual organization’s healthcare data.
From a Meaningful Use compliance perspective, CMS and ONC have provided some clarity around these issues in the two Final Rule documents. With regard to encryption for data at rest, while both groups stress they are not requiring anything above what HIPAA requires, remember that HIPAA is a broader regulation that applies to PHI in general while the MU rules apply to the certification of EHR technology. So, in regards to data at rest within Certified EHR Technology (CEHRT), the Rules do require that CEHRT’s assure that PHI either 1) does not remain on an end use device or 2) that any remaining PHI should be encrypted, where possible . The Rules further remind us that the encryption standard MUST be made part of a facility’s formal risk assessment and is only addressable “where it is not reasonable and appropriate”. Of note, the ONC Final Rule is very specific that the MU rules DO NOT apply to data at rest within a facility’s data center or servers, although HIPAA would still be generally applicable.
In regards to Transport, ONC is specific in that they allow two options for securing transport, including 1) entity to entity type transmissions must meet the specification outlined in the Applicability Statement for Secure Health Transport (found here http://wiki.directproject.org/file/view/Applicability+Statement+for+Secure+Health+Transport+v1.1.pdf or 2) must use a SOAP secure transport requirements traceability matrix. Each transmission option requires the use of XDR and XDM for Direct Messaging specification.