Electronic Healthcare Records , Governance , HIPAA/HITECH

Analysis: HITECH Stage 3 Security Rules

Concerns Voiced Over Narrower Risk Assessment Proposal
Analysis: HITECH Stage 3 Security Rules

Some security experts are concerned that narrower risk assessment requirements in a proposed rule for Stage 3 of the HITECH Act "meaningful use" electronic health records incentive program could confuse healthcare organizations about the importance of conducting a broader risk assessment as required under HIPAA.

On March 20, the Department of Health and Human Services' Centers for Medicare and Medicaid Services issued a notice of proposed rulemaking for Stage 3 of the Medicare and Medicaid EHR incentive program, and HHS' Office of the National Coordinator for Health IT issued the notice of proposed rulemaking for EHR software that qualifies for the incentive program: 2015 Edition Health Information Technology Certification Criteria.

The rules are slated to be published in the Federal Register on March 30, with HHS accepting public comment for 60 days. Regulators are expected to issue final rules after reviewing the comments, which could take months.

Under Stage 3 of the HITECH Act incentive program, eligible hospitals and healthcare professionals can qualify to receive additional incentives by "meaningfully" using certified EHR software to accomplish a list of objectives, including sending secure messages to patients and conducting a security risk assessment of EHR data.

Currently, depending upon when they began participating in the HITECH program, which launched in 2011, eligible hospitals and healthcare professionals are participating in Stage 1 or Stage 2 of program.

Under the HITECH Act, penalties for not using a certified EHR system will kick in beginning in January 2018. Hospitals and physicians participating in the Medicare program must meet a list of Stage 3 objectives and measurements to avoid reduced Medicare payments, a CMS spokesman explains. Those participating in Medicaid have through 2021 to qualify for financial incentives under the HITECH program, and are not subject to financial penalties for failing to meet the objectives.

Meaningful Use Proposals

One of the most significant proposed changes for Stage 3 requirements deals with risk assessments.

While healthcare providers are still expected to conduct broader HIPAA security risk analysis as part of their HIPAA compliance, the Stage 3 proposals state that healthcare providers must conduct annually an assessment that specifically looks at technical, administrative and physical risks and vulnerabilities to electronic protected health information created or maintained by the certified EHR technology.

The proposal addresses "the relationship" between this EHR-related measure and the HIPAA Security Rule risk assessments. "We explain that the requirement of this proposed measure is narrower than what is required to satisfy the security risk analysis requirement under [HIPAA]," the proposal says.

"The requirement of this proposed measure is limited to annually conducting or reviewing a security risk analysis to assess whether the technical, administrative and physical safeguards and risk management strategies are sufficient to reduce the potential risks and vulnerabilities to the confidentiality, availability and integrity of ePHI created by or maintained in [the certified EHR technology]," says the proposal.

"In contrast, the security risk analysis requirement under [HIPAA] must assess the potential risks and vulnerabilities to the confidentiality, availability, and integrity of all ePHI that an organization creates, receives, maintains or transmits. This includes ePHI in all forms of electronic media, such as hard drives, floppy disks, CDs, DVDs, smart cards or other storage devices, personal digital assistants, transmission media or portable electronic media."

Seeking Clarity

Security expert Tom Walsh, founder of consulting firm tw-Security, says the proposed rule offers some clarity of what's expected of healthcare providers.

"With the new MU Stage 3 there was clarification that this was the original intent" to assess the security risk of EHR data, he says.

However, the focus on the annual security risk analysis of EHR data may inadvertently water down the importance of conducting broader HIPAA risk analysis, he says.

"Some organizations, especially smaller organizations that do not have a dedicated information security professional on staff, think that the only risk analysis they need to conduct is just for the certified EHR," Walsh says. "The HIPAA Security Rule requires that all applications and systems that store or transmit ePHI need to have a risk analysis conducted."

John Halamka, CIO at Beth Israel Deaconess Medical Center in Boston, expressed disappointment with the risk assessment language in the proposed meaningful use rule. "The MU3 security requirements are less than HIPAA requirements in that they focus only on the EHR and not all information flows. Since security is an end-to-end process, it is not clear to me why the security focus of MU should be less than HIPAA."

Halamka suggests that "maybe a balanced approach is to require a HIPAA Security analysis - NIST 800-66 for example - once every three years, then ask for yearly progress on the plan, rather than yearly re-audits."

Secure Messaging

Another security issue spotlighted in the meaningful use requirements proposed for Stage 3 is secure messaging.

The proposal call for healthcare providers ramping up patient communication using secure messaging, especially after patients are discharged from a hospital or emergency room. For instance, the proposal says that providers should electronically send secure messages to more than 35 percent of all patients seen by a provider or discharged from a hospital during the EHR reporting period. The secure message should be sent "using the electronic messaging function of the certified EHR technology to the patient - or the patient's authorized representatives - or in response to a secure message sent by the patient or the patient's authorized representative."

Software Certification

The proposed rule for certifying software that qualifies for Stage 3 also contain changes related to privacy and security.

"Building on past rulemakings, this proposed rule further identifies how health IT certification can support the establishment of an interoperable nationwide health information infrastructure," the rule notes.

To accomplish the goal of interoperability, the proposal calls for ensuring "all health IT presented for certification possess the relevant privacy and security capabilities," as well as providing certification for data segmentation standards in the exchange of sensitive health information, such as behavioral health data.

The Stage 3 certification criteria spell out privacy and security requirements based on the type of software module used. "In essence, we identify the privacy and security certification criteria that would be applicable to a health IT module presented for certification based on the other capabilities included in the health IT module and for which certification is sought," the rule states.

So, for instance, if the module being presented for certification contains demographics data, then it must include privacy and security features such as authentication, access control and authorization; auditable events and tamper resistance; automatic log-off; emergency access; and end-user device encryption.

Data Segmentation

Another component of the proposed certification rule aimed at bolstering privacy and security of sensitive health data, such as mental health or substance abuse information, is for health IT modules to begin applying data segmentation for privacy (DS4P) data tagging.

The proposal would require a software module to be able to send and receive documents containing sensitive data according to regulations of the Federal Confidentiality of Alcohol and Drug Abuse Patient Records part two, or "42 CFR part 2" regulations. The proposed rule acknowledges that the DS4P technology is still evolving.

"The application of the DS4P standard at the document level is an initial step. We understand and acknowledge additional challenges surrounding the prevalence of unstructured data, sensitive images and potential issues around use of sensitive health information. ... The adoption of document level data segmentation for structured documents will not solve these issues, but will help move technology in the direction where these issues can be addressed."

Fine Print

Some security experts say that the proposals overall by HHS don't initially look like big changes, until healthcare entities begin digging into the provisions.

"At first pass, the security requirements are fairly straight forward, what most prudent organizations are already doing," notes Charles Christian, new chairman of the College of Healthcare Information Management Executives, an association of CIOs, in an statement to ISMG. "The devil is always in the details," adds Christian, who is also CIO at 370-bed St. Francis Hospital in Columbus, Ga.


About the Author

Marianne Kolbasuk McGee

Marianne Kolbasuk McGee

Executive Editor, HealthcareInfoSecurity

McGee is executive editor of Information Security Media Group's HealthcareInfoSecurity.com media site. She has about 30 years of IT journalism experience, with a focus on healthcare information technology issues for more than 15 years. Before joining ISMG in 2012, she was a reporter at InformationWeek magazine and news site, and played a lead role in the launch of InformationWeek's healthcare IT media site.




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.