13.1. Diagnostic Department

??????

At a diagnostic department of a hospital, incoming patients first get recordings of their heart’s electrical activity via an Electrocardiography (ECG) and then get an ultrasound scan.

For getting a quick impression, you can run this model from the Sim4edu website, or inspect its OESjs code.

Our Diagnostic Department modeling problem is based on the chapter "Example Model 4: Clinic" in the book The Art of Process-Centric Modeling with AnyLogic by Arash Mahdavi.

The diagnostic process consists of two subprocesses:

  1. Performing the ECG: When a patient enters the clinic, they must wait in a waiting area for their name to be called. A patient whose name is called will walk to the “ECG room”, choose a free spot and wait for an ECG technician. ECG technicians have to walk from the “ECG technician room” to the “ECG Room” after being requested to a new patient. They will first go to the “ECG storage room", pick up an ECG machine, bring it to the waiting patient in the ECG room and start the ECG procedure. When the ECG procedure is completed, the technician returns the ECG machine to the storage room and walks back to the ECG technician room. After each procedure, ECG technicians rest for five minutes before they accept a new patient. A patient who has completed the ECG will not leave the ECG room until there is an available spot in the “ultrasound room”.

  2. Performing the ultrasound (US) scan: At the start of this procedure, a patient is done with the ECG but still waiting in the ECG room for a free spot in the US room. Each US spot is a combination of a US machine and the bed it's assigned to. When there is an available spot, the patient's name is called; they walk to the assigned bed and lay down on it. At this point, the patient is ready and a request for a doctor is sent to the “Doctors on Call” room. If there is no doctor available (that is, they are resting or with other patients), the patient must wait until a doctor becomes available. When an on‐call doctor is readily available, they will walk to the patient's bed in the US room and start the US scan.

The department's management has the following business objectives:

  1. Process 50 patients during each operating day.
  2. Minimize the time to process patients (also called throughput time), as this is the most important indicator of patient satisfaction.
  3. Complete the ECG and US procedures for all admitted patients by the end of the department's daily working hours (within eight hours) and without the need for after-hour work.

The purpose of this modeling and simulation project is to find system designs that fulfill the above business objectives. For observing if a system design fulfills the objectives, we can use the following simulation statistics: (a) average throughput time, (b) utilization of resources, (c) the departure time of the last patient (used as a measure of daily operation duration)

Conceptual Model

The diagnostic department under consideration has resource pools for ECG spots, ECG technicians, ECG machines, US beds, US machines and doctors. While a perform ECG activity is performed by an ECG technician using an ECG machine and an ECG spot, a perform US activity requires a doctor using a US machine and a US bed.

For simplicity, we make a non-spatial (purely temporal) model, not modeling any spatial aspects, as opposed to the model discussed in The Art of Process-Centric Modeling with AnyLogic.

Conceptual Information Model

The potentially relevant object types are:

  1. diagnostic departments (the organizational units that own/manage their diagnosis business processes);
  2. patients;
  3. the seven spaces/rooms: waiting area, ECG room, ECG technician room, ECG storage room, ultrasound room, "doctors on call" room, doctors resting room;
  4. the six resource object types ECG spots, ECG technicians, ECG machines, US beds, US machines and doctors.

Potentially relevant types of events and activities are:

  1. arrivals of new patients;
  2. patients walking to the ECG room;
  3. ECG technicians (a) walking to the ECG storage room, (b) moving an ECG machine from the ECG storage room to the ECG room, (c) performing an ECG on a patient, (d) returning the ECG machine to the storage room, (e) walking back to the ECG technician room, and (f) resting for five minutes;
  4. patients going from the ECG room to the US room,
  5. doctors (a) walking from the "doctors on call" room to the patient's bed in the US room, (b) performing an US scan on the patient, (c) walking to the doctors resting room, (d) resting for some time, and (e) going back to the "doctors on call" room;
  6. departure of patients.

When making a process model, we normally adopt the perspective of the organization (or organizational unit) that "owns" the business process to be modeled, here: the diagnostic department. Notice the conceptual issue that the activities performed by patients (walking to the ECG room, going to the US room) are not ordinary business activities, since they are not performed by an organizational actor, such as a technician or doctor, counting as a resource. In their case, the performer (a patient) is not a resource. For this reason they will be modeled without a performer role.

