The EHR Non-User Interface

Every time someone publishes an article or a paper or a blog post that has anything remotely to do with Electronic Health Records (EHR), there is usually a flurry of reactions in the comments section, now available in most publications, and these always include at least half a dozen anonymous statements, usually from clinicians, decrying the current state of EHR software, best summed up by a commenter on THCB: “It is the user interface stupid!... It has to be designed from the ground up to be an integral part of the patient care experience”. Can’t argue with that now, can you? Particularly when coming from a practicing physician.

And why argue at all? The user interface in any software product is the easiest thing to get right. All you need to do is apply some basic principles and tweak them based on talking to users, listening and observing them in their “natural habitat”. Having done exactly that, for an inordinate amount of time, and being aware that most EHR vendors were engaging in similar efforts, I found the growing discontent with EHR user interfaces somewhat inexplicable.  The common wisdom in EHR vendor circles is that doctors are unique in how they work and whenever you have two doctors in a room, there are at least three different preferences in how the EHR should present itself. As a result, you will find that most mature EHRs have dozens of different ways of accomplishing the same thing. These are called “user preferences” and are as confusing as anything you’ve ever seen. Hence the notion that if you spend enough time configuring and customizing your EHR upfront, you will increase your chances of having a less traumatic EHR experience down the road. We were an industry like no other, doomed to build software for users with no common denominator, or so I came to believe, until one afternoon in the summer of 2006…..

My personal moment of Zen occurred in an unremarkable little primary care practice somewhere in the Pacific Northwest, where a kind and wise physician offered me a chance to play doctor, right there in his cramped exam room. He handed me his shiny new tablet and sat in the patient chair across from my rolling stool. I saw that as the perfect opportunity to teach the doctor how to use “my” software. I designed large portions of it and I’ve done hundreds of “live” demos of patients with diabetes, hypertension, COPD and “by the way” to showcase the ease of use and uncanny abilities of the EHR to simplify the most onerous tasks. And then he started talking. A simple visit. A little bit of gout. Some stiffness when climbing stairs and he didn’t like his new blood pressure meds. I couldn’t keep up. I couldn’t find the right templates fast enough. I couldn’t find the right boxes to click on. I tried typing in the “versatile” text box. I am a lousy typist. I tried to write stuff down with the stylus in the “strategically located” handwriting recognition box. I kept making mistakes and couldn’t erase anything. I tried to type code words for completing the note later. My head was down and I was nervously fumbling with the stylus and the tablet keyboard and my rolling stool kept moving unexpectedly. I would have killed for a pencil and a piece of paper. I finally looked up in total defeat and saw the good doctor’s kind smile, “now you get it”. Indeed.

A recent Tech Crunch article is quoting Prof. Christensen’s (of Innovation fame) assertion that “Understanding the customer is the wrong thing to do — it’s confusing”. It seems that Prof. Christensen believes that “what’s really important is understanding the job that customers are trying to accomplish, and only once an entrepreneur truly understands the need that a product or service fulfills for the buyer can they optimize their business or product”. I couldn’t agree more. So what is the job that EHR customers are trying to accomplish? What need does the EHR fulfill for the buyer? Are the job and the need one and the same? They are not, and the difficulty in creating an interface that satisfies EHR users arises because doctors love the job and hate the need. The job is to heal people and the need is to be properly paid for services rendered, including an escalating system of regulatory incentives and penalties for activities not immediately related to patient care.

Most physicians would describe their job to be the provision of medical advice to patients seeking their help and, to paraphrase Sir William Osler, most doctors will probably agree that observing and understanding the patient who has the disease is much more important than understanding the disease itself. So what can a contemporary software program contribute to observing and understanding patients? Nothing of any significance. Someday we will have intelligent software accessing sensors plastered on patients’ organs and clothing and perhaps then software will be able to assist with observation and understanding. But right now software can only offer protocols for simple and self-evident conditions. If the original electronic calculators were only able to multiply single digit numbers, nobody would have bought anything from Texas Instruments in those early days.  How about the other parts of a physician’s job? Can EHR software help with delivering babies? Or performing surgery? Or at the very least, can it assist with a physical examination? Maybe an EHR can help with formulating treatment plans and ordering therapies? Mostly an EHR cannot do any of these things, and the little it can do comes at great inconvenience to physicians, when compared to methodologies it aims to replace.

But doctors are buying EHRs at increasing rates, so perhaps EHRs cannot help with the job itself, but they fulfill a need after all. The original need EHRs were designed to fulfill was the simple need for one to be paid for the job one was doing. This is the same universal need that drives every business to acquire and use accounting software. Generating proper invoices for services rendered (claims) was the first rationale for buying software in a medical establishment. As the rules and regulations for payments became more and more complex, the need for software increased and in parallel the software began interfering with the job. And although most physicians realized that they must allow the software to interfere if they wanted to get paid properly, it didn’t require that they like this interference. Most of us pay our taxes, but this does not stop any of us from complaining about the complexity and lack of user friendliness of the tax code. Later on, Meaningful Use and other “quality” reporting initiatives introduced regulations directly into the job of physicians and their staff. EHR software, still unable to contribute much to the job, is now fulfilling a much larger and more onerous compliance need, and at least from a physician perspective, it still has to do with being paid appropriately for services rendered.

Designing an EHR from the ground up to be an integral part of the patient care experience, as the anonymous commenting physician suggested, was never in the cards. EHR software was born to fulfill externally imposed needs, and as such it was destined to be regarded with suspicion and when those needs started invading every aspect of the job, even early supporters of computerization became disenchanted with EHRs. It doesn’t really matter how many user centered usability experts the government regulates that EHR vendors employ, because it’s not about the buttons and the clicks, it’s about what the buttons do. At a recent conference I saw a presentation delivered by two primary care doctors who found a way to restore happiness to the practice of medicine. Every slide had a picture of an exam room where in addition to a happy doctor holding the hand of a sweet patient, there was a third “team member” in the background fumbling with a tablet.

Shouldn’t there be a better way? At one point shortly before the advent of Meaningful Use, there was a slight buzz in the industry regarding something called EMR Lite. A brand new notion of creating software humble enough to take on the peripheral portions of the job that could be automated with existing technology. That seed of innovation was killed off by the perpetual onslaught of Meaningful Use requirements. Should it be revived? And if so, what should it look like? Stay tuned…..