A basic conceptual model

In our basic model of a medical department we consider just one activity, medical examinations, and one type of resource, doctors:

• Patients arrive at a medical department at random times.
• If there are no other planned examinations waiting for the availability of a doctor, and a doctor is available, any newly arrived patient is immediately examined by that doctor. Otherwise, the planned examination of the newly arrived patient is added to a list of planned examinations (representing a queue).
• The duration of examinations varies, depending on the individual case.
• When an examination by a doctor is completed, the next planned examination is started by the doctor, if there is still any planned examination in the queue.

The potentially relevant object types of the system under investigation are:

• patients,
• medical departments,
• doctors.

The potentially relevant event types are:

• patient arrivals,
• examination starts,
• examination ends,

Instead of considering the event types examination starts and examination ends, we can consider the activity type examinations. Thus, we get the following conceptual information model (expressed as an OE Class Diagram, which is a special type of UML class diagram):

From the diagram we can infer that:

• For patient arrivals and for examinations, there is an association with medical departments providing the process owner, such that for any patient arrival event and examination activity a specific medical department is in charge of handling the event or seeing to it that the activity is going to be performed.
• While patient arrivals have two participants: a patient and a medical department, examinations have three participants: a patient, a medical department and a doctor.
• Examinations have one resource role, doctor, with a resource cardinality constraint of exactly one, which means that exactly one doctor is required for performing an examination.
• The process owner of an examination, a medical department, has a resource pool for doctors. The doctors needed for performing examinations at this department are allocated from this pool, and the department, as the process owner of examinations, has a business procedure for allocating doctors to planned examinations (using certain policies).

In addition to a conceptual information model, which captures the system's state structure, we also need to make a conceptual process model that captures the dynamics of the system. A process model can be expressed with the help of event rules, which define what happens when an event (of a certain type) occurs, or, more specifically, which state changes and which follow-up events are caused by an event of that type.

The following conceptual process model (in the form of a DPMN Process Diagram) is based on the information model above. It refers to a medical department as the process owner, visualized in the form of a container rectangle (called "Pool" in BPMN, but not in DPMN), and to doctor objects, as well as to the event type patient arrivals and to the activity type examinations.

This conceptual process model describes two causal regularities in the form of the following two event rules, each stated with two bullet points: one for describing the state changes and one for describing the follow-up events brought about by applying the rule.

1. When a new patient arrives:

   • if a doctor is available, then she is allocated to the examination of that patient; otherwise, a new examination task (involving the newly arrived patient) is enqueued;
   • if a doctor has been allocated, then the examination of the newly arrived patient is starts.

2. When an examination is completed by a doctor:

   • if the queue of planned examinations is empty, then the doctor is released;
   • otherwise, the next planned examination by that doctor starts immediately.

We can simplify the model by using a Resource-Dependent Activity Scheduling arrow between the patient arrivals event type circle and the examinations activity type rectangle, as shown in the following DPMN process diagram:

An extended conceptual model

For being more realistic, we consider the fact that patients first need to be walked by nurses to the room allocated to their examination before the examination can start. So, in our extended model of a medical department we consider two other resource types, examination rooms and nurses, and another type of activity: walks to rooms (the walks of patients to examination rooms guided by nurses):

• Patients arrive at a medical department at random times.
• When a new patient arrives, and an examination room and a nurse are available, that nurse walks the patient to that room, otherwise the patient has to wait for the availability of an examination room and a nurse (administratively, a new planned walk is added to the queue/list of planned walks).
• When a nurse has walked a patient to a room and a doctor is available, an examination of the patient by that doctor in the room starts; otherwise the patient has to wait for the availability of a doctor (administratively, a new planned examination is placed in the queue/list of planned examinations).

• When an examination of a patient by a doctor in a room is completed,

  1. if there is still another planned examination of a patient waiting in a room for the availability of a doctor, the doctor goes to that room and starts the examination of that patient; otherwise, the planned examination of the newly arrived patient is added to a list of planned examinations (representing a queue);
  2. if there is still another planned walk of a patient to a room waiting for the availability of a room, the room is allocated to this planned walk; if a nurse is available, she walks the patient to that room.
• The duration of walks and examinations varies, depending on the individual case.

