What is the best method for modeling clinical workflows and processes? This is an important question because so little pertaining to clinical workflow analysis is standardized. There are a number of diagramming tools that can be used to model processes and workflows—so many, in fact, that the choices can be overwhelming for someone entering the field. Considering how important process modeling is to software development, implementation, quality improvement, decision support, and a range of other initiatives, it is surprising that clinical process modeling has not gained a higher profile. Clinical workflow and process models lack formal standards and still rely on generic tools and methods.
On reviewing the ONC HIT Workflow-related curriculum materials, probably the most widely-distributed clinical workflow training resources, one finds a collection of the usual suspects—flowcharts, Yourdon and Gane-Sarson data flow diagrams, entity-relationship diagrams, and class, activity and state diagrams taken from UML. While all can be used for workflow and process modeling, they are generic and offer no specific support for clinical modeling.
Having used these modeling tools, I found them to be useful mostly for small problems. Trying to use them to capture complex processes and interactions was a no-go. There are too many types of diagrams. After a while, simply managing the diagrams requires as much effort as the analysis they are supposed to capture. (Those of you who follow this blog know that I consider Petri net-based tools, which are based on graph theory, to be superior to other process and workflow modeling methods.) Recently, while doing a literature review, I came across an article that looked at various modeling methods and how they are perceived by healthcare modelers.
In Health Care Process Modelling: Which Method When?, Jun and Ward et al. noted that flowcharts dominate modeling in health care. They then sought to introduce additional modeling methods to a group of subjects who had both clinical and non-clinical backgrounds. After researching various modeling methods, the authors settled on a final group of eight (see Table 2 in the article). Next they selected three clinical scenarios that were then used to create models for each method. Below is their description of how modeling methods were evaluated.
Building and validating the eight different models for each scenario, the researcher (G.J.) explained each of the models to a range of clinical and non-clinical staff (n = 29). The participants were first asked whether they have previously used the modelling methods. They were then asked to evaluate the usability and utility of them: 17 participants for the patient discharge process, 6 for the diabetic patient care process and 6 for the prostate cancer patient diagnostic process. Most of the evaluations were carried out one-on-one using an interview-based questionnaire for 40 to 90 minutes.
During the evaluation, participants were asked to rate their agreement on a five-point scale (strongly agree 5 to strongly disagree = 1) with the two statements: ‘This diagram is easily understandable (usability)’ and ‘This diagram is helpful in better understanding and communicating how the care process works (utility in better systems understanding)’. The participants were also invited to comment verbally on why they had made the particular rating, including what they thought were the strengths and weaknesses of each diagram. Their comments were audio-recorded.
Unsurprisingly, study subjects indicated that flowcharts were rated higher than other modeling methods. Of the methods tested, flowcharts are probably the easiest to grasp. They are great for group discussion and small workflows. However, they lack features that allow one to cleanly model state and concurrency, both of which are important in software development and implementation.
In their discussion, the authors conclude what anyone who has tried to do a detailed clinical workflow analysis has discovered:
The diagram characterization reconfirmed that models are all simplifications of a certain view of reality  and a single diagram cannot effectively capture every aspect of complex health care delivery.
Finally, they offer this suggestion:
We also believe that clear guidelines or computer-based tool supports for health care-specific process modelling could reduce barriers in generating and understating such diagram types. There are many modelling tools in the market from general diagramming tools to more sophisticated business modelling tools, which allow users to generate all the eight diagram types identified in this paper. However, we believe such various diagram types could be best utilized in health care only when users are aware of the health care-specific utility and usability of each diagram type and make extra efforts to apply initially unfamiliar but eventually more effective diagram types.
To a certain extent, I agree with them. There is a need for healthcare-specific modeling methods and tools. However, I disagree that we need so many different diagrams. Yes, a lot has to be captured in order to produce a useful model—actors, data inputs/outputs, time, sequences, states, and tasks, but attempting to use five or six different modeling methods (or even three or four) together for any complex analysis gets old fast…very fast. The messiness inherent in trying to model using so many different methods is one of the things that drove me crazy while working on the 1917 EHR project. It is also what made me embrace Petri nets so enthusiastically when I discovered them. Of course, basic Petri nets are not suitable for modeling complex systems either, but two of their derivatives, Colored Petri nets and YAWL, are wonderful modeling tools. And, unlike most other modeling methods mentioned by the authors, Petri nets and their derivatives have formal semantics and are mathematically-based.
Process and workflow models are important for software design, usability, EHR implementation, quality improvement, and decision support. This makes clinical modeling an area of significant importance in clinical informatics, and having the right tools and methods is essential for success. I will be writing more about my efforts in this area over the coming year starting with a series on YAWL, a language designed specifically to support the workflow patterns discussed in Workflow Patterns, Part I: A Pattern-based View of Clinical Workflows and related posts.
Until next week…