Requiem for our favorite EMR

Simple, efficient, quick, reliable, intuitive and accurate. That's Mountain Meadow Medical Records, and that's what I wish for all electronic health records to be so that doctors can provide better care.

Unfortunately, regulations intended to promote quality, security and interoperability have instead hobbled healthcare providers. Indeed, intrusive computer technology slows work, distracts precious time and thought from the more important tasks and even hinders communications between doctors. To meet regulations software often produces copious and meticulously codified pages of information in which one can hardly find any of the doctor's actual words or thoughts. Even the meticulously codified information is often inaccurate because data entry is so time consuming it almost always resorts to three risky tricks: 1. Importing previously entered information that might or might not still be accurate, 2. Generating long default sentences or paragraphs of which the clinician is expected to read and correct what isn't true (called charting by exception), and 3. Presenting long checklists which require a nurse to ask/answer so many questions that entry fatigue and time constraints result in wrong clicks.

Since its inception in 2003 Mountain Meadow has the goal of obtaining and displaying a patient's information to facilitate the doctor's primary work, caring for the patient. Here's how we do it:


Keep it simply simple! We concentrate on the core functions because too many special features introduce confusion and unintended mistakes. We do the basic activities really well, and leave the special custom features to plug-in pieces.


Let us facilitate work, not hinder it. Documenting the clinician's observations and conclusions comprises the biggest workflow bottleneck in electronic medical records. Therefore, we allow for different modes of entry depending on the doctor's personality and circumstances, including point and click branching trees of options in a customizable template, dictation with voice recognition or via a transcriptionist and free text typing.

Importantly, we measure the hindrance in terms of how much we take the doctors attention away from the patient or their own thoughts which is a different measure than how many seconds or how many clicks something takes. For example, even a slow typing doctor can enter a couple of words while a patient is speaking. They will learn to type while looking at the patient instead of the keyboard if they do it every day, and still concentrate on communicating. On the other hand, clicking choices from templates requires attention to the screen, reading what choices there are and making decisions as they go. Furthermore, in the history taking they may have to interrupt the patient to ask the questions the computer wants to know rather than adjusting to the story the patient is telling.

As another example, keyboard shortcuts that are used every day don't require concentration on the keyboard- it's always the same. But clicking a mouse on the screen requires seeing the screen, maneuvering the mouse pointer zeroing in on the target point, then clicking. Even if they take the same amount of time, the mouse click interrupts the clinician's attention more.

We also make use of inter-program-piece messaging to keep users from having to enter information twice. If we chart in the notes that we did a pap smear the chart note piece informs the preventive medicine piece to update that task, for instance. If we add a diagnosis to the problem list the chart notes template automatically merges that diagnosis and any associated templates on the fly.


A doctor will review more information when it is quick and easy to find. We expect less than500ms screen refresh time as we move from one section to another. We chose the client-server architecture over the popular "thin client," or "application service provider" architecture because it gives quicker page changes and more complete control over every pixel of screen. Thin clients are popular because each machine uses a browser interface that doesn't require updates when the program updates are installed on the server. But our C# Windows Forms clients update themselves from the database at login. Those updates are quick and easy, after which the program is the same on every computer and is not even vulnerable to problems when a new browser version comes out.


Please don't make a clinician see a patient without their medical record! In thirteen years of active service we have had next to no down time. Once our server was knocked out by an electrical storm and we transferred immediately to the backup server which still worked. Another time the power stayed off for half a day but the backup server was a laptop so we could carry it around to reference the patients we needed to see. Several times we have had loss of Internet connectivity which precluded e-prescribing but the rest of Mountain Meadow worked fine, including printing paper prescriptions because our server is in the building.


Our interface might be excessively simple. Most of the functions of the medical record are accessible from a single vertical sidebar, much like a paper chart with tabs. But even more complicated systems should have all functions easily found on a branching menu system in logical compartments.

Anyone who has implemented a new computer system knows the phenomenon of a steep and difficult learning curve after which the common daily tasks become familiar and easier and users stop complaining. At that point users are more interested in minimizing numbers of clicks required than on finding things easily. There is no reason a good program can't have both virtues though. It can be intuitive with easily found parts for new users and old users doing new things, as well as quick navigation with few clicks for experienced users.

For ease of learning new navigation, we use visible cues on the header or sidebar part of the screen that can be clicked. But for quick daily use navigation we use keyboard shortcuts to do the same tasks. Our keyboard shortcuts are obvious as they are either Alt-key pressed with the underlined letter of a button or menu item, or the Ctrl-key pressed with the capital letter in the sidebar.


Our data is more accurate because it is so easy to enter exactly what we mean, because problem lists and medication lists are quick to update and because our reports are not padded with more information than we reviewed.

For instance, we believe the chart note template should be simple. The normal default for cardiovascular auscultation is simply called "RRR" and only inserts the text, "Regular in rate and rhythm," when clicked. If someone wants to specify further they can click, "Murmur," "None," or alternatively, "Murmur," "Grade," "III," "In axilla." They can also enter whatever free text they want to describe the details. We intentionally avoid long sentences like, "Heart sounds are regular in rate and rhythm without murmurs, gallops or rubs," which rely on the user to read them and cross out the parts they didn't specifically listen for. If a user disagrees with us and wants to enter long sentences with single clicks, they can certainly do that because the template is completely customizable. However, as a rule we think simplicity correlates with accuracy of documentation.

Here's hoping these principles will help us be better doctors.

Wesley Eastridge, MD