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

September 18, 2012
5 Comments
Can You Achieve Meaningful Use Stage 2 Using Your Current Methods?
Graph3

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.

 

Delivering Prime Numbers at Scale

 

Our graph illustrates the key issue related to achieving MU Stage 2; finding the right methodology by reviewing different approaches.    

 

Approach 1 to finding prime numbers is represented by the blue line, and involves dividing each “candidate number” by the smaller numbers 2, 3, 5, 7, etc., until a number is found that evenly goes into the candidate.  This is the number we need to start solving our sample problem.  If no smaller number is found, the candidate is known to be prime.

 

Alternatively, once the first smaller number factor is found, the candidate can be declared non-prime and the next candidate can be tested through the same process.  The blue line (Approach 1) shows that looking at the first 16,384 numbers takes 5.546 seconds based on the division process.

 

Approach 2, commonly known as Sieve (click the link for the definition and a simulation), represented by the red line, takes only 12 milliseconds to accomplish the same task.  It’s much, much faster.  Scaling up to find all the primes to roughly 65,000 takes 77 seconds by division, but under 50 milliseconds by the Sieve method. 

 

Therefore, as the graph shows, Approach 1 is no longer a sub-second process by the time the scale is eight thousand.  Arguably, this approach is unusable in an interactive manner, because no rational end user can or will use a system that results routinely in multi-second screen flips.  This is referred to as “hitting a wall.”

 

Delivering Meaningful Use at Scale

 

What does all of this have to do with Meaningful Use and the evolution from Stage 1 to Stage 2? 

 

In short, the methods to solve some problems in MU Stage 1, e.g. the number of orders placed through CPOE (the scale) to achieve the required CPOE threshold percentages, may similarly hit a wall as did the division method for finding primes.  If, metaphorically, your organization is using an Approach 1 today, understanding its potential limitation, and having an Approach 2 ready to deploy, will be necessary to achieve some of the several dozen MU objectives and measures required by Stage 2.

 

As is the case when comparing Approach 1 to Approach 2 in our graph, some of the approaches necessary in Stage 2 may bear little resemblance to the methods that were more than sufficient for the scale of MU Stage 1.

 

Workflow at Scale: Changing “How” Work Gets Done, Not “What” Work Gets Done

 

Here are a few recommendations following this logic to get you started looking at process scalability for Meaningful Use.

 

The general approach is to recognize that the time to complete every task is a critical measurement to explicitly focus on, record, display, and look at in the context of scale.  You cannot expect to be successful if you see you’re clearly on a blue path, with essentially a brick wall between your course and the scale of Stage 2.  You’ll need both inside view estimates, as well as outside views, the latter typically labeled “benchmarking” in HCIT.

 

To help you gain further perspective, I’ve extracted the following excerpt from a Wiki post about the findings of psychologists Daniel Kahneman and Amos Tversky:

 

Kahneman and Tversky found that human judgment is generally optimistic due to overconfidence and insufficient consideration of distributional information about outcomes.  Therefore, people tend to underestimate the costs, completion times, and risks of planned actions, whereas they tend to overestimate the benefits of those same actions.  Such error is caused by actors taking an "inside view," where focus is on the constituents of the specific planned action instead of on the actual outcomes of similar ventures that have already been completed (the outside view).

 

If you would like to learn more, I strongly suggest you read a fascinating book by Kahneman, “Thinking, Fast and Slow.”

 

Achieving MU Stage 2 is a complex undertaking that requires, among other things, the proper and efficient application of scalability.  In Part 2 of this blog, we will review a series of specific Stage 2 examples where we’ll need to apply Approach 1 and 2 thinking in order to reach the desired goals.

 

Your comments thus far are welcome.

 

Joseph I. Bormel, MD, MPH

Chief Medical Officer and VP

QuadraMed Corporation

jbormel@quadramed.com   

Comments

Meaningful Use - Stage 2

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

Sprinting, Marathons, Scrumming it and the Departments

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.

Scalability Approaches - Results Management in an MU World

Shortly after posting the above piece on scalability, I enjoyed reading Jerome Carter's blog, http://www.americanehr.com/blog/2012/07/a-new-look-at-results-management . 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, http://www.himssehra.org/ASP/workgroups.asp) 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?

Scalability Approaches

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 – http://www.ehrscience.com
"Explorations in the Design and Implementation of Clinical Systems"

The Accountability Challenge

Jerome,
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!