9 Ways Your Outcomes Improvement Program Could Be Delayed

Outcomes improvement efforts in healthcare represent a significant commitment in terms of financial, operational, and human resources. So the return on investment should be significant, as well, and that’s only possible when those efforts are scalable and sustainable. To achieve these measures of success, healthcare organizations must identify potential delays and solutions to their outcomes improvement programs ahead of time. This works by delineating the phases of development in an outcomes improvement program, the milestones and attributes inherent in each one, and the associated sets of delays or impediments that have the potential to limit success.

Three Phases that Affect Outcomes Improvement

A vital first step in removing barriers to outcomes improvement is to agree on the scope of the work, which progresses in three phases, whether the health system works with Health Catalyst or not. Once the outcomes improvement platform is in place (phase 1), then the organization can focus on the potential delays around improvements, whether operational, clinical, or financial (phase 2). Finally, after moving into a steady state, the organization can hold the gains achieved (phase 3). Phase 1 happens once at the beginning of the engagement; phase 2 is iterative, and phase 3 is ongoing over the steady state.

9 Potential Delays of Effective Outcomes Improvement

Let’s examine the nine potential delays and impediments of these three phases of outcomes improvement in detail.

Phase One: Infrastructure, Platform, Data Integration

1. Hardware and Software Acquisition Delays

Hardware and software acquisitions can contribute quite a bit to delays. Preparatory meetings identify whether hardware and software should be hosted by Health Catalyst or on-premise (at the healthcare facility’s site). What is the scope of the work? How many sources are involved for pulling in data? Is the organization looking for at-risk solutions or more traditional clinical quality improvement solutions? All of these inform what the hardware/software acquisition looks like, as well as the timeline.

If the platform is hosted, the scope of the work is used to inform the hardware sizing in the hosting environment. This is easier and faster and Health Catalyst has a good process for this. When the healthcare organization procures the hardware for on-premise work, the scope of the program becomes more complex. Health Catalyst can submit a recommendation for a hardware configuration. It may not correlate with what the health system’s current hardware vendor supplies, so the organization needs to translate what we’ve recommended in order to fit its needs. Depending on the level of communication and willingness to collaborate, this achieves varying levels of success, but always introduces a delay into the health system’s ability to improve outcomes. In the end, the health system may still choose to go with its own configuration regardless of our recommendations.

Hosting is both a hardware and software issue. Of the available hosting solutions (Figure 1), Health Catalyst provides Software as a Service (SaaS), including the underlying hardware configuration.

We liken this to pizza night, where the solution options are making it at home (On-Premise), take-and-bake (IaaS), having the pizza delivered (PaaS), or dining out (SaaS). The Health Catalyst “dining out” arrangement helps to set expectations among the healthcare systems we work with and removes some of the barriers that can potentially cause delay.

2. Environment Readiness

Once the hardware and software have been acquired, there are two tracks for preparing the environment.

On-Premise: The health system provides everything and then must configure the environment for the right levels of security so users have the right amount of access to do their jobs. Health Catalyst provides a reference guide with this arrangement where we instruct how to configure the software, cover some fundamentals of setup, and warn about potential land mines. It’s the responsibility of the health system to follow the guide. This is where a technical implementation project plan helps. It covers the software/hardware, the environment, and the source systems to make sure all boxes have been checked. We have both hosted and on-premise versions of this checklist.

3. Source System Access

Data source systems potentially cause delays regardless of the environment (hosted or on-premise). There are many variables here that can make Phase One more complex. For example, an integrated delivery system may own the software and the systems that provide the data (e.g., Epic, PeopleSoft, costing). It may be structured with a lot of at-risk contracts, but they are contracts within its own network, so it’s easier to manage the source systems.

Now let’s pivot to a small ACO group of providers that is at risk for 100,000 lives. Its mission is not to reduce clinical variation, but to perform better with at-risk contracts. The ACO collects data from multiple academic medical centers, clinical and research facilities, regional multi-specialty practice groups, and a health information exchange. In addition, it collects claims data from Medicaid, Medicare, and a commercial insurer. All of these inputs require different levels of data governance, negotiating, and navigating the systems at different places within the ACO’s territory. This naturally introduces potential delays with source system access.

The integrated delivery system has source systems that are better contained and controlled. The ACO requires a lot of negotiating and navigating the systems between Health Catalyst and the ACO because we are all just learning them.

Many times, the healthcare organization doesn’t understand how many resources it needs to bring to the table. This is because of incomplete communication by Health Catalyst or higher expectations of the end user. The consequence is that the health organization is insufficiently staffed for the outcomes improvement program. It might see it only as a technical implementation or as a project that doesn’t really transform its work.

The endgame for healthcare systems is to better serve patients through higher quality, lower costs, and better patient satisfaction. So these projects are more than technical implementations and should always be considered with an eye toward outcomes improvement. Instead of just checking a box, saying a system was installed, and hoping it will be used, an organization needs to recognize the ability of its outcomes improvement efforts to transform care in the new business model that everybody is facing.

