The graph shows states in descending order based on the usage of any type EHR/EMR system.  The series of dots illustrates usage of any system, while the bars illustrate usage of systems that meet basic criteria.  Median percentages are illustrated by dotted lines.  Colored shading indicates the percentage range into which most (68%) states fall.  The shaded area on the left applies to usage of basic systems, the shaded area to the right applies to usage of any EHR/EMR system.

As we can see from the jagged outline of the blue bars, adoption of systems that meet basic performance criteria is not necessarily consistent with overall usage of electronic record systems.  For example, Utah ranks number 2 in terms of overall EHR/EMR usage, but four states rank higher than Utah in terms of systems with basic functionality.  These four states are Minnesota, Wisconsin, Washington and Oregon.

North Dakota, Utah, Minnesota, Wisconsin, Washington, Oregon and Hawaii not only lead the nation in terms of overall EHR/EMR usage, but also in terms of having basic systems in place.  Looking toward the lower end of the list, we can see that states like Mississippi, South Carolina, Nevada, New Jersey and Louisiana have the lowest percentages of systems that meet basic criteria.

click on the graph to enlarge it

To look up specific EHR/EMR adoption values for each state or to download the data, go to this interactive Tableau Workbook.

Given the current state of the debate around health care reform, one might be tempted to ask whether the political climate at the state level plays a role.  Using information about “Red States and Blue States” from Wikipedia, we can assign party affiliations to states based on results from the past five presidential elections (1992 to 2008).  At first glance, it appears that democratic states tend to be further along in terms of EHR/EMR system usage.  Their median percentages for overall usage (61%) and basic system usage (36%) are higher than those of republican states (57% and 31% respectively).

click on the graph to enlarge it

However, reducing this question to simple partisan politics ignores the many factors influencing the adoption of complex systems. Issues like perceptions and attitudes, computer experience, workflow impact and concerns about patient-doctor relationships play a much bigger role in the day to day decisions doctors make.  These issues are beyond the scope of this writing, though a very small sampling of relevant academic research appears at the end of this post.

Even without delving into those issues, we can get a sense that there is more at play here by looking at socio-economic data from the US Census Bureau. The graph below shows the usage of any type of EHR/EMR system, along with census data about poverty, annual pay, higher education, age, and number of physicians per capita.

click on the graph to enlarge it

Using this graph, we notice that our breakout of Democratic and Republican states shows some significant differences.  The thick grey lines indicate the median value for each variable within each party category, while the grey shading shows the range into which the majority (68%) of states in each category fall.  Based on this data, residents in democratic states tend to be

• wealthier (lower percentage of people living below the poverty line)
• earn higher incomes (higher average annual pay)
• more educated (higher percentage of residents with a bachelor degree or higher)
• able to choose among more doctors (higher rate of doctors per capita)

Since we are dealing with state level data we cannot say how much each of these factors influence EHR/EMR system adoption (see scatter plots at the end), except to say that higher levels of poverty appear to be linked to lower levels of EHR/EMR system usage – apparently more so if the state happens to lean republican.

Unfortunately this exploration suffers from the fact that we are dealing with high level data which hinders our ability to match up relevant details.  None the less, it provides some hints that socio-economic issues play at least an indirect role in the adoption and use of EHR/EMR systems.

click on the graph to enlarge it

click on the graph to enlarge it

Resources:

Explore the data details behind the graphs in this post via this interactive Tableau Workbook.

Electronic Health Record Systems and Intent to Apply for Meaningful Use Incentives Among Office-based Physician Practices: United States, 2001–2011

NCHS Data Brief, Number 79, November 2011

http://www.cdc.gov/nchs/data/databriefs/db79.htm

Definitions used in this report (direct quote from the NCHS Data Brief):

 “Physician office: A place where nonfederally employed physicians provide direct patient care in the 50 states and the District of Columbia; excludes radiologists, anesthesiologists, and pathologists.

Any EMR/EHR system: Obtained from “yes” responses to the question, “Does this practice use electronic medical records or electronic health records (not including billing records)?”

Basic EMR/EHR system: A system that has of all of the following functionalities: patient history and demographics, patient problem list, physician clinical notes, comprehensive list of patient’s medications and allergies, computerized orders for prescriptions, and ability to view laboratory and imaging results electronically (4). Having a comprehensive list of patient’s medications and allergies was asked as two separate questions in 2010 (one about medications and the other about allergies); the questions were collapsed into one question in 2011 (5).”

The 2012 Statistical Abstract:  State Rankings

U.S. Census Bureau

http://www.census.gov/compendia/statab/rankings.html

Red states and blue states

