We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.


Targeting Healthcare Business Intelligence Applications

Originally published June 24, 2008

Business intelligence projects can stall for a number of reasons including lack of sponsorship, lack of communication, lack of focus and lack of direction, just to name a few. The results of such a stall are fairly obvious – loss of return on investment, loss of reputation, loss of employment. The meter keeps running. This is true of projects of all types in all industries, but healthcare business intelligence application development projects seem particularly susceptible to these risks. These types of applications are often more complex than applications in other industries and of other types. The business and clinical processes in healthcare are complex, the data is complex, the goals are complex, and even the organizational structures in which they are built are complex.

Getting these projects back on track requires using various techniques to engage executive sponsors, users, managers, subject matter experts, developers and so forth. Out of desperation, some project managers and leaders resort to attempting brute force methods like memos from on high, complicated tracking schemes and outright badgering of team members. In addition, some of these managers and leaders are stuck in a mode of trying to use one method that has worked in the past someplace else, with a different type of team and a different type of application. Trouble is imminent.

Techniques that work to effectively target healthcare business intelligence applications and the projects undertaken to build them usually fall into one of four types of approaches: faster, slower, higher or lower. Think of a plus sign with the horizontal line as faster and slower, and the vertical line being higher and lower. Some of the following stories about people using these techniques come from friends and colleagues, others are techniques I have used myself. They all have one goal in mind, which is to get the project back on track and get the application into the hands of the decision-makers who can do some good with it.

Faster

A healthcare payer organization was implementing a customer service analytics system. The project came to a standstill because the subject matter experts and developers were constantly fighting over minor differences of opinion on data definitions, modeling techniques, project methodologies, and differing approaches to moving and storing data. The team had a weekly meeting to report progress and next steps, and to cooperate on removing obstacles to progress. Each meeting turned into an argument with each side claiming they were right. It seemed as if the entire team looked forward to the fight without any regard to the fact that the project was going nowhere, and the application was accumulating costs without any hope of getting any payback.

What the project manager did over the next few meetings was bring in a group of users at the beginning of each meeting to tell how they are doing the process currently and what they envisioned the new application would do for them. Sure, it was a bit emotionally manipulative, but this team of very intelligent people deserved it. They had forgotten their purpose – to deliver an application to the business. All of a sudden, the fights stopped and the team started working together to get the project moving again. They saw the importance of what they were doing in real, human terms.

Sometimes, the project needs to move faster, as in the previous example. At other times, the product needs to be developed faster. By this, I mean more types of information need to be delivered at a faster pace to keep up with the business.

At a technology conference, I had lunch with a data warehouse manager who worked for a medium-sized hospital system in rural Wisconsin. He related a story of how they got the product development cycle moving after the first phase of their business intelligence implementation. This first phase had just one metric, which was patient census by day, by department, by campus, etc. Because it only had one metric, the users in the hospitals could not see the full value of the application and perceived it as a burden to log into the system to just get one number. It seemed highly unlikely that the system would evolve the way it should or could.

What this manager did was to put screen shots of the reports on tag board, and hang them on the bulletin boards in the hospital break rooms. He put markers next to them and primed the pump with one sentence starter: “With this patient census report I could...” Each week, his business analysts would go around to the break rooms and gather the feedback. In three weeks, they had gathered over one hundred ideas for how to use this one metric. Plus, the people had written what types of data (e.g., staffing data, equipment data, supplies data, quality measures, service measures, etc.) they needed to add to the census data to make it even more valuable. The manager now knew what the evolution of the data warehouse application should look like and, more importantly, why.

Slower

Getting a stalled project or a stalled application to move faster seems like the obvious approach. But sometimes the project is moving too fast for the development team to handle, or the application is rolling out at too fast a clip for the business to absorb. Consider these stories, first with a project that needed a slower pace and second with an application that was overrunning the business it was intended to serve.

One of the projects I was helping to assess a few years ago was a clinical supply chain business intelligence application with potential to align clinical services (e.g., surgeries, hospital stays, clinic visits, etc.) with the various types of resources used (e.g., labor, equipment charges, supplies, ancillary services). The sheer magnitude of this project resulted in a large number of scope items. Each time the project lead would bring up a topic, everybody was convinced that it should be included in the first phase of the project. We were stalled because everything was too important to prioritize lower than number one.

This solution just came to me – and it may sound corny, but it worked. I went up to the whiteboard and drew a rectangle and a circle. The rectangle was a dock. The circle was an island. I said, first of all, what is not part of the solution? As we talked, I got a few answers, which I marked down in the “water.” Then I said, now let’s pretend that this project is not the only boat to leave the dock. There will be other boats. It turned out this got us over a real barrier. This group of sponsors had been conditioned to think that if they don’t make it on the first boat, they will never make it. They wanted to know how I could “guarantee” there would be other boats. I told them it was up to them to keep sending boats to the island until the cargo wasn’t worth the price of the trip. In short order, we had our trips planned in priority order.

The boat trip idea worked to slow down the ideas to a pace where we could get started on the project. But how do you slow down the flood of business functions to a level where the business can actually use the application?

I was on a project to build out a retail healthcare application that gave administrators the ability to look at patient volumes, revenues, costs, purchases, inventories and patient and provider populations across time, locations, specialties, etc. Because the data warehouse team had built a clean, solid basis for the application, we were able to roll out new releases at a rapid pace. We thought we were doing a good thing by delivering something new every two months. In the end, we delivered four major phases and sixteen point releases in a two-year span. But in doing so, we had outpaced the administrators’ ability to understand each function and to incorporate it into their normal workday. They told me they liked the stuff we were putting out, but it was a little overwhelming.

We needed to slow things down. The approach I used was to get out and give tours of the application. I visited two dozen clinic managers in their offices with the application up on their screens. I had them invite a few of their key staff members to watch over my shoulder as I clicked through some of the reports. In all, I gave tours to roughly four hundred people this way. In each case, I started the tour, but the clinic manager or one of the staff members eventually ended up with the mouse in their hands. By seeing the reports in familiar territory (not in a training room) and with somebody else driving, they were able to find a place to start. The Cheshire cat told Alice that if she did not know where she was going, then she could start anywhere on the path. This group of administrators and clinic staff now had a place to start.

Higher

There are times when the project is moving too slowly, or the product is evolving too slowly. And there are other times when the project and/or the product development is moving quickly. But sometimes, the problem is not the pace, but the level.

A health insurance company I worked at recently was installing a rules engine to appropriately match plans to the needs of its customers. The data was coming from seven different sources, and there were several transformation processes needed to consolidate and move data from these sources to the ultimate target – the rules engine application. The project’s test lead accepted another job halfway through development, and we had a new test lead from an entirely different area of the business fill the role. This new person was immediately deluged with demands from the team to pinpoint exactly what they should test and why. Then, every time she tried to answer their questions, they told her it would not work and that her answer was inconsistent with another answer she gave to somebody else on the team.

About a week into this, she decided to get everything out on the table. It reminded me of the process I use at home when my wife is in class and I have to make supper for our three teenage boys. I call this process fridge buffet. All I do is open the refrigerator and start putting leftovers on the table. Each of the boys takes what he wants, combines it, trades it and warms it up. And I clean out the refrigerator with little or no effort. I don’t get much to eat myself, but that is a small price to pay.

This test lead did the same thing, except she took all of the questions and converted them into elements of a test strategy. She did this openly on a frequent video conference call so each of the questioners could work with other questioners to develop a solution that was logical to him/herself and to the group, and which fit best practices in business intelligence application testing and data validation. Then, each person took what he/she needed and had the test lead record their tasks on her work plan.

While the collaborative approach works well to bring project activities up to a higher level, raising the level of the business intelligence product sometimes requires more education and selling.

At one integrated delivery network (4 hospitals, 800 beds, 45 family and/or specialty clinics, and a health plan), the executives could not see how investing in “reporting software” could be valuable to anybody but accounting analysts or clerical staff. One respected physician executive took a missionary approach to bring the perception of the proposed application up a few levels. He drew two simple pictures and carried them to every meeting to champion his cause.

One picture was a canister with arrows pointing into it. The canister was the business intelligence application, which was a patient registry repository. The arrows were types of data such as admission/discharges/transfers, clinic visits, lab orders and results, general ledger, claims, etc. The other picture was the same canister with arrows pointing out. These arrows were labeled patient population analysis, claims and reimbursement analysis, quality accreditation, patient demand prediction, chronic care case management, etc.

With each showing of the pictures, he added more arrows (inbound and outbound) and added more executives to his list of business intelligence champions.

Lower

Sometimes healthcare business applications and the projects to build them need the conversation to move up a level in order to open the checkbooks needed to invest in them. Other times, however, the conversation is going over everybody’s head and needs to be brought down to a simpler level to make it actionable.

During the first phase of the rules-engine project described previously, the project manager and executive sponsor conducted a kickoff meeting to lay out the strategic plan, the scope, the generic roles and responsibilities involved and project timeline. Following the presentation, which was very thorough but at an executive level, the group was asked for questions they might have. The whole group sat there as if stunned. One of the business process analysts in the room asked a killer question: “Does everybody see how their area of expertise links to the scope of this project?” It was as if everybody now had permission to speak up in order to bring the conversation down a level, and several did. Everybody now could see why they were involved right from the start.

Not only do the projects to build healthcare business applications need to be targeted to the right level, but the application itself sometimes needs an adjustment in order to make it understandable and to get it used.

At one physician practice organization, the cardiologists, cardiology nurse practitioners, physician assistants and RNs could not see the significance of the quality statistics they were provided. The information was in a form that did not give them a clear idea as to what action to take to improve the numbers. In addition, they might each see over fifty patients today and did not have time to translate the percentages into how they could influence the quality measures. That is, they could not see how the statistics were actionable.

Based on their feedback, the development team added one more drilldown to the reports. This drilldown translated the percentages and patient counts into a list of exactly which patients they needed to contact, for what services and why. In effect, the reports became “orders” in much the same way these MDs, NPs, PAs and RNs might write orders for meds, diet, exercises, therapies and other interventions. This was something these busy people could relate to, and it got the application back on track.

Next Steps

Next time you are leading or participating in a stalled project, or find that your user community is stalled in some way, think of targeting the project or application differently – either faster, slower, higher or lower. There is no one approach to doing this. As a matter of fact, there are more than these four approaches. But this may be a good place for you to begin.

Thanks for reading!

  • Scott WanlessScott Wanless

    Scott is the Healthcare Analytics Director for Cipe Consulting Group. He has more than 30 years of experience in business intelligence strategic planning, analytics application development and business analysis across numerous industries including hospitals, physician groups, healthcare payers, laboratory research, insurance, lending, manufacturing, retail and state government. Scott can be reached at scott.wanless@cipeconsulting.com.

    Editor's note: More healthcare articles, resources, news and events are available in the BeyeNETWORK's Healthcare Channel featuring Scott Wanless and Laura Madsen.

Recent articles by Scott Wanless

 

Comments

Want to post a comment? Login or become a member today!

Be the first to comment!