TagsPlanning the Approach
Every year there are business metaphors that get overused and underap preciated. One I hear very often is the “30,000‐foot view,” sometimes that of the data, as in getting a high‐level understanding of what the data is indicating and sometimes it’s about the project itself. Then, if it’s a re ally good analogy, it’s followed up with “We need to make sure we have plenty of runway.” This got me to thinking, as I sit here in this airplane, what does it mean to be at 30,000 feet? What is just enough runway?
A number of factors influence a successful landing. Some of them are flexible, others are not. Let’s consider briefly the factors: the air craft, the crew, the weather, the weight of the aircraft, and the destina tion. We can manipulate all of those factors to some degree, but once you’re in flight, you cannot change the crew or the aircraft. You can fly around weather, but that will change your destination (potentially), and you can drop weight if absolutely necessary but only in the form of fuel, which of course has other serious ramifications. Eventually the aircraft has to land, and the speed, distance, and altitude are the key performance indicators that can be aligned to best practices. What you will notice is that depending on where you are in your journey, your key performance indicators change. It could be said, in air travel and in data warehousing, that any landing you walk away from is a good one.
For our purposes, the aircraft is the products that you use, both back‐end systems and front‐end BI products. The crew is represented by your project staff. The weight of the aircraft is represented by your data; the weather is your broader organization and external influences like the federal government. Finally, the destination is the vision you have for data in your organization. My point to this rather elabo rate analogy is that if you can reduce the unknowns, identify alternatives, streamline the standards, and evaluate the activities (RISE), you can close the gap on these activities and improve the innovation cycle in your organization.
RISE
Creating a methodology that’s specific to healthcare’s adaption to data may seem daunting. It wasn’t the initial goal of this book. But the more research I did and the more conversations I had, the more I realized that there isn’t a good framework for this work. Sure, there are maturity cycles and development cycles, but there isn’t a frame work that helps us iterate through each of those cycles successfully. In other words, we had no way of repeatedly performing the work with enough consistency to ensure results. The RISE methodology allows us to do that, by focusing on the things that impede rapid innovation in healthcare.
Reduce the Unknowns
One of the most significant issues facing healthcare today is the dispa rate data. Frankly, it’s all over the board. Of course, standards are an issue, but even without the constraints of standards, most hospitals and healthcare organizations have such a broad variety of data and ranging quality of the data that just getting a standard file format out the door seems like a monumental effort. Much of the daily work that I do is talking with healthcare organizations about how they can manage this disparate, random, and challenging asset. Forcing standardization isn’t an option, so what we have to do is remove the unknowns.
When I was working on my master’s degree, I wrote a thesis researching the causal effect between depression and chronic pain. I used a little‐known regression test called “Two‐Stage Least Squares.” In lay terms, I was looking to control for intervening variables to de termine if there was one factor that was more statistically responsible for the causation. I spent hours in the computer lab running test after test. The intent of the effort was to remove the unknowns. In the first step of the RISE model we have to do the same thing, but that requires us to discuss the problem in a way that we likely haven’t discussed it before. When I was working on my thesis, I had the advantage of the data mining to tell me what variables consistently intervened. In most cases you won’t have that data, but what you will have is the knowl edge of your organization and previous attempts at similar efforts. You can discuss these and document them as much as possible, yet know that the whole point of RISE and specifically reducing the unknowns is that you have to revisit it over time. As our programs move along, our variables change.
Identify the Alternatives
Closing the gap won’t be easy. The traditional method of data ware housing is probably too slow; we have to accelerate ahead of many other industries in an attempt to save ourselves. That means that we have to become very good at identifying alternatives quickly, and fail early and often. We may find that a pilot program associated with big data doesn’t work the way we thought but it points out another alter native that we hadn’t considered before. Despite the name, we don’t just want to identify the alternatives; we actually want to test to see if they work. Don’t do it on the full scale, but smaller pilots and proofs of concepts will allow us to iterate quickly through new processes and products to determine which ones will be the most beneficial to close the innovation gap.
Streamline the Standards
The focus of this part of the methodology is to ensure that standards are identified and adopted into the integrated data warehouse. This is important because that is where your average business user will ac cess the data and reports associated with your organization. The stan dards, therefore, must be part of the standard governance process and adapted by the organization in alignment with the industry. There are so many standards that can be applied; it’s important to recognize that the assessment of standards is an effort in and of itself. The governance group is the most logical place for this to happen, but just like the rest of the RISE model, it must do so in an iterative and timely manner. These standards could also impact the alternatives that you work to identify. Since there may be a number of standards that you can adopt, identifying the key standards and running a pilot or proof of concept as part of the alternative analysis is prudent.
Evaluate the Activities
This final step in the model is the key to its success. The iterative, agile nature of RISE requires the adapter to be willing and able to evaluate all aspects of the program and make adjustments as needed to ensure success. Every aspect of the program is up for debate, discussion, and adjustment. The most effective way to ensure that you are able to do this is to create, as you begin, a set of success criteria that you will use to evaluate all aspects of the program to ensure that everything you do is aligned to delivering value, quality, and success. Anything else should be reconsidered or removed.