http://en.wikipedia.org/wiki/Red_states_and_blue_states

Direct quote from the wiki article:

“Current classification

The following classification of red and blue states (as well as purple/battleground states) was determined by compiling the average margins of victory in the five presidential elections between 1992 and 2008. Three of these past elections were won by Democrats, Bill Clinton in 1992 and 1996, and Barack Obama in 2008, while two were won by Republican George W. Bush in 2000 and 2004.”

A Framework for Predicting EHR Adoption Attitudes: A Physician Survey

by Mary E. Morton, PhD, RHIA, and Susan Wiedenbeck, PhD

http://perspectives.ahima.org/index.php?option=com_content&view=article&id=162&Itemid=56

The influence of payer mix on electronic health record adoption by physicians

Menachemi, Nir; Matthews, Michael C.; Ford, Eric W.; Brooks, Robert G.

http://journals.lww.com/hcmrjournal/Abstract/2007/04000/The_influence_of_payer_mix_on_electronic_health.4.aspx

 Predicting the Adoption of Electronic Health Records by Physicians: When Will Health Care be Paperless?

Eric W. Ford, PhD, MPH, Nir Menachemi, PhD, MPH, and M. Thad Phillips, MSHA, MSHI, MBA

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1380189/

There’s a big difference between the dashboard of a car and that of a passenger jet!  For one thing, understanding a car dashboard requires significantly less training and experience than a cockpit dashboard.  Of course each is designed to meet different needs: a pilot has to worry about many more things than a car driver when ferrying passengers safely from Point A to Point B. When developing information dashboards for a business we also need to keep user needs in mind: a VP of Marketing will need a much more high-level overview than a Product Director, who in turn has quite different requirements from a sales rep preparing an action plan.  In practical terms this means that we first have to figure out who will use the dashboard and how.

Image of a Jet Cockpit Image credit: http://flysusan.com/cockpits.htm

A dashboard is only useful when it can become an integral part of decision making.  Some decisions need to be made on a daily basis, such as which prospects to call or how to follow-up with a client.  Other decisions take more time.  Those decisions tend to be more organizational and strategic in nature.  They require input from many people and data sources, they require observation and a longer term perspective. The implication here is that a dashboard needs to be capable of providing information at the speed with which decisions are made.  A dashboard also needs to provide the appropriate amount of summary and detail.  Before we can build anything, we need to define what information is actionable and how soon it needs to be available.

From a technical standpoint, this initial exploration provides the framework for determining how the dashboard should be build.  The following questions are just a starting point:

• What information is required?
• How will the information be used?
• What kinds of summaries and calculations make the most sense?
• How much detail should be included?
• How can we best present the information?
• How often does data need to be refreshed?
• Which databases and information sources are necessary?
• Which software/hardware best meets our needs?

The answers to these questions always involve tradeoffs.  Which tradeoffs make sense depends on the impact the dashboard will have and whether we can demonstrate a positive ROI.  At some point, the dashboard has to help improve the bottom line.

Drawing a direct line between dashboard and bottom line dollars can be complicated.  Dashboard benefits tend to be intangible.  To measure ROI, we have to think about how the dashboard enables better decisions, how it helps users focus on profitable actions and whether it helps to save time or other resources.  Often we need to offset these intangible benefits against very real budgets and real money that needs to be spent on development, training, software, hardware, and so on.

As we can see, if we are serious about building a dashboard, we also have to be serious about spending some time upfront to map out a plan for getting from the Basic Idea to an Actual Dashboard.  To get there, everyone involved needs to develop a common language, that is, a set of common definitions and goals.  For instance, if our dashboard is supposed to track progress following a product launch we need a common understanding of what market penetration means.  Does it mean “number of actual customers vs. potential customers” or “number of actual customers vs. number of targets” or “number of customers who bought at least X number of widgets.”  How we define our key metrics has a direct impact on the usefulness of our dashboard and on the effort required to build it.

Developing common definitions and goals is a key step toward building a bridge across the communication gap. Just because we are using terminology that seems to be well defined doesn’t mean we really are talking about the same thing. For example, we might be talking about lighthouses and we might even have the same general idea of what a light house is and how a typical lighthouse looks. But when it comes to actually building the lighthouse we need something more concrete.

What’s a lighthouse?

The Idea	An Actual Lighthouse	Another Actual Lighthouse
When discussing the concept of a lighthouse, usually this type of image comes to mind.	Most of us would expect an actual lighthouse to look something like this.  It meets the typical expectations for a lighthouse.	Sometimes a lighthouse needs to address special situations: when a client needs a special lighthouse and the developer thinks of building a typical lighthouse, the project is in trouble.

Image credits (L to R):

http://www.freeclipartnow.com/buildings/lighthouses/

http://www.destination360.com/north-america/us/maine/images/s/maine-lighthouses.jpg

http://www.longislandlighthouses.com/lv112.htm

To get started we need to indicate when the Fiscal Period starts and when it ends, hence the two parameters: [CFY Start] and [CFYTD End]. Then we need to determine which data to include in our calculation. The DATEDIFF and DATEADD functions will come in handy for that.

Let’s assume we want to create a Fiscal Year summary for a measure called [Sales] based on the [Order Date]:

FYTD Sales Current =
IF [Order Date] < [CFY Start] THEN Null
ELSEIF [Order Date] > [CFYTD End] THEN Null
ELSE [Sales]
END

To compare the current fiscal year sales with the same period during the previous year, we need to shift everything back by 12 months using the DATEADD function:

FYTD Sales Previous =
IF [Order Date] < DATEADD(‘month’,-12,[CFY Start]) THEN Null
ELSEIF [Order Date] > DATEADD(‘month’,-12,[CFYTD End]) THEN Null
ELSE [Sales]
END

Note: when using the DATEADD function to add or subtract months, we don’t have to worry about leap days – pretty nifty.

A similar approach works for Month to Date calculations. With the DATEDIFF function we get rid of all the data that doesn’t fall into the current month, then we just add up the days we want to include:

FMTD Sales Curent =
IF DATEDIFF(‘month’,[Order Date],[CFYTD End]) <> 0 THEN NULL
ELSEIF [Order Date] > [CFYTD End] THEN NULL
ELSE [Sales]
END

When comparing to the same month a year ago, we can use the same trick of shifting time as we used for our Year to Date Previous calculation:

FMTD Sales Previous =
IF DATEDIFF(‘month’,[CFYTD End],[Order Date]) <> -12 THEN NULL
ELSEIF [Order Date] > DATEADD(‘month’,-12,[CFYTD End]) THEN NULL
ELSE [Sales]
END

Bonus Calculation:

If you need to calculate the number of days in a year, here’s a way that considers Leap Years:

IF (datepart(‘year’,[Order Date]) % 400) = 0 then 366
ELSEIF (datepart(‘year’,[Order Date]) % 100) = 0 then 365
ELSEIF (datepart(‘year’,[Order Date]) % 4) = 0 then 366
ELSE 365
END

The % sign is Tableau’s syntax for modulo calculations.

Enjoy!

Here’s a workbook with examples:

When doing this, however, we have to ensure that both scales are synched up as illustrated below.

The other example comes from Dona Wong’s recent Wall Street Journal. Guide to Information Graphics. ² In it she suggests using dual axis graphs to “ … help show how two directly related series move together.”   The picture below – courtesy of Kaiser Fung’s Junk Charts blog – shows the example from her book. ³

I am somewhat ambivalent about this chart since we have to be careful in selecting each scale in order avoid distorting the data (note that the Market Share scale starts at 30% and that the increments for both scales line up).

When done properly, both examples help us when we need to make a point with a single  picture:  we can save space and keep two related pieces of information within easy view.   This works best when illustrating a specific issue and when we can use a static picture  in a newspaper, printed report or a presentation.   We’re asking for trouble when using this approach in a dynamic environment, like a dashboard, where scales need to adapt to the latest data.

Acknowledgements:

1. Naomi B. Robbins, Creating More Effective Graphs (New Jersey: John Wiley & Sons, Inc., 2005), page 262

2. Dona M. Wong, The Wall Street Journal. Guide to Information Graphics (New York: W.W. Norton & Company, Inc.), page 59

3. Reading: WSJ Guide to Information Graphics, Posted on Mar 06, 2010 at 02:59 PM, Junk Charts: Infographics

But I do find dual axis graphs useful as a shortcut when exploring data – precisely because I can more clearly see the shape of the two curves in relation to each other.  Below is an example that looks at Dollars and Units.  When graphing them separately, the lines look somewhat similar and it takes a second look to notice that Units are declining while Dollars are increasing.

Two graphs, one showing Dollars the other showing Units

In the dual axis graph below, I got that message without needing a second look:

Dual axis graph showing Dollars and Units

When exploring data with visual analytics tools like Tableau, a dual axis graph can help me compare metrics quickly to see whether something jumps out.  Are the curves moving in synch with each other? Are they trending in a similar direction?  Do the curves indicate anything useful from a business point of view?   For instance, in this example it looks like our margin might be improving.  If the curves moved in the opposite direction, we may need to ask whether we’re discounting too much.

