You Can't Teach an Old EHR New Tricks

Even the best physician could use a little help managing information. There are patient details, things that occurred to you at the beginning of a visit that you need to do later, things that need follow-up and knowledge (both old and new) to keep up with. It all boils down to a lot of context-dependent remembering.

I wish for an assistant that was a good clinician in their own right and who was blessed with a perfect memory. I would have them participate in the visit and make impeccable notes (written and mental) of everything significant that transpired. They would initiate requests to implement the treatment plan, remind me of the things that needed to be reviewed or done during the visit, search the literature for me - well, you get the idea. Even if I could find such a person to be my "information manager," I couldn't afford to pay them.

I hope that a computer may, someday, be able to act as the assistant I can't afford. The typical EHR can't do this job for a couple of reasons:

1. Many early investigators got co-opted into working on problems related to healthcare operations. They neither had the time to consider, nor did the problems present, complex information management challenges.

2. The prevailing paradigm of computing was suited to the problems they tackled but not to the broader challenges posed by creating a computerized assistant.

The architecture of today's EHRs remains centered on clerical transaction processing. Neither minor "patches" nor tacking on a "documentation module" or a "rule engine" can alter their essential nature. Problems, such as order entry, result reporting, and hospital admissions are just too simple. Anyone can build such a system. I've built them myself, for tens of thousands, not billions, and built them in weeks, not years. They have been used in solo practices and 1,200-bed hospitals. Given a good design, they cost what they cost, regardless of the size of the facility. It's just not that hard, as demonstrated by the over 1,200 EHRs already certified.

Unfortunately the certification criteria do not force developers to think deeply about system design or information theory. The simplicity of the criteria does not demand new concepts or new technology. Building a certified EHR today is much like building a cinderblock wall. It requires only money and a supply of labor and materials, not a great architectural insight or a breakthrough in structural engineering or computer science.

To design a great computer system, one needs to confront the right problem - one that is hard in the right way. Some problems, as indicated above, are too simple. Some are complex, due to the number of exceptions that must be handled, but not complicated. A truly hard problem is one that, because of the exceptions and correction factors needed to solve it in the prevailing way, cries out for insight and reformulation - for a new paradigm that will transform the complicated into something that can be represented as a simple, orderly structure. One that treats most of the former "exceptions" to ordinary situations the fit a pattern.

How does one choose the "right" hard problem? It takes talent combined with serendipity. If Einstein had been thinking about genetics, he might have had a great insight into genetics, or not, but he would not have come up with e=mc².

Assuming you accept this argument, how can you use it in your practice? Don't "invest" effort in something that you hate in the hope that it will improve dramatically in future versions. It won't. It can't. Its core personality was determined at conception. If your goal is to be the best doctor you can be, don't get sucked into being a clerk as well. Limit your personal interaction with the EHR to those things that demonstrably help you be a better doctor. Ignore everything else that you can't leave to hired help.

EHR is one case where you cannot teach an old dog new tricks; you can't teach that which can't learn.