Better EMR Design

Posted on May 23, 2012 I Written By

Priya Ramachandran is a Maryland based freelance writer. In a former life, she wrote software code and managed Sarbanes Oxley related audits for IT departments. She now enjoys writing about healthcare, science and technology.

Now that we’ve heard the statistics about EMR use, we’re also hearing a lot of opinions on EMRs, and not all of them are laudatory. In fact I read some separate articles recently, and they pretty much said the same things in so many different words:

– EMRs are not intuitively designed. They do not reflect actual workflows that most doctors or hospitals follow. Rather the applications look like they’ve been designed by a bunch of programmers who then design the UI to look like how they’re underlying data are structured.
– Because they’re pretty much being foisted on hospitals and doctor’s offices through “incentive” programs, often the resources expended on them are sunk costs. To improve the workflow of a software to accurately reflect the needs of a particular hospital, you will need to pump extra money into it. That’s about as likely to happen as a software vendor providing you a customized solution without charging you anything extra.

Let me assure you – the medical establishment has it exactly right, at least in my experience. I work as a technical writer, so much of my working life consists of documenting the products that make it to your doorsteps, and I have experienced some of the same frustrations as you. I’ve complained about them, made myself unpopular with development teams and added my two cents to feature request lists, just like many of you.

But, I also see things from a programming perspective too, and I’m here as a sort of ambassador between both worlds. Many teams I worked with had an actual designer working as part of the team.
But the designer’s role was often making the colors look attractive enough, or the font large enough to appeal to a cross-section of users. One of my old bosses, different industry and everything, called this our Lipstick on a Pig game, and plenty of times that’s what the designer’s role was. Inventing plenty of shades of lipstick for the proverbial pig.

Ergonomic design was not what the designer was tasked with doing. One place I worked at even had a doctor on payroll. Except he had a doctor’s degree from Shanghai, had not cleared his exams in the States and had no idea how medicine is practiced in the States. It sure looked good on paper when their sales team went out to clients and talked about having a dedicated doctor on staff to help with software design.

And the effect of poor design on functionality is often perplexing, sometimes disastrous. Case in point – documenting all the drugs administered to a patient. It has been drilled into programmers that clicks are sacred things, you don’t want doctors wasting too many of them.

So because we don’t want too many clicks, we list each and every medication a patient has been administered, add some pagination logic around it and call it a day.

The doctor, who is the end user, for whom we designed this software system, now sees all the information in a “convenient” list and doesn’t need to open up a medication tree to view the medications under it. Except if she has a very sick patient with multiple encounters, the case history reveals a medication that is 31 pages deep. To get to Xanax, she might have to page through 30 previous pages.

While these “features” fall into the realm of merely annoying, they’re nowhere as disastrous as those modal alerts that Barbara J. Moore talks about in her KevinMD piece. A modal window is one of those annoying windows that you have to take an action on, otherwise you can’t proceed any further in your workflow. Moore points out the hazards of such alerts which force a doctor to take a choice, any choice, but aren’t available later if the doctor wishes to review the alerts at leisure.

So yes, software vendors need people who know the workflow to design the systems. But more importantly, you – the medical establishment – must keep requesting changes or suggesting features, or vendors will remain complacent about what they put out.