The three-phase simulation library that was built must be used together with a simulation model, as an integrated component. A Critical Care Unit (CCU) model is demonstrated in this part along with the features of the library.


  • Definition of model requirements
  • Design of simulation model
    • Entities and Resources
    • Activities
    • Activity Cycle Diagram
    • B Events and C Activities
  • Architecture of CCU model software
    • General Component Diagram
    • Class Diagram
    • Three-phase approach to implementation
    • Entities Specifications
    • Specifying B Events and C Activities
  • Demonstration of model
    • Setting Simulation Parameters
    • Setting Emergency Patient Group
    • Setting Elective Patient Group
    • Setting Care Unit
    • Setting initialisation and finalisation code for library events
    • Running simulation
    • Getting Results

Definition of model requirements

The basic structure of the system is shown below. A CCU is usually a part of a hospital where patients receive intensive care. Critical care is very limited and expensive, so good planning and management of capacities and providing good service to the patients are very important.



  1. Patients are of two broad types: emergency and elective (or planned). Elective patients are booked so that their arrivals in a CCU are known. Emergency patients arrive from many sources and they are often given priority over elective patients. People needing Critical Care are very sick and the mortality rate of emergency patients is around 30%.
  2. Resources are divided into physical (like beds) and human (like doctors and nurses). In this demonstration, only beds are considered, and the main question the model is trying to answer is: how many beds are required in a CCU for a certain number and type of patients.
  3. The flows of patients happen in this manner: emergency and elective arrive at the care unit and queue for an available bed. There should not be many patients in this queue, as rules states that emergency patients must be transferred to other units and elective patients operations must be deferred if all beds are busy in the unit.
  4. Patients who get an available bed stay in the unit for a random period (length of stay)estimated by a lognormal distribution. After their treatment, patients are discharged. Data is collected throughout the simulation regarding number of arrivals (emergency, elective), number of transfers and deferrals, and how much the system was utilised (bed occupancy rates).

Design of simulation model

The process of designing a model for discrete-event simulation is usually taken in three parts: the identification of entities and resources; consideration on the activities they engage, and link of these activities together.

Entities and Resources

Two entities and one resource can be identified in this model. An emergency and an elective patient group are the entities that would generate patients based on the population of each group. The only resource in this case is the care unit, i.e. the beds that can be used by the two patient groups/entities.


Patients (emergency and elective) arrive in the system, queue, occupy bed for a period of time (length of stay) and are discharged. For the patients, though, there are three activities: arrival, queuing and occupying beds. For the care unit, one activity is possible: the occupancy of beds.

Activity Cycle Diagram

The Activity Cycle Diagram is used to help in the development of simulation models. The diagram is particularly useful for systems with a queuing structure. Systems are modelled as sets of active and dead states, which are represented by rectangles and circles, respectively. Arrows symbolises the changes of states.

Active states involves co-operation of entities and resources, and dead states do not involve any kind of co-operation. A dead state is normally a state when an entity is waiting for something to happen. The duration of active states can be either deterministic or probabilistic, depending on this latter case, on the use of random numbers. Dead states duration cannot be predicted at all; it depends strictly on preceding and succeeding active states duration.

The CCU model can be modelled as the activity cycle diagram shown below. Active states, i.e. states where some co-operation is occurring, are the Arrival and Occupy Bed. Dead states, when the system is waiting for something to occur, are Queue and Idle.


Activity Cycle Diagram of CCU Model


B Events and C Activities

Another characteristic of the activity cycle diagram is that it can identify B Events and C Activities for a three-phase approach implementation of the model. B Events occur when an active state changes to a dead state, and C Activities starts when an entity goes from a dead state to an active state.

Looking again at the activity cycle diagram of the CCU model, two B Events and one C Activity can be defined. The event of a patient arriving, called PatientArrive, and the event of a patient being discharged is another B Event, called EndOccupyBed. Two arrows in the diagram represent the same C Activity, but occur in two directions: the first is the patient occupying a bed, and, second, a bed being occupied (not being idle anymore) by a patient. This C Activity can be called BeginOccupyBed.

All these events and activities have to be doubled in the system (for each patient group/entity), even though they behave very similarly. Thus, to differentiate an emergency from an elective event, the model will contain an EmergencyPatientArrive and an ElectivePatientArrive, an EmergencyBeginOccupyBed and an ElectiveBeginOccupyBed, and, finally, an EmergencyEndOccupyBed, and an

Architecture of CCU model software

Having defined the simulation objects, a very simple architecture to a software implementation was done based on the requirements for this model.

General Component Diagram