Object, event and activity types, together with their participation associations, can be visually described in a conceptual information model in the form of a conceptual Object Event (OE) class diagram. The following OE class model describes the core elements of our diagnostic department viewed as a business system.

conceptual information model describing object, event and activity types

While this model defines primary business activity types together with their resource roles (association ends annotated with «rr»), associated resource types and corresponding resource pools (association ends annotated with «rp»), it does not capture the types of secondary business activities of

  1. ECG technicians (a) walking to the ECG storage room, (b) moving an ECG machine from that storage room to the ECG room, (c) returning the ECG machine to the storage room, (d) walking back to the ECG technician room, and (e) resting for five minutes;
  2. doctors (a) walking from the "doctors on call" room to the patient's bed in the US room, (b) walking to the doctors resting room, (c) resting for some time, and (d) going back to the "doctors on call" room.

These secondary business activities are described in the following OE class diagrams.

conceptual information model describing object, event and activity typesconceptual information model describing object, event and activity types
Conceptual Process Model

As service processes, health care processes can be viewed/modeled as Processing Networks (PNs). Since PNs are more high-level than Activity Networks (ANs), it is preferable to model the Diagnostic Department as a PN.

The following BPMN process diagram shows a coarse-grained conceptual process model of the primary business activities of the Diagnostic Department, with two swimlanes for the two performers of the process:

A conceptual process model in the form of a BPMN diagram

Unfortunately, as an AN modeling language, BPMN does not provide any special elements for modeling PNs. While BPMN allows modeling the performers of activities with lanes, it does not support modeling other types of resource objects. As a workaround, we have included the resource objects ECG spot, ECG machine and US bed in the form of BPMN Data Objects. But this does not allow to clearly display the processing nodes of a processing network as a combination of a processing station (like ECG spot) with its processing activity (like perform ECG).

An even more severe issue of the BPMN model is its uniform (semantically overloaded) use of "sequence flow" arrows for representing different types of flows: event flows, activity flows and processing flows. While in the case of an activity, incoming arrows do not mean that an activity is started, but rather that a new planned activity (or task) is enqueued and only started when all required resources become available, in the case of a processing node, an incoming arrow represents a processing flow, which is a combined object-event flow of processing objects and their delayed processing activity start events.

These issues of BPMN have been solved in DPMN, which supports the visual modeling of processing networks with processing nodes connected by processing flow arrows, as shown in the following DPMN process diagram:

A conceptual process model in the form of a DPMN diagram

This conceptual DPMN process diagram is based on the underlying OE class model discussed in the previous section. Notice that a two-part name of a processing node (like "ECG spot / perform ECG") contains both the name of the node's processing station ("ECG spot") and the name of the node's processing activity ("perform ECG"). For the processing node "ECG spot / perform ECG", the model specifies three resource objects: an "ECG technician" as the performer, the processing station "ECG spot" (specified in the node name), and an additional resource object "ECG machine".

Run this model from the OESjs GitHub website

While this model attains a highly compact description of the Diagnostic Department system by compressing "ECG spot" resources and the "perform ECG" activity, as well as "US bed" resources and the "perform US scan" activity, into a corresponding processing node, it abstracts away from the activities of patients walking to the ECG room and walking from the ECG room to the US room.

The above model can be further refined by explicitly modeling the two patient activities "walk to ECG spot" and "walk to US bed". While the first of them requires an "ECG spot" as a resource, the second one requires a "US bed". In the following DPMN process diagram, we do not display the rectangular container (called Pool) for the Diagnostic Department, leaving it implicit.

A conceptual process model in the form of a DPMN diagram

Notice that in this refined model, the processing nodes of the previous model have been resolved into corresponding processing activities (and associated resources).

According to DPMN's declarative resource modeling principles, a required resource will be allocated before an activity starts and, unless the follow-up activity also requires a resource of that type, released after it has completed. In the case of the activity sequence of "perform ECG" and "walk patient to US bed", however, the resource "ECG spot" must not be released before the follow-up activity "walk patient to US bed" starts, because it represents the location of the patient (in the ECG room), which only becomes available when the patient leaves the room (for going to the US room) and not when the "perform ECG" activity ends.

