Dashboards from Sparklines: All Systems Go!

Dashboards will have several uses in the EMR environment.

• ICUs for displaying those 3-page wide flowsheets of clinical data: intake, output, vital signs, lab, drips, PCA.
• Chronic disease overviews: lab, home monitoring results, vital signs, prompts for next lab or immunization
• Quality Improvement: compliance with standards, progress toward targets, peer comparisons
• Pay for Performance: Budget, progress toward targets, return on investment
• Management dashboards: trends, year-to-year comparisons, key performance indicators

Here are some nice examples

Traffic light (colored dots of red) in the second column. Sparklines in the third column. Bullet graphs in the rightmost columns.

Microbar graphs on the lowest row, with sparklines just above them.

After you sketch out a new dashboard with pencil and paper, you may want to dress it up to show off before you start spending engineer time on it.

Here is a nice PowerPoint template for making high-fidelity wireframe mock-ups.
Download Dashboard Template

Sparklines: Coming to an EMR near you

Sparklines are data-intense, word-sized graphics designed to be incorporated into text. Used in an EMR, we can see the recent lab value and its associated trend over time.

Edward Tufte pioneered the concept of sparklines, and his website has a large collection of resources to those who want to explore sparklines further.

We should be using sparklines throughout our EMRs.

• As elements of clinical dashboards
• Monitoring chronic disease processes (lipids, A1C, renal function for diabetes)
• Monitoring vital sign and physiologic parameters in ICU patients
• Managing improvement trends in CQI processes
• Tracking financial performance in management dashboards

Where can I find code to implement sparklines?
Visit this site for links to non-commercial in several programming environments, including PHP, Javascript, C#, Lisp, Perl, Python, Ruby, Java, Excel VBA.

Commercial Implementations of sparklines include software add-ons for Excel:
BissantzSparkMaker
MicroCharts
Business Refinery SimpleCharts

This graphic from MicroCharts gives detail on how we can show "normal range" or "target range" with a gray band, or a threshold value with a red line.

Developers! Start your engines!

Clinicians! All you need is pencil and paper to start sketching the dashboards, lab displays, and other graphs you need. Then share those with your EMR vendor.
Let's start seeing these word-sized, data intense graphics in all our EMR visual displays.

What are we aiming for?

In the world of making EMR's more helpful to clinician users, how high should we aim?

It's tempting for EMR vendors to try to impress with a long list of features. But that doesn't make me an Efficient user. It certainly doesn't sustain Enchantment after the sales demo, once I'm using the product.

I saw this nice illustration of the User Hierarchy of Needs at a blog called Creating Passionate Users.

I think we are around 2nd or 3rd stage for most EMR's. We might see pockets of Learnability or Efficiency in our own EMR. The most progress has been made in areas like managing medications and remembering diagnoses.

How would you rank your own EMR on the whole? Send your comments. Spread the word.

Some Assembly Required

Make the EMR software work right out of the box.

I do expect my local organization to build lists of my favorite medications, diagnoses, pharmacies, consulting and referring physicians, etc.

I shouldn’t have to be making templates for common problems. That’s what programmers do.

If I can't create a template or a reusable note as easily as word-processing document, then there is a problem with the EMR product. I should not have to hire someone with IT training to make the software usable or efficient.

Blogging software has made it easy for the rest of us to make a dynamic website with no knowledge of HTML. Now let's bring that ease of use to the EMR.

What's Your Phone Number?

How can I, a physician user of an EMR, give feedback or enhancement requests to the someone who can make a difference?

As the EMR Champion in my medical group, I hear my partners come up with excellent suggestions all the time. Most of these gems are never recovered.

All EMR corporate websites need a “Contact us” page that includes a link to feedback for product improvement.

• It shouldn’t require me to log in to a secure website.
• It should give me an email address for support, suggestions, or to report problems.
•          That way, I can grab a screenshot, type a few words or lines, and shoot off the message while I’m still hot.

• The sorting (support, enhancements, issues/bugs) can be done at the corporate end.
• It should ask if I want to get feedback or not.
•         Feedback can be simple ("We got your message" or more nuanced "We forwarded your suggestion to the enhancement team" or "You should also notify your local support team").
  

Developers benefit by getting fresh feedback. A focus group done weeks or months later will yield only the most egregious problems.

Are you still taking Prozac?

Reviewing the medication list is a routine part of the visit for patients with chronic visits, or those needing refills. This is often not such a simple task. The tools we have are flawed in the world of EMR's. They improve on the written list by making changes dynamic and instantaneous. They make doing refills much simpler.

Many med list modules are limited and assume a fairly black and white reality: The doctor ordered it. You took it. You got better.

The real world is more chaotic and variable. We need systems that allow adding qualifiers, to cover circumstances like these:

1. I cut it back to one a day, so I wouldn’t run out before this appointment
2. The pharmacy switched me to the one covered by my insurance
3. They stopped that when I left the hospital. Should I still be taking it?
4. I'm not taking it yet. I plan to get that medicine this Friday, when I get paid.
5. I went to get it, and the copay was $75! So I didn't get it.

So the modern medicine list needs to accommodate the vagaries of the real world. Here are some of the features needed in an ideal EMR medication module:

The basics (you can skip over this section!):
1. name of drug (generic and brand name)
2. dosage and form
3. when and how taken (in patient-friendly language, and large-enough font for age)
4. purpose (the reason, not the ICD-9 description)
5. start and stop dates
6. quantities
7. number of refills
8. refill dates
9. who prescribed it

Other predictable features that are needed, but rarely present today:
1. Danger signs (e.g. symptoms to report promptly)
2. Monitoring required (e.g. periodic lab)
   
3. Notes about side-effects, dose adjustments, food-drug or drug-drug interactions to be alert for.
   

Weird events that are harder to describe:
1. I ran out ____ days/weeks/months ago.
2. I was about to run out, so I reduced the dose by ____% about ____ days/weeks/months ago.
3. I thought it was causing me problems/wasn't working, so I reduced/increased the dose.
4. I forget a lot of doses, especially the evening ones.
5. I ran out of the Nexium, so your nurse gave me some Prevacid samples, and my sister had some left-over Protonix she gave me for a couple weeks.

Can you think of other weird events to consider in the ideal med list design?

Notes:
For a model med list, see: Med List (a Microsoft Word document) from the Massachusetts Coalition for the Prevention of Medical Errors. It includes a number of helpful features to promote safety and clear communication.