Each person has likes and dislikes, things they do well, things they do with difficulty, and things they are simply unable to do. So it is with technology.
"Can the Ethiopian change his skin, or the leopard his spots?"
Adam Clarke says of Jeremiah 13:23 in his commentary on the Bible: "Can [anyone], at his own pleasure, change the color of his skin? Can the leopard at will change the variety of his spots? These things are natural to them, and they cannot be altered."
Each person is a product of their genetic heritage and early rearing. Thus, each person has likes and dislikes, things they do well, things they do with difficulty, and things they are simply unable to do. So it is with technology. At the inception of each technology, as the decisions necessary to define its fundamental structure and behavior are taken, the personality of the new technology is molded. As strengths and capabilities are introduced, the things that the technology will be able to do easily are determined. Other potential capabilities (that may or may not become important in the future) are made more difficult or are precluded entirely as a side effect of the decisions that are made.
An awareness of these factors can expand your ability to evaluate healthcare-related technologies and software beyond the usual hit-and-miss method of defining requirements - a method that is about as precise as was medical diagnosis in 1850. Instead it becomes possible to formulate hypotheses about how a technology will be likely to perform, what it will be able to do. In short, it is possible to develop theories about the technology. The hypotheses thus formulated lead one to expect the presence or absence of specific attributes or behaviors. If, when evaluating a product, one's hypotheses are validated, then one can be more confident that they understand how the product functions and what can be expected from it. If hypotheses are not validated, one can project the ways in which the product will be unsuitable and why.
Thinking about computer systems and software in this way involves understanding their ontogeny which, of course, includes expectations, constraints, and design decisions that were made at the dawn of computer time as well as a succession of others that have been made since.
Up to this point the discussion has been short on specifics. If I was a reader, I would be thinking "Yes, I follow that, but what next?" I would need specific examples before I could comprehend the implied paradigm shift. In the weeks to come I will present some of those examples. It may then become as obvious to you, as it is to me, that many the problems with the current generation of EHR products can be explained by their genetic heritage and early rearing. For those who can't wait, think about the reasons behind Y2K. And, by the way, while you were reading this the original Internet ran out of addresses.
This is the first in a series of blogs on the existing architecture of EHR systems, for more, check next week’s blog post.