The potentially relevant object types of the system under investigation are: patients, medical departments, rooms, nurses and doctors.

The potentially relevant event types are patient arrivals and the activity types walks to rooms and examinations.

Thus, we get the following conceptual information model expressed as an OE class diagram:

Notice that in this model, (a) the performer role is explicitly marked with «performer»: a nurse is a performer of walks to room while a doctor is a performer of examinations, and (b) the stereotypes «resource role» and «resource pool» have been abbreviated by «rr» and «rp».

From the diagram we can infer that:

• For the event type patient arrivals and for the activity types walks to rooms and examinations, there is an association with medical departments providing the process owner.
• While patient arrivals have two participants: a patient and a medical department, walks and examinations have four participants: a medical department, a patient, a nurse or a doctor, and a room.
• Walks have two resource roles, nurse and room, both with a resource cardinality constraint of exactly one, which means that exactly one nurse and one room are required for performing a walk.
• Examinations have two resource roles, doctor and room, both with a resource cardinality constraint of exactly one.
• The process owner of a walk to a room and a subsequent examination, a medical department, has three resource pools for nurses, rooms and doctors. All required resources needed for performing walks to room and examinations at this department are allocated from these pools, and the department has corresponding business procedures for allocating rooms, nurses and doctors using certain allocation policies.

In addition to a conceptual information model, which captures the system's state structure, we also need to make a conceptual process model that captures the dynamics of the system. A process model can be expressed with the help of event rules, which define what happens when an event (of a certain type) occurs, or, more specifically, which state changes and which follow-up events are caused by an event of that type.

The following conceptual process model (in the form of a DPMN Process Diagram) is based on the information model above. It refers to the object types medical departments and doctors, as well as to the event type patient arrivals and to the activity type examinations.

This process model describes three causal regularities in the form of the following three event rules:

1. When a new patient arrives:

   • if a room and a nurse are available, they are allocated to the walk of that patient to that room, otherwise a new planned walk is placed in the corresponding queue;
   • if a room has been allocated, then the nurse starts walking the patient to the room.

2. When a walk of a patient and nurse to a room is completed:

   • if there is still a planned walk in the queue and a room is available, then the room is allocated and the nurse is re-allocated to the walk of the next patient to that room;
     if a doctor is available, she is allocated to the examination of that patient, else a new planned examination of that patient is queued up;
   • if a doctor has been allocated, then the examination of the patient starts;
     if the nurse has been re-allocated, she starts walking the next patient to the allocated room.

3. When an examination of a patient is completed by a doctor in a particular room:

   • if there is still a planned examination (of another patient in another room), the doctor is re-allocated to that planned examination, else the doctor is released;
     if the waiting line is not empty, the room is re-allocated to the next patient, else it is released;
   • if the doctor has been re-allocated to a planned examination, that examination starts;
     if the room has been re-allocated to another patient and a nurse is available, that nurse starts walking the patient to the room.

Again, we can simplify the model by using Resource-Dependent Activity Scheduling arrows resulting in an Activity Network model, as shown in the following DPMN process diagram:

We can display the two performer roles doctor and nurse with the help of two corresponding swimlanes shown within the process rectangle:

Notice that the use of swimlanes (marking disjoint subrectangles) is a convenient visual syntax for displaying the performer roles when the different performers have a non-overlapping set of activity types. However, when activities of a certain type are performed jointly by more than one performer (e.g., when a doctor and a nurse jointly perform an examination), a different visual syntax needs to be introduced.

1.2.1. Design models based on the basic conceptual model

We model the random variations of two variables, the recurrence of new cases and the duration of examinations, in the form of random variables as special class-level ("static") functions, with a stereotype «rv», in the class to which they belong, as shown in the diagrams below.

The recurrence of NewCase events is modeled as a random variable with an exponential distribution having an event rate of 0.7 per minute. The duration of examinations is modeled as a random variable with a uniform distribution having lower bound 5 and upper bound 9.

The Medical-Department-1a design model

In the Medical-Department-1a information design model, instead of using the built-in generic resource management logic, we explicitly model the resource management of doctors with the help of a counter variable for available doctors in the form of an attribute nmrOfAvailableDoctors, and the operations isDoctorAvailable(), allocateDoctor() and releaseDoctor(), in the MedicalDepartment class:

