Prior posts have looked at the advantages of mapping clinical workflows using Petri nets (PN). One of the features that I find so compelling about Petri nets is their ability to represent state as well as key process properties such as concurrency and synchronization. However, basic PN do have a few drawbacks. For me, from a clinical modeling standpoint, the two most significant shortcomings of basic PN are the inability to distinguish between tokens (all are black dots) and the inability to fine-tune transition firing. Colored Petri nets* (CPN) address these concerns. CPN are a type of high-level PN and are one of many types of extensions to basic PN. Colored is actually an odd way to describe them since they do not actually have anything to do with pigments. Instead, color refers to the ability to tell one token from another by assigning data values to tokens.
While CPN are a modeling tool, they are also a programming language that can be used to create robust simulations of complex information systems. However, those capabilities, while intriguing, are overkill for modeling clinical workflows. Having tried four modeling programs, I decided against recommending any CPN-specific software in this post because these tools tend to be too complex for casual use. However, for those who want to give it a shot, here is a link to CPN Tools, the premier CPN modeling tool.
From my perspective, the value of colored nets does not lie in their ability to do complex simulations; rather, it is the way they demonstrate how state, processes, and data can be combined in a single representation. Even when rendered statically on paper, they are better mapping tools than flow charts and swim lane diagrams for capturing the nuances of clinical workflows. With this in mind, let’s take a look at the features that differentiate CPN from basic PN.
Tokens in basic Petri nets have no properties aside from their existence and location; adding data solves this problem. Tokens can be assigned an arbitrary number of attributes. For example, indicating that a specific patient is waiting for registration could be accomplished by assigning values to the attributes of a token in the place Waiting.
If a typical patient has the following attributes: name, chief complaint, date of birth, and gender, then the three patients in the above model might be depicted as follows:
Patient1(“John Doe”, “Headache”, 12/03/1969, “M”)
Patient2(“Jane Smith”, “Hypertension”, 09/07/1978, “F”)
Patient3(“Bob Katt”, “Rash”, 03/03/2003, “M”)
Now each token has a specific identity, making it possible to track patients as they move through the model. Simply giving tokens data values is not that great a stretch. The really interesting additions are the expanded capabilities of places, arcs, and transitions.
In basic Petri nets, places usually represent states, although they may represent other things as well. Places have a type in colored nets.* The place Waiting in the above diagram has the type patient. This means it will only accept tokens of that type. When colored nets are used for simulations, typing provides a way of preventing errors.
In the above model, there is one arc leading from the place Waiting to the transition Register_Patient. In basic PN, arcs are simply connectors. In CPN, they have the ability to distinguish between tokens by using arc inscriptions.* An arc inscription is an expression that may contain constants or variables. The variables of arc expression match token and place types (the arc from Waiting to Register_Patient has type patient). Accordingly, arc inscriptions can distinguish between tokens.
Transitions do all the work in PN. In basic Petri nets, transitions fire whenever all of their input places have tokens. However, in colored Petri nets firing can be made conditional because transitions have guards. A guard is an expression whose variables may be bound to token attribute values. When a guard is evaluated the result is a Boolean value (true/false).*
To see what this means in practical terms, let’s assume that registration procedures are different for those age 16 or younger. Looking at the tokens for our three patients, we see that Bob Katt is only 10 years old and should go through the Register_Patient_Peds transition.
When arc inscriptions and guards are present, transitions are only enabled when an appropriate token is available (proper type and required attribute values). Below is an example of an expression that could serve as a guard for the Register_Patient_Peds transition.
IF Age < 16 OR Age = 16
True (transition is enabled)
With this guard in place, the transition Register_Patient_Peds will ONLY be enabled and fire when a patient of pediatric age is waiting.
Well, that pretty much sums up the colored extensions to basic PN. Even though the differences are few, the added modeling capabilities are quite powerful. By adding values to tokens and providing arcs and transitions with decision-making ability, it is possible to finely-model processes. For example, one could model ED triage by creating transitions that fire for specific patient conditions (e.g., fever >101, head injury, labor).
There is much more to CPN than I have discussed. For one, the CPN language is based on the functional programming language standard ML. As a result, any system that can be built in a regular programming language can be modeled as a CPN. This provides a way of accurately simulating an information system before building it.
In the more than 50 years that have passed since Carl Petri introduced his invention to the world, Petri nets have found a home in systems modeling and simulation—there is even an ISO standard. Despite being used primarily in computer science and engineering domains, I think they could prove to be equally useful in clinical workflow modeling. They have certainly changed my way of thinking about clinical processes.
* van der Aalst W, Stahl C. Extending Petri Nets with Color and Time. In: Modeling Business Processes: A Petri Net-Oriented Approach. MIT Press: Cambridge, MA;2011.