• WisBusiness

Wednesday, November 17, 2010

Six rookie mistakes in health care business intelligence



By Tom Burzinski
We often make rookie mistakes when we try something new. The first time my wife and I went to Paris, we thought it would be fun to avoid the tourist restaurants and eat where the locals ate. So one Friday night we wondered into a very crowded and very hot out of the way bistro where we attempted to order dinner armed only with a rudimentary French vocabulary. I can still hear the non-English speaking waitress screaming at me as I frantically tried to order a meal by pointing at various words on the incomprehensible menu. To this day I don’t know what the exasperated waitress served me but I’m pretty sure it wasn’t the lamb that I had intended to order.

If you're undertaking your first health care Business Intelligence (BI) project, you may feel similarly overwhelmed as you struggle to turn the massive amounts of data that your health care technology systems are collecting into the information needed to control costs, increase revenue, and improve patient care. Obtaining quality requirements from people across your organization is a critical success factor in the deployment of any health care business intelligence application.

Here are six mistakes I see rookies make when it comes to performing this critical activity, along with some tips that will help you avoid these mistakes so you can maximize the value of your health care information assets.

1. Only asking business and clinical users what data they want instead of asking them how they plan to use the data in their day-to-day work.

Just asking a potential business or clinical BI user to list the data elements that they’ll require on a daily basis is like cataloging tree species and assuming you understand the complex ecosystem of an old growth forest. Data without its surrounding clinical or business context is of little or no use to anyone.

You need to understand what the user does (or will do) with the data, what business processes or clinical workflows it supports, and how, when, where, and why he/she makes decisions to ensure that the new BI system will support the needs of the enterprise. A good technique to help you understand how BI data will be used is to employ “user stories” and interactive process flow charting during your requirements gathering sessions. This way you’ll not only understand the data, but also what value the data brings to the various BI constituents in your organization.

I would definitely try and avoid sending out surveys or questionnaires asking users to list their data needs. Most users (especially clinicians and executives) won’t respond and the users that do respond usually supply incomplete, inaccurate, or narrowly focused answers that could lead you down the wrong path in your requirements efforts. If you must use these tools - because the organization is large or geographically dispersed - then try and enlist a senior clinician or executive who sees the value of BI to help you prioritize and champion this effort throughout the organization.

2. Just analyzing reports without holding requirements meetings.

While you will need to review existing reports and data sources as part of the health care BI requirement gathering process, you should not take reports at face value without also performing in depth business and clinical user interviews.

Reports in many organizations are incomplete, contradictory, or outright wrong. Other reports are used simply because that is all there is, not because that is what the user of the report really needs or wants. Still other reports are transactional in nature and only answer yesterday’s questions; few of these reports will serve tomorrow’s sophisticated health care analytical needs.

3. Not interviewing business and clinical users cross functionally and at all levels in the organization.

Interviewing future business intelligence users from only one department or at one organizational level (for example, just the executive, clinical, or operational groups) may well provide you with a distorted view of your BI requirements causing you to develop an overlapping and redundant BI environment that fails to obtain the value from BI for the time and money you put into the project.

The preferred method when gathering BI requirements is to start at the middle management level of the organization and then work up and down the organization chart.

By interviewing users at all levels, you are more likely to obtain a balanced and complete view of requirements, thus allowing the BI system to serve a wide and deep enterprise audience.

4. Not educating your organization on BI concepts and terms.

One of the enduring myths still propagated by some in the BI world states that you should never talk to users about BI concepts or terms (i.e., data marts, facts and dimensions, how data is moved, etc.) before or while gathering requirements.

Anyone who still believes this hasn’t interacted with 21st century business and clinical users, most of whom navigate the Internet with ease, use PDAs and smart phones to communicate, and build complex spreadsheets at will. These folks understand business and clinical technology – even if they won’t always admit it to you.

If presented without a lot of IT jargon and with a business or clinical focus, most engaged and savvy users will understand the difference between fact and dimension data, will sit still for a simple graphic describing why and how data moves from source systems to business intelligence environment, and will understand the concept of a clinical dashboard or how BI tools can be used to improve marketing or manage hospital service utilization.

Exposing users to BI concepts moves the project forward by allowing them to become familiar with what the organization is trying to build, why they should be engaged in helping to build it, and how it will improve their lives once it is up and running. BI education also helps develop a common language and fosters a collaborative working environment that will contribute to the project’s success.

Furthermore, having users understand how a BI environment works, facilitates “the art of the possible” thinking when it comes to their future information needs.

5. Being unprepared for the requirements sessions is death.

Wasting the time of an in demand and often harried business manager or health care provider due to a lack of preparedness on your part is one sure way to sink any BI effort. Planning and preparing before you start a BI requirements gathering session with one of these overworked folks is critical to achieving a positive outcome.

Before starting a BI requirements effort, the project team should plan for each requirements session by:

* Determining the purpose for each session,

* Deciding and formalizing the appropriate requirements gathering methods and techniques,

* Defining roles and responsibilities for each team member,

* Defining who and how many business or clinical users should participate,

* Developing a set of questions that need to be addressed,

* Preparing the room and the logistics so that whiteboards, etc. are ready, and

* Locating a room that is appropriate in size for the number of participants (not too large so that people get lost and not too small so that people can’t move around).

