How should drug interaction warning screens look?

Most clinicians I know suffer from "alert fatigue". I don't mean they feel tired from too much caffeine.

I mean, they are tired of EHR software crying wolf with too many drug interaction warnings. Embattled users simply dismiss all drug interaction warnings without reading them. Mild or theoretical interactions should be suppressable by individual user preference, as a default setting.

This is a significant patient safety issue.

If I am relying on my software to warn me about serious drug interactions, then the warnings about milder or dubious interactions are annoying, distracting false alarms. I need to be aware of serious interactions, so I can adjust therapy.

Here's another problem: I get warned that drug A interacts with drug B. I dismiss the warning. Then I immediately get warned that drug B interacts with drug A. I know that!

Worse yet, if I then change the dose of drug A, I get warned all over again. We need smarter systems now, geared to what fallable, imperfect, tired human users need, and geared to keeping patients safe.

Here is a modest proposal of a way to display drug interactions.

Note that the key findings are in the middle, the drug names are prominent, the severity level is great big number, and user pref settings are right there.

The Four-Layer EMR

We are being freed from the document-centric mental model of the medical record. In the paper past, we only could create, save, read, and review paper documents. That has changed, but our way of thinking has not.

As with data tables that allow us to sort, or links that allow us to drill down, our clinical documents have interactive features. Or should have.

So let me propose a model for the Four-Layer EMR. It would use some kind of "hide/reveal" technology. Show me the level of detail I, the reader, need right now, in this context.

The top layer I call the "one-line summary". What few words characterize this encounter. I am thinking of ambulatory physician visits. Perhaps other readers can translate this into other kinds of clinical encounters.

The one-line summary would be a terse description like: "diabetes, A1C 8.2, start metformin 500 BID" or "acute sinusitis > amoxicillin 875 BID 7 days" or "well woman exam > Gardisil, Yasmin".

The benefit? I can look at a list of all the visits chronologically and see what happened.

Like this:

Brenda Star          Acct No: 309144869
02/11/07                acute sinusitis > amoxicillin 875 BID 7 days
04/29/07              well woman exam > Gardisil, Yasmin
09/02/07              diabetes, A1C 8.2, start metformin 500 BID

The next layer down, the "Executive Summary", is what I would communicate to a surgery consultant. It is a 3-4 sentence description of this encounter in a depth adequate for a consultant or other peer not needing a complete picture of this patient.

For example, it might say "57 year old type 2 diabetic recently started on metformin with good control, needing evaluation of chronic cough, not on an ACE inhibitor".

Next, the 3rd layer, the "Working Layer" is the layer clinicians would like to work in for the details they need. That is, before we started documenting to cover our assess.

It would include only the pertinent history elements necessary to understand the diagnosis and treatment. In the Review of Systems, it would only include the positive elements, with a few negatives (e.g. "no murmur" if that is pertinent to note).

In the Assessment and Plan, only the parts that are not assumed. I do need to know which antibiotic was used. I don't need to read that the patient was told to take tylenol and come back if they don't get better as expected.

The fourth layer would make my attorney, my risk-manager, and my chart reviewers happy. All the wealth of detail is there that would only annoy the rest of us. All the detail that makes my record look more like a contract, and less like a story about a person.

Parenthetically, there are layers deeper than these four. These layers include the security/audit trails that record who recorded what and when. We'll ignore them for our purposes here.

So, how do we bring this concept about?

1. Identify the elements that define each layer.
2. Choose a technology that supports it in your particular product.
3. Work out the details that specify the contents of each layer within a specific document. Could the software identify key words for Layer 1 (One-line summary) in context? Would the provider need to supply these in the beginning or end of document production?

Your thoughts?

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.