Risk Analysis, Encryption Stressed in HITECH Act Final Rules

Risk Analysis, Encryption Stressed in HITECH Act Final Rules

Two final rules for the HITECH electronic health record incentive program strongly emphasize the value of risk assessments and encryption as measures for safeguarding patient information.

A new rule establishing requirements for proving a provider is a “meaningful user” for Stage 3 of the incentive program requires protecting patient data through the implementation of appropriate technical, administrative and physical safeguards and conducting a risk analysis that includes assessing encryption of ePHI created or maintained by a certified electronic health record.

A companion final rule setting 2015 standards for certifying EHR software as qualifying for the program requires the software to be capable of creating a hashing algorithm with security strength equal to or greater than SHA-2.

The Department of Health and Human Services’ Centers for Medicare and Medicaid Services says the Stage 3 requirements are optional in 2017. Providers who choose to begin Stage 3 in 2017 will have a 90-day reporting period. However, all providers will be required to comply with Stage 3 requirements beginning in 2018 using EHR technology certified to the 2015 Edition requirements.

When it comes to privacy and security requirements included in the final rules, versus what was in the proposed rules, there were “no significant changes, no surprises,” says John Halamka, CIO of Beth Israel Deaconess Medical Center.

Some privacy and security experts, however, point out the rules spotlight the importance of safeguarding electronic protected health information through measures such as risk analysis, encryption and secure data exchange. But some observers criticize HHS for not offering more detailed guidance on risk assessments.

Risk Analysis

While conducting a risk analysis was also a requirement in Stages 1 and 2 of the meaningful use program, the final rule for Stage 3 requires that healthcare providers drill down further by “conducting or reviewing a security risk analysis … including addressing the security – to include encryption – of electronic protected health information created or maintained by certified electronic health record technology … and implement security updates as necessary and correct identified security deficiencies.”

The objective of that requirement is to protect electronic health information through the implementation of “appropriate technical, administrative and physical safeguards,” the rule states. Rulemakers stress assessing the data created or maintained by an electronic health record system, versus conducting a more comprehensive security risk assessment as required under the HIPAA Security Rule.

“Although [HHS’] Office for Civil Rights does oversee the implementation of the HIPAA Security Rule and the protection of patient health information, we believe it is important and necessary for a provider to attest to the specific actions required to protect ePHI created or maintained by CEHRT in order to meet the EHR incentive program requirements,” the rule notes. “In fact, in our audits of providers who attested to the requirements of the EHR Incentive Program, this objective and measure are failed more frequently than any other requirement.

“This objective and measure are only relevant for meaningful use and this program, and are not intended to supersede what is separately required under HIPAA and other rulemaking. We do believe it is crucial that all [eligible healthcare providers] evaluate the impact CEHRT has on their compliance with HIPAA and the protection of health information in general.”

New to the risk analysis requirement is the addition of assessing administrative and technical safeguards. “This measure enables providers to implement risk management security measures to reduce the risks and vulnerabilities identified. Administrative safeguards – for example, risk analysis, risk management, training and contingency plans – and physical safeguards – for example, facility access controls, workstation security – are also required to protect against threats and impermissible uses or disclosures to ePHI created or maintained by CEHRT.”

Missed Opportunity?

HHS should have used the final rule to offer even more helpful guidance about risk assessments, says privacy attorney David Holtzman, vice president of compliance at the security consulting firm CynergisTek.

“CMS focused significant attention to the role of risk analysis in safeguarding the privacy and security of health information created or maintained in an EHR,” he says. “However, they missed an important opportunity to … ensure that administrative and physical safeguards requirements of the HIPAA Security Rule are assessed in any security risk analysis.”

To guide healthcare providers, including smaller doctors’ offices, in conducting the Stage 3 risk analysis, the rule makes note of free tools and resources available to assist providers, including a Security Risk Assessment Tool developed by ONC and OCR.

But the use of that tool is daunting for some smaller healthcare entities, contends Keith Fricke, principal consultant at consulting firm tw-Security.

“The SRA tool is too overbearing for any organization to use, let alone small healthcare organizations, including small provider offices,” he says.

Secure Data Exchange

Besides a renewed focus on risk analysis, other privacy and security related enhancements to the meaningful use Stage 3 final rule include an emphasis on encryption and secure messaging.

“More than half of the objectives in Stage 3 starting in 2017 require EHRs to have interoperable exchange technology that is encrypted and offered to relying parties with strong identity assurance,” said David Kibbe, M.D., CEO of DirectTrust, which created and maintains a framework for secure e-mail in the healthcare sector.

“DirectTrust’s work can and will be relied upon for multiple Stage 2 and 3 objectives and criteria announced by CMS in the new rule,” he says.

For instance, secure electronic messaging to communicate with patients on relevant health information is an objective in Stage 3, with a series of measurements.

Software Certification Rule

While privacy and security are weaved through the final rule for Stage 3 of the meaningful use program for healthcare providers, HHS’ Office of the National Coordinator for Health IT also raised the bar on requirements in the final rule for 2015 Edition health IT software certification. That includes phasing in requirements for more robust encryption.

“Given that the National Institute of Standards and Technology, technology companies, and health IT developers are moving away from SHA-1, we believe now is the appropriate time to move toward the more secure SHA-2 standard,” ONC wrote in its rulemaking.

The rule also states: “We note that there is no requirement obligating health IT developers to get their products certified to this requirement immediately, and we would expect health IT developers to not begin seeking certification to this criterion until later in 2016 for implementation in 2017 and 2018. We further note that certification only ensures that a health IT module can create hashes using SHA-2; it does not require the use of SHA-2. For example, users of certified health IT may find it appropriate to continue to use SHA-1 for backwards compatibility if their security risk analysis justifies the risk.”

Some other safeguard features, such as data segmentation for privacy of sensitive health information, are included in the software certification rule as optional, Halamka notes. “That’s appropriate for immature standards,” he says.

Public Input

CMS is continuing to seek public comment on the “meaningful use” rule for 60 days. This input could be considered by CMS for future policy developments for the EHR incentive program, as well as other government programs, the agency says.

However, this additional public comment period could become problematic, Holtzman contends. “The adoption of the changes in the objective and measures as a ‘final rule with comment’ could cause delays in EHR vendors and developers in producing upgrades to their technology. The uncertainty in that CMS could make further changes in the months ahead might encourage these industry partners to hold off in their production process.”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.