The Good, the Bad and the Ugly of Meaningful Use Stage 3: Objective 5 – Patient Electronic Access to Health Information

Half-way home now, we’ll address Objective 5 today, and one of the more interesting proposed objectives, Patient Electronic Access to Health Information. This is an extension of the similar Stage 2 measures, and this is the first objective where CMS begins to reference the availability of an API-driven app as an alternative way to meet MU objectives. (We’ll look at APIs – “Application Programming Interfaces” – as part of “The Ugly” in this post, and what the implications may be of this technology for MU in a future blog post).

As a reminder, the complete Stage 3 proposed rule can be downloaded here.

Patient Electronic Access to Health Information (Page 94)

Objective Specifics:

• 2 Measures; Both must be met
  • Provide access to view/download/transmit a patient’s health information within 24 hrs of availability to the provider –or– the patient is provided access to an ONC-certified API within 24 hours of information being available to the provider
  • Patient-specific educational resources are provided to patients seen by the EP (or discharged from the EH/CAH) during the EHR reporting period
• Thresholds: 80% measure 1 (view/download/transmit); 35% measure 2 (educational resources)

Initial Thoughts:

• This objective is a consolidation of the two similar metrics from Stage 2: “Patient Electronic Access” and “Patient-Specific Education Resources” (both now with higher thresholds for Stage 3).

The Good:

• These are again familiar measures, and ones that successful Stage 2 attestors should have little difficulty meeting.
• Exclusions are available for EPs with no office visits, or limited broadband availability.
• For this objective, providers need only “provide access” – the patient is not required to take action in order for the provider to meet this metric (but the provider must inform patients of the availability of this information, and provide sufficient guidance so patients could leverage this access). This contrasts from Stage 2, where patients needed to “take action” to view, download or transmit their health information –but– this “action” component is now part of the next objective for Stage 3 (Coordination of Care through Patient Engagement)!
• Providers may choose to withhold information if it would do harm, or if release is prohibited by law.

The Bad:

• Stage 3 thresholds have increased from Stage 2: (50%) to 80% for for View-Download-Transmit, and (10%) to 35% for Provision of Educational Resources.
• The time threshold is now 24 hours after the information is available (vs. 4 days in Stage 2)
• Both measures must be satisfied in order to meet MU
• Paper-based communication and provision of patient education or clinical summaries is no longer acceptable.

The Ugly:

• This metric now includes an API (Application Programming Interface) option. This is one of the more vague additions to the MU standards (and one which we will comment on in a future blog post) but it seems that CMS is viewing the API as “the answer” to interoperability.

While it does not provide specifics as to how the API option will be defined or measured, CMS clearly seems to feel this is the wave of the future, and is heavily promoting API use for healthcare technology.

Given that there are 2-3 years before Stage 3 MU comes into play, APIs may mature during this time. However for now, we would recommend providers plan on providing electronic access using more traditional methods, especially since any Stage 2 EPs and hospitals would likely already have a patient portal in place to help with achieving these measures.

Curiously CMS even specifically notes that by enabling APIs that providers would no longer have to implement Patient Portals, nor purchase a mechanism to provide a way to securely download and transmit information, as theoretically APIs would be able to achieve this-ignoring the fact that successful Stage 2 providers have already had to implement View-Download-Transmit, likely by already using (and paying for and implementing) a patient portal!

• CMS is considering multiple versions of whether the two sub-measures are required, and are seeking public comment. Curiously the options presented all include an API option (again, given a bit of insight into how much emphasis CMS is placing on APIs). This is a measure to watch, as the requirements may change with the final rule.
• As previously mentioned, this objective represents a consolidation of the two similar metrics from Stage 2: “Patient Electronic Access” and “Patient-Specific Education Resources”.

What is interesting is that while CMS has touted the “simplification” of Stage 3 and its focus on reducing the number of MU objectives, there really is no net simplification here! In Stage 2 there were two unique objectives. Now in Stage 3 there is one objective, but with two sub-measures, both of which must be met. So there are the same two “hurdles” for EPs and hospitals to achieve–CMS has simply restructured how they are labeled for Stage 3.

What’s next?

Well, certainly watching the evolution of this metric! But as far as our blog series is concerned, up next is Objective 6–Coordination of Care through Patient Engagement.

Thanks for reading, and see you next time!