The Yin and Yang of data refers to the age-old tug-of-war between techniques that gather data and those that retrieve it. The pendulum is forever swinging, favoring one, then the other. The tools and techniques used to build software, particularly information gathering software, have serious deficiencies. You, the intended user, feel the impact. Applications are rigid, inefficient, and generally lacking in capability that is important to you. It is a testimony to your intelligence and creativity that you manage to use them at all and especially if you feel a sense of mastery over your EHR. Some of your colleagues are less fortunate.
When I studied programming (long before medical school) we had a mainframe equipped with a card reader and a printer. The challenge was to get data into the computer. After that, all the computer could do was perform calculations and print the results. The input process required hours at the keypunch machine (the IBM 029 if you go back that far), loading the cards in the reader and waiting hours or days later for the results.
The hot research topic of the day was "interactivity" — how to replace the keypunch and reader with a video terminal so you could enter code and data, execute the code and get results back on the screen, all in a few minutes. The folks doing this research were trying to create a capability, not an application. They wanted something that any programmer or sophisticated user could use to enter whatever code or data suited them.
Much early computing was concerned with statistical calculations and soon, bright people realized that the standard statistical formulas could be coded once and reused by non-programmer statisticians. A number of "statistical packages" appeared in short order — SAS, SPSS, BMDP, followed by many others. These packages are really meta-applications, ready to be turned into customized stat applications by providing some configuration information that describes the dataset and the specific calculations desired.
Why was this possible? Because, statistics projects are more alike than they are different. Those with a deep understanding of the work can anticipate the needs, and the likely pitfalls, and create a meta-application that accounts for most of that stuff.
With this background, when I first tackled the job of building an EHR, I recognized that my challenge was to get the information in and saved; getting it out was not going to be a limiting factor. By 1982, hundreds of computer programs had been developed to collect and store information. I assumed that someone must have realized that there was a pattern to this kind of application, just as there was in statistics so I went looking for a meta-application targeted at producing "forms" that would facilitate the entry of information. I tried 18 and with each I (we) attempted to construct an EHR [^Essin, DJ and Essin, CD: Computerizing Medical Records: Software criteria for systems to document patient encounters. Critical Care Medicine, 18:100-102, 1990].
All but one lacked the ability to specify enough details of how a field on the screen was to behave. In the process of the 18 attempts, I discovered what capabilities were needed by observing what real physicians try to do with the applications produced by each of the form-definers. If you were building a meta-application — a form-definer — your response would/should be to go back and add the missing capabilities in a generalized manner. Fortunately one of the 18 provided sufficient capability that I was able to produce EHR software that real doctors can use, have used, are still using and have enjoyed using.
By now you're all cheering "Way to go!" but then you wonder, if this thing was so great in the early 80s, where is it today? Why aren't we all using it? These are good questions but answers that would be too lengthy to include in this post.
The important point for this story is that the basic functions that a physician needs from an EHR have been well known for a long time, just as the needs of statisticians were well known in the 60s when the statistical packages were developed. In the sciences and engineering the number of meta-applications has continued to expand — LabVIEW, R, Matlab, Mathematica and Auto-CAD are examples. In medicine, nothing similar has appeared. Am I the only one that sees patterns in the medical work flow? Patterns that lend themselves to being captured in a meta-application, an EHR-definer, that could be customized by each practice with little, if any, custom programming? Maybe it's just that dealing with billing, coding, regulations, and certifications have stifled the creative thinkers, dulled their senses or diverted their attention away from those things that could not only make their work easier but actually improve patient care.
Find out more about Daniel Essin and our other Practice Notes bloggers.
