Can You Achieve Meaningful Use Stage 2 Using Your Current Methods? | Joe Bormel | Healthcare Blogs Skip to content Skip to navigation

Want to Fail? Approach Stage 2 Like Stage 1 (Part 1)

September 18, 2012
| Reprints
Can You Achieve Meaningful Use Stage 2 Using Your Current Methods?

As we’re all well-aware, CMS released the long-awaited MU Stage 2 Final Rule in August.  Many HCIT pundits reviewed it as challenging but achievable.  Most noted there will be a few new system capabilities needed to attain the higher performance required when combined with the existing capabilities from Stage 1. 


Implied in the notion of “achievable” is “scalable.”  We need the ability to scale up what we did to achieve MU Stage 1.  And interesting, but sometimes not intuitively obvious, is the impact of organizational governance on scalability. 


The need to meet the requirements set forth in the various stages of Meaningful Use is and will continue to be ubiquitous.  Healthcare leaders, like it or not, recognized this fact, and most began mobilizing their organizations to ensure they could attest to Stage 1.  The proof lies in the methodologies we’re using today for the things we do with, for instance, problem lists, CPOE, and quality measures.       


However, not all methods are scalable.  So as we move forward to MU Stage 2, I’d like to make some recommendations for those of you who are resilient, but who really don’t like surprises.


Using the graph above, let’s start by quickly reviewing the issue of methods and scalability.


In computer science, figuring out the prime numbers up to some scale such as 64 or 512 is a classic task.  We’ll use this to learn how to plan and manage the organizational changes required to achieve Stage 2, and the associated attestation performance levels.





Shortly after posting the above piece on scalability, I enjoyed reading Jerome Carter's blog, . He points out the Clinician's work of results management and specifically, what to do about abnormal results. It's a great read, and there are references to both Approaches 1 and 2 in my post.

How far should we go with inbox automation tools and how fast? As Dr Sarah Corley (Chair of the EHRA Patient Safety Workgroup, correctly points out, all of the vendors support methods such as problem-specific templates, report displays and flowsheets, situational order-sets, etc that enable faster and more process reliability in handling abnormal results. Does patient safety and usability demand more uniform practices (detection, training, monitoring) use of these capabilities, perhaps in Stage 3?

Joe, this is a great post! Scalability is indeed a tricky problem. As you point out, solutions that work well at one level of activity may not work with increasing workloads. My interests center on how software architecture and design affect issues such as scalability, usability, productivity, and safety. Specifically, I am trying to understand how to tie EHR software architecture and design more directly to real-world care delivery issues such as results management, workflow support, and clinical decision support. There is much to be learned by all involved as MU moves forward, and I am eager to see how what is learned drives innovation and product design. Again, great post.

BTW, Joe, thanks for your comment on the American EHR Partners post.

Jerome Carter, MD
EHR Science blog –
"Explorations in the Design and Implementation of Clinical Systems"

It was a treat to find your thought work and discussion on results management. We've been studying and enhancing our Provider Inbox functionality over the last year. As a result, I've done a lot of reading, attended many internal client planning meetings, and participated in the elaboration and prioritization of literally dozens of recommendations.

If I've learned anything, it's that there is a wide variety of options out there in terms, of what providers want and need. For example, some insist that auto-purging results after some period of time is essential. Others say you should never auto-purge results. Some say this needs to be a health system policy decision that applies to all. This is only one of many contentious decisions around inbox that highlights the drama.

Others want to author and maintain inbox rules like they do in Outlook, with a system of sub-folders and contextually-driven workflow, custom to the individual provider. They are likely both engineers as well as clinicians!

Beyond all that tactical stuff, I've also begun exploring "What Ever Happened To Accountability? When leaders don’t fire underperforming executives, they send a bad message to the whole organization. Case in point: the U.S. Army" by Thomas E. Ricks. This is an article in the current HBR. An implication for Results Management is, what is a reasonable expectation on providers in terms of volume and cognitive load? Do we have a duty to monitor provider fatigue? And, more broadly, how many clinical quality measures and other taxing requirements does it take to break a health system?

The above questions were each brought to me as ponder points, raised by Stage 2. I, for one, am glad we're having these dialogues. There are clearly no easy answers!

Dr. Bormel,
This post is insightful! My hospital is just now starting to "scratch the surface" of Stage 2. You have provided me with information I am taking to our HCIT descision making and evaluation team at next week's meeting.

I would like to have your thoughts as to how you see the responsibilities for Stage 2, and other complex subsequent stages, divided up among a hospital's various departments. Have you given any thought to which will carry the heaviest burdens, and in what sequence these departments should be submitting their recommendations?

From my point-of-view, in order to be be both efficent and effective, from this point forward we will need to be very organized and more tightly structured to succeed. Do you agree?

Doc Benjamin

Thanks for your kind and insightful observations. I do agree that organization and governance are central to managing through Stage 2.

Historically, the departments and specifically Pharmacy often bore the brunt of the design, build and testing of clinical information system projects. There were great reasons for that. We've entered an era where that doesn't work as well as an Agile with Scrum approach, where component elements are tested and rolled out on a rolling basis. I'm talking about advancing clinical functionality for service lines (Cardiology, OB, ED), not implementing new releases of software.

Because of the massive degree of co-dependence in meaningful use objectives, sequencing and harmonizing becomes prominent. The design, build and test of system enhancements requires coordination above the department level. This is almost always extremely difficult relationship, planning and leadership work.