Impact Insights

The Good, the Bad and the Ugly of Meaningful Use Stage 3: Objective 1 – Protect PHI

Dan Golder

Today we’ll tackle the first of the Stage 3 objectives, “Protecting PHI”. Note that as we review each objective we will reference the appropriate page numbers linked to the rule that can be downloaded here.

(Most seem to feel this is an easier format to read and reference than the same version published in the Federal Register here in a three-column format. If you prefer the three-column format please recognize that page number references used here will not match). 

Protecting PHI (Page 60)

Objective Specifics:

  • Single measure
    • Conduct or review a security risk analysis at least once in an EHR reporting period
  • Attestation Only

This objective is an extension of the Stage 2 metric associated with Security Risk Assessment (SRA). However, there is an expansion of the scope of the Stage 2 metric for Stage 3.

For Stage 3, the SRA must address a triad of safeguards:

  • Technical – These are the “traditional” safeguards of IT; typically relying on software & hardware to secure data
  • Administrative – This category represents an extension of the SRA to INCLUDE implementation and documentation of organizational safeguards, such as risk analysis, risk management, training and contingency planning.

While many hospitals and larger organizations often have this kind of infrastructure and process in place, this may be a challenge for smaller practices to implement.

Again these security protocols may be in place for large organizations, but incorporating this level of physical security may pose a significant challenge to the solo practitioner or small group practice.

  • Physical – Also an expansion of the Stage 2 SRA, this now includes not only things like device encryption, but also facility access controls and workstation security.

Initial Thoughts:

  • The SRA can occur prior to the first EHR reporting period, and then the SRA must be reviewed annually (at least once a reporting period) for future years.
  • Simply conducting the SRA is not sufficient–it must be reviewed, and updated as necessary.
  • Then, any identified deficiencies must be corrected as part of the provider’s risk management process.
  • While CMS seems to hint that deficiencies must be corrected before the end of the attestation period, it stops short of stating this explicitly–which is a good thing as correcting all identified deficiencies would be difficult to implement in a single calendar year, especially if new infrastructure or software would be required.
  • However, any identified deficiencies must be addressed by specifically planning for any required remedies as part of the provider’s risk management process–which could potentially be scrutinized as part of any future audits. 

The Good:

  • ONC has provided an “SRA Assessment Tool” to help solo providers / small groups navigate completing an SRA. This is actually a very robust and comprehensive tool, although it is a bit cumbersome to use. It is even available as an iPad app.
  • One caveat here: ONC states that the tool alone is not sufficient (so it must be accompanied by additional documentation such as a risk management plan) and it is not a stand-alone tool. Yet even so, using the ONC-supplied tool would likely be helpful during an audit for most providers, as it’s structure helps ensure that all areas are reviewed and are consistent with ONC expectations. 

The Bad:

  • Technical, Administrative and Physical safeguards may be difficult for small groups to interpret and implement.
  • The SRA standard continues to call out the need for specific language supporting security of data at rest. 

The Ugly:

  • Two security standards (HIPAA and MU’s SRA) still exist, and it would be simpler if there was a single “Security Rule” (see page 64).
  • The expanded scope of the Stage 3 Security Risk Assessment adds complexity to what was already a vague and difficult to navigate Stage 2 measure.
  • This is an Attestation-only measure, so EPs and EHs may not know if they have met the standard until they are audited (and simply “attesting yes” should not be taken lightly, and evidence of a completed SRA has been an ongoing focus of MU Audits).
  • Turning on EHR “audit logs” are “strongly recommended” but this does not seem to be a requirement per se.
    • Still, given the focus on audit logs in the rule’s language, it would be wise for providers to enable this functionality, and to document that it has been in effect for the entire reporting period.

 More Comments:

Will the SRA be an audit risk? Only time will tell, but given the open-endedness of this rule, and the “recommendation” to turn on audit logs, the SRA is likely to represent a future focus for MU auditors.

Providers are encouraged to thoroughly complete a comprehensive SRA each year, and to exhaustively document each of the three required components (technical, administrative and physical) along with all necessary risk and contingency (and other) plans specified in the rule, to protect themselves in the event of a future audit.

One final caveat–EPs must complete a separate SRA for each of their private offices if they access PHI from those locations.

This is especially important if those offices are not part of an institution (e.g., hospital) and the IT systems and infrastructure there are not maintained by the hospital.

In such cases the hospital may be able to provide an SRA covering its systems, but if a provider accesses those systems using any personally owned equipment, then the EP is responsible for conducting an independent SRA covering this equipment.

What’s next?

Next up will be the second objective—ePrescribing.

Thanks for reading, and see you next time!

 

Leave a Reply

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

*