It’s vital to set expectations up front and allow both parties to understand the scope of the work. In fact, even though we often refer to this process as a project, it really is a program. A project has start and end dates; a program is ongoing, always funded, and always staffed to meet expectations.

It’s easy to consider the work as being only technical, that everything has been deployed, and to get stuck in Phase One. But Phase Two moves into adoption and utilization of the tools, which contributes to driving change.

5. Lack of Analytic and Technical Skills

The composition of analytic and technical skills in a traditional health system is illustrated in a pyramid that shows the user distribution (Figure 2). The bottom layer consists of passive consumers who have reports pushed to them; the middle layer consists of drillers who get into the dashboard to analyze specific metrics; knowledge workers, those with clinical knowledge and access to tools and data, are at the top of the pyramid. This is the smallest group.

Figure 2: Current state of data literacy (l) and desired future state with increased number of knowledge workers (r)

Knowledge workers need to be better represented, as shown by the hourglass illustration. This is a mindset change where we are moving beyond making information available and actionable, to where we are also acting on that information. This requires grooming an audience to be more data literate. This is not an easy task because change is difficult, painful, and sometimes seen as threat.

6. Data Quality Paralysis

The mindset of so many organizations is that data must be perfect before it can be introduced to physicians. Or two financial reports must reconcile before anyone in finance can see them. There’s an underlying assumption with quality theory that data isn’t perfect and that technical staff—data architects and analysts—will work together with end users and business owners to build more accurate representations. The goal is perfect data, but there is an acknowledgement that data can be imperfect and that it’s not only okay, but probably healthy, in that everyone works together to achieve the quality of data that is acceptable across the board.

We want the health systems we work with to see the warts in the data, work together to clean it up at the source, and have that lead to confidence in the data.

7. Lack of Clinical or Operational Engagement

If the true desire is for adoption and outcomes improvement, then either the clinical process owners or the business owners on the finance side must be present while building the solution. The aphorism is that business or process owners must be present for the takeoffs and not just the crash landings. For example, for the success of an improvement project to reduce sepsis, it’s imperative to have the clinical process owner (physician) who can influence peers and earn consensus on defining problems and solutions (i.e., the definition of sepsis, the 3- and 6-hour bundles). Too often, the healthcare organization acknowledges this, but when it comes time to roll up its sleeves, the physician is nowhere to be found. Whether it’s administrators or clinicians who don’t see value in the program, they don’t come to the table, so when it comes time to launch, nobody wants to use the new process. Fingerprinting, feedback, and input are imperative in this work.

If you don’t have the right people, then great data doesn’t matter much.

In Phase Three, the goal is to have scalable and sustainable outcomes. This means keeping the wins and gains. Typically, we’ll do a project, with a start and an end, and then the healthcare system will turn it over to another group just to keep it moving. But it loses momentum, accountability, traction, and visibility. Our goal is to have a data-driven learning culture where everybody asks questions about the data and we keep what’s important, important.

The Stephen Covey quote, “The main thing is to keep the main thing the main thing” applies here. Too often, goals lack sincerity, like when a hospital claims that sepsis is high in variation and it needs to reduce sepsis mortality by five percent. Then it launches an improvement project and forgets about it. It’s important to keep the main thing the main thing. If sepsis is really that important, keep the team engaged, keep the light shining on it, and maintain accountability and visibility to continually improve that process and not fall back into old habits. This is a common theme, where people can change temporarily, but if improvement isn’t continuously on everybody’s mind, then things will go back to the way they were before.

9. No CEO, No Go

It doesn’t matter how well-intended the organization is or how many frontline staff have been educated about data and believe in using it to solve problems. If the CEO doesn’t care about it and doesn’t set the tone, there’s a good chance the rest of the organization won’t care either.

Figure 3: Trending of EDW users pre- and post-mandate.

Figure 3 shows a chart over a period of time for one healthcare system, where adoption of an enterprise data warehouse (EDW) was barely trending (the green bars from August 2015 to November 2015). At the end of 2015, the CEO issued a systemwide mandate to stop sending reports unless they had been run through the EDW. The next six months show a dramatic increase in utilization, where it doubled from 234 to 467 users.

This is how to create a data-driven culture, but governing requires a fine balance to avoid a punitive environment, create an atmosphere of learning, and allow people to make clinically and financially responsible decisions.

Plan for Setbacks, Expect Success

The thinking around outcomes improvement must transition from “project” to “program.” It is a continuous loop with many iterative components and plenty of opportunities for derailment. As the saying goes, “in for a dime, in for a dollar,” meaning anything worth doing is worth doing right. The health system that jumps in with eyes wide open, with an understanding of all three phases in the loop, and that plans for the potential delays and barriers, will be positioned for success in achieving its goals.