EHR Best Practices Highly Touted, But Don't Exist

The number and scope of the workarounds that one finds in an EHR is a good indicator of the quality of the design. Usually, however, the process of making compromises (one kind of workaround) begins the moment the architect envisions a new system. The initial vision is, in essence, a theory of how EHR works. It may be consistent with established theory or something totally novel.

The architect, having designed other kinds of systems, may assume that EHRs are nothing out of the ordinary - what worked for a bank or an e-commerce application should be perfectly adequate. The architect's vision may be totally unique, influenced by neither existing theory nor practice. Some ideas and assumptions are better than others. Not knowing how to predict the performance characteristics of a new design, developers reply on experimentation and testing to differentiate the good from the bad. They build it; the customer, acting as a "lab rat" becomes the subject of the experiment. Experience will eventually answer the question, but by that time the customer feels "locked in."

Once the architecture of the new EHR is defined, a development team must be assembled and set to work. Again, there is a choice between a developer that has in-depth knowledge about the theory of medical information and years of experience implementing these specialized systems or one that is like a handyman or jack-of-all-trades, skilled in what are known as “best practices.”

For "best practices" read: Today's favorite programming language, database, and methodology. In IT, the "best practices" are analogous to the products and advice that you can get at the Home Depot - items that sell in high volume and are widely used. The first developer, familiar with the theoretical foundations will use specialized techniques and materials (if available) and produce an elegant product. The second developer’s product will be a collection of workarounds, each necessitated by the fact that the “best practices” are not, in fact, best for developing EHRs.

Best practices are not best because electronic health records present unique requirements that differ qualitatively from those of a generic data-oriented application. Medical information is complex, nuanced, often fragmentary, and rarely precise and the popular programming languages and databases are ill-equipped to address these aspects. There could be tools and techniques that are specialized and tailored to the unique needs of the medical record, but there are not. Even if there were, the typical computer-science graduate or amateur that has been pressed into service as a "programmer" might not know about them.

Computer science students learn only a few standard techniques and a bit of generic theory and are given simplified problems to work. The tools and techniques used in the curriculum reflect the "best practices" - after all, schools want to be seen as teaching "marketable" skills. The students learn neither "esoteric" computer science nor medicine's unique requirements yet school is where programmers begin to develop a style. The tools, techniques and concepts to which they are exposed become their palette and gradually become second-nature, allowing them to be most comfortable and productive.

When a design decision is required or an obstacle is encountered, most developers will devise a solution that draws on what they already know and how they learned to program. At least some of the time, what is done will be a workaround, not a definitive solution. The developers may not appreciate the implications of their actions and the customers will neither be aware of nor appreciate the implications of those actions. This is, however, the means by which EHRs accumulate workarounds during development. The users gradually discover that there are aspects of the EHR (or the entire experience) that they don't like and they have no idea why. They will respond be devising their own workarounds on top of the developer's workarounds.

Elaborate statistics are not needed to know that this formulation is correct. The need to devise yet another workaround for your EHR constitutes an existence-proof that something, or things, about the design and implementation neither anticipated the need nor provided sufficient flexibility to accommodate it gracefully. Such an EHR is flawed - the users realize that they found it necessary to workaround it in order to care for patients properly or run the organization effectively.

The shortcomings that qualify as flaws are in the eye of the beholder and each practice is different. Nevertheless, when the cost of an EHR are 400 percent greater than initial estimates (e.g. Kaiser) and the list of workarounds includes increasing the time allocated to each visit, hiring more practitioners, and paying physicians to train and act as medical coders, It doesn't take a rocket scientist to conclude that there is at least one flaw in that EHR and it is not a small one.

Knowing that the typical EHR is flawed is a good reason to steer clear of the hype. Have a clear definition of what an electronic health record should, can and cannot do, focus on a few practical, simple-minded goals and don't get greedy