Automating the Medical Record - Can Your EHR Help?

For years I've watched administrators get misty-eyed as they talked about their plans to "automate" the medical record and then proceeded to implement systems that increased the need for and the actual quantity of manual (non-automated) labor. In this article I'm going to make an assertion from which you may recoil: Automation is not possible without algorithms and a way to put them into effect. Planning a patient's diagnosis and treatment involves devising an algorithm and translating it in to a sequence of action steps - in other words, programming. Your initial reaction to the notion that doctoring involves programming may be to "run and hide in fear because everything you know [or don't know] about algorithms [and programming] reminds you of high-school Calculus nightmares," as Jonathan Cutrell described in "Understanding the Principles of Algorithm Design."

Let's deconstruct the assertion. An algorithm is a pre-defined set of steps that, if followed, achieve a specific goal. A program is nothing more than the algorithm - the steps - expressed in a language that can be understood (unambiguously) by whomever or whatever is going to carry them out. The algorithm is an abstract concept. The written set of steps is the program. It must be written because it must be communicated to those who will carry it out and because in medicine the law requires documentation. The programming language that most physicians use is a gemish [^1] of English and Medicalese. The written plan is a program for the care of a specific patient. It is usually intended that the plan will continue to be carried out (executed) until it ends normally, encounters some situation that was not anticipated (an exception) or it is changed in response to new or altered conditions.

At this point your care programs and computer programs diverge, to your disadvantage. A computer program is executed by a hardware device consisting of a processor, registers, memory, persistent memory, and input/output devices. In biological terms it is an effector. A care program is usually executed by people.

While the number of actions that a general purpose computer can perform is limited, it can perform those things faithfully and unerringly as often as needed. The results are highly reproducible, even if they are wrong. When people are the effectors neither timeliness, consistency, nor correctness is assured. People are neither predictable nor reproducible, in the way that a computer can be. Complicating matters - physicians who are not necessarily skilled in the art of programming. People misread programs, get distracted, use their judgment to handle exceptions inappropriately, and simply forget things. If anything can go wrong, it will. Better programs can help, but as long as people are expected to be the primary effectors, the dream that regulators have of turning Medicine into a smoothly functioning Six Sigma production line a la Toyota cannot be realized with currently available EHRs unless they undergo a drastic redesign.

Today's EHRs operate in parallel with the patient care process, not as part of it. The primary link between the EHR and care delivery is indirect. Portions of the care program may be entered into the EHR which then displays those items on a screen where they sit until they are noticed and acted upon by someone. There are circumstances when the link is more direct but these are rare. Examples of few ways in which the computer has a direct effect on patient care today are automated phone calls to remind patients about an appointment or a prescription refill.

An EHR can't and won't have a meaningful impact on patient care until it is embedded in the patient care process and can perform a variety of actions directly and until physicians write their care plans as programs that the EHR can execute. This means that physicians learn to write care programs that can be executed by either a person or a computer without crashing either the computer or the patient. This depends on, and awaits, the development a patient care programming language. Once developed it must be incorporated into an EHR and learned by physicians. Until then, there no point in pouring a lot of time and money into an EHR.

It's worth considering that perhaps an EHR should not be designed to have a meaningful impact on patient care; meaningful is not always good. It's just possible that, for all its faults, relying on people is preferable to the dehumanized, depopulated, and automated healthcare production-line-world envisioned by regulators. Perhaps that world would be better left to the domain of science fiction and fantasy. Doing so might allow us to get real and focus our attention on the needs of the patient. With the money we saved we might even be able to afford it.

[^1] GEMISH is an acronym for a computer language developed by Ed Hammond's group at Duke University that was used to create TMR. It also happens to be a Yiddish word meaning mixture.