Clinical Workflow Analysis: The Value of Task-Level Detail

EHR selection and implementation, usability, and software design all share a common set of goals, the most important of which are ensuring that users are productive and that patients receive quality care.   Workflow analysis as an adjunct to system selection and implementation is old news (1).  Perhaps, the recent ground swell of interest in usability and, by extension software design, points to another potentially useful application of workflow data.  Obviously, software design and usability affect implementation and productivity. Why not, then, use the knowledge captured during workflow analysis across all four areas?

Properly conducted, workflow analysis reveals important information about what occurs in an organization.  Analyzing key processes and determining the tasks involved in completing them helps organizations to eliminate redundancies and identify activities requiring further optimization (1).  Conceivably, workflow data taken from a representative cross-section of similar organizations could prove to be useful for software designers.   For example, having workflow data from 500 primary care internal medicine practices should provide invaluable information to software designers concerning clinician work habits and information needs that could be mapped directly to EHR software features, functions, and workflows.    It seems reasonable to assume that this type of information would be helpful for other healthcare initiatives such as meaningful use and patient safety as well.

As I see it, the lack of granularity in workflow analyses used primarily for selection/implementation is the major obstacle preventing their use in guiding software design and usability testing.   Allow me to illustrate this point using two typical workflow diagrams provided by AHRQ.    (I am using AHRQ workflow materials because they are the closest thing that I am aware of to a reference set and they are  freely available.)

Here are two diagrams provided in AHRQ’s Workflow Assessment Toolkit.  The first diagram, In-office Prescribing-Paper System, uses a swim lane format and captures the prescribing process prior to EHR implementation.  It notes three provider tasks: evaluate patient, patient need (sic) prescription or refill, and write out prescription and/or refill.   The second diagram, In-office Prescribing-Electronic System, captures how the prescribing process should work once the EHR is in place.   Here, four provider tasks are noted: Log-in to EMR, evaluate patient, patient need (sic) prescription or refill, and write out prescription and/or refill.

When considering workflows, one must look at things from two perspectives.  The first is at the process level. The process level illustrates all personnel involved and how they interact.   This is very useful for sorting out redundant tasks (one or more people doing the same thing) or unnecessary tasks (why do we do that at all?).    When selecting an EHR, process-level information can help one determine if a product offers the basic functionality required.  For example, it is obvious that this practice needs an EHR that supports prescribing.   Process-level analyses help to assure that no important tasks are ignored or forgotten when reviewing products.

Once again, consider both diagrams, but from the level of the provider and how he/she might be supported by an EHR.   At the level of the provider, the only difference between the two diagrams is the Log-in to the EMR system task. Neither diagram captures sufficient information about how each task is carried out (on paper or with the EHR) to allow one to determine if the provider will be more productive or possibly even hampered by the EHR.   Common prescribing actions – check formulary, select drug, enter the number of pills to dispense, write patient instructions, allergy check, interaction check—the specific steps required in writing a prescription,  are subsumed under Write out prescription and/or refill in the diagram.   Thus, information that is suitable for usability testing or software design assistance is absent (i.e., there is a lack of task-level granularity).

Workflow analyses that capture detailed task-level information can be very helpful in creating test scripts and evaluating EHR usability (see posts Preventing Your EHR from Working Against You: I, II, and III).   Further, there is no reason that detailed task-level analyses should not be equally useful to EHR shoppers and EHR builders, as both are interested in how the EHR conforms to typical users’ needs.   Finally, one could go in the other direction and have vendors create task-level workflow maps of their products, which might help buyers with product selection and maybe training as well.  After all, training is mostly about learning a product’s workflow.

Above, I alluded to the possibility of pooling workflow data from multiple sites for review/analysis.   The main barrier to creating analyzable workflow databases/libraries is the lack of a standard, widely-used representation format for workflows.    While a number of tools exist (e.g., Petri nets, activity diagrams, flow charts), there are no constraints on how organizations use them. Thus, organizations using the same tool to map the same process may use different names for tasks, a variable number of tasks per process, or different process start and end points.   This is a difficult challenge, but not an insurmountable one.  As someone involved in software development, I would welcome the availability of workflow databases that I could download and use as a basis for new projects –sort of like having access to an archive of building blueprints.   The underlying idea is the same—not reinventing the wheel.

Now that workflow analysis has gone mainstream, and usability and software design have gained mindshare, perhaps it is time to explore more fully the shared workflow properties of EHR selection, implementation, usability, and software design.

(If you found this post helpful, you may wish read this tutorial series on workflow patterns and clinical workflow analysis.)

1.  Carter JH. From process analysis to product evaluation. In Carter, JH. Electronic Health Records,  Second Edition. Philadelphia, PA: American College of Physicians; 2008: 345-355.

For a good introduction to workflow analysis see Workflow Management: Models, Methods and Systems by Wil van der Aaslt and Kees van Hee.




  1. Hello,
    I am looking for a way to show optimization in the EHR to resistant physicians. I enjoyed your discussion and want some concrete evidence for them. I agree that it can hamper their productivity and slow them down. I have witnessed lately the EHR being used incorrectly to just get the numbers needed for MU. I also see many practices holding on to so much paper causing redundancies that make it feel inefficient. How do I make believers out of them and convert the resistant!

    1. Michelle, thanks for your comment. I believe the best first-step in realizing the benefits of an EHR for anyone begins with the understanding that an EHR is not simply a software application, but also a system for documenting and assisting with patient care. Since providers together with the paper record also constitute a system, failure to recognize the true three-fold nature of EHRs causes problems.

      Those who began the move to EHRs with the belief that EHRs are simply complex software applications soon hit a productivity wall when the EHR, in the guise of a documentation and care assistant, makes its presence felt. In light of this, getting things back on track requires looking at the most common processes (processes are comprised of tasks) that occur in a practice and 1) reconciling them to their EHR equivalents then 2) optimizing these processes with the EHR over time. Of course, this requires time and effort, but it is the only approach that seems to work.

      “How do I make believers out of them and convert the resistant!”
      Perhaps identifying the processes that consume the most provider time and/or that have the greatest impact on revenue would be a good starting point. Pick no more than three. From there, as best you can, do before and after analyses (before = either when things were paper-based or how things work inefficiently now with the EHR). Once the “before” scenarios are documented, create plans to optimize the identified processes. After process changes are implemented, measure everything affected (time, number of clicks, number of screens, revenue, etc.). Repeat this cycle for any process you study until either it is optimal or it becomes clear that it cannot be fixed. Be aware that one outcome of this approach may be that you decide the EHR system is the main culprit and should be replaced.

Leave a Reply

Your email address will not be published. Required fields are marked *