Requirements, Usability, and Petri Nets

by Jerome Carter on March 4, 2013 · 0 comments

Requirements are the cornerstone of software development.   Among other things, they capture the specific functions that a software system must perform in order to help a user accomplish a goal.     Use cases are one tool for gathering requirements.  They, like user stories, work well because both encourage interaction and discussion between developers and users.    A use case is a series of steps that capture how a user interacts with a system to accomplish a goal.   Thus, in a sense, use cases are a type of workflow capture tool (1).

Think back to workflow analyses that you have seen or done.   Typically, workflow analyses focus on group work; for example, the  steps and job roles involved in an activity such as patient registration.   Rarely do they go down another level to see how staff in those job roles interact with the computer system.   Yet, many discussions about software usability issues are, in fact, about how people interact, for better or worse, with a system.  Thus, there are two types of workflows to be evaluated when considering using software to aid in performing a manual task–group workflows and personal workflows.   (For more about personal vs. group workflows, please read Preventing Your EHR from Working Against You, Part I: EHR Workflow and Personal Work Habits.)

Obviously, getting a better handle on how software features, functions, and user interfaces affect productivity, efficiency, errors,  and training times requires looking closely at personal workflows.   In this post, I hope to demonstrate how the expressiveness of Petri nets, especially their ability to capture state and perform simulations, can help improve both requirements capture and discussions between developers and users.

Case Study: Writing a Prescription
A start up, New EHR, Inc.,  is creating an EHR system.  Knowing that prescription writing can be a cause of decreased productivity if not handled properly,  they hope to engage a few local practices to help with the system’s design.  Here is what they have to date.

Use Case: Write Prescription
Goal: User is able to write a prescription with appropriate allergy and drug interaction checks.

  1. Steps
    1. User logs on
    2. Main Menu
    3. Select patient
    4. Access formulary
    5. Select drug
      i.      Automatic allergy check
      ii.      Automatic interaction check
    6. Set amount, dose, and instructions
    7. Add medication to medication list
    8. Another medication?
      1. Yes
        1. Access formulary
      2. No
        1. Main Menu

This use case covers the basics of writing a prescription, and while it is a good starting point for a prescription writing feature, it’s only words.     A simulation that shows how users interact with the system could make for a richer discussion.    While UML activity and sequence behavior diagrams can be used to capture workflows, I personally find them less intuitive than Petri nets for discussions with those without a technical background.   (Significantly, UML 2.0 actually adopted Petri net semantics,  acknowledging the value of Petri nets.)

When considering processes,  it is helpful to identify which steps are mandatory (e.g., allergy and interactions checks)  and  which can be altered or configured by the user (e.g., choosing from a “favorites” drug list instead of the entire formulary).  Since New EHR, Inc.  is approaching this as a workflow project as much as a feature/function project, workflow management capabilities must be accounted for during system design, which requires separating out mandatory workflows from the rest.

EHR systems without workflow engines have hard-coded workflows that cannot be altered (at least not easily or cheaply) once the system has been built.  In such cases, users and clinical/business processes must adapt to the software system.  New EHR, Inc. hopes to separate their product from the pack by providing features that allow its software to adapt to users.

Below is the initial Petri net model for this use case.   It illustrates the clinician and his/her interactions with the system (the prescription itself is not shown).   One reason for choosing this modeling perspective is that it can represent the cognitive needs of the clinician (e.g., review formulary), a key component of personal workflows.

For the sake of simplicity,  I have omitted options for choosing a different patient or adding a second medication.  Try running the model to get a feel for how it works.  Here are links to the software, Petri Net Editor,  and the model, RxWrite.    (Click on the image for a full-sized version.) Those who require an introduction to Petri nets should review Petri nets and Clinical Information Systems: I,II,III.

 

 

The clinician logs in, which sets the EHR state to EHR_InUse and takes the clinician to the place MainMenu.   Choosing a patient fires the SelectPatient event and takes the clinician to the state PatientChosen.   The next step, SelectRx_Writer, represents a menu selection that takes the clinician to the place Rx_Menu.   From here, the formulary can be accessed, and once a medication is chosen, allergy and drug interaction checks occur automatically.   If either an allergy or interaction is present, the Reject transitions fire and return the clinician to the place Rx_Menu.    Note that both places Allergy? and Interaction? are non-deterministic and represent choices based on specific conditions (e.g. patient is allergic or a new medication interacts with a current one).

Finally, the Add_MedList transition fires, which inserts the medication into the patient’s record.   From here the clinician token moves to the place FinishedPatient, which enables the Log-out transition allowing the clinician to log out of the system—place End.  Note that the firing of the Log-out transition also returns the EHR’s state to EHR_Free.

Note how cleanly this Petri net model separates clinician behavior (menu option choices) and cognitive needs (review formulary) from data processing tasks (allergy and interactions checks).   This is a great feature that can make it easier to model complex decision support systems in a way that users can grasp.

Personal workflows and their cognitive dependencies can have a significant impact on usability, EHR design, productivity, errors, and software training.    Since it is cheaper to correct design problems before a system is built than it is after, modeling techniques that enhance developer-user dialogs can readily prove their value.   Petri nets, by seamlessly portraying processes and state in a graphic form that can be animated, are a great tool for these situations.   What do you think?
___________________________________
1.       Chaudron M, van Hee K, Somers L.  Use cases as workflows. In Proceedings of the 2003 international conference on Business process management (BPM’03), Wil M. P. Van Der Aalst, Arthur Ter Hofstede, and Mathias Weske (Eds.). Springer-Verlag, Berlin, Heidelberg, 88-103. 2003.

Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 0 comments… add one now }

Previous post:

Next post: