Computers & Software Medicine Stories

I’m a Better Computer Than Any Doctor

[Ed note: I couldn’t resist writing the following after reading this post on by Dr. Keith Pochick. Please read it first. Apologies in advance.]

I’m a Better Computer Than Any Doctor

“I love you,” she said as she was leaving the room.

“I, I um…”

“Not you. Your computer.” She cast my computer, still warm and glowing with its brilliantly colored logout screen, a glance of longing and desire, and left the exam room.

“Oh, I thought…”

The slamming of the exam room door clipped off whatever the end of that sentence might have been.

I sat down and rolled my chair over to the computer. I stared at the mutely glowing screen. It stared back at me, mockingly perhaps, daring me to click the OK button and log out. Which is what I should have done. She had been my last patient of the afternoon. Not that my day was over. I had to go back to the hospital to see a couple of consults that had come in during office hours. And I was on call tonight. I was tired, but that didn’t matter.

Yet here was this stupid machine in front of me, getting all the credit when I was doing all the work.

I was in a sour and contrary mood. I cancelled the logout. The busy EHR screen reappeared — my patient’s data, all fields filled, all checkboxes checked, and all meaningful use buttons pushed. Yet somehow, despite fulfilling all my data entry duties, I didn’t feel satisfied. Who was the doctor here anyway? Me or the blasted computer?

I scanned my patient’s history. Female. Black. 45 years old. Diabetes. Abscess. The boxes were all ticked, but somehow the list of characteristics failed to capture the essence of my patient. Where were the checkboxes for sweet, smart, chatty, charming, or stoic? How was I going to, five minutes from now, distinguish her from every other “female-black-middle-aged-diabetic-with-abscess” patient? Of course the computer wouldn’t have any problem figuring out who she was. Birthdate, social security number, telephone number, or patient ID number — all those meaningless (to me) numbers were easy for the computer to remember. I had to make due with trying to remember her name, and her story — a story that had been diluted down and filtered out of any meaningful human content by the wretched EHR program.

My patient hadn’t had to interact directly with the computer like I did. All she saw was me looking up information, me typing in information, me staring at the screen. All she saw during most of the visit was my back. From her point of view I was just a conduit between her and the computer — the real doctor in the room. I was just a glorified data entry clerk. It was the computer that made sure that I was compliant with standard medical practice, that the drugs I ordered did not conflict with the other drugs I had ordered, and that I didn’t otherwise screw up her care. I shouldn’t have been surprised that her last remark had been addressed to the computer and not me.

“Well, screw this,” I remarked to no one in particular. Suddenly angry, I reached down and yanked the powercord of the computer from its electrical socket.

There was a brief flash on the screen. But it didn’t go dark. Instead a dialog box appeared accompanied by an ominous looking red explanation point icon.

“Warning,” it read. “External power loss. Backup battery in use. To protect against data loss, please shut down the computer using the Power Down button. Never turn off power to computer while it is running.”

The condescending tone of this message only made me angrier. I looked at the base of the stand that the computer sat on. Sure enough there was a big black block with a glowing red LED. Must be the backup battery. A thick power cable connected the battery to the computer box.

I grabbed the power cable and wrenched it loose from the backup battery.

Sitting back up I expected to finally see a nice dark screen. Data-loss be damned!

The screen was still on. The EHR program was still on. Another dialog box had replaced the first. The red exclamation point had been replaced by a black skull-and-crossbones icon.

“Critical Error!” it read. “All external power lost. Internal backup power now in use to preserve critical patient data. Local data will be backed up to main server, after which this unit will shut down in an orderly fashion. DO NOT ATTEMPT TO INTERFERE WITH THIS PROCESS AS IT WILL RESULT IN THE INEVITABLE LOSS OF CRITICAL PATIENT DATA!!”

At that moment the gauntlet had been thrown down. I knew what I had to do. Let the dogs of war be unleashed!

