Вы находитесь на странице: 1из 4



General Description
This model represents a portion of a Health Care Clinic that includes care for several types of sick
patients. The clinic consists of a registration area, basic and advanced evaluation rooms, a lab, and a
checkout area.
Patients enter the clinic through the entrance and go directly to the registration area. After they are
registered, they are sent to either the basic or advanced evaluation room, based on the type of care that
is required. Mild sick patients are sent for basic evaluation tasks, while sick patients are sent for more
advanced evaluation tasks. A portion of the sick patients require lab work to be completed. Once
patients are evaluated and treated, they are sent to the checkout area.

Detailed Description
Patient Arrivals
The PatientArrivals Source is where all patients arrive to the clinic. This Source uses the PatientTypes
data table to determine the percentage mix of patients into the system. The table includes the Patient
Type, as well as the Mix Percentage that is then used in the Row Number property reference
PatientTypes.MixPercentage.RandomRow. The Patient Type, which is the entity name, is set as a key
column so that other tables can use this field for relational tables.
The patient flow through the clinic is determined by the entitys Initial Sequence, which is defined in the
PatientFlow table. The Mild Sick patients will first go to the Registration area, then Basic Evaluation, and
then Checkout. The Sick patients will also first go to the Registration area, then Advanced Evaluation and
then Checkout. The PatientType column in this table is set up as a Foreign Key column that points to
the key PatientType column in the PatientTypes table (PatientTypes.PatientType). Therefore only
those rows associated with a given patient type will be used for that patient type, even though all
sequence type information is shown within this single table.
Registration Area
The registration desk is a standard Server with Initial Capacity of 2. The registration area process
includes several tasks that are specified within the Activity Tasks table, specifically the Registration
activities. These include FindPatientName which is a 5 minute delay and SendInfoToNurse which is a 10
minute delay.
Basic Evaluation
The basic evaluation process is also a standard Server with an initial Capacity of Infinity. The basic
evaluation process includes several tasks (also within the Activity Tasks table), specifically the
BasicEvaluation activities. These include GetVitals which is a 4 minute delay, EvalWithDoctor which is a
6 minute delay and then FollowupTask which is a 2 minute delay. These three tasks are used only by
mild sick type patients based on that patients sequence.


Advanced Evaluation
The advanced evaluation process is also a standard Server with an initial Capacity of Infinity. The
process activities are defined within the Activity Tasks table, specifically the AdvancedEvaluation
activities. These include EvalWithDoctor which is a 15 minute delay and then SendLabWork process,
which only occurs for 70% of the patients (Branch Type is Probabilistic with Condition or Probability of
0.7). These tasks, used only by sick type patients based on that patients sequence.
The SendLabWork task is not a simple delay task like the other tasks defined within the ActivityTasks
table. Instead, the ProcessType is defined as Submodel which will create a SubmodelEntityType
LabWorkOrder that will be sent into the SubmodelStartingNode named Input@LabWork, which is the
entry point of the LabWork Server object. When the ProcessType is Submodel (instead of Specific
Time), then a specified type of entity is created and sent into some other distinct part of the overall
model. The task is considered finished then once that entity has ended its processing (and is destroyed).
In this example, the LabWorkOrder entity is sent into the LabWork server, delays for 20 minutes and
then is done. Once that is completed, the task is complete and the sick patient (still physically located at
the AdvancedEval server) continues to the Checkout.
The last activity for either of the patient types is Checkout, which is a Sink object. There is a simple
Transfer-In Time delay of 1 minute for paperwork activities.
Data Tables
As described above, this example uses a number of relational tables to store data that is used within the
objects of the Facility window.
The PatientTypes table includes an entity reference column and mix percentages used to create the
entities in the PatientArrivals Source object. The PatientType is then a key and used within the
PatientFlow table. The Activities table also has a key column that is used to define the various activities
in the system, including Registration, BasicEvaluation, AdvancedEvaluation and Checkout. Both of these
tables are then used in the PatientFlow table.
The PatientFlow table defines the entity sequences in the system, that is, the steps that each patient will
take as it moves through the clinic. Both the MildSick and Sick patient sequences are shown in this table,
with the Destination column, which is a SequenceDestination property type of column. In this table,
the PatientType column references the PatientTypes table, and the Activity column references the
Activities table. Note that all TransferNodes from one location to the next within the next in the model
indicate the Entity Destination Type as By Sequence.
The ActivityTasks table defines the data that is required in the Processing Tasks repeating properties
within a Server that is specified to have a Process Type of Task Sequence. In this example, the

ActivityTask table includes all the data for 3 types of activities, including Registration, BasicEvaluation
and AdvancedEvaluation. If a property within the repeating property area of the Processing Tasks is not
specified, the property will take on a default value. Note that within the Processing Tasks of a Server,
there are many more properties than shown in the table. For example, Resource Requirements and AddOn Process Triggers properties do not have table references, therefore, there are no resources or
additional process logic needed for any of the activities in this example. An enhancement could include a
resource being required at one or more of the Servers for a processing task. Additional column(s) would
then be required in the ActivityTasks table to map into the corresponding resource fields.

** Note that this example is in progress. **