We have all had the experience of trying to do something that could have been done easily with an appropriate tool when we didn't it — things like trying to tighten a screw with a dinner knife because there was no screwdriver handy or trying to bring home a 4-foot by 8-foot sheet of plywood in a sport coupe rather than in a pickup truck. With effort and luck, you might get these jobs done, but if the tasks recur, pretty soon you are going to either get the right tools or abandon the activity.
No matter what kind of screw you encounter, there is a screwdriver that will fit. Why is it that? The answer is that there are people who are familiar with every aspect of screw design, manufacture, and use, allowing them to anticipate most of the variations that screw users will need and want and no one creates a new screw type without creating a matching driver. Whenever a new variant would be useful, it is easy to add it to the product line without creating any side effects that would affect existing screwdrivers. Indeed, I have screwdrivers made by my grandfather in 1895. Their continuing utility is not altered by the fact that when they were made there were no torx, pozidriv, or pentalobe screws. The same applies to saws, drills, and plumbing aids.
On the other hand, some tools are designed and built by people that have neither theoretical knowledge about nor experience with the tasks for which a tool is intended. They arrive at a design by applying whatever knowledge and experience they have and they improvise the rest. They make assumptions about what they, with their limited experience, imagine will be the use of the tool. Sometimes their guesses are correct but often they are not.
Would you want your new house built by workers that not only lacked the right tools but who knew so little about building that they did not comprehend that there might be a "right" tool? I don't know about you, but I know from personal experience that my answer to this question is No, no, no.
EHR construction is analogous to house construction in many ways. As with a building it begins with an architect, usually working in a particular frame of reference. The frame may be defined by the architect's knowledge of medical information theory, but most commonly the frame of reference is one that assumes that medicine is pretty much like any other business that needs a computer system. The task of the builders is to faithfully translate the architect's concept into a working product using the tools and materials specified by the architect, with the remaining implementation details left primarily in the hands of the builders. The primary tool of the builders is the programming language, but where do programming languages and other tools come from?
The programming languages used to build EHRs have, so far, come from two
sources: 1.) a language (MUMPS) developed in a medical setting at a time when there was little medically-related theory or experience to guide its design; and 2.) "general purpose" languages developed to serve a wide variety of applications (mostly business, military, and scientific), again by people that neither had medicine in mind nor knew much about medicine's unique data requirements. Designers of languages either build one from the specifications of a language architect for a specific purpose or they decide what a language should do by surveying potential users, add their own experience and knowledge of computer science, and then try to anticipate the unforeseen.
If the real information that physicians would like an EHR to accept and process does not fit naturally into the data structures allowed by the programming language — and it does not — the information will be trimmed, flattened, folded, and otherwise mutilated until it does fit. If the data storage elements provide no way to differentiate between data that is unknown and data that was known but not entered — and they don't — you will never get an accurate denominator for any outcome or quality measure. If there is no way to differentiate between precise and approximate information — and there isn't — then you will never know how much weight to give any piece of information.
If an EHR is primarily expected to capture charges and diagnosis codes for billing — and that is what most of the major ones were originally designed to do — a general purpose programming language is fine. If we want an EHR to collect clinically relevant information, in detail, so that we can get accurate statistics and reason about patient's problems and treatment, then the typical programming language, and the EHR created with it, is worse than nothing. We expend maximum effort to use it and get minimal benefit and indeterminate results in return. I rest my case.
Find out more about Dan Essin and our other Practice Notes bloggers.