The isDoctorAvailable function simply tests if nmrOfAvailableDoctors > 0, while the procedures allocateDoctor and releaseDoctor decrement and increment the nmrOfAvailableDoctors counter.

In addition to an information design model for defining the simulation's state structure, we also need to make a process design model for defining the dynamics of the simulation. The following DPMN process diagram defines two event rules:

Notice that this process design model contains the entire resource management logic for (de-)allocating doctors to (from) examinations. Since standard resource management procedures can be defined in a generic way, this logic (and the related code) can be moved from example models to the simulator, as explained in the next section.

The following table shows the two event rules defined by the above DPMN diagram, expressed in pseudo-code.

ON (event type)	DO (event routine)
NewCase( md) @ t with md : MedicalDepartment	newExam = new Examination( md); IF md.isDoctorAvailable() md.allocateDoctor(); SCHEDULE new ActivityStart( newExam); ELSE md.plannedExaminations.enqueue( newExam);
Examination( md) @ t with md : MedicalDepartment	IF md.plannedExaminations.length = 0 md.releaseDoctor(); ELSE plannedExam = md.plannedExaminations.dequeue(); SCHEDULE new ActivityStart( plannedExam);

The Medical-Department-1b design model

In the Medical-Department-1b information design model we make two simplifications:

1. We drop the object type MedicalDepartment; since we only need to model one medical department as the process owner, we can leave it implicit. This is a general pattern: whenever there is only one process owner, we can leave it implicit.
2. Since we now use the generic resource management logic that is built into OES Core 2, we do not need to model the methods isDoctorAvailable, allocateDoctor and releaseDoctor. Instead, we define a resource role doctor (with resource cardinality 1) for the activity type Examination.

The resulting information design model only includes two classes: the event type NewCase and the activity type Examination, as shown on the left-hand side of the following class diagram.

On the right-hand side bottom of this diagram, the resource role doctor and its count pool doctors, instantiating the OES Core 2 library classes ResourceRole and CountPool (as a special type of ResourcePool), are shown. Notice that resourceRole assigns the OES resource role doctor with resource cardinality 1 to the activity type Examination[1], which is in turn linked to a count pool with name doctors. In OESjs-Core2, this is coded in the file Examination.js in the following way:

class Examination extends aCTIVITY {
  constructor({id, startTime, duration}={}) {
    super({id, startTime, duration});
  }
  static duration() {return rand.uniform( 5, 10);}
}
Examination.resourceRoles = {
  "doctor": {card:1}
}

The generic class-level ("static") property Examination.tasks is automatically created by the simulator. Likewise, the count pool "doctors" is automatically created and assigned to the resource role definition map entry Examination.resourceRoles["doctor"].

In the Medical-Department-1b process design model we make corresponding simplifications as in the information design model above:

1. Leaving the process owner implicit, we drop the process owner rectangle MedicalDepartment.
2. Since we use the generic resource management logic that is built into OES Core 2 by means of Resource-Dependent Activity Start arrows, we do not need any resource management code involving the methods isDoctorAvailable, allocateDoctor and releaseDoctor in event rules. Since the event rules of the Medical-Department-1a model have only be concerned with resource management, we can discard them altogether.

In the resulting DPMN diagram, the event type NewCase is connected to the activity type Examination with a Resource-Dependent Activity Scheduling arrow:

Using a Resource-Dependent Activity Scheduling arrow from NewCase to Examination implies that upon a NewCase event a new planned Examination activity is enqueued by the simulator, if the required resources are not available; otherwise, a new Examination activity is scheduled to start immediately. Using this built-in standard resource management logic relieves the simulation developer from coding the resource availability tests and the enqueuing of a new Examination activity in a NewCase event rule.

Since in this model, NewCase events and Examination activities are handled according to the generic logic of Activity Networks built into the OES Core 2 simulator, we do not need to model/specify any event rules. For having NewCase events succeeded by Examination activities, we just need to specify this event flow relationship (in OESjs-Core2) in the following way:

NewCase.successorActivity = "Examination";