DPMN allows to mark such a deferred resource de-allocation with the help of a special resource role association end (a dot with a bar), as can be seen in the diagram at the "ECG spot" resource type rectangle. It means that this resource is not released when the activity (here "perform ECG") ends, but only when the follow-up activity (here "walk patient to US bed") starts.

In this example, the requirement for deferred resource de-allocation stems from the ambiguity of the ECG room (with three spots) representing both a spatial resource for the activity "perform ECG" and an input buffer for the processing activity "walk to US bed". This points to an intricate relationship between the concepts of spatial resources and input buffers in PNs, which requires further research.

Run this model from the OESjs GitHub website

Simulation Design

T.B.D.

Based on the two conceptual models discussed in the previous section, we are going to make two design models, a simpler (more abstract) one and a more detailed one. In both designs, we consider only one diagnostic department, which does not have to be modeled as an explicit object.

These secondary business activities will only be modeled in a third version of the Diagnostic Department model.

Diagnostic-Department-1

Activity Duration
perform ECG

We consider a scenario with two order takers, ten pizza makers, five ovens and 20 scooters.

Information Design Model

T.B.D.

An information design model, in the form of an OE class diagram as shown below, is derived from a conceptual information model by abstracting away from items that are not design-relevant and possibly adding certain computational details.

An OE class design diagram like the one above, defines resource roles, resource role types and resource multiplicity constraints for all types of activities. Normally, in an OE simulation there is a one-to-one correspondence between resource role types and resource pools. By convention, a resource pool has the same name as the corresponding resource role type, yet pluralized and starting with a lowercase character.

Process Design Model

T.B.D.

A process design model, in the form of a DPMN process diagram as shown below, is derived from a conceptual process model by abstracting away from items that are not design-relevant and possibly adding certain computational details.

A DPMN process design model essentially defines the admissible sequences of events and activities together with their dependencies and effects on objects, while its underlying OE class design model defines the types of objects, events and activities, together with the participation of objects in events and activities, including the resource roles of activities, as well as resource multiplicity constraints, parallel participation constraints, alternative resources, and task priorities.

It is an option, though, to enrich a DPMN process design model by displaying more computational details, especially the recurrence of exogenous events, the duration of activities and the most important resource management features defined in the underlying OE class design model, such as resource roles (in particular, performer roles can be displayed in the form of Lanes) and resource multiplicity constraints. The following model shows an enriched version of :

Such an enriched DPMN process design model includes all computational details needed for an implementation without a separate explicit OE class design model. In fact, such a process model implicitly defines a corresponding class model. For instance, the enriched DPMN model of implicitly defines the OE class model of above.

The notation for defining performer roles in Lanes consists of a performer role name (such as pizzaMakers) and and an object type name (such as PizzaMaker) denoting its range, separated by a colon. When the performer role name is appended by a multiplicity expression in brackets, as in pizzaMakers[2], this denotes a resource multiplicity constraint (stating that exactly 2 pizzaMakers are required). When only a performer type prefixed with a colon (such as :OrderTaker) is provided, this means that the implicit performer role name is obtained by lowercasing the performer type name (as in orderTaker:OrderTaker).

The notation for defining a non-performer resource role, such as oven:Oven, consists of a named object rectangle, such as the :Oven rectangle in , attached to an activity rectangle by means of a connection line with a small filled square representing a resource link, such as the line between the MakePizza activity rectangle and the :Oven object rectangle in .

Notice that the model of does not include any element representing a resource pool. It is assumed that for any organizational position described in the underlying OE class model, the organization under consideration has a corresponding resource pool. By default , each resource role of an activity type is associated with a resource pool having the same (yet pluralized) name, such that its resources are instances of a corresponding resource role type, which is an organizational position in the case of human resources.

Combined with its underlying OE class design model, a DPMN process design model provides a computationally complete specification of a simulation model.

13.1.1. Implementation with OESjs

The JavaScript-based simulator OESjs-Core3 implements the Object Event Simulation (OES) Processing Networks paradigm, and, consequently, allows a straight-forward coding of OE class design models and DPMN process design models of Processing Networks.

Implementing the OE Class Design Model

T.B.D.