Workflows with Friends…

by Jerome Carter on September 7, 2015 · 4 comments

Clinical workflow has finally become a big deal. Everyone is talking about workflows these days. Workflow issues are widely recognized as underlying factors for a range of problems that impact clinical work and affect software design.   Consequently, ONC, AHRQ, and NIST have jumped into the fray with grant money dedicated specifically to clinical workflow research. Concurrent with the federal government’s interest in clinical workflow has been the rise in the business process management (BPM) community’s interest in automating healthcare processes. Of course, software vendors, informaticists, and clinicians have also staked out territory in the clinical workflow landscape.

The exploding interest in what was once an obscure topic has resulted in a concomitant increase in articles, books, and conference presentations.   I have spent the summer trying to get a handle on this. The experience has been both fascinating and exhausting.   You see, despite the fact that everyone is discussing clinical workflows and processes, analysis methods, modeling standards, and terminologies differ widely among groups. Making matters even worse, there is little overlap in journals or conferences.   (In order to update resource pages on Clinical Workflow Center, I search ACM Digital Library, IEEE Xplore, PubMed, and Google Scholar.)  As one might expect, the lack of overlap means that sharing of ideas and cross-pollination occur infrequently.

Here is a brief review of what I found in terms of communities, methods, and tools.

Clinicians tend to have the most practical view of workflow.   Their writings tend to focus on changing how they work and improving common practice processes such as registration, results management, and preventive care.   Research articles are found in professional society journals (e.g., ACP, AMA, AAFP, AAP, ACS, etc.). Typically, searches in PubMed will locate all articles of this type.   Articles about workflow disruptions, especially with regard to productivity, cost and staffing secondary to HIT adoption, also tend to appear more frequently in these journals.

Workflow analysis methods are not usually described in great detail; however, common general methods – interviews, observation, and documentation review – are used. Modeling is usually done with flowcharts and swimlane diagrams.

Human Factors
Human factors studies focused on clinical workflow are showing up much more frequently. In fact, NIST, AHRQ, and ONC seem to prefer human factors approaches for workflow research, if the grant reports released in the last four months are any indication.   Hierarchal task analysis and cognitive task analysis (CTA) seem to be the dominant methods used for studies.   CTA focuses on the cognitive needs of those involved in workflows and covers topics such as cognitive load, error causation, etc.   HTA is a method for determining, in detail, the steps that make up a process. HF articles are found in a variety of journals, those dedicated to HF as well as informatics and IEEE journals. HF workflow articles appear in ACM, IEEE and PubMed databases.

CTA has specialized tools for gathering workflow information (e.g., concept maps, Critical Decision Method, Think Aloud). Workflow models tend to use flowcharts and swimlane diagrams. A notable exception to this rule is Keith Butler.   He has an excellent chapter on task analysis and software design in Computing Handbook, Third Edition .   Dr. Butler uses Business Process Model and Notation Version 2.0 (BPMN 2.0) as the modeling language for his MATH project, which, in my experience, is an uncommon choice for human factors researchers.

Since many informaticists are clinicians, their workflow publications are diverse.   However, their publications are more technical than those in the clinician group. Studies on click counts, UI problems, process support (e.g., care coordination, results management, etc.), and workflow disruptions due to HIT design flaws seem to be key areas of inquiry for informaticists.   There is a growing collaboration between HF and informatics researchers (NCHFH, NCCD), so HF methods are increasingly found in informatics papers.  Modeling is usually done with flowcharts and swim lanes. In addition, informaticists often employ use cases from Unified Modeling Language (UML).  Most informatics research appears in informatics journals. Major informatics journals appear in all three bibliographic databases.

Business Process Management
Business process management (BPM) has roots in information technology and business management. Process reengineering/improvement was all the rage in the 1990s. BPM grew out of a practical need to match business goals with processes. With the rise of information technology, matching processes to technology become important.  While BPM is a discipline, workflow management systems were a technology created to automate processes. I say were because workflow technology is increasingly subsumed under BPM in the form of BPM suites – software systems that allow for the modeling and execution of workflows.   Health care is big business, so it is no surprise that BPM suite vendors want to bring their enterprise experience to health care.

I have four books on process mapping and improvement that were published in the late 1990s. They take the same basic approach to analyzing processes – observation, interviews, documentation analysis — but with a focus on business goals. BPMN 2.0 is the standard for modeling business processes.   BPMN 2.0 is not simply a modeling tool; BPMN diagrams are executable. Further, modern BPM suites are sophisticated development environments similar to Microsoft’s Visual Studio or Apple’s Xcode.

