For the last few weeks or so, I have taken time from other activities in order to take a fresh look at EHR design. This was not on my to-do list. It came about because of my interest in how usability, workflow, and other design issues affect implementation success. EHR implementation is a source of FUD for many clinicians, and the main reason that I hear for this disquiet is loss of productivity. Obviously, every clinician’s experience varies, but significant productivity decreases are real. Typically, the biggest complaints are related to altered workflows—usually associated with data entry and EHR-feature navigation. Repeatedly hearing the same complaints made me wonder how EHR systems might be improved, and reawakened my inner EHR designer.
In the United States, there are two major standards aimed at describing an electronic health record: ASTM 1384-7 and the HL7 EHR System Functional Model. Standard Practice for Content and Structure of the Electronic Health Record, the ASTM 1384-7 standard, provides detailed guidance on what information an EHR should contain and how that information is best organized to form a coherent record. The goal of the HL7 EHR System Functional Model (HL7 EHR-S FM) is to:
… provide a summary understanding of functions that may be present in an Electronic Health Record System (EHR-S), from a user perspective, to enable consistent expression of system functionality.
While both standards deal with key aspects of electronic health records, neither offers specifics on how to build a working EHR. For example, they (intentionally) do not provide information on matters such as database schema, concept representations, workflow patterns, or user interfaces.
Building an ideal EHR requires solving a set of fundamentally hard problems:
- Building a database that can properly store current and future data elements
- Creating computable representations of clinical concepts
- Developing a sophisticated reporting engine
- Creating a workflow representation that can be adjusted for different users and clinical specialties
- Providing state-of-the-art security and auditing features
- Offering support for data exchange and semantic interoperability
- Providing flexible, configurable user interfaces that support a range of interaction modalities (e.g. voice, touch, mouse, pen)
No EHR designer can hope to get all of these features right the first time. This means every EHR is a work-in-progress. Unfortunately, aside from the standards mentioned, there are no other widely-accepted sources of guidance on designing EHRs. Moreover, many problems users complain about have no standard solution. No one knows the optimal way to implement decision support in EHRs or even the best way to implement a problem list. How should user interfaces be adapted to accommodate the wide range of clinical professionals who interact with patients? There are no firm answers to these questions.
Having had nearly eight years to mull over the design problems I faced when building an EHR, and now reviewing current user complaints, I am becoming convinced that many EHR design problems require mathematical analysis to arrive at optimal solutions. For example, workflows are graphs. Perhaps analyzing workflows using observational data of clinician activity along with graph theory might result in more robust systems than could be designed by simply observing clinicians and tinkering with code. Problem lists may be organized in a variety of ways: chronologically, acute vs. chronic, by specialty, by organ systems, active vs. resolved, or a combination of these. Perhaps rendering these permutations mathematically would allow for the creation of an efficient algorithm that could be shared by all EHR designers.
I now see EHR design as a discipline that needs, and will eventually develop, a strong mathematical and engineering foundation. EHRs can no longer be viewed merely as the combination of a front-end + a data store. We are moving away from EMRs, many of which originated as electronic attempts at emulating paper, to EHRs that are intended to act as sophisticated digital assistants. This requires complexity in EHRs beyond what is seen in current systems. Usability issues, productivity complaints, HIT safety concerns, and semantic interoperability problems are all evidence of the need for a new approach to EHR design. It is time for EHR design to move to the next level and become a more formal activity.