The last post focused on state and how this concept helps to portray the interactions between workflow participants.   Movement through the Good Care, LLC workflow model followed the paths laid out by arcs connecting places and transitions.  You undoubtedly noticed that places are static, and that transitions drive the action in Petri nets.  Now, it is time to take a closer look at the respective properties of tokens, places, and transitions in order to see how, by embracing a few additional concepts, one can greatly increase the expressive capability of Petri nets.

Thus far, tokens have been used only to represent people–patients and Good Care, LLC staff.  When combined with places, tokens indicated states or conditions.  However, this use of tokens was simply my choice.  In Modeling Business Processes: A Petri Net Approach*, van der Aalst and Stahl suggest other possible meanings that can be assigned to tokens.  In fact, they list three things besides states and conditions that can be represented using tokens.

Token type Examples
Physical object Lab specimen, paper chart
Information object Drug alert, email message
Collection of objects Medication cart, a research cohort

Tokens also provide a means of adding data to Petri nets.  By now, you may have noticed that since all tokens are black, it is difficult to distinguish one from the other visually (it is easier with animated models, but still not ideal).   Colored Petri nets address this concern. The term colored is somewhat misleading.  It doesn’t refer to pigment, but instead to data.   (Yeah, I know, but these are computer scientists, not decorators, so cut them some slack.)

Tokens are colored by assigning values to them.     For example, if we wish to add information about each patient visiting Good Care, we might require the following data for each patient: MedRecNo, LastName, VisitReason, and PrimaryInsurer. A typical colored token might then hold the values (120900,”Doe”, “back pain”, “My Insurance Co”).    Colored nets also allow one to add time signatures to tokens and transitions, providing the ability to include temporal dependencies in process models.

Colored nets offer more modeling power, but are also more complex than the basic nets that I have been discussing.  They would be overkill for creating clinical process models suitable for EHR selection and implementation planning. However, for those who wish to pursue the topic, the publications of Kurt Jensen are the standard references for the field.

In the Good Care, LLC model, places represented states and conditions.  However, some could just as readily been interpreted as locations.   For example, the state waiting could have been interpreted as the location waiting room.  It is up to the modeler to determine the meaning of model elements.  Van der Aalst and Stahl offer additional potential interpretations for places such as communications media or buffers.  These are both useful interpretations. However, since I consider them to be somewhat advanced interpretations of places, I will not discuss them further. In any case, I think you will find that the properties of places and tokens discussed thus far offer plenty of modeling freedom.

Transitions drive the action in Petri nets by controlling the movement of tokens.   Generally, they model events (e.g., start_intake); however, they can also model object transformation (e.g., remove_wart) or transport (e.g., send_drug_alert).   Because of their role in controlling net markings, the way in which transitions are connected to other elements provides additional semantic detail.  Van der Aalst and Stahl identify five structural patterns with the following interpretations: causality, concurrency, synchronization, and mutual exclusion.

Causality is easy to comprehend–one event depends on the occurrence of a prior event.   In the Good Care model, transition t6 cannot fire unless transition t5 has fired.    Mutual exclusion is also straightforward.  The place doctor is the input place for transitions no_blood_draw_t7 and blood_draw_t8. When a token is present in doctor, both transitions are enabled, but according to Good Care, LLC rules, only one should fire. Thus, no_blood_draw_t7 and blood_draw_t8 exclude one another.

Concurrency and synchronization are a little more involved.  In order for two transitions to work concurrently, they cannot have any firing dependencies between them.   (Since I avoided using these constructs in the Good Care model, they are illustrated below in the phlebotomist model—PNG File, Pflow Model).

Concurrency Pattern 1
Suppose there are two phlebotomists working in a lab, A and B.  Each has his/her own waiting area. When patients arrive, they choose which phlebotomist they will see, and once the choice is made, it is final. Phlebotomist B uses music to help her patients with needle anxiety.  She gives music players to patients as soon as they enter the procedure area. Next, she determines the types of samples required, gathers the required containers, then collects the samples.  Once she is satisfied that the samples are suitable, she retrieves the music player and checks the patient out by giving him/her a copy of the lab order sheet.