The simulator interprets this successorActivity assignment when creating follow-up events for NewCase events by enqueuing a planned examination activity in the following way

Examination.tasks.enqueue( new Examination())

The Medical-Department-1c design model

In the Medical-Department-1c design model, the resource pool doctors is modeled as an individual resource pool instead of a count pool. This allows making the model more realistic, for instance, by assigning an individual work schedule to each doctor defining her availability.

Compared to the Medical-Department-1b information design model, we have to change the following:

1. We need to define an object type Doctor having a resource status attribute with the four possible values AVAILABLE, BUSY, OUT_OF_ORDER or OUT_OF_DUTY.
2. While we keep the resourceRole link with the definition of the resource role doctor (with resource cardinality 1), we replace the count pool linked to it with an individual resource pool.

The resulting information design model is shown in the following class diagram:

On the right-hand side bottom of this diagram, the resource role doctor and its individual pool doctors, instantiating the OES Core 2 library classes ResourceRole and IndividualPool (as a special type of ResourcePool), are shown. In OESjs-Core2, this is coded in the file Examination.js in the following way:

Examination.resourceRoles = {
  "doctor": {range: Doctor, card:1}
}

The Medical-Department-1c process design model is the same as in the Medical-Department-1b process design model above:

1.2.2. A design model based on the extended conceptual model

In the Medical-Department-2a design model, we model two activity types: WalkToRoom activities involve a room and are performed by a nurse, while Examination activities involve a room and are performed by a doctor. The resource pools nurses and doctors are modeled as individual resource pools, while the resource pool rooms, which is used by both WalkToRoom and Examination activities, is modeled as a count pool.

The resulting information design model is shown in the following class diagram:

Notice that the generic class-level ("static") properties WalkToRoom.tasks and Examination.tasks don't have to be defined when coding the two activity types since they are automatically created by the simulator.

However, it is an option to show the performer roles with the help of corresponding Lanes:

In OESjs-Core2, the two Resource-Dependent Activity Scheduling arrows between NewCase and WalkToRoom, as well as between WalkToRoom and Examination are coded as

NewCase.successorActivity = "WalkToRoom";

in the file NewCase.js, and as

WalkToRoom.successorActivity = "Examination";

in WalkToRoom.js.

2.1.1. Time Granularity

A model's time granularity is the time delay until the next moment, such that the model does not allow considering an earlier next moment. This is captured by the simulation parameter nextMomentDeltaT used by the simulator for scheduling immediate events with a minimal delay. When a simulation model is based on discrete time, nextMomentDeltaT is set to 1, referring to the next time point. When a simulation model is based on continuous time, nextMomentDeltaT is set to the default value 0.001, unless the model parameter sim.model.nextMomentDeltaT is explicitly assigned in the simulation.js file.

2.1.2. Time Progression

An important issue in simulation is the question how the simulation time is advanced by the simulator. The OES paradigm supports next-event time progression and fixed-increment time progression, as well as their combination.

An OESjs-Core1 model with fixed-increment time progression has to define a suitable periodic time event type, like EachSecond or EachDay in the form of an exogenous event type with a recurrence function returning the value 1. Such a model can be used for

1. modeling continuous state changes (e.g., objects moving in a continuous space), or
2. making a discrete model that abstracts away from explicit events and uses only implicit periodic time events ("ticks"), which is a popular approach in social science simulation.

Examples of discrete event simulation models with fixed-increment time progression and no explicit events are the Schelling Segregation Model and the Susceptible-Infected-Recovered (SIR) Disease Model.

2.2.1. An Activity Type with a Class-Level Resource Role and a Count Pool

Based on the conceptual model of Section 1.1, we choose the design discussed in Section 1.2 in the subsection "The Medical-Department-1b design model" and defined by the following information design model:

Notice that this model

1. Does not define an object type Doctor, since the doctors of the department are not modeled as a collection of individual persons, but as an abstract aggregate in the form of a count pool.

2. Does not link the resource role doctor to the count pool doctors because linking a resource pool to an activity type for any of its resource roles has to be done by a process model, either implicitly or explicitly. By default, if there is a resource pool with the same (but pluralized) name as a resource role, it is implicitly assigned to that resource role. In general, an information design model may be the basis for many process models, and each of them may assign a different resource pool to the same resource role of an activity type.