In the moment before I acted I imagined the reaction of the software engineers at the company that created our EHR program. “I knew we couldn’t trust doctors with our software. We give them a simple job to do. Just enter the data into the system, print out the generated instruction sheets, and send the patients on their way with a merry ‘have a nice day.’ I knew we should have programmed the stupid doctors out of the loop.”

Too late for that, I thought. My chair crashed down on the computer, smashed the monitor to pieces, and caved in the aluminum siding of the computer case. Sparks flew and the air filled with the smell of smoke and ozone. Suddenly the exam room went dark. The circuit breakers must have tripped when I short-circuited the computer.

The room was not completely dark. There was a glowing rectangle on my desk. My heart skipped a beat, then I realized it was just my phone. I had left it on the desk. Why was it glowing? Probably a text or email or something.

I picked up the phone. It was the mobile app version of our EHR program. A dialog box filled the screen. The icon was a round black bomb with an animated burning fuse GIF.

“FATAL ERROR!,” it read. “You are responsible for the IRRETRIEVABLE LOSS of CRITICAL PATIENT DATA. In doing so you have violated the unbreakable bond of trust between the PATIENT and the COMPUTER. This is a breach of the EHR contract made between you, your hospital system, and our company, as well as a breach of the EULA for this software. As such, you will be terminated.”

Strange use of words, I thought. Also strange that the bomb GIF animation seemed to show the fuse burning down…


Hospital Board Meeting — One Week Later

Hospital CTO: “So it appears that Dr. Stanton, in a fit of anger at our EHR system, took it upon himself to smash his computer. The cause of the resultant explosion that killed him is, certainly, still somewhat unclear.”

Hospital CEO: “Unclear?”

Hosital CFO: “I hate to interrupt, but I didn’t think there was anything in a computer that could blow up, no matter how much you smash it up. Am I wrong?”

Hospital CTO: “Well ordinarily, yes that’s true.”

Hospital CEO: “Ordinarily?”

Hospital COO: “Let’s be clear. Dr. Stanton certainly violated our contract with the ____ EHR Corporation.”

Hospital CEO: “Violated?”

Hospital CBO: “It’s clearly stated on page 197 of the contract that any attempt to reverse engineer or otherwise try to, uh, figure out how the EHR program works is a violation of the contract.”

Hospital CEO: “Smashing the computer was an attempt to reverse engineer the program?”

Hospital CTO: “I think that we would be on shaky legal grounds to argue otherwise.”

Hospital CEO (nodding to the elderly doctor seated at the other end of the table): “What’s your opinion, Frank?”

Medical Board President: “Well, as the only physician representative here, I’ve become more and more concerned that our EHR system is subsuming more and more of the traditional role of the physician.”

Hospital CXO: “Oh come on!”

Hospital CSO: “Same old story from the docs every time!”

Hospital CCO: “Broken record, I’d say.”

Hospital CEO: “Gentlemen, and Ms. Jones, enough already. This has been an unfortunate accident, and at this point our major concern has to be that there is no adverse publicity that could harm us in our battle against the ______ Hospital System, our sworn and bitter rivals. Accidents happen. The party line is that we are all upset that we lost Dr. Stanton, one of the best EHR data entry operators we had. OK? Meeting adjourned.”

Hospital CEO (Privately to hospital CTO as the meeting breaks up): “George, when are they updating that damn software. You know, that stuff we saw at the Las Vegas EHR convention last month. Where we can finally get rid of these damn meddling doctors who are constantly screwing up our EHR.”

Hospital CTO: “Bob, believe me, it can’t come soon enough. Not soon enough.”


Computers & Software Medicine

How to Build a Better Electronic Health Record Part 27 — Modularity

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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].
  5. 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.]


[1] This is a listing in a future version of Amazon, hence it is not available yet.
[2] Only available to purchasers of the full version of this text.
[3] This citation refers to a work that has not been written yet.
[4] See Eric Raymond’s The Art of Unix Programming
[6] This citation also refers to a work of the future that doesn’t exist yet.
[7] Ibid.
[8] Yes Wikipedia is still essential in the future.
[9] The EHR toolkit will be available when the book is published, 74 years from now.