From the model, we see that transitions start_blood_draw_A and start_ blood_draw_B are completely independent events; they have no shared input places.  There is no way that the firing of one can affect the other. The work processes of the two phlebotomists form two independent pathways.

Concurrency Pattern 2
The second concurrency pattern occurs when one event (transition) spawns two or more processes that then run concurrently.  This is referred to as an AND-split.

Phlebotomist B, seeing that blood draws cause needle anxiety, always give patients music players to listen to during blood draws.   In the phlebotomist model, start_blood_draw_B fires, moving the patient from waiting to two concurrent states: listening and blood_draw.  The next two events, end_blood_draw_B and stop_music happen independently of one another (i.e. termination of sample collection does not turn off the music player).  Concurrent processes that begin this way may continue along independent paths or merge in a synchronization step.

Synchronization occurs when two or more concurrent processes fire the same transition (i.e. trigger the same event).   Note that in the phlebotomist model, the places samples_complete and not_listening must both be filled by the firing of end_blood_draw_B and stop_music. They need not fire simultaneously, but both must occur in order to fire transition perform_check_out. This final transition now ensures that the patient has a copy of the labs ordered, and that he has returned the music player, sending the patient on his way.

If you have followed along closely, you now have all of the tools needed to create Petri nets that can aid in EHR selection and implementation planning.   With the appropriate tools in hand, you will discover, as I have, that Petri nets (especially when using simulations) are better than flow charts and not much harder to learn.

I hope that this series of posts along with Clinical Workflow Analysis: The Value of Task-Level Detail and  Preventing Your EHR from Working Against You: III, and III have demonstrated the value of workflow analysis in EHR selection and implementation planning.

I am considering a second Petri net-focused series, possibly for late winter, which addresses Petri nets as adjuncts to clinical software development and usability testing.  I’ll have to see if time and circumstances permit it.

Give Petri nets a try—you won’t regret it!
*  Definitions and concepts in this post are based on chapters 3-5 of  Modeling Business Processes: A Petri Net-Oriented Approach by Wil van der Aalst and Christian Stahl, published in 2011 by The MIT Press.




  1. Hi Jerome,
    I love Java applets! I created my own workflow for checking in patients! I don’t get the set of “free FDn”, “with RD Staff”, and “busy FDn”. It seems you are referring to both the FD staff and the waiting patient at the same time since “free” and “busy” refer to the staff and “with” refers to the patient.

    Anyway – I sent the post to my favorite Visio colleague to see what he thinks. It would be cool if you could export in Visio format!

    Looking forward to the next series.


    1. Bruce, thanks for stopping by. The model shows how the states of the patient and FD staff interact. A patient being “with” a FD Staff person makes that FD Staff person “busy.” Thus, you are correct; the model displays the states of both simultaneously, which is one of the great things about Petri nets. When you run the model, you will see that the places “busy FD1” and “with FD Staff” always have tokens at the same time. Remember, only the places with tokens are active. Hope this clears things up.

  2. A very ncie post. Just note that it’s “Kurt Jensen”, rather than “Ken Jensen”.

    1. Thanks, not sure how I made that switch!

  3. Chuck, glad you have enjoyed the series, and thanks for your support in letting others know about the blog.

    I’ll look over the TEPR series. BTW, do you have a favorite FOSS workflow engine?

    Learning software design and architecture at a deep level has been a major goal for me over the last 18 months. I have been very surprised to discover that Petri nets are useful for software design, and for me, far more intuitive than UML modeling tools for capturing the dynamic nature of software. If it turns out that my current software development explorations go well, I’ll likely do the second series a few months from now.

Leave a Reply

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