With EHRs, Irregular Pegs Don’t Fit Well into Any Hole

For the previous post in this series, click here.

"Neurosis is the inability to tolerate ambiguity."
- Sigmund Freud

“A worker may be the hammer's master, but the hammer still prevails.”
- Milan Kundera

"Much of the software available today is poorly written, inadequate in its facilities, and altogether a number of years behind the most advanced state of the art."
- Professor Maurice V. Wilkes, September 1973

If you have tried to use an EHR you may agree wholeheartedly, even if you weren’t aware that the underlying problems date back to the time when the computer system’s initial design decisions were made.

We all know that a good history is important for making a diagnosis and managing treatment. Traditionally, the physician kept most of the subtleties and complexities of each patient's history in their head and used the medical record, often on a 5x8 card, as a memory jogger. A few key words along with the diagnosis and any other major event were considered adequate. Physicians trusted their memories and were rarely in doubt although they may have been wrong.

Today, the expectation is that the patient's history, along with all that subtlety and detail will be recorded in the EHR. To the physician, details are additional information about the patient; the computer expects precise bits of data that will fit nicely into ready-made slots like antigens into receptors. Thus, the computer does not lend itself to recording subtlety as data. They do much better in banks.

In the real world, important historical information is often approximate. For example, tetanus boosters are recommended every 10 years. If we administered it then we know the date. If it is necessary to ask the patient, the answer is unlikely to be a date; a more likely response is "I had one in 2001." Most computer systems won't accept "about 2001" as a date. Most programming languages will not allow a date variable to be empty. Some users get inventive and enter 1/1/2001 or 7/1/2001 to represent the ambiguous date. Once in the database, I defy anyone to tell the "about 2001" information apart from a booster that was actually given on 7/1/2001. It's always a bad practice to put incorrect data into a database because there is no telling how it will be misinterpreted later. The need to accommodate ambiguity was not addressed at the time the programming language and the database were developed and as a result there is no straightforward, standardized way of dealing with it.

Some EHR vendors have developed their own proprietary ways of dealing with this and some have ignored it. For those who have, interoperability and the ability to migrate data to a different product in the future are compromised. For those that haven't addressed it, well, those products are just unpleasant to use and are loaded with questionable data leading physicians to doubt the credibility of the system. A better solution is needed; one that includes validated procedures for performing calculations and displaying results on approximate data - a good research topic should anyone think that building a good EHR is simply an implementation detail.

If you stop to think about it, the issues surrounding approximate data are obvious (even if the solutions aren't.) What is less obvious is the fact that even numerical data that is precise when entered can become approximate inside the computer. Bo Einarsson * has summarized these problems as follows:

"Approximations occur at all levels [within the computer.] Continuous functions are replaced by discretized versions. Infinite processes are replaced by finite ones. Real numbers are replaced by finite precision numbers. As a result, errors are built into the mathematical fabric of scientific software which cannot be avoided. At best they can be judiciously managed. The nature of these errors, and how they are propagated, must be understood if the resulting software is to be accurate and reliable."

Many of the limitations of today's EHRs result from the failure to accommodate approximate and "missing" data and/or the developer's attempts to work-around the issue. This problem is likely to persist until there is a new generation of languages and databases that have integral support for ambiguity and approximation.

The next article will wrap up this series by presenting an overview of what the next generation of EHR - kind of an architect's rendering of your new house situated on its lot complete with landscaping.

* Reference of the week: Accuracy and Reliability in Scientific Computing, Bo Einarsson, Society for Industrial and Applied Mathematics, Philadelphia, 2005.

Learn more about Daniel Essin and our other contributing bloggers here.