The CCU Model will be implemented with no graphical user interface, and the interactions of the model with its probable end-user are very restricted through standard console and hard-coded into the piece of software. A general component view of the model is shown below. The CCU Model (an executable) interacts with a component (ThreePhaseSharpLib) and the package System (from the Microsoft .NET Framework, version 1.0).

Class Diagram

The CCU model will be implemented as a system that contains a main class, Model, which represents the simulation model and comprises other three: Simulation (taken from the library), PatientGroup (derived from the EntityBase) and CareUnit (derived from the ResourceBase). The PatientGroup class realizes two other classes in the model: Emergency and Elective, representing the two distinct patient groups. UML diagram that illustrates these relationships is shown below.

Three-phase approach to implementation

The model was developed from the activity cycle diagram using the three-phase approach. This means, in practical terms, that entities have a crucial role in the simulation mechanism. Consequently, all events are related to them.

Another thing that should be pointed out is the order that C Activities are tried. This is important for the behaviour of the model if activities must be executed with some priority. In this demonstration model, for example, the EmergencyBeginOccupyBed should be tried first than the ElectiveBeginOccupyBed, because emergency patients have a priority through elective ones.

Entities Specifications

Entities (emergency and elective patient groups) have two essential operations:

  • Generation of arrivals – This is done through a negative exponential distribution, with the variable PopulationByYear as a parameter. The result is an inter-arrival time between patients (in hours).
  • Length of Stay (LOS) sample – The period a patient of each group stays in a bed is calculated from a lognormal distribution. This distribution takes two parameters: a mean and a standard deviation. There are also minimum and maximum values if this sample goes out of user-defined range. LOS data is usually available as days so this value has to be transformed from days to hours.

Specifying B Events and C Activities

Four B Events (two PatientArrive and EndOccupyBed for each patient group) and two C Activities (emergency and elective BeginOccupyBed) are methods of the Model class. They are responsible for making the system move, scheduling next B events to occur, and are all managed by the simulation library. These are brief descriptions of each of them (observing that there are two for each patient group as well):

  • PatientArrive – This B event occurs at each inter-arrival time, defined by each patient group. A patient arrives in the care unit and joins a queue to be attended. The next arrival is scheduled.
  • BeginOccupyBed – This C activity depends on having an entity (patient) and a resource available (bed). It tries to put all patients in the queue on beds in the care unit. If a patient gets a bed, another B Event (EndOccupyBed) is scheduled to occur after the specific LOS of that patient (sampled from Lognormal distribution).
  • EndOccupyBed – This is another B event, which occurs when the patient finishes his treatment in the care unit. This also releases one bed in the care unit, making space for other patients to be admitted.

Demonstration of model

In the following subsections, the CCU model that was built using the three-phase simulation is demonstrated. The data and parameters used in this example of CCU model are fictional and are shown here for the purpose of a demonstration.

Setting Simulation Parameters

The simulation parameters are set directly to the Simulation class in the library. The base time unit used here is hour. The duration of the simulation will be set to 1 (one) year or 365 days, which are 8760 hours. The number of runs will be 10 and there is no warm-up time.

Setting Emergency Patient Group

The Emergency Patient Group has a population of 400 patients in a year. The LOS for these patients will be given in integer days, but transformed to hours, and it is sampled from a lognormal distribution. It has the following parameters:

  • LOS Mean: 4.79
  • LOS Standard Deviation: 10.26
  • LOS Minimum: 0
  • LOS Maximum: 102

Setting Elective Patient Group

The Elective Patient Group has a population of 200 patients in a year. The LOS for these patients will be given in integer days, but transformed to hours, and it is sampled from a lognormal distribution. It has the following parameters:

  • LOS Mean: 3.49
  • LOS Standard Deviation: 8.69
  • LOS Minimum: 0
  • LOS Maximum: 54

Setting Care Unit

The critical care unit has 10 beds and reserves 1 bed only for emergency patients.

Setting initialisation and finalisation code for library events

The model has specific code for two of the simulation library events. The first is the OnStartRun, where initialisation is performed: results values for entities and resources are set to zero, and two B Events (for the two entities) are scheduled to occur at simulation time (ST) zero (EmergencyPatientArrive and ElectivePatientArrive). At the end of each run, the library raises the OnFinishRun event, and the CCU model calculates results and display them on the standard console.

Running simulation

The process of running the simulation is straightforward having set the library properly. A function to display time was added to the model so the end-user can check how progress is going. In a more complex and interactive model, this should be done by the GUI (graphical user interface).

Getting Results

During the simulation run, basic statistics are collected for entities and resources. The user essentially controls these, except from the Utilisation field for the entities, which is updated at each call of the Schedule operation through simulation run.