The random variable recurrence for modeling the random variation of the time between new cases samples from the exponential probability distribution with an event rate of 0.3, while the random variable for the duration of an examination samples from the uniform probability distribution with lower bound 5 and upper bound 10 (representing minutes).

The NewCase class can be coded with OESjs-Core2 in the following way:

class NewCase extends eVENT {
  constructor({ occTime, delay}) {
    super({occTime, delay});
  }
  onEvent() {return [];}
  createNextEvent() {
    return new NewCase({delay: NewCase.recurrence()});
  }
  static recurrence() {return rand.exponential( 0.3);}
}

The onEvent method is empty since no event rules are needed for this simple model. Its dynamics is entirely determined by the standard logic of resource-dependent activity scheduling built into OES Core 2.

The Examination class can be coded in the following way:

class Examination extends aCTIVITY {
  constructor({id, startTime, duration}={}) {
    super({id, startTime, duration});
  }
  static duration() {return rand.uniform( 5, 10);}
}
Examination.resourceRoles = {
    "doctor": {countPoolName:"doctors", card:1}
}

The process resulting from NewCase events followed by Examination activities is modeled with a Resource-Dependent Activity Scheduling arrow:

In OESjs-Core2, this simple process model is coded with one line of code in the file NewCase.js:

NewCase.successorActivity = "Examination";

2.2.2. Modeling a Sequence of Two Activity Types

The following information design model of a medical department with two types of activities (discussed in ) is based on the conceptual information model discussed in :

The class implementing the event type NewCase is defined as above. The class implementing the activity type WalkToRoom is defined as follows:

class WalkToRoom extends aCTIVITY {
  constructor({id, startTime, duration}={}) {
    super({id, startTime, duration});
  }
  static duration() {return rand.uniform( 0.5, 2.5);}
}
// A walk to a room requires a room and a nurse
WalkToRoom.resourceRoles = {
  "nurse": {range: Nurse, card:1},
  "room": {countPoolName:"rooms", card:1}
}

The class implementing the activity type Examination is defined as follows:

class Examination extends aCTIVITY {
  constructor({id, startTime, duration}={}) {
    super({id, startTime, duration});
  }
  static duration() {return rand.uniform( 5, 10);}
}
// An examination requires a room and a doctor
Examination.resourceRoles = {
  "doctor": {range: Doctor, card:1},
  "room": {countPoolName:"rooms", card:1}
}

The following process design model (discussed in ) is based on the conceptual process model discussed in :

This process design model with its two Resource-Dependent Activity Scheduling arrows is implemented with just two statements on top of the classes NewCase and WalkToRoom:

// Enqueue a new planned walk
NewCase.successorActivity = "WalkToRoom";
// Enqueue a new planned examination
WalkToRoom.successorActivity = "Examination";

You can run this Medical-Department-2a model from the project's GitHub website.

Activities with Default Durations

When an activity type is defined without defining a class-level duration function, the exponential PDF is used as a built-in default random variable for setting the durations of activities of that type according to the following settings:

aCTIVITY.defaultMean = 1;
aCTIVITY.defaultDuration = function () {
  return rand.exponential( 1/aCTIVITY.defaultMean)
};

It is possible to overwrite these defaults, both the defaultMean and the defaultDuration function, in a simulation.js file.

2.3.1. A Simulation Scenario for Medical-Department-1b

The default simulation scenario for the Medical-Department-1b model defines a duration of 1000 min per simulation run and an initial state with a count resource pool with 3 doctors:

sim.scenario.durationInSimTime = 1000;
sim.scenario.setupInitialState = function () {
  // Initialize the count pool "doctors"
  sim.resourcePools["doctors"].available = 3;
  // Schedule initial events
  sim.FEL.add( new NewCase({occTime: 1}));
}

You can run this Medical-Department-1b scenario from the project's GitHub website. An example of a run of this scenario is shown in the following simulation log:

In the Medical-Department-1c model, which is a variant of Medical-Department-1b, the count pool for doctors is replaced with an individual pool.

2.3.1. A Simulation Scenario for Medical-Department-2

