Pre/post-implementation studies typically use a few standard measures. Business metrics (e.g., total cost of ownership, return on investment, revenue changes) and clinical metrics (e.g., patient visit levels, visit duration) are employed to get an understanding of how the EHR’s presence has impacted the organization (1,2,3). Unfortunately, clinical metrics often assess the post-implementation state from too high a level to detect actual changes in clinician productivity. As a result, they do not convey the underlying reality that clinicians experience.
Dimensions of clinical work
Clinical work does not require the presence of a patient. If we define clinical work as “any activity undertaken by a clinician to support the diagnosis and management of patients,” then clinical work often occurs outside of patient encounters.
Results management is a huge part of patient care. I used to spend at least an hour each day reviewing results and planning future interventions. This work was done at my desk, usually after hours. When results were expected and the proper follow up already in the works (i.e., patient has elevated liver enzymes, but presented with signs of hepatitis) life was good. However, there were many times when a change in therapy was required or a diagnostic workup plan was altered by unexpected results. A new breast mass, unexpected liver enzyme elevations, a call from a patient, or my personal favorite, microscopic hematuria, could easily result in chart reviews, literature searches, or calls to a colleagues. This is clinical work, and current post-implementation metrics do not measure it.
Care coordination is another activity that can occur outside of patient encounters. One of the few times I had a terminal patient in hospice care required many phones calls to family and discussions about pain management. The notes were in the patient’s record, but the work was done outside of any visit.
Complaints related to documentation completion also fail to show in EHR productivity metrics. Completing documentation after patients have left is doing clinical work, but it is not counted.
When workarounds occur, they consume clinician time, but may not affect patient visit levels. Instead, one may simply end up with nurses that are more harried or more distracted doctors.
Usability provides a view into productivity. The number of clicks required to create a referral or write a prescription certainly count as productivity measures. Patient visit levels can obscure productivity issues by shifting work after hours. For example, systems that require too many clicks may force note writing into after-clinic hours.
Training is another example of a hidden productivity drain. EHR systems that take multiple days or weeks of training to gain proficiency, take time away from other non-patient-encounter clinical work.
Clinical work that occurs outside of patient encounters may be the hidden factor confounding EHR satisfaction surveys. Every few months or so, survey results are reported as saying that: a) doctors hate their EHRs and b) given a choice, doctors would not go back to paper. Such discrepancies can be explained, in part, by understanding the positive and negative consequences of EHR implementation. EHR systems can make it a breeze to review labs or order a referral. However, support for results management varies greatly among systems. Writing notes might be a pain, but preventive care management might be easy. Robust care coordination support is not a major feature of most EHR systems. C-suite inhabitants reviewing typical post-implementation metrics see acceptable patient throughput, but not the actual number of hours clinical staff have to put in to achieve those numbers. Patient throughput and clinical productivity are NOT the same thing.
Ultimately, the problem of EHR use and clinician productivity comes down to a simple design decision: EHR systems are designed to replace paper charts, especially during patient encounters, not to support the full range of clinical work. Billable clinical work receives the greatest consideration.
Designing better clinical systems
Clinical work has to become the basis for clinical system designs. Much of what doctors, nurses, and allied health professionals do when they are not seeing patients is just as much clinical work as patient encounters. For system designers this means looking at clinical processes holistically. It also means looking at care coordination, population health management, results management, preventive care and referral management as important clinical processes that require HIT support.
Since these activities do not require direct patient interactions, why should they be accessed through user interfaces that are designed for patient encounters? Care coordination is about communication and collaboration as much as it is about accessing patient information. Systems supporting care coordination should allow for chats (text/video), screen-sharing, data exchange, and project management-type functions, features uncommon to current EHR systems. All clinical processes listed above present special requirements, so shoehorning all of them into a typical EHR user interface makes no sense.
Architecturally speaking, we have two categories of applications—one requiring optimization for use during direct patient encounters and the other requiring optimization for specific subtypes of clinical work. Practically speaking, one could achieve this by using an architecture similar to that proposed in Building Clinical Care Software Systems. Patient data repositories would be designed as ReSTful resources that clinical applications interact with via APIs. Using such an approach would allow clinical applications to be written, tested, and optimized individually. The patient data/EHR layer would become the platform that other applications were built on. EHR-as-a-service (EHRaaS) or patient data-as-a-service (PDaaS) could be a boon to innovation by providing an ecosystem for applications aimed at niche clinical processes. Many EHR vendors already allow third-party apps to interact with their systems. This would move it up a notch. In fact, I can see a market for a vendor who supplies only the skeleton PDaaS platform.
Looking at productivity from the standpoint of clinical professionals, whether designing systems or metrics, can lead to greater end-user satisfaction. Making care coordination, population health management, results management, preventive care, and referral management first-class citizens alongside patient encounters would make these activities more visible to metrics designers and software developers. All are important for care quality, and patient throughput metrics generally ignore them. Each of these activities can easily spill over to after-clinic hours, and some happen only then. They consume time after-hours and on weekends that put-upon clinical professionals would love to recoup, and better software tools can help. Here’s a metric that would be meaningful to clinicians: “Amount of time after clinic required to complete patient-related work.” Hint: lower numbers are better…