Blueprints for an Effective EHR are Still Incomplete

In recent articles I have addressed with what I consider to be the most important unanswered question about EHRs. Should an EHR be a group of clinical applications built on a solid foundation consisting of the information recorded in the chart in the course of providing care or is an EHR merely another business application, one that happens to be used in healthcare rather than banking, merchandising, or manufacturing?

When today's major EHRs were initially developed, everything favored not asking, and not even considering, this question. Added to the constraints of hardware that was too slow and very costly were urgency, poor software tools, and the fact that since healthcare computing was in its infancy; everyone was a novice. Few were inclined to consider that basic research was necessary; there was a job to do. For lack of having ever asked the question, it was answered by default. Available computer hardware and software were used in ways that mimicked what seemed to be "working" in other sectors. Those doing the work borrowed heavily from the design approaches and techniques of their exemplars.

The result, as many are painfully aware, is EHR  systems that are extremely costly to buy and use and which generally fall far short of meeting expectations. How long will the cost, inefficiency, and inflexibility of today's EHRs be tolerated in a world that is under constant pressure to cut cost?

One can only hope, as I do, that had a different approach been used - one that made the medical record the center of attention - the results would have been better. My personal experience with one alternate approach has satisfied me that the results can be better, and if not better, at least less costly and more "anti-fragile" (resilient, tolerant of ambiguity, and change, etc.).

There is no escaping it. New systems will need to be built sooner or later, perhaps much sooner than people realize. Will those who build them use the same techniques that produced sub-optimal results in the past? Will efforts to build the next generation of EHRs begin now, or will it be deferred until a crisis develops and there is again no time or inclination to think clearly?

If the medical record is to be the central feature,  the single repository of all patient and care related information, then one must settle the way in which chart information will be represented and manipulated "electronically" before one can start designing and building. There are a myriad of factors that impact the decision. Some have already been discussed; more will follow.

Taken together, the factors and the background behind them constitute a body of theory which, as far as I know, can be found nowhere except in the content of these articles and some of the references. No one who depends on grant funds to support research is working on this as no grants are offered. Existing EHR vendors are probably not working on it, for obvious reasons. The government is not promoting research in this area; they believe that the important questions have already been asked and answered.

Everyone understands how important it is for buildings to have a sound foundation. Over the years the theory necessary to engineer structures that will protect their occupants during earthquakes has advanced to the point that laws now require hospital buildings to be built in accordance with theory. This, after numerous hospitals built by rules of thumb have collapsed or been seriously damaged by past quakes.

Today's EHRs are not built on a sound foundation and their designs have little grounding in theory. Quakes can be expected as hardware becomes obsolete, EHR internals become increasingly complex and brittle dealing with exceptions and future regulation, and as organizations are pushed to the brink of insolvency by the direct and indirect costs of their EHRs.

Events of the past 10 years to 20 years make it obvious that the important questions about EHR systems are neither widely appreciated nor answered. So far, I have presented part of the story and will pick it up next time.