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.