Each patient group (Emergency and Elective), which is derived from the EntityBase, have two result values: NumberOfArrivals and NumberOfPatientsDeferred. These reset at the beginning of each simulation run. In the summary results, they appear as Number of Emergency Arrivals and Number of Emergency Transfers (for Emergency patient group) and Number of Elective Arrivals and Number of Elective Deferrals (for Elective patient group).

The beds resource, which is derived from the ResourceBase in the library, accumulates a value for its total utilisation. This value will be calculated to give the bed occupancy rate at each simulation run. Bed Occupancy Rate have the following formula: u / (nb * d), where u is the utilisation (the sum of all LOS of patients), nb is the number of beds in the care unit, and d is the duration of each run.

Results for the 10 runs from an execution of the CCU Model software are shown below. Results for emergency and elective arrivals are normally around the population for those patient groups. In this case, for 10 runs, there is an average of 400 for emergency arrivals and 200 for elective arrivals (not accounting for emergency transfers and elective deferrals). Bed Occupancy Rate had an average of approximately 77% for all 10 runs. This is based on the lognormal distribution with its parameters.


Simulation Results


Run Duration: 8760 hours (365 days)

Number of Runs: 10


Results for Run 1 of 10


Number of Emergency Arrivals: 383

Number of Elective Arrivals: 200

Number of (Emergency) Transfers: 20

Number of (Elective) Deferrals: 20

Utilisation (of Beds): 65352 (hours)

Availability (of Beds): 87600 (hours)

Bed Occupancy Rate: 74.60 %


Results for Run 2 of 10


Number of Emergency Arrivals: 383

Number of Elective Arrivals: 192

Number of (Emergency) Transfers: 47

Number of (Elective) Deferrals: 27

Utilisation (of Beds): 65640 (hours)

Availability (of Beds): 87600 (hours)

Bed Occupancy Rate: 74.93 %


Results for Run 3 of 10


Number of Emergency Arrivals: 440

Number of Elective Arrivals: 182

Number of (Emergency) Transfers: 47

Number of (Elective) Deferrals: 37

Utilisation (of Beds): 66432 (hours)

Availability (of Beds): 87600 (hours)

Bed Occupancy Rate: 75.84 %


Results for Run 4 of 10


Number of Emergency Arrivals: 388

Number of Elective Arrivals: 198

Number of (Emergency) Transfers: 25

Number of (Elective) Deferrals: 26

Utilisation (of Beds): 62280 (hours)

Availability (of Beds): 87600 (hours)

Bed Occupancy Rate: 71.10 %


Results for Run 5 of 10


Number of Emergency Arrivals: 391

Number of Elective Arrivals: 185

Number of (Emergency) Transfers: 39

Number of (Elective) Deferrals: 32

Utilisation (of Beds): 64200 (hours)

Availability (of Beds): 87600 (hours)

Bed Occupancy Rate: 73.29 %


Results for Run 6 of 10


Number of Emergency Arrivals: 434

Number of Elective Arrivals: 213

Number of (Emergency) Transfers: 55

Number of (Elective) Deferrals: 40

Utilisation (of Beds): 75600 (hours)

Availability (of Beds): 87600 (hours)

Bed Occupancy Rate: 86.30 %


Results for Run 7 of 10


Number of Emergency Arrivals: 404

Number of Elective Arrivals: 211

Number of (Emergency) Transfers: 54

Number of (Elective) Deferrals: 42

Utilisation (of Beds): 67464 (hours)

Availability (of Beds): 87600 (hours)

Bed Occupancy Rate: 77.01 %


Results for Run 8 of 10


Number of Emergency Arrivals: 414

Number of Elective Arrivals: 202

Number of (Emergency) Transfers: 53

Number of (Elective) Deferrals: 27

Utilisation (of Beds): 66696 (hours)

Availability (of Beds): 87600 (hours)

Bed Occupancy Rate: 76.14 %


Results for Run 9 of 10


Number of Emergency Arrivals: 387

Number of Elective Arrivals: 212

Number of (Emergency) Transfers: 24

Number of (Elective) Deferrals: 37

Utilisation (of Beds): 70536 (hours)

Availability (of Beds): 87600 (hours)

Bed Occupancy Rate: 80.52 %


Results for Run 10 of 10


Number of Emergency Arrivals: 385

Number of Elective Arrivals: 205

Number of (Emergency) Transfers: 24

Number of (Elective) Deferrals: 44

Utilisation (of Beds): 68760 (hours)

Availability (of Beds): 87600 (hours)

Bed Occupancy Rate: 78.49 %


Summary Results (average) for 10 run(s)


Emergency Arrivals: 400

Elective Arrivals: 200

Emergency Transfers: 38

Elective Deferrals: 33

Bed Occupancy Rate: 76.82 %


Last edited Mar 26, 2013 at 1:16 PM by axcosta, version 8


No comments yet.