Small but significant changes in meaningful use rules simplify compliance

The Department of Health and Human Services (HHS) today announced the release of final versions of its rule on meaningful use and its electronic health record (EHR) incentive program and associated health IT standards and certification criteria for EHR technology. The two final rules, slated for publication in the Federal Register on July 28, 2010 and available from the Office of the Federal Register’s Public Inspection Desk in the interim, collectively reflect a decision to ease the requirements by which eligible health care providers and professionals will be able to qualify for financial incentives to adopt EHR technology. With respect to security, there is one security-related measure contained in the final version of the rules, but changes in the language of this measure and additional changes in security-related certification criteria and associated standards should make it easier for health care entities to comply with security requirements under meaningful use.

The basic security requirement under meaningful use is the same now as it was when the draft rules were issued last December in a Notice of Proposed Rulemaking:  under meaningful use health care entities are required to conduct a risk analysis, following the same requirement that exists in the HIPAA Security Rule (codified at 45 CFR 164.308(a)(1)). In the last six months, in anticipation of Stage 1 meaningful use rules going into effect for 2011 and in advance of more proactive HIPAA security audits planned by the HHS Office for Civil Rights, HHS has provided more detailed guidance on what expectations OCR will have for health care entities with respect to their risk analyses. The core requirement for entities to conduct or review a risk analysis remains a required meaningful use measure in the final rule, but the language of the requirement has been changed so that for the purposes of meaningful use, the risk analysis must address only the certified EHR technology used by the entity. This is a significant reduction in scope compared to the previous wording of the requirement, which essentially incorporated the HIPAA requirement by reference, and therefore applied to all electronic personal health information held by the entity. The meaningful use language was further amended to clarify the meaning of “implement security updates as necessary,” so that the final requirement now reads, “Conduct or review a security risk analysis per 45 CFR 164.308(a)(1) of the certified EHR technology, and implement security updates and correct identified security deficiencies as part of its risk management process.” (emphasis added to highlight revisions)

The change in language for the security meaningful use measure should greatly facilitate health care entities’ ability to comply with the requirement, regardless of their current level of proficiency (or HIPAA compliance) in performing risk analyses. The revision not only puts a clear boundary around the systems or technologies that must be addressed in such a risk analysis, but in doing so opens up an opportunity for EHR technology vendors to provide product-specific risk information to the entities that acquire their products. Every entity will still need to consider the use of EHR technology as implemented in their own environment (or as accessed, if they use hosted EHR services), but many of the technology-related risks associated with a given EHR product should be able to be identified in advance.

In addition to the security measure in the meaningful use rules, there are several security-related certification criteria and associated standards that must be followed by EHR vendors seeking certification of their products under meaningful use. Several revisions were made to the certification criteria and standards, and taken collectively these changes should also make it easier for EHR technologies to become certified. These changes include minor re-wording in the language for audit, integrity, and encryption criteria (there were no changes at all to access control, emergency access, and automatic log-off); and the removal of cross-network authentication as a criterion, as well as the corresponding standard for cross-enterprise authentication. ONC also kept the same language on accounting of disclosures, but chose to make this criterion optional for Stage 1, pending further consideration of the issue. Many health care entities have complained that the accounting of disclosures requirement is too burdensome, especially given the changes in the requirement stemming from provisions in the HITECH Act, which removed the exception for treatment, payment, and health care operations. ONC issued a request for information in May on accounting of disclosures, and it seems apparent that it preferred to wait and provide a more thorough review of the requirement and its potential impact, rather than mandating it now under meaningful use.

Lastly, a look at the final privacy and security standards recommended for adoption under meaningful use finds that almost all references to specific technologies have been removed, even those that were cited as examples. The only explicit standards mentioned are the National Institute of Standards and Technology’s FIPS 140-2 for encryption and FIPS 180-3 for secure hashing algorithms, with SHA-1 cited as a minimum strength reference. In general, it seems health IT vendors and EHR implementers will be given a lot of flexibility in meeting technical standards for meaningful use, as seen in the revised standard for encryption and decryption of electronic health information for exchange: “Any encrypted and integrity protected link.”

2 Comments on “Small but significant changes in meaningful use rules simplify compliance

  1. Steve – great post and very informative. I was very disappointed to see the reduction of scope to just the certified EHR. With the change of the wording regarding the Risk Assessment, is the EHR AND the underlying database (SQL or Oracle) AND the actual Server (Windows or Unix) all within the scope of the Risk Assessment? The wording change doesn’t limit the scope to just the EHR software does it? In your opinion does anything else need to be considered as part of this Risk Assessment.

  2. While I wouldn’t put it past someone to try to limit the scope to just the EHR application or modules, and not the supporting systems, most risk analysis approaches for IT systems don’t separate out the components, especially for commercially packaged software like many of the likely-to-be certified EHR systems. From a slightly broader (not just meaningful use) perspective, since the risk analysis language refers to the requirement in the HIPAA Security Rule, and the vast majority of providers or others seeking incentives are HIPAA-covered entities, it makes a lot of sense to just go with the HIPAA language for risk analysis. Specifically, the risk analysis requirement under HIPAA applies to electronic PHI held by the covered entity (45 CFR 164.308(a)(1)(ii)(A)), so this would logically include the database where the information is stored and any systems or applications that access or process that information.