EHRs Are Designed for Data Entry, Not Work Flow
EHRs Are Designed for Data Entry, Not Work Flow
I spent some time the other day in a post-procedure recovery room at a Kaiser facility while a friend recovered from conscious sedation. This provided an opportunity to watch Kaiser’s EPIC EHR in action as the nurse charted the various required assessments. I was impressed by how long it took to complete the charting. The nurse's mouse was flitting madly around the screen. Every element on the checklist in the center of the screen, when clicked, generated a cascade of pop-up windows at various locations on the screen but mostly in the lower right corner. At least five minutes were occupied in this manner.
I have personally built applications that collected a similar volume of information but in different ways, none of which were that time consuming. I have also observed other applications that were similarly streamlined. This got me thinking about the root cause of the relative inefficiency of what I observed.
The difference can be summed up succinctly: The primary purpose of some applications seems to be to collect data while for others, it is to assist someone in efficiently performing a task, silently collecting data as a by-product.
The situation is not unique to EHRs. Over the years I have studied dozens of so-called "application generators." They work like this: First you design a database, not difficult if it is a database of contacts, the inventory of raw materials in a factory, or a web storefront. Second, you point the generator at the database and it "generates" one or more screens for each table in the database. Third, using these screens you begin entering data.
You might object that there is more to a useful application than the ability to see and work on the raw tables in the database, and you would be right. These applications are nothing but CRUD. Create, Read, Update, and Delete (CRUD) are the four basic functions needed to be able to store and use information that persists. CRUD dates back at least as far as James Martin's 1983 book "Managing the Data-base Environment" [^1]. For many, the primary purpose of an application is to perform these basic operations in a way that the data will eventually be available for reporting.
I'm sure you will agree that the typical EHR user does not want to know or care about these details. The question is, does their EHR expose users to these unpleasant details or keep them hidden from view, and to what extent?
What I observed at Kaiser bore a strong resemblance to a CRUD application, nicely embellished with a bunch of pop-up windows, each presenting a list of allowable responses. There was nothing about the application that streamlined the documentation process or that was tailored to the cramped physical environment. Now sensitized, you may detect the CRUD in other EHRs and other apps in general.
Whatever other failings they may have, all could be improved by building applications that have the goal of getting the real work done in the shortest possible time and with the least effort. I won't bore you with some of the solutions that have occurred to me, and could occur to you.
Once you start thinking outside of the CRUDdy box, the possibilities are limitless.
[^1] Martin, James (1983), "Managing the Data-base Environment," Englewood Cliffs, New Jersey: Prentice-Hall, p. 381, ISBN 0-13-550582-8.
Aren't we as physicians to blame for this sad state of affairs. Aren't we smart enough to be able to solve the problem, rather than just complain about it ?
Dr Aniruddha Malpani, MD
Medical Director
HELP - Health Education Library for People
[Promotional content deleted.]
I agree that we have a hand in it. But, frankly, physicians in practice likely don't have the time or resources to be able to break into the EMR process other than on the subscriber end. I have found, as a physician with at least 3 different EMR companies, that the process for providing feedback is either absent, minimal or overly onerous. Most physicians are not familiar with EMR company forums or feedback options, and often we feel like ours is one voice so what can it matter?
Unfortunately, the cost of an EMR can be so devastating once you've locked in with one and are not happy, the cost to change doesn't exactly make you likely to want to make that change. It's hardly like buying a pair of pants, finding you don't like the fit and returning it to the store.
Again, as consumers, we've put ourselves in this position, but I believe that the incentive program has also maneuvered us into this situation as well.
I agree completely. I personally own a medical billing company, but also run my father's medical office, so I see what he does on hand written notes and dictated notes, and often wonder why the EHRs have to be so combersome. The programming of these systems is done by programmers, not doctors, and there is little if any MD collaboration. There are too many clicks, and "cloned" notes are the only way to spead through most aspects of a note, but if you do that you get in trouble. Why can't these systems recognize how a doctor takes notes, recognize that the numbers after BP or Blood Pressure is the BP, why do we need to enter it in a sepperate box. There is structured data and there is inefficiancy. And these systems are inefficiant, combersome, and not user friendly, or as my father likes to say "not ready for prime time!"
These are the most cogent thoughts I have seen on EMR in a long time! Most posts talk about meaningful use, government incentives, and other such issues that have little to do with a physician diagnosing and treating a given patient's illness. I think there is a lot of frankly fraudulent data in EMR's such as urologists documenting that the patient denies feelings of hopelessness or suicidality. The social planners would love to have the behavioral data in the various EMR's, but we don't need physicians who spend decades in training to become data input clerks. Our professional societies have let us down in not recommending a nearly universal platform ten years ago. "User friendly" has become a dated term, but we need a user friendly product which is sensitive to the work flow in a busy physicians office. I have yet to see it.
I could not agree more! I am constantly reminded when learning new EMR systems, that the systems are designed to catch parameters to send for billing and incentive purpose. They were not designed from the provider point of view: I want an office note that provides the data that a scrawled hand written or dictated note is supposed to provide. I want it to be clear what the problem was, the assessment and the plan.
Some EMRs do this well. I have not received an ER note yet from a system that has gone to an EMR that is easy to navigate and follows the patient through from entry to exit. There is such over documentation of small data points that the bigger picture is lost for the provider trying to care for their patient post-ER visit or hospitalization. While the data points are supposedly important, where is the narrative of the patient course?
EMRs are for programmers and billers, not for providers looking to find their patients' medical story. It's disappointing.