Advertisement

Blog Viewer

User interface issues in the EMR

By Dennis Tribble posted 04-03-2018 15:00

  
Today I ran across two articles regarding physician ordering in the EMR that caused me to stop and think about where we are in automating the patient record.

In the first, out of BMJ Quality and Safety, Wong et al report about an association of inappropriate overrides of computerized decision-support (CDS) data and adverse drug reactions in which they concluded that inappropriate overrides resulted in six times the risk of a patient experiencing an adverse medication event. That was what made the article newsworthy, but I found another statistic in the article... Over 80% of the overrides were justified

What is alarming about that, of course, is that CDS data is wrong a lot of the time and that, after over 25 years of experience producing CDS databases to detect drug interactions, allergies, etc., we still don't have CDS systems that are sufficiently context sensitive to be right more often than they are wrong.

The second of the articles was by Robert Wachter in Harvard Business Review entitled To Combat Physician Burnout and Improve Care, Fix the Electronic Health RecordIn this article, Wachter asserts that physicians spend "...almost half their professional time typing, clicking, and checking boxes on electronic records."  He goes on to assert that much of this is not spent ordering per se, but in "buffing up" the notes to meet process records and maximize billing. In other words, the physician is now performing, via CPOE, billing and compliance documentation that was once the job of others and the only answer, to date, has been to hire a horde of scribes to follow the physicians around and do the recording for them.

Wachter goes on to say, however, that the largest portion of the problem, however, is not this additional administrative burden as much as it is the 1990's-era user interfaces used to drive these functions. Rather, he suggests, "For EHRs to become truly useful tools and liberate clinicians from the busywork, a revolution in usability is required. At its center should be a portrait of the patient's medical situation at the moment, including the diagnosis, major clinical risks, and trajectory, and specific problems the clinical team must resolve." I urge you to read the remainder of his thoughts; I hope it stirs you, like it did me, to think about what a truly useful clinical user interface might look like. While I don't necessarily agree with all his suggestions, there are plenty of really good user interfaces out there on the web that could be used as examples. 

Let's face it; the text box/selection list/checkbox interface common on most healthcare software is a tired old user interface that was never intended for use in environments as hectic, data dense and cognitively challenging as healthcare. Where a physician once wrote in a chart "change KCl to 30 mEq/L', they now get to click, check and scroll their way through a 2-3 page form, likely unintentionally changing other things on the way.

This caused me to look back at my own previous blogs and I found four of them along the same lines:

The ideal user interface

Thoughtful design, CPOE and human factors

More thoughts on user interface

Human factors and usability

I note not because I wrote them, but because each one of these came from presentations or articles about how awful the EMR user interface is, and what needs to be done to provide a UI that maintains context, drives appropriate decision-making, reduces cognitive load, and helps the clinician progress to a positive outcome for their patient. These reach back to 2011! So we have known for some time what kinds of steps we need to take in order to make user interfaces work well. 

I recall back to my first visit to Microsoft's Redmond, WA campus during an MS-HUG (that's for Microsoft Healthcare User Group) meeting which had to be back in the late 2000's. I recall that, during a reception after the more formal meetings, a host of earnest and interested UI designers joined us wanting those of us in attendance to look at some really interesting and innovative concepts around presentation of healthcare information that were intended to overcome problems like unintentional data changing, loss of context (as in ordering on the wrong patient), dense graphic presentation of key diagnostic information (as opposed to reading through lines and lines of reports and result tables). There was some stuff I still think was really good. The problem was, I was the closest thing to a clinician in the room (which was mostly filled with CIO's) and those designers were being politely ignored.

So how do we get people working on the kinds of interfaces that Wachter describes?

Perhaps the first step might  be to start demanding it in our own operating software to model the ways information might be presented, and show that it can drive meaningful clinical outcomes.

But wait a minute; when my friend and colleague Allen Flynn tried to present some of these concepts years ago, we, as pharmacists, told Allen that we didn't like or trust graphics that showed us where patients laboratory values were in relationship to expected but wanted, instead, to be given the tables of raw data to review for ourselves.

Unless that opinion has changed (and I really hope it has - even though I haven't seen or heard it), we have our own work to do to get ourselves to the point where we are not wasting precious time wading through the haystack of mostly normal data looking for the needle that is the problem we need to solve.

I would like to therefore challenge our profession in general, and SOPIT in particular, to take a leadership role in experimenting with alternative data presentations that spends less time asking us to confirm what it already knows, and more time presenting us decisions to be made, showing us that data in novel ways that make understanding a patient's current condition almost a gestalt experience.

If we can do this for ourselves, then perhaps we can model this for the larger healthcare community, and free ourselves from the tyrrany of an antique user interface. Who knows what it may eventually look like. But until someone starts trying to figure that out, we remain in the position of trying to solve 2010's problems with 20 year old tools. That's centuries behind, in computer years.

If you had to dream up something different, what would it look like?

Dennis A. Tribble, Pharm.D,.FASHP
Ormond Beach, FL
DATdoc@aol.com

The opinions expressed herein are my own, and not necessarily those of my employer, or of ASHP. 
4 comments
50 views

Permalink

Comments

04-12-2018 10:29

Thank you for the question, Sonya.

Sadly, it is hard to envision clinicians who find the current presentation overwhelming doing something like directly querying an API. FHIR addresses simplicity and availability of data, but does not address its organization or presentation, which are really at the root of this problem.

The problem appears to me to be a matter of using ancient (in computer terms) technologies to present and capture data, and in freeing that process from managing what is essentially billing and coding functions. 

I can envision mechanisms that might do just that; I am curious to see what others in the profession think a good user interface might look like.

Dennis

04-12-2018 09:50

Isn't this where the advent of FHIR as a new data standard comes into play? Physicians should be able to pull in from an API to get more contextual information for their patients in their workflow.

04-04-2018 15:57

A good user interface is like a joke.  If you have to explain it, it's not that good.  -Martin LeBlanc, Founder+CEO of @iconfinder

04-04-2018 09:51

Dr. Tribble, 

I happened to come across the same articles. I also came a across a recent article that took xml files from guidelines.gov and converted them into a CDSS. Gad El-Rab W, Zaïane OR, El-Hajj M. Formalizing clinical practice guideline for clinical decision support systems.  Health Informatics J. 2017;23(2);146-156. 

I am currently trying to create my own "smartforms" which allow patient subjective and objective data to be entered into a pdf form of sorts, and the form can take the information and "screen it" and see if the patient's disease states, labs, medications, and vitals qualify for a certain disease state (HTN, CVD, COPD, Asthma, dyslipidemia, metabolic syndrome, diabetes) and also if patient is on current pharmacotherapies already, needs pharmacotherapy, if there's therapeutic duplications, meds without an indication, meds that are contraindicated, etc. I know Epic can do this? But what I am really looking for is the code - which I am assuming would be javascript? I am also looking for the code/equation to calculate ASCVD 10 year risk score.