Petri Nets and Clinical Information Systems, Part II: A Closer Look at State

In the first post in this series, I introduced basic Petri net terminology and symbols.  Today’s post looks closer at modeling state using Petri nets.  The primary care office model in the first post illustrated straightforward movement by patients from waiting to checked-out.   While this model does capture the essence of what occurs in practices, it lacks the detail required for building an information system to support patient flow.  In addition, it tells us little about how things actually work in the practice (e.g., if we wanted to know more about staffing requirements, bottlenecks, etc.).

The initial primary care office model focused exclusively on the patient’s state.  While even this limited amount of state information offers more modeling sophistication than flow charts, much more is possible.  In this post, the initial model has been extended to include state information for front-desk and nursing staff.  With this new information, it is possible to illustrate the effects of transition firing as well as how these events alter the overall state (marking) of the model.

Scenario – Good Care, LLC
Good Care, LLC is a small primary care practice. It has two front-desk staff, one nurse, one physician, and a lab tech.  Here are a few key operational policies/procedures:

  1. On entering the practice, patients go to the front desk for check-in.
  2. There are two front-desk staff.
  3. If no front-desk staff person is free, patients remain in the waiting area.
  4. If a front-desk staff person is free, the intake process starts.  During intake, a patient may  interact with only one of the two available front-desk staff person.
  5. Once intake is finished, a patient is considered checked-in.
  6. Once checked-in, a patient must see the nurse before seeing the doctor.
  7. There is only one nurse.  The nurse either is with a patient or is free to see a patient.
  8. After seeing the doctor, a patient may check-out (no labs are required) or go the lab and then check out.
  9. Check-out requires dropping a form in the box and getting a follow-up appointment, if required.   (For the sake of simplicity, checked-out is modeled only as a place without any interactions with front-desk staff–same as the initial model.)

Modeling Good Care, LLC
The Petri net model created for this scenario is necessarily limited in complexity so that it is not too difficult to follow. However, it does have enough detail to illustrate key Petri net capabilities.  This model captures the states of the front-desk staff, nurse, and patients, but not the lab tech or doctor.   The interplay between patients and front-desk staff (they share transitions) should provide an idea of how doctor or lab tech interactions might work.

The model may not be clear in the image below. If it isn’t, please download the graphic (PNG) and follow along. (You may also right-click the image and select “Open in a new window.”)

Understanding the Model
Let’s begin by noting all of the places that hold tokens: waiting(5), freeFD1(1), withFDStaff(1), busyFD2(1), and freeNurse(1).   In the initial model, all of the tokens represented patients,  and the places that held tokens represented the state or condition of the patient.  However, in this model we have tokens that represent the states/conditions of the front-desk staff and nurse as well.

Recall from the last post that the marking of a net is the instantaneous location of all of its tokens.   Here are the initial conditions for our Good Care model.

  • Five patients are waiting.
  • Front-desk staff person 2 (FD2) is busy (token in busyFD2) with a patient (token in withFDStaff) performing an intake.
  • The nurse is free (token in freeNurse) as no patients are checked-in.
  • No patients are with the doctor or in the lab.  (Unlike patients, nurses, and front-desk staff, the model does not include state information for the doctor and the lab tech.)   Thus, while we know explicitly when the nurse and front-desk staff are busy or free, this information is not available for the doctor or lab tech.  Our knowledge of the doctor and lab tech is implicit. When patients are with them, we know that. When no patients are present, we know only that the doctor or lab tech exist–not what they are doing.

IMPORTANT: Note that patient tokens, those of the nurse, and front-desk staff cannot share places!   Front-desk staff may only occupy freeFD1/ busyFD1 or freeFD2/busyFD2. Conversely, patient tokens may move from waiting –>withFDStaff –> checked-in, but never to freeFD1/freeFD2 or busyFD1/busyFD2. (If you find this confusing, running the simulation of the model—see instructions below—should clear things up.)

Workflow occurs in Petri nets when transitions fire.  Remember that in order for a transition to fire, all of its input places must have tokens.  By examining token locations and input places for transitions, one can determine which transitions are primed to fire.  In the current marking, transitions start intake_t1 and finish intake_t4 are the only transitions that have tokens in all of their input places.

Transition start intake_t1 has two input places, waiting and freeFD1, indicating that front-desk staff person 1 (FD1) is available to perform an intake.  Since both input places have tokens, the transition start intake_t1 will fire.  When this firing occurs, the states of this patient and FD1 will mirror those of FD2 and the patient FD2 is serving.

Transition t5 cannot fire because it has two input places, checked-in and freeNurse, and only freeNurse has a token. Transition finish intake_t4 can fire because both of its input places have tokens.  When finish intake_t4 fires,  the patient token will move to checked-in, which will then prime transition t5 for firing.

Simulation Instructions
Petri nets are dynamic entities, and they are best understood by seeing them in action.   Follow these steps to see the Good Care model in action.

  1. Install Petri Net Editor. This is a Java application so make sure Java is installed and active on your system.
  2. Download the model file.  (This is a zipped folder containing the model file GoodCareLLC.pflow.)
  3. After opening the GoodCareLLC.pflow file, look at the icons that are just below the menu bar of Petri Net Editor. The third icon from the right (a little circle with a little square) animates the model. Clicking this icon will highlight all transitions.
  4. Transitions that have tokens in all of their input places will highlight green and can be fired by clicking on them.
  5. Try this sequence:
    1. Place the cursor on transition start intake_t1 and click it. This will move a patient token from waiting to withFDStaff and the FD1 token from freeFD1 to busyFD1. Notice that when this occurs, the transition finish intake_t2 becomes green and can fire.
    2. Click transition finish intake_t2.  This will move the patient token to checked-in and the FD1 token back to freeFD1.
    3. Transition t5 should now be green because its input places checked-in and freeNurse have tokens.
    4. Fire transition t5. Tokens will move to withNurse and busyNurse.  Transition t6 should now be green.
    5. Fire transition t6. The patient token moves to doctor and the nurse token to freeNurse.  The blood draw transitions should now be green.
    6. Click the green transition of your choice to move the patient until they arrive at exited.

I hope this post has helped to demonstrate the value of Petri nets as modeling tools.   Consider how adding state information improves the ability of the model to capture real-world scenarios.  For example, we could add the following states for the doctor: chief complaint, review of systems, patient exam, patient recommendations, and documentation as a means of capturing care process information.  Even better, we could model at an even lower level that would more closely match EHR features/functions: medication list, rx_writer, formulary review, interaction check, etc.

There are still important Petri net features that I have not discussed.  Future posts will look at adding new types of data to nets; how nets can be used as a basis for programming code; and, perhaps, a little more about the underlying mathematics.   Until next time…

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.





  1. Chuck, I commend you on the work you have done in this area. Obviously, you have been/are ahead of the pack. What do you see as the major reason WFM has not attained a higher profile in clinical software design?

    Thanks for the ProHealth and BPM links, it’s exciting to see so much activity. At present creating EHR software is not my top priority, but rather trying to understand/determine to what degree clinical care may be described mathematically. Creating software is mostly a means of testing assumptions.

  2. Chuck, I have this foolish idea, probability nothing more than tilting at windmills, that it is possible to tie clinical actions to a mathematical representation and then use that representation as a basis for building clinical software. Petri nets seem to be perfect for this, but, of course, my study of graph theory and Petri nets is still in its infancy.

    Yes, I am exploring YAWL, and I absolutely consider component-based EHRs with WFM engines to be the future. I cannot see how CDS is realistically possible without both components and WFM engines.

    Glad that you enjoy the blog!

Leave a Reply

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