The default simulation scenario for the Medical-Department-2 model defines an initial state with three doctors in the individual pool "doctors", two nurses in the individual pool "nurses" and three rooms in the count pool "rooms":

sim.scenario.durationInSimTime = 1000;
sim.scenario.setupInitialState = function () {
  const d1 = new Doctor({id: 1, status: oes.ResourceStatusEL.AVAILABLE}),
      d2 = new Doctor({id: 2, status: oes.ResourceStatusEL.AVAILABLE}),
      d3 = new Doctor({id: 3, status: oes.ResourceStatusEL.AVAILABLE}),
      n1 = new Nurse({id: 11, status: oes.ResourceStatusEL.AVAILABLE}),
      n2 = new Nurse({id: 12, status: oes.ResourceStatusEL.AVAILABLE});
  // Initialize the individual resource pools
  sim.resourcePools["doctors"].availResources.push( d1, d2, d3);
  sim.resourcePools["nurses"].availResources.push( n1, n2);
  // Initialize the count pools
  sim.resourcePools["rooms"].available = 3;
  // Schedule initial events
  sim.FEL.add( new NewCase({occTime: 1}));
}

You can run this Medical-Department-2a scenario from the project's GitHub website. An example of a run of this scenario is shown in the following simulation log:

2.6.1. Simple Experiments

A simple experiment type is defined with a sim.experimentType record on top of a model by defining (1) the number of replications and (2) possibly a list of seed values, one for each replication. The following code shows an example of a simple experiment type definition:

1
2
3
4
5

sim.experimentType = {
  title: "Simple Experiment with 10 replications, each running for 1000 time units (days)",
  nmrOfReplications: 10,
  seeds: [123, 234, 345, 456, 567, 678, 789, 890, 901, 1012]
};

Running this simple experiment means running the underlying scenario 10 times, each time with another random seed, as specified by the list of seeds. The resulting statistics are composed of the user-defined statistics and the generic statistics (per activity type) for each replication complemented with a summary statistics listing averages, standard deviations, min/max values and confidence intervals.

When no seeds are defined, the experiment is run with implicit random seeds using JavaScript's built-in random number generator, which implies that experiment runs are not reproducible.

The following table shows the experiment results of a simple experiment defined for the Medical-Department-1c model.

2.6.2. Parameter Variation Experiments

A parameter variation experiment is defined with (1) a number of replications, (2) a list of seed values (one for each replication), and (3) one or more experiment parameters.

An experiment parameter must have the same name as the model parameter to which it refers. It defines a set of values for this model variable, either using a values field or a combination of a startValue and endValue field (and stepSize for a non-default increment value) as in the following example.

The following code shows an example of a parameter variation experiment definition (on top of the Inventory-Management simulation model):

1
2
3
4
5
6
7
8
9
10
11

sim.experimentTypes[1] = {
  id: 1,
  title: "Parameter variation experiment for exploring reorderInterval and targetInventory",
  nmrOfReplications: 10,
  seeds: [123, 234, 345, 456, 567, 678, 789, 890, 901, 1012],
  parameterDefs: [
    {name:"reviewPolicy", values:["periodic"]},
    {name:"reorderInterval", values:[2,3,4]},
    {name:"targetInventory", startValue:80, endValue:100, stepSize:10},
  ]
};

Notice that this experiment definition defines 9 experiment scenarios resulting from the combinations of the values 2/3/4 and 80/90/100 for the parameters reorderInterval and targetInventory. Running this parameter variation experiment means running each of the 9 experiment scenarios 10 times (each time with another random seed, as specified by the list of seeds). The resulting statistics, as shown in the following table, is computed by averaging all statistics variables defined for the given model.

2.6.1. Storage and Export of Experiment Results

In OESjs-Core1, an experiment's output statistics data is stored in a browser-managed database using JavaScript's IndexedDB technology. The name of this database is the same as the name of the simulation model. It can be inspected with the help of the browser's developer tools, which are typically activated with the key combination [Shift]+[Ctrl]+[I]. For instance, in Google's Chrome browser, one has to go to Application/Storage/IndexedDB.

The experiment statistics database consists of three tables containing data about (1) experiment runs, (2) experiment scenarios, and (3) experiment scenario runs, which can be exported to a CSV file.