EMR event log study shows 6 hrs of use per day, but implicitly belittles the clinician’s cognitive effort and the EMR’s support

In a recent paper in the Annals of Family Medicine by Brian Arndt and colleagues at the University of Wisconsin, the authors described the results of an analysis of the user event logs of their Epic EMR.  The authors determined that primary care clinicians used the system nearly 6 hours per day out of an 11.4 hour work day, and that 44% of that time was spent on tasks that the authors categorized as “clerical and administrative.”  It is an interesting paper, but I think it represents a lack of vision and insight on the part of the authors regarding the role that technology can and should play in supporting the cognitive effort of clinicians.
Most specifically, when a clinician was using EMR-based template charting and orders modules, the authors categorized that work as “clerical.”  Such a classification fails to acknowledge that the clinician is (or should be) using such modules to create a coherent, evidence-based plan of care:
  • using condition-specific templates that help remind her of the clinical observations and treatments to consider,
  • viewing reminders and order sets to help her to remember to include important evidence-based services in the plan of care,
  • receiving alerts to help her avoid ordering services that may cause an allergic response, conflict with other medications that the patient is taking, or that are dosed inappropriately considering the body mass of the patient,
  • viewing prompts for a needed referral for care management, or
  • receiving referral guidance to help direct specialty referrals to the specialists that have agreed to integrate care processes with the primary care practice within a clinically integrated network or accountable care organization.

The authors implicitly dismiss the cognitive work being done by the clinician when they are doing “documentation” and “ordering” and the support that the technology is providing to that cognitive work.  They reduce it all down to being wasteful paperwork, and suggest that it be eliminated through voice dictation or assignment of such paperwork to other members of the care team — both of which would preclude the decision support to those important cognitive processes.

I share the authors’ implied frustration with the failure of the current generation of health information technology to live up to the long-standing vision of supporting clinicians’ decision-making and coordination of care across a multi-disciplinary care team.  I acknowledge that today’s EMR-based care planning and coordination functionality feels like clerical work.  I’ve spent time on that problem.  I have two patents on proposed solutions to that problem.  I hope some day to help solve that problem, which I consider to be one of the most important problems in the broad fields of health care improvement, population health management and medical informatics.
I strongly agree with the idea of using user event logs to study how users actually spend their time and how they use application functionality, and I applaud the author’s efforts to validate the event log data with some direct observations.  But, I don’t agree with the authors’ suggestion that others should use their “EHR task categories” because they implicitly reject the vision of real technology-assisted care planning and coordination.  We shouldn’t give up on that vision.  We can and must do better to make it reality.
Read More

Don’t pave the cow paths: The challenge of re-conceptualizing health care processes

There is a popular adage for information technology professionals: “Don’t pave the cow paths.”

I recently worked with a client from Texas, and they were fond of this adage. They said it with the most excellent drawl, giving it extra credibility, as if they may have actually learned it the hard way on their own ranches.

In the IT context, I interpret the adage to mean:

When designing an information technology solution for a business area, don’t just learn how they did the process manually and then create a software application to transfer that same process to computers. Rather, try to understand the underlying problem that the business process is trying to solve and the value that the business process is intended to create, and then take the opportunity to design a different processone that is rendered feasible with enabling information technology and that delivers greater value.

When designing a new process to replace an old one, the starting point is re-conceptualization. The process designer must shed some of the terminology used to describe the old process when that terminology is too strongly tied to the details of the old process. Rather, the designer must dig down to the more essential concepts, and choose labels that are simpler and purer, seeking fresh metaphors to provide cleaner terminology. Then, the new process and the associated data structures can be re-constructed on top of a conceptual foundation that is easier to talk about, simpler to manage, and more stable.

Once we have a strong conceptual foundation, we can then flesh out the details of how the process can be made leaner and more effective, enabled by information technologies. Obviously, the proposed new process design influences the selection and configuration of enabling technologies. But, awareness of the capabilities of various technologies can also help generate ideas about candidate process designs that will be rendered feasible by the technologies. Therefore, this process is inherently iterative. The old-school philosophy of getting sign-off on detailed system requirements before considering the technology solution was a response to a valid concern that people will fall in love with a technology and then inappropriately constrain their process design accordingly. But, applying that philosophy too rigorously causes the opposite problem. If process designers don’t know what’s possible, they naturally stick with their old conceptualization, which also serves to inappropriately constrain their process design. As with most hard things, effectiveness requires finding the right balance between two undesirable extremes.

