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.
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.