EHR Best Practices Highly Touted, But Don't Exist
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
Challenge with the EHR mandate is that the federal government has already set the timer long before the solutions had cleared the drawing board.
In short, there are financial penalties (i.e. reduced payment for services) to those who choose to await the "getting the bugs out" version.
There are also financial penalties, in terms of lost productivity, for adopting most EHRs. The Feds have done medicine a great disservice by disrupting the normal evolutionary processes of software development by the certification requirement.I cannot avoid thinking that the mandate to adopt an EHR may be one more thing that drives physicians to abandon medicine entirely, or medicare in particular, rather than deal with increasing intrusions into what used to be an enjoyable profession.
From my experience, it appears that no one with medical knowledge is ever consulted during the develoment of the medical note portion of an EHR. People with just enough knowledge to be dangerous take it upon themselves to develop templates for the medical note that change the SOAP layout, describe the exam findings with vague layman terminology and redefine words that already have strict medical meaning. As the provider, I feel that my portion of the EHR - the medical note - has become the least important part. I want my note to succsinctly reflect my medical findings and impressions. Instead, my note is 3 pages long and sounds like it was written by a teenager who saw too many episodes of "House."
Your comment reinforces my assertion that in most so-called EHRs the physicians note is something of an afterthought. I suspect that you are correct in your assumption that many of them are designed by individuals without medical knowledge, and more importantly, without experience as a practicing physician. One of the most glaring consequences is that the typical note function, focused as they tend to be on SOAP and lots of boilerplate, produces a system that is unbalanced. While it might be remotely useful to someone whose practice precisely mirrors the intended use, it totally ignores the fact that there are many other types of encounters, many other medical settings and many other goals to be achieved.
This means that the typical EHR is a JOKE if the expectations is that it will assist in creating a lifetime medical record. The soap note format is totally unsuitable for use by many subspecialties such as ophthalmology, ENT, ortho, gyn, neurology and it is totally unsuited for real-time documentation of procedure notes, especially if they include serial sets of vital signs and serial reassessments, all of which are part of a single procedure.
If you have been following this blog you may have detected my repeated allusions to the fact that I have found the solution to the problem that you have described. I have hesitated to discuss it in detail because it is not my intention to use this blog as a forum for advertising and also because the existing implementation in not "certified" and is therefore of little interest to most potential customers. Suffice it to say that there is a way to do what you envision and it can be done quickly and efficiently while leaving the physician in total control of the organization and content of their notes.
Thank you for your comment.
Actually, you can meet meaningful use criteria without using the EHR to write progress notes (not that this would be a good idea). I have a very bare bones EHR (RxNT) and love it because I can use it with mostly free text and not a lot of clicks. My plan is to take the federal money (2011, 2012, maybe 2013) and then when the requirements get too tough abandon the effort and accept the penalties. But I'm 68, so my plan may not work for everyone.
Not only is medicine very individual and quirky, the whole EHR effort involves conflicting goals. Want to record your visit? Free text is fine. Want to generate data usable by researchers and quality care people? You'll need structured data with lots of boxes and buttons to click. Want to share with your consultant? Another set of needs.
Dan, this is such a great article, one which I have been looking for in my HIT consulting role. I hope to use it in one of my next blogs at Digital Health Space