An example: the case of “registries.”  

A “registry” is a list of patients. The list includes the evidence-based services they need and whether or not they have received them. It is like a tickler file to help members of the clinical team remember what preventive services and chronic condition management services need to be done, so the team can improve their performance on quality of care metrics and provide better care to their patients.

But, if you dig down, the more fundamental purpose of the registry can be conceptualized as enabling care relationship management and care planning processes. Conceptually, health care providers need to know which patients they are taking care of. That’s care relationship management. It involves integrating different sources of information about care relationships, including derived care relationshpis based on claims data (also called “attribution”) and declared care relationships from health plans, patients and physicians. Part of the function of a registry is to clarify and make explicit those care relationships. This simple function can be considered  radical to clinicians who have become accustomed to an environment where such care relationships have been ambiguous and implicit.

If a physician has a care relationship with a patient, then, conceptually, he or she has a professional responsibility to make and execute a plan of care for that patient. Care planning is the process of determining which problems the patient has and what services are needed to address those problems. Conceptually, a good care planning process also includes provisions for multi-disciplinary input by members of the clinical team.  And, a good care planning process also includes decision support, including alerts for necessary things missing from the care plan, and critique of things that have been put on the care plan.  Such critique can be based on clinical grounds, such as drug-drug interactions, drug allergies and drug dosing appropriateness. Or, they can be based on evidence-based medicine or health economic grounds, such as in utilization management processes.

The name “registry” is tied historically to the word “register” which is a type of paper book used for keeping lists of things. In the health care context, “registries” were used by public health officials to track births, outbreaks of infectious diseases and cancer tumors. So, when people think about chronic disease registries, their mental model of keeping a paper list is a barrier to their willingness to re-conceptualize the underlying function differently.  But, more fundamentally, a “registry” is just one type of tool to facilitate care relationship management and care planning — a tool designed to be used for a narrowly defined list of problems and services, rather than being designed for more general use.

Today, there is no single care plan for most patients.  The function of keeping track of the problems that need to be addressed is either not done or it is done in a haphazard way, peppered across various structured and unstructured encounter notes, scribbled on problem lists, auto-generated in clinical summaries based on diagnosis codes on billing records, checked off on health risk appraisals, etc.   The function of figuring out which services are necessary to address each problem is peppered across numerous clinical notes, requisition forms, e-prescribing systems, order entry systems, care management “action lists” and in the fields of registry systems.  The function of facilitating interdisciplinary input to a patient’s care occurs informally in hallway conversations, morning rounds, tumor board meetings, or, most commonly, not at all.  These are all care planning functions, but most clinicians have no familiarity with the concept of linking these diverse bits of data and process in a cleaner, simpler notion of managing a single care plan to be used and updated over time by the entire care team.  As far as they are concerned, such a notion is probably infeasible and unrealistic.  They’ve never seen a technology that can enable it to become reality.

Choosing the right leap distance.

Of course, when re-conceptualizing processes, it is possible to go too far.  Old habits, mental models, terminology, and processes die hard.  If your re-conceptualization is a great leap to a distant future state of elegantly conceptualized processes, it might end up being too difficult to convince people to take the leap with you.  Other adages come to mind:  “Don’t get in front of your headlights.” Then there is President Obama’s version: Don’t get “out over your skis.”  And my favorite, often quoted by Tom Durel, my old boss at Oceania, “Never confuse a clear vision for a short distance.”

The optimal “leap distance” is a function of motivation to change.  If people start to experience great pain in their current state and begin to fear the consequences of sticking to their old ways, change happens.  As we move forward to a world where providers are taking more economic risk and facing more severe consequences for failing to improve quality of care, we will be able to pursue bolder innovation and leap greater distances in our process and technology improvements.

Read More