Back to Blog

Designing an EHR System with usability in mind

Designing an EHR System with usability in mind
17 March 2015

Recently, news broke in Modern Healthcare about the “American Medical Association calling for an overhaul of a federal program to test and certify electronic health-record systems for suitability in the EHR incentive-payment program. Its request has been joined by 34 other medical specialty societies and healthcare professional organizations.”

9-page letter to the head of the Office of the National Coordinator for Health Information Technology complained of “documented challenges and (a) growing frustration with the way EHRs are performing.” Such problems are inadequately addressed by the federal EHR testing and certification program led by the ONC, the AMA and its colleagues contend.”

And there it is: an official validation to our argument that there is a need for a highly customizable EHR. I never get tired of this quote: “EHRs are like the Model-T, any color as long as it is black

Essentially they are talking about the adaptability and customizability of an EHR system.  They are saying that an EHR is used in different ways in different environments, such as inacute care and ambulatory settings; I say it is more than that.  EHRs are used by each specialty and each individual doctor within a specialty in different ways as well.

American Medical Associations problem with EHR usability


One major gripe of the AMA is the usability of most EHR systems.  If you look at many of the EHR systems in the market today it feels like the cockpit of 747 Jumbo, clunky and intimidating.  Very few EHR systems have thought about the interfaces in a deeper level.  The few who have think that taking away features is what makes it simple, which means their EMR remains a one trick pony that can be used by what they call “a single provider” practice.  But even those providers to whom it was targeted just put up with it for lack of a better choice.

Design principles that must be employed in EHR systems are in a different category altogether, than say,  designing a good website.  Understanding the nature of use is important: how long is someone using this system and for what.  These kinds of applications are used for a longer period continuously than say, a shopping site.  So would the same principles be applicable?  The flow of the EHR should follow the thought process of a doctor, not the other way around where the doctor has to follow the flow of the EHR.  However simple or beautiful the app is, if it is designed for the wrong user and use, it does not work.

Even if they did not do the research on how best to create a good medical software interface, some basic principles can be followed.  An example of a design concept that we followed is to bold the data-fields rather than the label fields.  Sounds simple, but when you think about it, it makes sense.  IF you, as a doctor, are looking at the EHR screen all the time in your practice, you know where the label “Sex” or “Name” is.  You don’t need to see the labels in bold all the time: that is not what should catch your attention.  You need to see the data in bold so that you can glance at it once.

How many doctors ask their patients to come on a certain date? Not many. Doctors generally use time frames like “see me in a week, or in a month.”  This concept is lacking in the current crop of EHR systems.  The placement and color coding of allergy information, the display of appointments, are all simple but key issues that need to be concentrated on.

We went through multiple researches by acknowledged organizations and universities to include the latest design principles in the development of blueEHR. We also got live feedback from our open source community of doctors.


The next major gripe of the AMA is about the inflexibility of the systems.  When EHR systems talk about “customizable” or “flexible,” what they mean is you can make your own forms using a tool that allows you to add fields. That is it, you are supposed to be happy.

Each doctor uses his own unique set of forms that he might have tweaked to his satisfaction over the years.  This doctor should be allowed to use those form while transferring to an electronic health records system.  These forms could contain check boxes, note boxes, radio buttons, selection lists, and even images that can be marked up.  He should be able to input data either by typing, scribbling on a pad, or voice to text or just record his voice for transcribers.

Now enhance it another level.  You are a large practice with 15 different specialties and 40 providers in multiple locations in different time zones.  So how are you going to have all these different set of forms in a single EHR if all they allow you to do is tweak some static form?

The letter by the AMA continues to say,“We believe there is an urgent need to change the current certification program to better align end-to-end testing to focus on EHR usability, interoperability and safety,” the group said. “Physician informaticists and vendors have reported to us that MU (meaningful use) certification has become the priority in health information technology design at the expense of meeting physician customers’ needs, patient safety and product innovation.” So you see: MU certification alone was the goal of all the leading EHR companies.  Check out the blueEHR WYSIWYG (what you see is what you get) form builder to see the power of building your own form without the help of a “techie.”


Unit testing “does little to assure a product’s performance once deployed in a clinical environment,” the group wrote. Instead, the AMA and the others said EHRs should be rigorously tested “against a multitude of clinical scenarios that represent the variety of workflows seen in acute and ambulatory care settings.”

This is where most, if not all, EHR companies fail.  They all have one workflow for every office.  Many do not even have a treatment plan, let alone a workflow designer.

So what is a treatment plan? It is a set of actions at a defined period of time to meet a particular objective as it relates to the treatment of a patient.  You should be able to track the progress of the plan and tweak it and alter it as you go along. Rigidity is anathema in this case.

Especially in the age of personalized medicine the doctor must have the ability to allocate a treatment plan for each individual patient.  The EHR systems who claim they have a treatment plan do not usually have patient specific plan. Case management and tracking must also follow this process.

Workflow relates to the practice.  How they see a patient and how the process is handled in a clinical environment is key.  Nobody has even thought of adding this in the EHR system because they don’t see the EHR as an Electronic Health Solution, but just a place to store Electronic Health Records.  A sort of digital filing cabinet if you will.

Check out blueEHR CDR engine tool  to see how to build a treatment plan and a work flow.

Many practices and organizations have found their answer to these problems by adopting the open source alternative.  Another alternative is to check out the open source hybrid model of blueEHR.

It could have been Einstein who said “If you can’t explain it to a six year old, you don’t understand it yourself.”  I would say that is what the EHR system should do, present the highly complicated world of digital health to the end user in a way that they can use it cognitively and intuitively.