The case for elegance in health care technology

It is well known that electronic health records (EHRs) can be frustrating to the health care providers who use them. Often described as “clunky” or “cumbersome,” I submit that a more accurate term is “inelegant.” As a solution to this problem, many have called for better user interfaces with adherence to good human-computer interaction principles. This is necessary, but I don’t think it’s sufficient. Although better user interfaces would improve the EHR user experience, I believe that we should reach for the broader goal of elegance in our EHRs and EHR-supporting solutions. 

The definition of “elegant” that best applies in this situation is “pleasingly ingenious and simple.” With respect to software, elegance reflects not just the user interface, but also what goes on “under the hood.” When you consider the user interface together with the guts upon which the user interface relies, you get a tool, presumably designed to accomplish a task. You recognize inelegance in a software tool viscerally—before you realize it cognitively—in the frustration that you feel, for example, when the software requires seemingly extraneous or non-intuitive steps to accomplish a task.  

In contrast, elegance is often appreciated only in hindsight if you reflect on how naturally you performed a task without needing to think much about how. Elegant software demands the least possible amount of the user’s time and cognitive effort to accomplish the task at hand. When a tool is well-suited to accomplish the task at hand, we call this good tool-task fit. I suggest that elegance as applied to user facing software also implies good tool-task fit, like asking Alexa to turn the lights on and it just works. 

Most EHRs are rife with inelegantly implemented features with poor tool-task fit. Here is an example: EHR vendors have not implemented a universally standardized controlled terminology for ordering laboratory tests. In the outpatient EHR that my practice uses, each laboratory testing provider has its own catalog of orderable tests and corresponding proprietary code set. The user can filter for a particular laboratory that is running a provider’s tests, but ultimately the user needs to select a different item to order a complete blood count from Lab A vs. Lab B.  

The physician user derives no additional value beyond selecting the test itself in the abstract, yet the EHR forces him to do so. Never mind that my practice’s EHR has only an inbound interface with our laboratory test providers. Choosing the item from the correct laboratory testing provider does not make a practical difference, nor is it efficient, because the lab order gets printed. A person at the laboratory testing provider identifies the appropriate proprietary code and reenters the test order into their system anyhow.  

A more elegant implementation of this feature would be to utilize a mapping of the various laboratory testing providers’ order catalogs to a standard terminology (I think that LOINC would be the best choice) to allow the physician user to select the test without respect to where it will be performed. Translation to the proper laboratory testing provider’s code set would occur automatically without the ordering physician’s intervention. Oh, and the order would be transmitted electronically rather than printed, but let’s consider that a separate issue. 

Here is another example. Recently I was rounding in my local hospital and wanted to consult a subspecialist on a case. The way to accomplish this task in my hospital’s EHR is to enter a “consult physician” order, which then exposes a free text search field in which the user types to search for the consultant physician by name. While this works if one knows the name of the physician to consult, sometimes we don’t know and would rather search by specialty, which is not possible in my hospital’s EHR.  

Furthermore, most physicians these days work in groups, so technically the consult would be for the group rather than the individual; consulting a physician from a given group functionally translates into consulting the group to which that physician belongs. At my hospital, a human ultimately reviews the consult order, figures out what physician group to which the consulted physician belongs, and perhaps which physician is taking new consults that day, then conveys the necessary information to the appropriate person.  

The process works, but only because a human compensates for poor tool-task fit, where the task is entering an order for a consulting physician at the appropriate level of granularity and conveying that order to the physician who will perform the consultation. A more elegant implementation of this feature would allow the consult-ordering physician to search for consultants by specialty, group name or physician name, aligning more naturally with how physicians think when searching for consultants. It would also automatically identify and transmit the consult order to the appropriate consultant without the need for a person in the middle. 

These are simple examples. Many more examples exist that impact EHR users’ daily work lives even more and in more complex ways. For the benefit of our clinicians and our patients, I want us to prioritize good tool-task fit and to strive for elegance. 

Adam Rothschild is a clinical informaticist with 3M Health Information Systems. 

Focus on the patient while the technology works in the background.