Getting Your EMR’s UI/UX RIght

Posted on June 4, 2013 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

A couple of weeks ago, someone posted an interesting question on the buzzing question and answer site Is there room for any more new EMRs in the insanely crowded marketplace we have today? According to one very sharp medical student who’s keeping an eye on the field, the best response isn’t “yes,” or “no,” but “you’ve got the wrong question.”

His answer, which I’d like to share with you, argues that there’s no point whatsoever trying to introduce a new EMR with a shiny new feature set when none of the existing field have a decent UI/UX right now. Jae Won Joh then lays out the steps he believes vendors should take if they want to get the basic UI/UX right (steps excerpted for brevity):

Step 0: Architect the patient data structure carefully
I mention this because you’re going to need to be able to pass this patient data around for clinical use, billing, research, auditing, etc, so design for flexibility and expandability from the get-go. Too many EMRs make it painfully obvious that things were thrown in as afterthoughts.

Step 1: Decide on your market…
…because you need to do everything possible to totally kill it. It’s the only way to go. If you’re going to take on group practices, great, take on group practices. If you’re going to work the hospital scene, fine, work the hospital scene. Stop trying to make something that does everything everywhere. This is not a feature, it’s a horrible bug.

Step 2: Analyze what your market does
If it’s a hospital, you need multiple classes of user, ranging all the way from student to nurse to physician to administrator. You’ll also want a competent notification system, because inpatient things tend to be more urgent and if the ICU patient’s potassium is critically high, you probably want to warn the physician immediately instead of waiting for the physician to check on it manually, because gee, the patient might code and die before that happens….The concerns are different for an outpatient scenario: you don’t need a lot of the stuff that hospitals require in an office. Less orders, more scripts, greater throughput in terms of number of patients, scheduling functionality, etc.

Step 3a: Abstract workflows to a very high level first
In other words, they are as follows: 
1) read data
2) interpret data
3) input data

There’s really not much else to it. Every workflow is a permutation of those three. For example: a physician orders a lab, and it’s performed. The result is read by the tech who provides the input to the system, where it is then read and interpreted by the physician so they can go from there. Figure out how each workflow revolves around these three abstractions.


Step 3c: Design for a 5-year-old
If a five-year old couldn’t use your UI, you screwed up. Period.

There’s a lot more to Joh’s answer, and I suggest you hit Quora youself and read his entire piece. When it comes to usability, most EMRs have barely scratched the surface, and talking about these issues more is always a Good Thing.