In terms of clinical workflow, BPM is just now making its way into health care, especially clinical work. However, there is no reason, aside from lack of familiarity, that BPM tools cannot be used for CDS, care coordination, or results management.   BPM articles/journals appear in IEEE and ACM databases and much less so in PubMed.

Within the BPM community there is a subgroup that deserves much more attention from all the other groups.     Led by Wil van der Aalst, the group at Eindhoven University of Technology, Netherlands, has made what I consider the most important contributions to workflow research.   Starting with Petri nets, Dr. van der Aalst, associates, and protégés have given workflow concepts a mathematical basis. Workflow patterns, another huge contribution, have been used mostly to test compliance of BPM/workflow management suites. (I hope to demonstrate that they have additional uses, especially for clinical workflow research and clinical software design.)

Yet Another Workflow Language ( YAWL), like BPMN, is an executable language that is programmed visually. YAWL conforms to all workflow patterns and is ideal for exploring clinical workflow concepts. YAWL offers a development environment that allows one to create deployable applications.

Software Developers
Within the software development community, UML is the standard for documenting workflows. Use cases are the main way to capture user workflows. A use case, among other things, consists of a description and a series of steps that accomplish a specific goal.   Use cases are usually presented in text form without a process representation (i.e., without a graphical control-flow representation).   UML does provide graphical process representations (e.g., Activity, State, and Sequence diagrams); however, only use cases and activity diagrams are suggested for capturing users’ actions.

Since software developers are creating applications, their focus is understanding workflows in terms of application development.   As with all other groups, they use interviews, observation and documentation analysis to analyze workflows.   Developers tend not to be researchers, so their writings are more likely to be found on blogs (when it appears at all) than in journals. However, there are development-focused articles in IEEE and ACM databases and, rarely, PubMed.

There you have it — five groups, each with its own approach to studying and modeling clinical workflows.   All are eager to help health care adopt HIT and create better software. Having sampled research from all groups, I can say that each has something worthwhile to offer in creating next-generation clinical systems. The question is how to get them to interact on a regular basis and see the commonalities in their work. HF, informatics, and clinician workflow researchers infrequently cite BPM-related research; the reverse is also true.

The deepest knowledge of clinical workflow issues and how they affect care quality and clinician productivity rests with clinicians, informaticists, and HF researchers. BPM developers and software engineers have the most application development experience AND they have technology that can actually implement workflow support. BPM suites offer executable workflow languages and mature development tools with visual modeling capability. We have the knowledge and tools — what we lack is collaboration. It would be nice if AMIA and/or HIMSS actively worked to bring everyone together. A conference dedicated to clinical software development with a major clinical workflow component would be great (a guy can dream).

Moving clinical software forward requires that all groups find common ground and share ideas, notations, and concepts. And there is no time like the present to start. Workflows with friends…Let’s do it!


Leave a Comment

{ 4 comments… read them below or add one }

John Frederick Chionglo September 10, 2015 at 2:08 AM

I develop application software, interactive PDF (forms). The software is written in JavaScript and uses the Acrobat/JavaScript API.
I use annotations to Petri Net elements to document requirements and to specify software. With this method, it is possible to use the output of other techniques such as UML, BPMN and use cases as starting points for developing software and to systematically translate specifications into computer programs. In other words, it may be used as a collaboration technique for getting the work of diverse stakeholders using various methods into a common framework so that ideas can be communicated among stakeholders more effectively and computer programs coded systematically.
These techniques combined with PDF technology would facilitate the development, use and maintenance of health information systems. For example, you described some key operational policies/procedures for Good Care, LLC in your earlier blog “Petri Nets and Clinical Information Systems, Part II: A Closer Look at State”. Based on your description and the Petri Net diagram provided in the blog, I developed an interactive software of the procedure in PDF for “illustration” purposes.

A PDF version of this reply includes the “illustration”:”$0$1441794253.pdf.”

Regards, john


Jerome Carter September 11, 2015 at 7:48 PM

John, thanks for your comment. This is a very interesting approach. Have you written something that would explain it in more detail?


John Frederick Chionglo September 14, 2015 at 4:24 AM

Hi Jerome,

I have written something in detail with an example that explains half of the “method”: “” This explains how we can systematically create computer programs using “Petri Net diagrams”.

I am still working on the other half: dealing with diagrams with very many elements and very many types of elements. The second half basically deals with how to annotate “high-level diagrams” that map to Petri Net elements and annotations.

BTW, I am not sure if the URL included in this reply would show up. If you don’t seen any, please let me know. I say this because I also had a URL in my earlier reply and I do not see it in the post.

Thanks. – john


Jerome Carter September 14, 2015 at 1:41 PM

Thanks John, this is very interesting.


Previous post:

Next post: