What could we have done differently, is the question I hear from many of the healthcare executives with whom I speak about the productivity loss resulting from their EHR.
My answer, nothing. I am willing to bet that in most cases your EHR was implemented correctly. I am just as willing to bet that the training was executed well. “If we did everything correctly, then why is the EHR performing so poorly?”
Fair question. The EHR is not performing poorly. It is performing exactly as it was written to perform. If that is true, why is there such a dichotomy between how it is working and how we need it to work? That is the perfect question to be asking. Here is why. If you interviewed your EHR vendor and asked them to tell you how the system is supposed to work when a nurse or doctor is with a patient they will tell you something like this:
We wrote the system to mimic what doctors and nurses need to do during an examination. Start with getting a history of the present illness (HPI). Then get vital signs, list of allergies, significant events, medical history, current meds, and lab and test results. Then write any prescriptions, order tests, and end the visit.
Very neat, very orderly. Linear. Move from Task 1, to Task 2. Just the way the EHR was written, just the way doctors were trained to conduct an exam.
Unfortunately, most exams do not follow that flow. Why? Patients. Somebody forgot to tell the patients and the clinicians that, in order for the EHR to work in anything that could be construed to be an effective and efficient manner, the exam must be conducted according to the EHR’s script. In order to minimize the number of screen navigations and clicks, you must complete all of Task 1 before moving on to Task 2. Linear. Front to back.
Exams are not linear. Patients generally dictate much of the order of an exam. They move indiscriminately and randomly from one task to the other. This randomness causes the clinician to hop about the screens in the EHR in an ad-hoc manner. Data entry and screen navigation are neither orderly nor complete. Nor are they front to back. The patient may start the exam with a question about lab result or about a side-effect of a medication.
All of this jumping around adds time, more time than what was allotted for the exam. Imagine that on your desktop you have several programs running; PowerPoint, Word, Excel, and email. Instead of completing what you hoped to accomplish in one program, closing it, and moving on to your next task, you were forced after each minute to stop what you were doing in one program and go work on something different in the next program.
Is there anyone who doubts that it would have taken less time to complete all your tasks if you were allowed to complete one before starting the other?
You EHR was not designed to work efficiently in an non-linear exam. Chances are good that your EHR was never really designed at all. Were designers, professionals with advanced degrees in human factors — cognitive psychology, heuristics, taxonomy, and anthropology — asked to determine how the EHR would need to work? Did they watch users work prior to writing code? Did the EHR firm iteratively build prototypes and then measure how users used it in a research lab that tracked hand and eye movements? If not, that is why I think it is fair to characterize EHRs as having been built, not designed.
The good news is that even at this point, even as you continue to watch productivity drop, you can choose to bring design in to solve the problem. Retraining will not solve the problem. After all, it was trained users who helped bring about the productivity loss.