Readers Write: Analytics Optimization: Doing What It Takes

Analytics Optimization: Doing What It Takes
By Lee Milligan, MD

Lee MIlligan, MD is VP/CIO of Asante of Medford, OR and a director of the governing boards of Asante, Oregon ACO, and Propel Health.

I recently surveyed a number of large and medium-sized integrated healthcare institutions in the Pacific Northwest with a focus on the analytics experience. I sought to answer one question: how do the operational and clinical end users perceive their experience of requesting and receiving information? I talked to CIOs, CMIOs, and directors of analytics.

Although the conversations touched on many concerns, three themes emerged that I now call the “Three Reporting D’s” – delay, distrust, and dissatisfaction. End users are just not getting what they need to do their jobs on time. Despite the adoption of sparkly analytics software products, the problems continue to fester.

We experienced a similar disconnect a few years back, and have, over the course of three years, re-architected our approach. Although we still have room for improvement, I’d like to share a bit about what we learned and how this reboot has led to a more satisfying end user experience.

We started the internal investigation by looking at the entire end-to-end experience from the customer’s perspective. Using a lean management technique known as value stream mapping, we drew out on a white board all of the steps that a typical end user would experience as they requested information from our analytics team. Surprisingly, this took quite a while and we ran out of white board space.

This was telling. Why does this process include so many steps? It reminded me of the 1990s Windows installations where the customer would continuously have to click “next” to move the process forward.

One of the keys of this lean technique is to identify the steps in the process that add value and eliminate the rest. We got stuck on the definition of value. What is valuable to the end user? When we honestly answered that question, a surprising number of steps were removed.

Next we asked, what’s missing? That question required us to walk in the shoes of our customer, like a doctor’s seeing the world through the patient’s lens. I also had the advantage of two additional frames of reference:

• I personally requested that a report be built for me from scratch using the prior method, and
• I asked the BI developers to CC me on all email communications between them and the customer.

Both experiences unearthed missing fragments, which ultimately informed our strategic BI architecture. Most of the changes we instituted were budget-neutral, process-related improvements. However, I would like to highlight two changes which cost a few bucks that delivered tremendous ROI.

Customer/BI Developer Partnership and Communication

We recognized fairly quickly that these relationships were in need of optimization. First, the customer rarely knows what they want. That’s not to say they can’t make a request. However, they frequently request what they don’t ultimately need or want.

Second, I discovered through those CC’d emails that they are requesting many additional discrete elements, far beyond the initial scope, usually as they learned more about what the information looks like. In other words, they didn’t fully understand what they were looking for and we were unprepared to fully discover with them what they ultimately need.

To plug that hole, we instituted a new position within our team, the clinical data analyst. Something akin to the business analyst in the corporate world, this role is responsible for working directly with the end user to accomplish two goals: (a) to fully understand the ask to detail this in the agreed-upon scope, and (b) to commit the requestor to actively participate in the data development process.

Also, our team of BI developers desired guidance on how they should communicate with our end users. We had naively taken that piece for granted. They requested clear direction on how to frame conversations, how to respond to specific requests that are outside of agreed-upon scope, and how to ask better questions of the initial ask.

Teaching/Training

We surveyed our customers and discovered something astonishing. Many are not using the reports and data that we have delivered. When pressed, it became clear that many did not fully understand the information produced and even fewer understood how to incorporate this data into their workflow to better inform operational decision-making.

We developed a new role as a principal trainer within ITS-Analytics. The goals of this role are twofold: (a) to work directly with end users to assure a full and practical understanding of the delivered information (i.e., how to read the report, what the symbols mean, how to navigate an analytics dashboard, etc.), and (b) to lead our self-service domain. The self-service aspect has significant potential to meet customer’s needs in a rapid, nimble fashion.

Putting it all together, our take-home lesson has been the criticality of performing regular internal assessments in order to verify that we are meeting our customer’s needs—from their point of view—objectively and subjectively.