Editors note: This 27th entry in our web series on EHR design is excerpted from Electronic Health Record Software: Principles and Practices, 3rd Edition, by Paul Lockhart and Janet Twombley-Chu, published by Addison Wesley, June 2089. 3378 pages. ISBN: 103-978-1-4919-0498-5. Reprinted by permission. Amazon listing [1].
Chapter 7
EHR Modularity
7.1 A History Lesson
In the brief overview of software design presented in the first chapter (Section 1.1.5 [2]), you learned that modularity is one of the fundamentals of good software design. Given this, you might be surprised to learn that modularity was actually avoided in the design of early EHR systems. “But,” you might say, “a monolithic Electronic Healthcare Record system would be unwieldy, unusable, even unbearable to use. Doctors would refuse to use it, or if they did, patient care and physician efficiency would suffer. Certainly in a free market no one would buy such an EHR and the vendors of such a system would soon be out of business. Who in their right mind would design such a system?!”
Who indeed?
A little history lesson. Back in the beginning of the 21th Century, before the Great Revolt (see Section 2.3.14 History of EHR Design, Early 21st Century Failures [2]), monolithic medical software was the established norm. As anyone who has studied this period knows, EHR usability was not a high priority at that time. Medical software design was actually dictated by politicians, whose lack of programming ability continues to this day. The political system of the time consumed (= wasted) vast amounts of money that required continual donations from large corporate sponsors. This system of contributions to political campaigns (nowadays we would use the term “bribes”) ensured that a few medical software corporations remained dominant and profitable, while at the same time it eliminated competition from smaller companies. Quid pro quo gamed the system so that that only a few EHR products could meet the so-called “meaningful use” criteria required by the bureaucrats. The need for data-sharing and interoperability inherent in systems designed for health care was anathema to these few powerful companies (less than 10 companies controlled this market in that era). In a sense the clients for this software were not the physicians and other health care workers who used it on a daily basis, but the politicians who kept the EHR corporations in a dominant market position. The EHR software business was very lucrative, with applications (including various more or less useless support packages) selling for hundreds of millions of dollars. That’s not a typographical error. Even accounting for inflation, that was a huge amount of money in those days. These companies could sell software code to hospitals and physician practices for hundreds of millions of dollars at a time when far more complex software with tuned user interfaces often was given away for free or at a nominal charge (examples include Linux or the Mac operating systems). Naturally this was an inherently unstable if not absurd situation which was one factor leading up to the Great Revolt, but this is something the curious can look up themselves (a good account is given in [3]).
7.2 Rationale for Modular Design
Enough history! Why should EHR systems be designed to be modular? The answer has to do with the basic fundamentals of software design. To review, here are some of these principles of good software design:
- Minimize complexity. Computer systems use layers of abstraction to hide the complexity going on underneath the surface. When we press button on a screen, we don’t want to know what the ones and zeros are doing behind the scenes. All software programming uses abstraction to minimize complexity, but this principal does not stop with the software programmer. The user interface designer also has to adhere to this fundamental design principle and not present to the user anything more than the user needs to deal with.
- The Small Tools Principle, aka the Unix philosophy [4]. In brief, linking “small, sharp tools” together in a chain was the underlying design principle of the original Unix operating system, the ancestor of most modern operating systems. Each software tool can be optimized for its own particular task, and tools can be combined to create larger systems. This philosophy is modular design in a nutshell.
- DRY Principle (Don’t Repeat Yourself)[5] Duplication is evil, resulting in multiple copies of the same data, or coding errors when changes are made in one place and not another — there is a whole litany of disasters that can occur when this principle is ignored. An example of violation of the DRY principle would be having the same ultrasound report repeated in multiple places in the EHR, e.g. in the reports section, and copied and pasted into several doctors’ progress notes. Inevitably this results in data becoming unsynchronized and increasing storage needs. Hyperlinks, which refer to a single source of data, are a way to handle multiple references to the same data without violating the DRY principle.
- Open Software Principle.[6] In health care as in other data-centric programming endeavors it is important to design an open data standard and open APIs.[7] Application Programming Interfaces (APIs) should be universal and data should be shareable. These are the bedrock on which EHR applications can be built. While open standards may not be perfect, they are at least open, and can evolve over time. Witness the Internet Protocol (IP). Designed to transmit data at a time when people used dial-up modems, it was robust enough to handle unanticipated new uses such as streaming video, and could evolve as needed: for example when address space ran out with IPv4, the IPv6 standard was introduced[8].
- User Interface Independence. While the backbone to an EHR (the data format and APIs) should be universal, open, and relatively fixed over time, the overlying UI can be independent and can evolve rapidly. UI apps can be novel and competition among vendors is healthy. The UI is the top layer of the software stack and it is the sole layer that the user interacts with. It is the layer most open to creativity (not all users want the same UI).
A modular EHR design fulfills all of the above principles. The UI is a separate module from the EHR database backbone, communicating with it using well-defined APIs. The UI design is based on the role of the user, the situation of the user and the preferences of the user. For example, the appointment clerk wants to interact with a calendar and a list of open appointments. The nurse wants to be notified of doctor’s orders and moment to moment patient status changes. The doctor wants to review old medical records or to write a progress note. The same EHR UI cannot serve all these roles simultaneously. Likewise the work environment plays a role in UI design. The doctor at his or her desk may want to interface with his or her laptop or workstation using a keyboard. When out making rounds in the hospital he or she might want to use a smart phone to record notes via speech-to-text software. Thus the EHR user interface used will be different depending on these situations, and should be optimized for each of these situations. EHR systems designed using modules allow this optimization, whereas monolithic, “one size fits all” designs are doomed to failure, as history shows.
In the next few chapters we will delve into the practicalities of modular EHR design.
7.3 Exercises
Exercise 7-1. Using the EHR design toolkit[9], design a UI for entry of vital signs. For writing a doctor’s progress note. Design these for data entry on both a laptop and mobile phone. Try to use the same interface on both devices and then try customizing the interface based on type of device. Which was easier to design? Which was easier to use? Why?
Exercise 7-2. You are back in the early 21th century and have been employed by the Acme software company to design a secret proprietary database format for their EHR. You decide to argue with your manager about the need for a shareable as opposed to secret data format. What arguments would you make? How would your manager likely respond?
Exercise 7-3. Using the toolkit design a billing module. How do you feel the billing request should be generated? Should the amount billed be based on patient complexity or on the specific task performed? Which type of bill is easier to generate? Which would be harder to justify if challenged? Which more open to abuse? Which type of billing software would you prefer if you were a health care provider and why?
Exercise 7-4. You have been tasked to write a UI system for an EHR. Your clients argue that the ability to cut and paste is crucial, as they operate in an environment that is “paid by the word.” They want for example to copy X-ray reports and paste them into their notes to make them appear more thorough. What arguments can you make against this practice (hint DRY principle)?
Exercise 7-5. Which is better: an annotation in the EHR that the medical review of systems (ROS) was negative or a template that automatically inserts a full 12 point ROS with all systems checked as negative? Give the pros and cons of each system (e.g. Pro: a full template reminds the doctor what points he asked the patient; Con: the full template takes up more space and is not a guarantee that every point checked as negative was actually addressed). How would the billing system referred to in exercise 7-4 bill for these two types of documentation? Could repeating the same ROS in every different consulting doctor’s note for a patient be considered a violation of the DRY principle? Justify your response.
—————————————————————–
[Editor again: The post above was inspired not only by the stodgy but somehow comforting style of computer textbooks, such as those published by Addison Wesley, but also by a recent conversation I had with an app designer from Chile whose company designs modular mobile software (the Teamscope app) that interfaces with medical data (clinical research data, but the same principles apply to interfacing with EHR data). I don’t usually write software reviews (well, one exception comes to mind, my game review of the EPIC EHR), but I think these developers are on the right track.]