As Joe Mako and Stephen Few point out, in a dual axis graph we cannot compare the magnitude of change, but we can get a general feel for the direction and whether there are further questions we need to ask.  In this example, a simple ratio calculation of Dollars per Unit helps to confirm whether we’re onto something.  When we report results from our analysis, a graph of this ratio will do a better job showing the relationship between Dollars and Units than the dual axis graph shown above.

Line graph showing Dollars per Unit

So, why should we care whether we call something a “dashboard” or a “scorecard?” After all, they both use visual gadgets and graphs, don’t they?  Both provide information about what’s going on in the business, right?  In my experience, most end users really don’t care about the difference in nomenclature: what matters to them is whether the information they get enables profitable business decisions.

Yet, there is a critical difference we need to ferret out during requirements gathering: are we measuring performance or are we monitoring progress?  Measuring performance simply means keeping track of things – like fuel consumption or engine temperature in a car.  Monitoring progress implies that some thresholds and goals have been established: when the needle on the gas gauge nears “Empty” we need to start looking for a gas station.

Ergo, the critical difference is this: measuring things just provides information – what we do with that information is open to interpretation.  Unlike progress monitoring, measuring things doesn’t tell us when to do something nor does it provide information on what needs to get done.   In order to measure progress, though, we have to set goals and determine acceptable performance standards – in essence, we have to figure out what needs to get done and when to do it.  To stick with the car dash metaphor: someone has to determine how low the gasoline level can sink before the “fuel empty” warning light turns on.

Much has been written about scorecards and dashboards and their respective differences.  As a practical matter, I like this short hand definition from Wayne Eckerson, formerly the director of research and services at the Data Warehousing Institute (TDWI):

This chart provides a good starting point from which to explore requirements.  Often a dashboard becomes the starting point for a scorecard: while building a dashboard, the organization discusses what needs to be measured and how.  With measurements in place it’s now easier to set thresholds and develop SMART goals for a scorecard.

So, does it matter whether we call something a “dashboard” or a “scorecard”?  Yes – but not as much as one might think.  What matters more is that everyone is on the same page about the main purpose of the tool: are we measuring performance or are we monitoring progress?

Coincidentally, this white paper arrived while I was working through the intricacies of sales transactions for a client who is looking for quick – and accurate – ways to answer questions like “What happened to my sales?” and “What happened to my margin?”  Both are high level questions that require a thorough understanding of “low level data” in order to provide meaningful answers.  This got me thinking about the complexities of performing predictive analytics.

Complexities lurking under the predictive analytics table include issues such as data quality.  For instance,

• Customer IDs and customer names not always matching
• Customer ratings changing over time
• Master invoices being used to track transactions over an extended period of time
• Inconsistent data entry – for instance, credits sometimes showing up as negative numbers and sometimes as positive numbers – depending on how the data entry person coded the transaction.

More important than data quality is the question of “how do we interpret what we see?”  Statistical outliers serve as an example here, since they do not require a lot of explanation and their meaning is open to interpretation.  They could be the first sign of a new trend, a fluke, a data error, or the result of factors beyond our control.  How we deal with outliers when building our predictive model depends on what caused them.

Non-repeatable exceptions, a.k.a. flukes, are meaningless when we are trying to build a model of the future.  Usually they are noise and become part of our margin for error rather than a factor we would include in our model. In order to separate meaningful facts from flukes, we need to dig further into the details and determine their influence on the big picture.

For example, the chart below shows an “Outlier Territory” that performed particularly well in terms of achieving sales goals.

Graph showing territory performance, including a statistical outlier.

As we refine our bonus plan for the next pay period, how should we proceed?  Should we assume this territory will continue to have high sales and therefore raise its quota?  The answer depends in part on whether we are dealing with

• A real issue, such as our bonus model not working for that territory, or
• A fluke, like a one-time-only buy in by a major customer, or
• Data errors, as in “somehow we summed up the sales data incorrectly,” or
• Factors beyond our control, like an uptick in demand because of an unexpected and short-lived emergency.

Sometimes the sales rep can provide the insight we need to understand what caused the outlier.  Usually, though, we need to look for likely causes using the data we already have and relating it to information from other sources.

As we can see, our crystal ball is only as good as the answers we derive from data collected in the past.  Building it also requires us to make assumptions about how pieces fit together, how they influence each other and how important they are in shaping the future.  We can improve our assumptions using statistical tools like t-Tests, ANOVAs and various regression models.  We can look to proxies and draw on our understanding of the market place.  No matter how we develop our assumptions, we need to understand their limitations or they might turn us into Jacks and Jennys down the road.

Long story short: to build a crystal ball we need more than powerful tools.  We need skilled and experienced people, good data and the commitment to adapt over time.