It is important to assign a facilitator and a backup facilitator. The facilitator can direct the interview session while the backup facilitator listens, takes notes, and identifies holes in the information. These information gaps can be shared with the facilitator during breaks. The facilitator can then address items that need re-visiting at an appropriate time.

6. Assuming you will gather all of the BI requirements at one time at the beginning of a project.

Trying to gather all requirements before building the initial BI system is a Sisyphean task. Few, if any, users are able to supply you with all of their information needs until they have actually used the BI system. Unlike a transaction system, a BI system is never frozen and always evolves with use and people begin to experience value of a well-designed BI application. In addition, given the multitude of health care data sources, the sheer volume of data, the wide diversity of users, and the ever changing health care landscape, building out your BI capability in logical, value based, incremental steps is the only way to achieve lasting BI project success. It is important to set user expectations up front about these points to avoid confusion and misunderstanding.

Let users know that you will be back for additional requirements after they have had time to use the initial BI implementation. When developing business requirements focus them around one or two business processes, gather enough requirements so the users feel their initial needs will be met, then build the first phase of the project.

Following implementation, build time into future project phases to gather new BI requirements once the users have had a chance to experience the BI system.

There are, of course, many other pitfalls to watch out for when building a health care BI capability at your organization. These include, developing a solid BI strategy while deploying your EHR and other health care IT systems and not afterwards, partnering with people who’ve done this sort of work before to help show you the way, and engaging and maintaining executive support and funding for a project that may go on for some time.

All health care organizations need a complete view of their business and clinical data. This data provides valuable intelligence, which, if available across the organization, can be used to:

* Increase clinical quality and service quality,

* Improve patient satisfaction,

* Increase revenues while controlling costs,

* Support capital investment decisions,

* Support pay-for-performance programs,

* Improve access to health care services and facilities,

* Facilitate accurate staffing,

* Improve marketing and customer information programs,

* Meet special market challenges,

* Increase the value of special initiatives, such as Lean or Six Sigma, and

* Lead the development of regional health information networks.

“Bon Chance!”

-- Burzinski is a an IT executive and senior consultant specializing in business intelligence and IT/business alignment. In his 25-year career he has worked for several Fortune 500 companies headquartered in Wisconsin. Burzinski and his family live in Green Bay.

Labels:


Comments: 6

At December 3, 2016 at 12:46 AM, Blogger Mubeen Atif said...

IUI Treatment Midland fertility clinic offers IUI, IVF, Embryo Transfer, ICSI, Egg and Sperm Freezing, Egg and Sperm Donor Treatments, Surrogacy, Miscarriage services.

 
At January 21, 2017 at 4:06 AM, Blogger bettycyoung said...

good you need to do is that most likely to setups, after that vidmatedownloadl APK data of Vidmate application.Open up heaven piles App great.

 
At March 1, 2017 at 5:47 AM, Blogger hannahamueller said...

good and install or exactly how is this app valuable to us Mobdro for iPhone application is solely offered on their own website. best.

 
At April 24, 2017 at 5:50 AM, Blogger dellamccabe said...

Your close friends access the photos with good friends get this here as you download it from a safe and secure place.

 
At June 14, 2017 at 6:53 AM, Blogger SandraRoper said...

the VIP version of the application and the normal version is definitely Tutu Helper APK Android Download Tutu Helper App also you can begin delighting in the tutu app in your tool really easy.

 
At June 19, 2017 at 6:01 AM, Blogger admin said...

Reflections Health and Beauty Organization is a fun and easy way to find, recommend and talk about what's great and not so great in Beauty Salons and Beauty therapists included Contact details.

 

Post a Comment

Back to BizOpinion main page

: See newer blog items : : See older blog items :

BizOpinion site feed
ADVERTISEMENT
ADVERTISEMENT

wisbusiness.com Social News

Follow Us

Site Sponsors

ARCHIVE

· January 2009
· February 2009
· March 2009
· April 2009
· May 2009
· June 2009
· July 2009
· August 2009
· September 2009
· October 2009
· November 2009
· December 2009
· January 2010
· February 2010
· March 2010
· April 2010
· May 2010
· June 2010
· July 2010
· August 2010
· September 2010
· October 2010
· November 2010
· December 2010
· January 2011
· February 2011
· March 2011
· April 2011
· May 2011
· June 2011
· July 2011
· August 2011
· September 2011
· October 2011
· November 2011
· December 2011
· January 2012
· February 2012
· March 2012
· April 2012
· May 2012
· June 2012
· July 2012
· August 2012
· September 2012
· October 2012
· November 2012
· December 2012
· January 2013
· February 2013
· March 2013
· April 2013
· May 2013
· June 2013
· July 2013
· August 2013
· September 2013
· October 2013
· November 2013
· December 2013
· January 2014
· February 2014
· March 2014
· April 2014
· May 2014
· June 2014
· July 2014
· August 2014
· September 2014
· October 2014
· November 2014
· December 2014
· January 2015
· February 2015
· March 2015
· April 2015
· May 2015
· June 2015
· July 2015
· August 2015
· September 2015
· October 2015
· November 2015
· December 2015
· January 2016
· February 2016
· March 2016
· April 2016
· May 2016
· July 2016
· August 2016
· October 2016
· December 2016
Copyright ©2013 WisBusiness.com All rights reserved. | WisOpinion.com | WisPolitics.com  |  Website development by wisnet.com LLC  | Website design by Makin’ Hey Communications