Well, it has taken longer than expected, but it’s time to discuss Petri nets. This is the first post in a series that will look at this remarkable tool. I am enamored with Petri nets because they provide an elegant solution to a range of problems I have encountered during software design and implementation. Here is a brief list of what makes them so wonderful:

- They provide a graphical, easy-to-understand tool for capturing workflows. Of course, one could do workflow mapping with flow charts, but as you will see in this series, Petri nets are able to capture notions such as concurrency that flow charts cannot handle cleanly.
- They have a formal mathematical basis in graph theory. Petri nets are directed graphs; therefore, all of the tools available for manipulating graphs may be used to study and analyze them. In addition, Petri nets can be represented algebraically.
- Petri nets offer well-defined semantics, which comes in handy when creating programming code to reproduce their behavior.
- Due to the above, Petri nets provide the ability to capture process information in as much detail, and with as much precision, as desired.

When designing clinical systems, one has to be aware of both data and process requirements. Too often, process requirements are not addressed explicitly or in sufficient detail because the available tools are too cumbersome. This was the problem I encountered during the EHR project at UAB. Workflow analyses for major clinic processes were documented using Visio flowcharts, whereas activity diagrams were used to model software workflows. (One can show flowcharts to end users…activity diagrams, not so much.) Having to use different tools to map workflows was counter-productive. Had I known about Petri nets, all workflows could have been documented using the same tool. Petri nets rule!

Aside from software design, Petri nets offer a way to mathematically model clinical processes at any arbitrary level of detail, and that bodes well for the scientific study of clinical care activities. Actually, I find this to be their most exciting potential use. Okay, enough with the philosophical preamble–let’s dig in. (This would be a good time to review Workflow Analysis–Doing the Math and From Data to Data + Processes: A Different Way of Thinking about EHR Software Design.)

A Primary Care Practice

In the* From Data to Data + Processes *post the scenario of a visit to a primary care practice was introduced. In particular, the various states that a patient could take on or be in (whichever you prefer) while at the doctor’s office were identified: in the waiting area, checked-in, with the doctor, in the lab, checked-out, and exited. (I added exited here to make for a more definitive final state.) This gives the state space set:

* S*** = {waiting, checked-in, doctor, lab, checked-out, exited}**

Changes in state can be denoted using ordered pairs. The ordered pairs listed below illustrate the order of states that might occur during a typical visit.

** (waiting, checked-in), (checked-in, doctor), (doctor, lab), (lab, checked-out), (checked-out, exited)**

Petri net diagrams are comprised of four simple components: places, transitions, arcs, and tokens. *Places* are equivalent to states and are represented as circles. Moving from one state to another requires going through a transition (represented as a square). Arcs (arrows) connect places to transitions and vice versa. Places are never connected directly to another place without an intervening transition; the same holds true for transitions. In the diagram below, there are two places (place, place2), two arcs, and one transition.

Here is a simple net with all places included. The net now has six places and five transitions. In addition, note that in the place *waiting,* there are three black dots; these are tokens. For our purposes, the tokens represent three waiting patients.

Now let’s look at the arcs. Note the arcs leading from place *waiting *to transition t1 and* *from transition t1 to place *checked-in, *these indicate how tokens may flow in the net. Tokens move when transitions fire. Transitions may fire whenever ALL of their input places hold tokens. Since transition t1 has only one input place (waiting), transition t1 may fire anytime there are tokens (patients) in the place *waiting*. Firing is one of the key features that make Petri nets great for workflow mapping. They can be activated and used for simulations! For those who wish to take a shot at building a net, here is a link to a very simple Petri net editor (it does simulations).

Marking

Another useful feature of Petri nets is the way they maintain an examinable state, referred to as the net’s *marking*. The marking is the instantaneous location of all the tokens in the net. This is very important. Since tokens may be distributed anywhere in the net, and may fire transitions according to whatever rules have been used to design the net, it is possible to model concurrency.

Thus far, I have not named the transitions. Although transitions can be thought of in a number of ways, for this scenario I’ll use typical office actions. For example, transition t1 could be “Front-desk staff information validation,” and t2 could be “Obtain vital signs and place patient in exam room.”

Using Petri nets, one can go from a high-level model, such as patient movement through a practice, to low-level models, such as every single action a front-desk staff person might perform while obtaining and validating patient information. The former is great for resource planning, the latter for designing software.

In the next installment, we will look at a more complex version of the primary care office that illustrates additional Petri net capabilities. See you then…

_____________________________

The definitions used in this post, as well as virtually everything else I discuss about Petri Nets, come from two books (and a few articles) by Wil van der Aalst and his co-authors. If you wish to understand workflow and Petri nets, buy these books.

van der Aalst W, van Hee K. *Workflow Management: Models, Methods, and Systems.* Cambridge, MA:The MIT Press; 2004.

van der Aalst W, Stahl C. *Modeling Business Processes: A Petri Net-Oriented Approach*. Cambridge, MA: The MIT Press; 2011.

Chuck, sorry it has taken so long to reply. Somehow, your comment was overlooked, not sure how exactly. I agree that notations for mapping workflows can potentially limit their application by EHR users. However, I find Petri nets to be far superior to other notations as they allow much richer models to be built.

It is not clear to me whether the problem with end-user application of Petri nets arises due to the inherent complexity of Petri nets (doubt this) or because most teaching materials are aimed at CS/software professionals and couched in graph theory (leaning strongly toward this). One of the reasons I began studying discrete math was to be able to understand Petri nets. Having done so, I get the math, but find it is not required for everyday use in mapping workflows for implementation and software development purposes. Alas, if only I had discovered them 12 years ago…