Tesis Usando SIMIO PDF

UNIVERSIDAD DEL BÍO-BÍO Profesor Patrocinante:
FACULTAD DE INGENIERÍA Dr. Francisco Ramis L.

DEPARTAMENTO DE INGENIERÍA INDUSTRIAL
Tesis para optar al grado de:

Magíster en Ingeniería
Industrial
Desarrollo de un Modelo de Sistema de Salud

Mediante un Lenguaje de Simulación Orientado a
Objeto Inteligente
Concepción, Mayo de 2011 Marcos Fernando Goldemberg Vargas

2
UNIVERSIDAD DEL BÍO-BÍO Profesor Patrocinante:

FACULTAD DE INGENIERÍA Dr. Francisco Ramis L.
DEPARTAMENTO DE INGENIERÍA INDUSTRIAL
Desarrollo de un Modelo de Sistema de Salud

Mediante un Lenguaje de Simulación Orientado a
Objeto Inteligente
Marcos Fernando Goldemberg Vargas
Tesis para optar al grado de
Magíster en Ingeniería Industrial
Mayo 2011
3
Resumen
La simulación es ampliamente utilizada en casos de manufactura, sin embargo los simuladores
y lenguajes de simulación que son diseñados pensando en estos ambientes, raramente contienen las
herramientas y algoritmos necesarios para manejar asuntos en casos de salud. Para estos casos
generalmente los modeladores utilizan un lenguaje orientado a Proceso, enfocado a la entidad y
donde el modelamiento de las decisiones está basado en números aleatorios. La simulación
orientada a objeto, por su parte, es un paradigma que enfatiza la reutilización de objetos para
representar entidades del mundo real de una forma más amigable.
El software de simulación de evento discreto Simio, el cual es orientado a objeto y no posee
herramientas especialmente diseñadas para casos de salud, es nuevo en el mercado y ofrece la
ventaja de permitir crear un modelo y luego reutilizar el trabajo inicial para adaptarlo a futuros
modelos del mismo tipo, a diferencia de simuladores orientados a proceso. En el presente trabajo se
busca analizar la factibilidad de desarrollar modelos de sistemas de salud en Simio. A partir de datos
reales, se desarrolló un modelo de una sala de emergencias de un hospital. Se utilizaron las distintas
opciones del simulador para caracterizar diferentes tipos de pacientes según su edad, gravedad,
transporte utilizado en la llegada, considerando también otros criterios para dar diferentes secuencias
de tratamiento y disponibilidad de recursos, además de poder registrar información de manera
eficiente para efectuar futuros análisis sobre cómo mejorar la atención a los clientes. Se detallan las
instrucciones propuestas a seguir para realizar el modelo.
Se compara la forma de modelar en Simio con respecto al software Flexsim HC, el cual
también es orientado a objeto, pero está exclusivamente diseñado para representar casos de salud. Se
encuentra que existen diferencias entre ambos programas a la hora de definir secuencias e ingresar la
lógica del modelo. Para un modelo simplificado, se verifica que al momento de correr los
programas, Simio se ejecuta hasta 15,6 veces más rápido y se concluye mediante pruebas de
hipótesis para la comparación de las medias, que los datos de tiempo de ciclo promedio de ambos
software son estadísticamente similares, mientras que se encuentran diferencias en los tiempos de
espera de la sala del triage, donde Simio entrega tiempos menores.
4
5
Agradecimientos
A todas las personas que me ayudaron durante el transcurso de este postgrado, no tan sólo en
la parte académica misma, sino que también a los que me instaron a comenzarlo y a los que me
apoyaron a seguir adelante. Entre ellos quiero hacer especial mención a toda mi familia, por ser mi
soporte constante.
A mi profesor patrocinante Dr. Francisco Ramis, por su apoyo en este último trabajo, su
paciencia y por sus consejos, así como a los integrantes del CASP de la Universidad, por toda su
cooperación.
Al profesor Dr. José Alejandro Sepúlveda, no sólo por compartir sus conocimientos, sino que
por recibirme con gran acogida en su lugar de trabajo y en su hogar.
Finalmente a los profesores y compañeros de clases con los que compartí durante el curso, a
mis amigos y compañeros de trabajo.
6
Tabla de Contenidos
LISTA DE TABLAS .......................................................................................................................................................... 8
LISTA DE FIGURAS ........................................................................................................................................................ 9
CAPÍTULO 1. INTRODUCCIÓN ............................................................................................................................... 10
1.1. INTRODUCCIÓN GENERAL .................................................................................................................................. 10
1.2. TRABAJOS PREVIOS ........................................................................................................................................... 11
1.2.1 Discusión .................................................................................................................................................. 11
1.2.2 Hipótesis de Trabajo................................................................................................................................. 12
1.3. OBJETIVOS ......................................................................................................................................................... 12
1.3.1 Objetivo General ...................................................................................................................................... 12
1.3.2 Objetivos Específicos ................................................................................................................................ 12
1.4. ALCANCES Y LIMITACIONES .............................................................................................................................. 13
1.5. TEMARIO Y METODOLOGÍA ............................................................................................................................... 13
CAPÍTULO 2. ANTECEDENTES GENERALES ..................................................................................................... 14
2.1. HISTORIA ........................................................................................................................................................... 14
2.2. MODELAMIENTO EN SIMIO ................................................................................................................................. 16
2.2.1 Objetos y su Jerarquía .............................................................................................................................. 16
CAPÍTULO 3. MODELO DE SALA DE EMERGENCIAS ...................................................................................... 19
3.1. INTRODUCCIÓN .................................................................................................................................................. 19
3.2. ANÁLISIS DEL SISTEMA ...................................................................................................................................... 19
3.3. CLASIFICACIÓN DE PACIENTES .......................................................................................................................... 20
3.4. DATOS DE ENTRADA .......................................................................................................................................... 21
3.5. FLUJO DE PACIENTES ......................................................................................................................................... 23
3.6. RECURSOS.......................................................................................................................................................... 24
3.7. TIEMPOS DE PROCESO ........................................................................................................................................ 25
CAPÍTULO 4. CONSTRUCCIÓN DEL MODELO EN SIMIO ............................................................................... 26
4.1. INTRODUCCIÓN .................................................................................................................................................. 26
4.2. CREACIÓN DE OBJETOS PERSONALIZADOS ........................................................................................................ 26
4.2.1 Entidades (Pacientes) ............................................................................................................................... 26
4.2.2 Triage ....................................................................................................................................................... 27
4.2.3 Businesss Office ........................................................................................................................................ 27
4.2.4 Camas ....................................................................................................................................................... 28
4.2.5 Salas de Espera ........................................................................................................................................ 28
4.2.6 Paramédicos ............................................................................................................................................. 29
4.3. INGRESO DE DATOS ........................................................................................................................................... 30
4.3.1 Tablas ....................................................................................................................................................... 30
4.3.2 Creación de Entidades .............................................................................................................................. 34
4.4. CONSTRUCCIÓN DEL MODELO ............................................................................................................................ 36
4.4.1 General ..................................................................................................................................................... 36
4.4.2 Horarios de Atención de Pacientes Fast-Track ........................................................................................ 42
4.4.3 Pacientes que se van sin Tratamiento (LWT) ........................................................................................... 43
4.4.4 Agravamiento de Pacientes en Espera ..................................................................................................... 47
4.4.5 Transportes ............................................................................................................................................... 49
4.5. COMENTARIOS ................................................................................................................................................... 50
CAPÍTULO 5. MODELAMIENTO EN SIMIO V/S MODELAMIENTO EN FLEXSIM HC .............................. 51
5.1. INTRODUCCIÓN .................................................................................................................................................. 51
5.2. SECUENCIAS ...................................................................................................................................................... 51
5.3. LÓGICA DE MODELAMIENTO .............................................................................................................................. 55
5.4. HERRAMIENTAS ADICIONALES ........................................................................................................................... 58
7
5.4.1 Experimentos ............................................................................................................................................ 58

5.4.2 Analizadores de Datos de Entrada y Salida ............................................................................................. 61
5.4.3 Otras herramientas ................................................................................................................................... 63
5.5. RENDIMIENTO .................................................................................................................................................... 63
5.6. CONCORDANCIA DE DATOS ................................................................................................................................ 65
5.6.1 Consideraciones ....................................................................................................................................... 65
5.6.2 Resultados de los experimentos ................................................................................................................ 68
CAPÍTULO 6. CONCLUSIONES ............................................................................................................................... 79
6.1. SUMARIO ........................................................................................................................................................... 79
6.2. CONCLUSIONES .................................................................................................................................................. 79
6.3. TRABAJO FUTURO .............................................................................................................................................. 81
BIBLIOGRAFÍA .............................................................................................................................................................. 82
8
Lista de Tablas
Tabla N° 3.1 Parámetros Utilizados para la Simulación .................................................................... 21
Tabla N° 3.2 Pacientes Promedio por Hora ....................................................................................... 22
Tabla N° 3.3 Secuencia Seguida por Pacientes Según su Clasificación ............................................ 23
Tabla N° 3.4 Disponibilidad de Recursos .......................................................................................... 24
Tabla N° 3.5 Tiempos de Proceso ...................................................................................................... 25
Tabla N° 4.1 Datos de Pacientes ........................................................................................................ 31
Tabla N° 4.2 Llegada de Pacientes según Horario ............................................................................. 32
Tabla N° 4.3 Ingreso de Llegada de Pacientes según Horario en Simio ............................................ 32
Tabla N° 4.4 Grupos de Camas expresadas como Listas de Nodos ................................................... 40
Tabla N° 5.1 Rendimiento en Computador de Simio y Flexsim HC ................................................. 64
Tabla N° 5.2 Rendimiento en Computador de Simio y Flexsim HC ................................................. 64
Tabla N° 5.3 Tiempo Medio de Ciclo (min) por Réplica................................................................... 68
Tabla N° 5.4 Estadísticas Descriptivas, Tiempos de Ciclo ................................................................ 69
Tabla N° 5.5 Tiempo Medio de Espera en Triage (min) por Réplica ................................................ 73
Tabla N° 5.6 Estadísticas Descriptivas, Tiempos de Espera en Triage.............................................. 74
9
Lista de Figuras
Fig. N° 2.1 Clases de Objetos en Simio ............................................................................................ 17
Fig. N° 3.1 Layout de Sala de Emergencias ...................................................................................... 20
Fig. N° 4.1 Entidad Personalizada como Paciente ............................................................................ 27
Fig. N° 4.2 Servidor Personalizado como Cama............................................................................... 28
Fig. N° 4.3 Transporte Personalizado como Paramédico.................................................................. 30
Fig. N° 4.4 Tabla de Horario de Camas Fast Track ........................................................................... 33
Fig. N° 4.5 Proceso para Asignación de Gravedad de Pacientes ...................................................... 35
Fig. N° 4.6 Red de Caminos en Sala de Emergencia ........................................................................ 37
Fig. N° 4.7 Proceso de Asignación de valor a Indicador de Camas Ocupadas ................................. 38
Fig. N° 4.8 Esquema de Ruteo de Pacientes desde Triage................................................................ 38
Fig. N° 4.9 Ruteo de Pacientes desde Business Office ..................................................................... 39
Fig. N° 4.10 Esquema de Ruteo de Pacientes desde Sala de Espera................................................. 41
Fig. N° 4.11 Esquema de Ruteo de Pacientes Fast Track desde Sala de Espera............................... 42
Fig. N° 4.12 Proceso de Inserción de Entidades en Cola de Almacenamiento ................................. 44
Fig. N° 4.13 Proceso de Remoción de Entidades en Cola de Almacenamiento ............................... 44
Fig. N° 4.14 Proceso de Pacientes que se van sin tratamiento (LWT) en Triage ............................. 46
Fig. N° 4.15 Nodos para Gatillar Procesos de LWT ......................................................................... 47
Fig. N° 4.16 Indicador se Pacientes que se van sin Tratamiento ...................................................... 47
Fig. N° 4.17 Proceso para Agravamiento de Pacientes ..................................................................... 48
Fig. N° 5.1 Ingreso de Secuencias - Simio........................................................................................ 52
Fig. N° 5.2 Propiedades de Nodo de Transferencia para Secuencias – Simio ................................... 52
Fig. N° 5.3 Propiedades de Caminos para Secuencias – Simio ........................................................ 53
Fig. N° 5.4 Ingreso de Secuencias en Tracks - Flexsim HC ............................................................. 54
Fig. N° 5.5 Funciones Avanzadas en Secuencias - Flexsim HC ....................................................... 55
Fig. N° 5.6 Ejemplo de Entidades Fluyendo en el Modelo Físico – Simio ...................................... 56
Fig. N° 5.7 Ejemplo de Proceso – Simio .......................................................................................... 56
Fig. N° 5.8 Disposición del Modelo - Flexsim HC ........................................................................... 57
Fig. N° 5.9 Ingreso de Parámetros en Tracks - Flexsim HC ............................................................. 58
Fig. N° 5.10 Experimenter – Simio ................................................................................................... 59
Fig. N° 5.11 Experiment Manager - Flexsim HC ............................................................................. 60
Fig. N° 5.12 Visualización de Medidas de Desempeño - Flexsim HC ............................................. 61
Fig. N° 5.13 Cuadros SMORE – Simio ............................................................................................ 62
Fig. N° 5.14 Diagrama de Sistema de Sala de Emergencias Simplificado ....................................... 63
Fig. N° 5.15 Gráfico Tiempo de Ciclo Promedio v/s Réplicas – Simio ........................................... 70
Fig. N° 5.16 Gráfico Tiempo de Ciclo Promedio v/s Réplicas - Flexsim HC .................................. 70
Fig. N° 5.17 Gráfico de Cajas, Tiempos de Ciclo ............................................................................. 71
Fig. N° 5.18 Gráfico Tiempo Promedio de Espera en Triage v/s Réplicas – Simio ......................... 75
Fig. N° 5.19 Gráfico Tiempo Promedio de Espera en Triage v/s Réplicas – Flexsim HC ............... 75
Fig. N° 5.20 Gráfico de Cajas, Tiempos de Espera en Triage .......................................................... 76
10
Capítulo 1. Introducción
1.1. Introducción General

Debido al incremento en número y complejidad de las intervenciones quirúrgicas, se hace
imprescindible el mantener una gestión eficiente en los sistemas de salud, por lo que las
herramientas que ofrece la Ingeniería Industrial, ya sean existentes tales como el estudio de los
procesos, su modelamiento y estandarización, así como las más nuevas que hacen uso de avances
recientes en la tecnología, han probado ser beneficiosas para mejorar la productividad y la calidad
del servicio. La simulación permite sacar conclusiones a partir de un modelo computacional y es útil
cuando se estudia situaciones dinámicas y de naturaleza estocástica, ya que entrega estimadores
realísticos de un sistema con cierto comportamiento esperado y de sus variaciones.
La simulación ha probado ser de gran ayuda para resolver problemas en los campos de la
manufactura, logística y aplicaciones militares, sin embargo los simuladores y lenguajes de
simulación que son diseñados pensando en estos ambientes, raramente contienen las herramientas y
algoritmos necesarios para manejar asuntos en casos de salud, a pesar del tamaño y la importancia
de esta industria [9] [10]. Un sistema de salud es una organización compleja de analizar y simular,
debido a la alta interacción entre el personal médico y los pacientes que pueden presentar distintos
tipos de severidad. Para estos casos generalmente los modeladores utilizan un lenguaje orientado a
proceso enfocado a la entidad y donde el modelamiento de las decisiones está basado en números
aleatorios. Por la experiencia de trabajos anteriores se tiene que la simulación orientada a proceso es
muy demandante de tiempo ya que el modelar un caso levemente diferente requiere usualmente la
generación de un modelo totalmente nuevo. La simulación orientada a objeto, por su parte, es un
paradigma que enfatiza la reutilización de objetos para representar entidades del mundo real de una
forma más amigable [6].
Las características de un sistema de salud hacen de la simulación orientada a objeto la más
apropiada, presentando resultados concordantes con la realidad y teniendo la ventaja de ser más
sencilla de modelar [6].
11
1.2. Trabajos Previos

♣ J.A. Sepúlveda, F. Baesler, W. Thompson, “The Use of Simulation for Process Improvement
in an Emergency Department”, Industrial Engineering and management Systems, University
of Central Florida, Orlando, FL, USA, 2003.
En este trabajo se presenta la experiencia con un modelo de simulación desarrollado en un

lenguaje orientado a proceso, donde se analiza el flujo a través de un departamento de emergencia
hospitalario. El modelo fue construido con el objeto de analizar alternativas para disminuir los
tiempos de espera y el número de pacientes que se van sin ser atendidos. El análisis del modelo
muestra que una disposición alternativa de los recursos puede llevar a importantes resultados. El
más significante de ellos es que se disminuyó en un 30% en los tiempos de espera de los adultos y
una reducción casi total de los pacientes que se van sin ser atendidos. Se presenta una descripción
de estos resultados y otros logros cualitativos.
1.2.1 Discusión
Actualmente, los lenguajes de simulación raramente contienen las herramientas y algoritmos

necesarios para manejar asuntos en casos de salud. Para estos casos generalmente los modeladores
utilizan un lenguaje orientado a proceso, como es el caso del software Arena, sin embargo la
simulación bajo el enfoque de proceso puede resultar poco eficiente si se utiliza como herramienta
de análisis en forma regular, ya que el modelar un caso levemente diferente requiere usualmente la
generación de un modelo totalmente nuevo. La simulación orientada a objeto, permite la creación de
bibliotecas de objetos para reutilizarlos en aplicaciones similares. El software Flexsim HealthCare
nació como una biblioteca de objetos para casos de salud a partir del simulador Flexsim, el cual es
orientado a objeto.
Con la aparición en el mercado del software de simulación orientado a objeto Simio, surge
una buena oportunidad para analizar la factibilidad de su implementación como herramienta de
análisis para casos de salud y la creación de objetos con características especialmente desarrolladas
para este campo, con el potencial de obtenerse una versión exclusiva para modelamiento de este tipo
de sistemas.
12
1.2.2 Hipótesis de Trabajo
Hipótesis general:
El software de simulación Simio permite su aplicación en modelamiento de sistemas de
salud.
Hipótesis puntuales:
Es posible modelar en Simio un sistema complejo de salud consistente en una sala de
emergencias que recibe 75.000 pacientes al año, clasificarlos según su edad, origen,
gravedad y darles distinto tipo de atención.
El software Simio presentará un mejor rendimiento que Flexsim HC al momento de su
ejecución en un computador.
Los valores resultantes arrojados por Simio serán similares a los arrojados por Flexsim HC.
1.3. Objetivos
1.3.1 Objetivo General
Desarrollar en el software de simulación de evento discreto orientado a objeto Simio un

modelo de una sala de emergencias y evaluar su desempeño en relación al software Flexsim HC.
1.3.2 Objetivos Específicos
Construir un modelo de una sala de emergencias donde se utilicen las herramientas del
programa para representar características del sistema como clasificación y flujo de pacientes.
Proponer los pasos a seguir para representar en el software Simio las distintas características
del sistema.
Determinar las ventajas y desventajas de modelar un sistema de salud en Simio, comparado
con Flexsim HC.
Estudiar el rendimiento de Simio y comparar la concordancia de sus datos resultantes con
Flexsim HC.
13
1.4. Alcances y Limitaciones

Este trabajo comprende la realización en Simio de un modelo que ya fue realizado
anteriormente en los softwares de simulación Arena y Flexsim HC. Los datos de entrada fueron
obtenidos de estos trabajos anteriores. No se incluye el estudio del comportamiento del sistema o el
análisis de alternativas para su optimización.
1.5. Temario y Metodología

En el capítulo 2 se entregan antecedentes generales de la evolución de la simulación de
evento discreto en la historia. El capítulo 3 presenta al modelo a simular, se señalan sus
características y se indica la información de entrada que se utiliza. El capítulo 4 detalla el diseño
propuesto de cómo realizar el modelo en Simio. En el capítulo 5 se realiza una comparación entre
Simio y Flexsim HC, mientras que en el capítulo 6 se concluye sobre el trabajo realizado.
14
Capítulo 2. Antecedentes Generales
2.1. Historia
En los primeros años de la simulación de evento discreto el paradigma de modelamiento
dominante era la orientación a evento, la que fue implementada por herramientas tales como
Simscript y GASP. En este paradigma de modelamiento, el sistema es visto como una serie de
eventos instantáneos que cambian el estado del sistema. El modelador define los eventos en el
sistema y modela los cambios de estado que se llevan a cabo cuando estos eventos ocurren. Este
enfoque de modelamiento es bastante eficiente y flexible, pero también es una representación
relativamente abstracta del sistema. Como resultado, muchas personas consideran dificultoso el
modelamiento utilizando una orientación a evento [2].
En la década de los ’80 la simulación orientada a proceso desplazó a la orientación a evento,
convirtiéndose en el enfoque dominante para la simulación de evento discreto. En la perspectiva del
proceso se describe el movimiento de entidades pasivas a través del sistema como un flujo de
procesos. El flujo de procesos está descrito por una serie de pasos de procesos (tales como retardar,
aprovechar un recurso, dejarlo ir) que modelan los cambios de estado que se llevan a cabo en el
sistema. Este enfoque data de la década de los ’60 con la introducción del GPSS (Sistema de
Simulación de Propósito General) y proporcionó una manera más natural para describir el sistema.
Sin embargo, debido a numerosos asuntos prácticos con el GPSS original (por ejemplo su reloj
integrado y su lenta ejecución) este sistema no se convirtió en el enfoque dominante hasta las
versiones mejoradas en el año 1976, junto con lenguajes de procesos más nuevos como SLAM y
SIMAN que se volvieron ampliamente utilizados en los ’80 [2].
Durante los ’80 y ’90 la animación gráfica también emergió como una característica clave de
las herramientas de modelamiento en simulación. La construcción de modelos gráficos simplificó la
confección de modelos de procesos y la animación gráfica mejoró dramáticamente la observación y
validación de resultados de simulación. La introducción de Microsoft Windows en el mercado
informático hizo posible el construir interfaces de usuario mejoradas y el surgimiento de nuevas
herramientas gráficas (por ejemplo ProModel y Witness).
Desde la amplia propagación hacia la orientación a procesos basados en gráficos ha habido
refinamientos y mejoras en las herramientas, pero no avances reales en la estructura fundamental del
15
modelamiento. La gran mayoría de los modelos de evento discreto siguen siendo construidos
utilizando la misma orientación a proceso de los últimos 25 años [2].
A pesar de que esta orientación a proceso ha probado ser muy efectiva en la práctica, una
orientación a objeto ofrece un atractivo paradigma de modelamiento alternativo que tiene el
potencial de ser más natural y fácil de usar. En una orientación a objeto se modela el sistema al
describir los objetos que lo conforman. Por ejemplo, se modela una fábrica al describir los
trabajadores, las máquinas, las cintas transportadoras, los robots y otros elementos que son parte del
sistema. El comportamiento del sistema emerge de la interacción de estos objetos.
Aunque algunos productos han sido definidos como orientados a objeto, a la fecha en la
práctica muchos simuladores han elegido continuar con la orientación a proceso. Esto se debe en
gran parte a que, a pesar de que el paradigma de modelamiento fundamental puede ser más simple y
menos abstracto, la implementación específica puede llegar a ser difícil de aprender y utilizar, ya
que necesita programación y tiene lenta ejecución. Estos desafíos no son diferentes a los que
experimentó la orientación a proceso al destronar a la orientación a evento. Cabe señalar que desde
la introducción del primer lenguaje de simulación orientado a proceso (GPSS en 1961), pasaron 25
años antes de que la orientación a proceso se desarrollara a tal punto que los simuladores llegaran a
ser persuadidos a realizar el cambio [2].
Actualmente el software de simulación más utilizado en el mercado es Arena.. Sus creadores,
Dennis Pedgen y David Sturrock, vendieron la marca y presentaron una nueva alternativa de
simulación orientada a objeto, llamada Simio (Simulación basada en Objeto Inteligente), con la que
se ofrecen las siguientes ventajas [3]:
• La capacidad de definir y personalizar objetos utilizando lógica de procesos en lugar de
código, permitiendo que usuarios sin conocimientos en programación tomen completa
ventaja del poder de los objetos.
• Un paradigma que permite que objetos que fueron diseñados de manera independiente
tengan interacciones complejas entre ellos.
• La opción de realizar simulación orientada a objeto, a proceso, de evento discreto, continuo y
basado en agente, y mezclarlas en un solo modelo.
• Una fuerte integración en animación en 2D para una fácil construcción de modelos con
animación en 3D automática para un mayor impacto en la presentación.
16
2.2. Modelamiento en Simio

Simio es un lenguaje de simulación basado en objeto inteligente, y entrega diferencias con
otros software de simulación en la perspectiva de la construcción del modelo. Por ejemplo, en el
software Arena, se utiliza un solo tipo de patrón de modelamiento, llamado orientación a proceso,
en el cual se trabaja en términos de un proceso lógico compuesto por bloques pasivos y que son
activados ante la llegada de una entidad. Las entidades se mueven de bloque en bloque y cambian el
estado del modelo en el tiempo. Los bloques representan acciones lógicas como aprovechar un
recurso, realizar retardos en el tiempo, etc. Primero se debe crear el flujo de procesos para el modelo
en forma de diagrama y luego se dibuja la animación en 2-D de forma separada y se enlaza con el
proceso [11].
En Simio, los modelos se construyen típicamente basados en una orientación a objeto. Se
insertan objetos en la ventana “Facility” (instalación) y se conectan en un ambiente en 3-D. La
ventana “Proceso” es donde se define la lógica en forma de diagramas similares a los de Arena. Los
objetos definen tanto la lógica como la animación del modelo, construyéndose ambos aspectos en un
solo paso. A diferencia de Arena, en Simio se modela a través de objetos físicos en el sistema, por
ejemplo, máquinas, robots, cintas transportadoras, etc., que conforman el sistema [11].
2.2.1 Objetos y su Jerarquía
Existen seis clases básicas de objetos en Simio, las que se muestran en la Fig. N° 2.1, donde
las flechas indican su jerarquía. Éstas proveen un punto de partida para crear objetos inteligentes en
Simio. Por defecto estas seis clases de objeto tienen poca inteligencia nativa, pero poseen la
capacidad de irla adquiriendo. Las clases definen un comportamiento genérico, pero no el
comportamiento específico de un objeto, ya que éste último se da por una definición particular del
objeto, lo que le da su propio comportamiento inteligente. Por ejemplo, una cinta transportadora
puede ser creada mediante la definición de características singulares en un enlace entre dos nodos.
Se puede construir versiones inteligentes de estos objetos al modelar su comportamiento como una
colección de procesos manejados por eventos [11].
17
Fig. N° 2.1 Clases de Objetos en Simio

Fuente: C.D. Pedgen, 2010
La primera clase es el objeto fijo. Éste tiene una ubicación fija en el modelo y puede usarse
para representar un sistema completo (por ejemplo una planta) o componentes del sistema que no se
mueven de un lugar a otro (por ejemplo máquinas, equipamiento) [3][11].
Los agentes son objetos que pueden moverse libremente en el espacio 3D y se usan
típicamente para desarrollar modelamiento basado en agente, lo que es útil para estudiar sistemas
que están compuestos por muchos objetos inteligentes independientes que interactúan entre ellos
para crear un comportamiento general del sistema. Ejemplos de aplicaciones incluyen aceptación del
mercado de un nuevo producto o servicio, o crecimiento poblacional de especies rivales dentro de
un ambiente [3].
Una entidad es una subclase de la clase Agente y posee un comportamiento adicional
importante. Pueden seguir un flujo de trabajo en el sistema, incluyendo la capacidad de utilizar una
red de enlaces para moverse entre objetos; la habilidad de visitar, entrar y salir de ubicaciones entre
otros objetos a través de nodos, y la capacidad de ser recogidas, llevadas y entregadas por objetos
transportadores. Ejemplos de entidades incluyen clientes de un sistema de servicio, piezas de trabajo
en un sistema de manufactura o doctores, enfermeras y pacientes en un sistema de salud. Cabe
señalar que en un sistema de modelamiento clásico las entidades son pasivas y son controladas por
los procesos del modelo [3][11].
Los objetos enlace y nodo se utilizan para construir redes por donde las entidades pueden
circular. Un enlace define un camino para el movimiento de entidades entre objetos. Un nodo define
un punto de partida o de fin para un enlace. Ambos pueden combinarse para componer redes
18
complejas con comportamiento de flujo sin restricción o de tráfico congestionado, entre otros
[3][11].
La clase final es el transporte, que es una subclase de la clase Entidad. Un transporte es una
entidad que adicionalmente posee la capacidad de recoger objetos en una ubicación, llevar esas
entidades a través de una red de enlaces o en el espacio libre, y luego dejarlas en un destino. Un
objeto transporte también la habilidad de moverse fuera de una red y mantener una asociación con
un nodo en esa red, como por ejemplo estacionarse en un nodo de una red [3][11].
19
Capítulo 3. Modelo de Sala de Emergencias
3.1. Introducción
El sistema simulado en este trabajo corresponde a la sala de emergencias del Centro de Salud
Regional de Orlando, Florida, USA, el que recibe alrededor de 75.000 pacientes al año y cuyo
modelo fue confeccionado inicialmente con el objeto de analizar distintas alternativas para disminuir
la cantidad de pacientes que se iban del hospital antes de ser tratados, probablemente dado a largos
tiempos de espera que se producen en ciertos momentos del día [1].
3.2. Análisis del Sistema

La Fig. N° 3.1 muestra la disposición de planta del departamento de emergencias que se
modeló, donde existen varias salas y estaciones de trabajo. Para este modelo de simulación se
definieron las siguientes estaciones [1]:
• Triage: La enfermera clasifica los pacientes que entran caminando por la entrada principal
como emergentes, urgentes o no-urgentes, para luego ser tratados de forma diferenciada
según su gravedad. Algunos pacientes que reúnan requisitos especiales, son clasificados
como “Fast Track”.
• Sala de Espera de Adultos: Lugar donde los pacientes esperan por su atención, luego de
haber sido entrevistados por el business officer.
• Sala de Espera de Pediátricos: Lugar donde los niños esperan por su atención si no hay
camas disponibles.
• Estación de Business Office: Los pacientes se entrevistan con un oficial, quien le toma sus
datos antes de ser atendidos.
• Sala de Espera de Business Office: Los pacientes esperan ser entrevistados por el business
officer.
• Estación de Camas Pediátricas: 10 camas disponibles exclusivamente para atender a niños.
• Estaciones de Camas de Adultos: 29 camas destinadas a la atención de pacientes adultos. A
ciertas horas del día, algunas camas permanecen cerradas debido a falta de personal.
20
• Estación de Camas de Trauma: 6 camas reservadas para casos de trauma.

• Estación de Camas Fast Track: 10 camas disponibles de 11:00 a 23:00 hrs para casos que
cumplen con ciertas características específicas. La atención es realizada en su mayoría por
asistentes de médico y enfermeras.
Camas
Fast Track
Camas Sala de Espera

Pediátricos Pediátricos
Camas Adultos Business

Office
Camas
Trauma
Triage
Paramédicos
Sala de
Sala de Espera Espera
Adultos Business
Office
Ingreso por Ingreso a Pie

Ambulancia
Fig. N° 3.1 Layout de Sala de Emergencias

Fuente: J.A. Sepúlveda et Al., 2003.
3.3. Clasificación de Pacientes

A continuación se indican las distintas clases que tienen los pacientes de este modelo [1].
• Llegada de los pacientes: Los pacientes hacen ingreso a la sala de emergencias caminando o
siendo transportados en ambulancia.
21
o Llegada en ambulancia: Los pacientes transportados en ambulancia entran a la

instalación a través de la entrada de ambulancia y no pasan por el área de triage. Se
les da prioridad a estos pacientes ante los que están esperando en el triage.
o Triage: Los pacientes llegan por sus propios medios, ya sea conduciendo, caminando
o siendo transportados en auto. Acceden a la sala de emergencias a través de la
entrada principal y son entrevistados por la enfermera en el triage donde se les
clasifica por su gravedad y prioridad.
• Gravedad de los pacientes
o Emergente: Accidentes automovilísticos severos, enfermedades agudas, etc. Los
pacientes emergentes tienen prioridad ante los demás ya que el tiempo es un factor
importante en situaciones donde hay riesgo vital. Se representan con ropa de color
rojo en el modelo. Éstos tienen prioridad y son atendidos antes que cualquier otro
paciente.
o Urgente: Pacientes con condición menos seria que un caso emergente. En el modelo
se representan con ropa de color amarillo.
o No Urgente: Casos que no representan riesgo vital. Representados con pacientes con
ropa de color verde.
• Edad de los Pacientes
o Adultos: 18 años de edad o más.
o Pediátricos: 17 años de edad o menos.
3.4. Datos de Entrada
Para el modelo simulado, se tomaron como parámetros los datos indicados en la Tabla N°
3.1 [1].
Tabla N° 3.1 Parámetros Utilizados para la Simulación

MODE DE Total de Casos % de Número de
LLEGADA Pacientes
Ambulancia 234 22%
No-Ambulancia 828 78%
22
PACIENTES NO- Adulto Pediátrico

AMBULANCIA
Emergente 8% 8%
Urgente 65% 80%
No Urgente 27% 12%
Total de Casos 1.026 342
PACIENTE No-Ambulancia Ambulancia

ENVIADO A
Adulto 53 % 67 %
Fast-track 17 % 3%
Pediatrico 28 % 12 %
Trauma 2% 18 %
Número de Casos 703 195
Fuente: J.A. Sepúlveda, 2003.
La tasa de llegada de pacientes es variable en el día según el horario y es la que se indica en

la Tabla N° 3.2.
Tabla N° 3.2 Pacientes Promedio por Hora

Horario Llegadas por
hora
0 a 1:59 5.3
2 a 7:59 3.7
8 a 10:59 68.1
11 a 18:59 10.4
19 a 21:59 12.9
22 a 23:59 9.9
Fuente: Centro Avanzado de Simulación de Procesos, Universidad del Bío- Bío.
23
3.5. Flujo de Pacientes

Los pacientes siguen distintas secuencias al interior de la sala de emergencias, dependiendo
de su clasificación. Éstas se indican en la Tabla N° 3.3 [1].
Tabla N° 3.3 Secuencia Seguida por Pacientes Según su Clasificación

PEDIÁTRICO ADULTO FAST- AMBULANCIA
TRACK
Triage Triage Triage Cama
Espera BO Espera BO Espera BO Atención
BO BO BO BO
Espera Espera Espera - Espec.
Pediátricos Adultos Adultos
Despacho
Cama Cama Cama
Pediátricos Adultos Fast-Track
Atención Atención Atención
BO BO BO
- Espec. - Espec. Despacho
Despacho Despacho
Según la Tabla N° 3.3, los adultos que llegan caminando pasan por el triage y van a la sala
de espera de la Business Office, en caso que no haya camas disponibles. Después de una entrevista
preliminar con el Business Officer donde se consigue información básica del paciente para generar
una cuenta, el paciente queda en la sala de espera. Cuando hay disponibilidad de camas, el adulto
recibe atención, luego una segunda entrevista y algunas veces se llama a un especialista para
consultas. Para efectos de simulación, estas tres últimas actividades se concentraron en un solo
proceso (“Cama”). Finalmente el paciente es despachado.
Cabe señalar que si existe disponibilidad de camas desde un principio, el paciente va
directamente a la cama luego de la atención en el triage, sin pasar por las salas de espera. En este
caso el buisiness officer realiza la entrevista en la cama, tiempo que en este trabajo está considerado
dentro del proceso “Cama”.
Adicionalmente, existen tres tipos de disposición del paciente: el paciente es admitido, el
paciente es despachado o el paciente se va sin ser atendido. En este trabajo sólo se consideraron
estas últimas dos clasificaciones. Para los pacientes que se van sin tratamiento (LWT) se asumió que
un 30% de los pacientes que esperan más de 2,5 horas se van sin tratamiento. Por lo tanto, cada 1
24
hora la simulación verifica en las colas y salas de espera si hay pacientes que llevan más de 2,5
horas esperando y determina si se van sin tratamiento (30% de probabilidad) o si esperan una hora
más [1].
3.6. Recursos
En la sala de emergencias existen distintos tipos de recursos, ya sean humanos o materiales.
En la simulación se asumen los recursos indicados en la Tabla N° 3.4.
Tabla N° 3.4 Disponibilidad de Recursos

RECURSO DISPONIBILIDAD
Enfermera de Triage 1
Business officer 1
Paramédicos (transporte de 4
pacientes)
Camas de Adultos
• De 23:00 a 03:00 hrs 25
• De 03:00 a 09:00 hrs 22
• De 09:00 a 11:00 hrs 25
• De 11:00 a 23:00 hrs 29

Camas Fast-track
• De 11:00 a 23:00 hrs 10
• De 23:00 a 11:00 hrs 0

Camas de Pediatría 10
Camas de Trauma 6
Cabe señalar que en el horario de 11:00 a 23:00 hrs, dos camas de Fast Track pueden ser
utilizadas para pacientes de ambulancia en casos de alta demanda. Además, de las 6 camas de
Trauma una puede ser utilizada para otros casos de ambulancia y otra para casos emergentes del
triage [1].
25
3.7. Tiempos de Proceso
Los tiempos de atención considerados en este trabajo son los que se indican en la Tabla N°
3.5, para cada tipo de paciente.
Tabla N° 3.5 Tiempos de Proceso

Servidor Tiempo proceso Comentario
Triage erla(2.5,2 ) Todos
Business Office norm( 5,2.2 ) Todos
Cama niños gamm(75,2.58) No Urgente & Urgente
70+weib(342,1.6) Emergente
Cama adultos 9+gamm(60,2.22) No Urgente & Urgente
tria(90,300,540) Emergente
Cama Fast Track 4+erla(30,3) Todos
Fuente: Centro Avanzado de Simulación de Procesos, Universidad del Bío- Bío.
26
Capítulo 4. Construcción del Modelo en Simio
4.1. Introducción
En este capítulo se propone un desarrollo del modelo presentado en el Capítulo 3 en el
software de simulación Simio. Se detallan las instrucciones paso a paso que se siguieron para su
construcción.
4.2. Creación de Objetos Personalizados

A partir de objetos estándar, se crean objetos personalizados con características particulares
para representar el sistema. Éstos son los pacientes, salas de espera, enfermeras, etc.
4.2.1 Entidades (Pacientes)
Se crea una nueva entidad personalizada para utilizarla como distintos tipos de paciente (Fig. N°
4.1). Los pasos a seguir son los siguientes:
• En la ventana de Navegación se crea una nueva entidad llamada “Paciente”.

• En Definiciones, Estados, se crean dos estados discretos llamados “Gravedad” y
“TiempoEnCola”. Éstos se utilizarán más adelante.
• En Definiciones, Externo, poner símbolo de figura humana.
• En Definiciones, Propiedades, cambiar la Velocidad Inicial Deseada a otro valor, como 0.5
(m/s).
• En la vista Facility, insertar una entidad del tipo Paciente.
• Nombrarla como “Adulto” y agregarle 2 símbolos adicionales. Asignarle colores verde,
amarillo y rojo para símbolos 0, 1 y 2, respectivamente. Estos colores representarán la
gravedad del paciente.
• En Propiedades de Paciente, Animación, Símbolo Actual, ingresar la expresión
‘Paciente.Gravedad - 1’. Esto cambiará el color de la entidad, según su gravedad.
• De la misma forma se puede agregar más tipos de pacientes, tales como “Pediatrico”,
“FastTrack” o “Trauma”.
27
Fig. N° 4.1 Entidad Personalizada como Paciente

Fuente: Elaboración propia.
4.2.2 Triage
A partir de un servidor, se crea el “Triage”, que es donde se reciben los pacientes por primera
vez y se identifican según su gravedad. Los pasos a seguir son los siguientes:
• Hacer una subclase de un Servidor y nombrarlo “Triage”.

• En Definiciones, Externo, cambiar la apariencia del símbolo y las colas.
• En Definiciones, Propiedades, modificar el Tiempo de Proceso por la expresión
‘DatosPacientes.TiempoTriage’.
4.2.3 Businesss Office
A partir de un servidor, se crea el “Business Office”, que es donde se toma los datos de los
pacientes que están esperando atención. Los pasos a seguir son los siguientes:
• Hacer una subclase de un Servidor y nombrarlo “BusinesssOfficer”.

‘DatosPacientes.TiempoBusinesssOffice’.
28
4.2.4 Camas
A partir de un servidor, se crea la Cama, que es el proceso donde se atiende al paciente (Fig.
N° 4.2). Los pasos a seguir son los siguientes:
• Hacer una subclase de un Servidor y nombrarlo “Cama”.

‘DatosPacientes.TiempoCamaNoUrgente*(Paciente.Gravedad==1)+DatosPacientes.Tiempo
CamaUrgente*(Paciente.Gravedad==2)+DatosPacientes.TiempoCamaEmergente*(Paciente.
Gravedad==3)’. Esta expresión tiene tres sumandos, pero sólo uno será distinto de cero,
dependiendo del número que lleve el estado “Gravedad” de la entidad “Paciente”. Así, el
tiempo en cama corresponderá a una de las tres expresiones ingresadas en la tabla
“DatosPacientes”.
• En Definiciones, Propiedades, modificar la Capacidad de Búfer de Entrada a 0.
Fig. N° 4.2 Servidor Personalizado como Cama

4.2.5 Salas de Espera
A partir de un servidor, se crea la Sala de Espera, que tiene tiempo de proceso 0 y donde el
paciente espera por una cama disponible. Los pasos a seguir son los siguientes:
• Hacer una subclase de un Servidor y nombrarlo “SalaEspera”.

• En Definiciones, Propiedades, modificar lo siguiente:
29
o Initial Capacity: 1
o Ranking Rule: Largest Value First
o Ranking Expression: Paciente.Priority. Se le dará prioridad en la cola a pacientes
con mayor gravedad.
o Processing Time: 0
o Input Buffer Capacity: 200
o Output Buffer Capacity: 0
4.2.6 Paramédicos
A partir de un vehículo, se crea el Paramédico, que es el transporte que mueve a los pacientes
dentro de la instalación (Fig. N° 4.3). Los pasos a seguir son los siguientes:
• Hacer una subclase de un Vehículo y nombrarlo “Paramédico”.

• Cambiar la apariencia del símbolo y las colas. Se sugiere descargar de Google Warehouse un
símbolo de una silla de ruedas y agregarle un símbolo de una figura humana que la
transporte.
• En Definiciones, Propiedades, modificar lo siguiente:
o Initial Desired Speed: 0.5. La velocidad de los paramédicos será de 0.5 m/s.
o Initial Node: Nodo desde donde los paramédicos inician su recorrido en el modelo,
por ejemplo BasicNode52.
o Idle Action: Park at Home. Cuando el vehículo esté libre se irá al nodo inicial para
estacionarse en una cola.
o Task Selection Strategy: Largest Priority. Los vehículos darán prioridad a los
pacientes emergentes.
30
Fig. N° 4.3 Transporte Personalizado como Paramédico

4.3. Ingreso de Datos
4.3.1 Tablas
Se creará una tabla conteniendo información como tipos de pacientes, llegadas, tiempos de
procesos. Los pasos a seguir para su construcción son los siguientes:
• En la vista Datos, crear una Tabla de Datos llamada “DatosPacientes”.

• Agregar una Referencia a Objeto del tipo Entidad llamada “TipoDePaciente”. En la columna
se ingresará los distintos tipos de pacientes, es decir, “Adulto”, “Pediatrico”, “FastTrack”,
etc.
• Agregar una Propiedad Estándar del tipo Real llamada “Llegadas”. Los valores a ingresar
corresponderán al porcentaje de llegadas de cada tipo de paciente.
• Crear 3 columnas de Propiedad Estándar del tipo Real llamadas “PorcentajeNoUrgente”,
“PorcentajeUrgente” y “PorcentajeEmergente”. Éstas contendrán el número correspondiente
al porcentaje de llegada de cada gravedad para cada tipo de paciente.
• Crear columnas para tiempos de Triage y Businesss Office agregando Propiedades Estándar
del tipo Expresión llamadas “TiempoTriage” y “TiempoBusinesssOffice”. Se completarán
con una expresión, como por ejemplo ‘(Random.Erlang(2.5,2))/60’ para Triage. En este caso
los tiempos son comunes para todos los pacientes, por lo que se debe repetir la misma
expresión en las columnas, pero el modelo da la posibilidad de utilizar tiempos distintos.
Cabe señalar que las tablas trabajan con valores en horas, por lo tanto se debe dividir la
expresión por 60.
31
• Se tiene 3 tipos de gravedad por cada paciente, por lo tanto hay 3 tiempos de atención por
cada paciente. Se ingresará entonces el tiempo en cama en 1 columna por cada tipo de
gravedad. Se debe agregar una Propiedad Estándar del tipo Expresión llamada
“TiempoCamaNoUrgente”, donde se completará con una expresión, como por ejemplo ‘(9 +
Random.Gamma(2.22,60))/60’.
• De la misma forma anterior, crear columnas “TiempoCamaUrgente” y
“TiempoCamaEmergente”. En las propiedades del objeto Cama se incluye la expresión
general que considera los 3 tiempos según gravedad.
Finalmente, la tabla “DatosPacientes” que se ingresa en Simio conteniendo la información de

llegadas y tiempos de proceso es la Tabla N° 4.1.
Tabla N° 4.1 Datos de Pacientes

TipoDePaciente Llegadas PorcentajeNoUrgentes PorcentajeUrgentes PorcentajeEmergentes TiempoTriage
Adulto 41.34 27 65 8 (Random.Erlang(2.5,2))/60
Pediatrico 21.84 12 80 8 (Random.Erlang(2.5,2))/60
FastTrack 13.26 27 65 8 (Random.Erlang(2.5,2))/60
Trauma 1.56 27 65 8 (Random.Erlang(2.5,2))/60
AdultoAmb 14.74 27 65 8 0
PediatricoAmb 2.64 12 80 8 0
FastTrackAmb 0.66 27 65 8 0
TraumaAmb 3.96 27 65 8 0
TiempoBusinessOffice TiempoCamaNoUrgente TiempoCamaUrgente TiempoCamaEmergente

(Random.Normal(5,2.2))/60 9+Random.Gamma(2.22,60) 9+Random.Gamma(2.22,60) Random.Triangular(90,300,540)
(Random.Normal(5,2.2))/60 Random.Gamma(2.58,75) Random.Gamma(2.58,75) 70+Random.Weibull(1.6,342)
(Random.Normal(5,2.2))/60 4+Random.Erlang(30,3) 4+Random.Erlang(30,3) 4+Random.Erlang(30,3)
(Random.Normal(5,2.2))/60 9+Random.Gamma(2.22,60) 9+Random.Gamma(2.22,60) Random.Triangular(90,300,540)
0 9+Random.Gamma(2.22,60) 9+Random.Gamma(2.22,60) Random.Triangular(90,300,540)
0 Random.Gamma(2.58,75) Random.Gamma(2.58,75) 70+Random.Weibull(1.6,342)
0 4+Random.Erlang(30,3) 4+Random.Erlang(30,3) 4+Random.Erlang(30,3)
0 9+Random.Gamma(2.22,60) 9+Random.Gamma(2.22,60) Random.Triangular(90,300,540)
El número de llegadas por hora dependerá de la hora del día. Para este caso se tiene que en
promedio la sala de emergencias recibe por hora el número de pacientes indicado en la Tabla N° 4.2.
32
Tabla N° 4.2 Llegada de Pacientes según Horario

Horario Nº de Pacientes
por hora
0 a 1:59 5.3
2 a 7:59 3.7
8 a 10:59 68.1
11 a 18:59 10.4
19 a 21:59 12.9
22 a 23:59 9.9
Fuente: Centro Avanzado de Simulación de Procesos, Universidad del Bío-Bío.
Por lo tanto se creará una tabla para establecer tasas de llegada variables en el tiempo.
• En la vista Datos, crear una Rate Table llamada “TasaLlegada”.

• Ingresar datos para cada hora del día. La tabla debería verse como la Tabla N° 4.3.
Tabla N° 4.3 Ingreso de Llegada de Pacientes según Horario en Simio

Starting Offset Ending Offset Rate (events
per hour)
Day 1, 00:00:00 Day 1, 01:00:00 5.3
Day 1, 01:00:00 Day 1, 02:00:00 5.3
Day 1, 02:00:00 Day 1, 03:00:00 3.7
Day 1, 03:00:00 Day 1, 04:00:00 3.7
Day 1, 04:00:00 Day 1, 05:00:00 3.7
Day 1, 05:00:00 Day 1, 06:00:00 3.7
Day 1, 06:00:00 Day 1, 07:00:00 3.7
Day 1, 07:00:00 Day 1, 08:00:00 3.7

Day 1, 08:00:00 Day 1, 09:00:00 68.1
Day 1, 09:00:00 Day 1, 10:00:00 68.1
Day 1, 10:00:00 Day 1, 11:00:00 68.1

Day 1, 11:00:00 Day 1, 12:00:00 10.4
Day 1, 12:00:00 Day 1, 13:00:00 10.4
Day 1, 13:00:00 Day 1, 14:00:00 10.4

Day 1, 14:00:00 Day 1, 15:00:00 10.4
Day 1, 15:00:00 Day 1, 16:00:00 10.4
Day 1, 16:00:00 Day 1, 17:00:00 10.4

Day 1, 17:00:00 Day 1, 18:00:00 10.4
33
Day 1, 18:00:00 Day 1, 19:00:00 10.4
Day 1, 19:00:00 Day 1, 20:00:00 12.9
Day 1, 20:00:00 Day 1, 21:00:00 12.9

Day 1, 21:00:00 Day 1, 22:00:00 12.9
Day 1, 22:00:00 Day 1, 23:00:00 9.9
Day 1, 23:00:00 Day 2, 00:00:00 9.9
Cabe señalar que las camas de Fast Track están abiertas sólo durante el período de 11:00 a
23:00 al día. Por lo tanto se debe crear una tabla de Schedule (Horario) con esta información, de la
siguiente manera:
• En la vista Data, crear un Horario nuevo llamado “HorarioFastTrack”.

• Marcar las casillas desde las 11:00 hasta las 23:00. Hacer clic con el botón derecho del
mouse y agregar un nuevo ciclo. Marcar como “On Shift”.
• Copiar el ciclo para todos los días de la semana.
• La tabla debe verse como la Fig. N° 4.4.
Fig. N° 4.4 Tabla de Horario de Camas Fast Track

34
4.3.2 Creación de Entidades
Para crear distintos tipos de pacientes, se debe desarrollar un proceso para crear entidades
según las llegadas ingresadas en la tabla (Fig. N° 4.5). Esto se realiza de la siguiente manera:
• En la vista Procesos se crea un proceso para crear entidades llamado “CrearPacientes”.

• Agregar paso SetTable con los siguientes parámetros:
o Table Name: DatosPacientes
o Row Number: DatosPacientes.Llegadas.RandomRow
o Object Type: Token
El proceso anterior creará distintos tipos de pacientes tales como adultos, pediátricos, etc. Sin
embargo, todos tendrán la gravedad por defecto, es decir 0 correspondiente a no urgente. Para
asignar la gravedad correcta se debe crear otro proceso.
• Crear proceso para asignar gravedades llamado “AsignarGravedad”.

• Agregar paso Decide basado en probabilidad. La expresión será leída de la tabla de datos y
corresponde al porcentaje de llegadas de pacientes no urgentes y es
‘(DatosPacientes.PorcentajeNoUrgente)/100’.
• El porcentaje de llegadas si irá por la salida True. Ahí se debe agregar un paso Assign, donde
asignaremos el valor 1 a la variable de estado Paciente.Gravedad.
• Por la salida False del paso Decide irá el porcentaje de pacientes urgentes y emergentes. Por
lo tanto el porcentaje de pacientes urgentes está dado por
% Urgentes
% Urgentes + % Emergentes
Se debe agregar entonces otro paso Decide basado en probabilidad con la expresión
‘DatosPacientes.PorcentajeUrgentes/(DatosPacientes.PorcentajeUrgentes+DatosPacientes.Po
rcentajeEmergentes)’.
• En la salida True del segundo Decide se agrega un paso Assign con el valor 2 a la variable de
estado Paciente.Gravedad.
35
• Por la salida False irá el resto del porcentaje correspondiente a los pacientes emergentes. Se
agrega entonces un paso Assign para asignar el valor 3 a la variable Paciente.Gravedad y
otro paso Assign para asignarle un valor 2 a la variable Paciente.Priority. En este modelo los
pacientes con gravedad 1 y 2 tendrán prioridad 0, mientras que los pacientes emergentes
tendrán prioridad 2.
Fig. N° 4.5 Proceso para Asignación de Gravedad de Pacientes

En el modelo se debe agregar una Fuente (Source) que cree las entidades. Las Propiedades de la
Fuente son las siguientes:
• Arrival Logic
o Entity Type: DatosPacientes.TipoDePaciente. Se lee de la tabla los distintos tipos
de entidades (pacientes).
o Arrival Mode: Time Varying Arrival Rate. El número de llegadas dependerá de la
hora del día. Esta información está definida en una Rate Table.
o Rate Table: TasaLlegada.
• Add-On Process
o Creating Entities: CrearPacientes. Proceso para crear distintos tipos de entidades
Paciente según tabla.
o Created Entity: AsignarGravedad. Proceso para asignar gravedades según tabla de
datos. También asigna prioridad a pacientes emergentes.
36
4.4. Construcción del modelo
4.4.1 General
1. Insertar en el modelo las entidades “Paciente”, una por cada tipo de paciente. En este caso se
tiene pacientes del tipo Adulto, Pediátrico, Fast Track y Trauma. Además, se decidió crear
aparte los pacientes que llegan en ambulancia, ya que tienen distintas secuencias y recursos
disponibles, por lo tanto se tiene 8 tipos de entidades del tipo Paciente.
2. Situar en el modelo los objetos:
o Source
o Triage
o Businesss Officer
o 50 camas. En este caso las camas se situaron de la siguiente forma:
1 – 24: Adultos
25 – 34: Pediátricos
35 – 44: Fast Track
45 – 50: Trauma
o 5 salas de espera, una por cada tipo de paciente que llega a pie, más otra para la
Businesss Office.
o Sink
3. Es recomendable crear una red de caminos para interconectar todas las camas con salas de
espera y salidas de pacientes. Esto se puede lograr insertando Nodos Básicos en las junturas
y uniéndolas mediante caminos. Por estos caminos constantemente tienen que circular
entidades y vehículos de transporte, por lo tanto no basta con que sean unidireccionales. Al
hacerlos bidireccionales se encontró problemas de tráfico, ya que muchas entidades y
vehículos quedaban atorados en nodos. Esto se resolvió utilizando 2 caminos
unidireccionales en cada tramo, uno en cada dirección. La red de caminos utilizada en este
trabajo se muestra en la Fig. N° 4.6.
37
Fig. N° 4.6 Red de Caminos en Sala de Emergencia

Después del Triage, los pacientes tienen dos posibles destinos. Se dirigirán directamente a
las camas si es que hay alguna disponible, o en caso contrario pasan a la sala de espera de la
Businesss Office. Una de las formas de implementar lo anterior en Simio es la siguiente:
1. En Definiciones del modelo, crear un Estado Discreto llamado “CamasAdultosOcupadas”.

2. Insertar un Nodo Básico unido a la salida del Triage por un camino. En las propiedades del
camino, cambiar el peso del camino por la expresión ‘Is. Adulto && (Paciente.Gravedad !=
3)’. Así nos aseguramos que sólo pacientes del tipo Adulto y con gravedad No Urgente y
Urgente irán hacia el Nodo Básico. Los adultos emergentes pasarán directamente a las
camas. Mediante otro camino.
3. En las propiedades del Nodo Básico, crear un Add-On Process Trigger en Entidades
Ingresadas llamado “SalidaTriageAdultos”.
4. En la vista Procesos, crear un proceso llamado “SalidaTriageAdultos” (Fig. N° 4.7).
38
Fig. N° 4.7 Proceso de Asignación de valor a Indicador de Camas Ocupadas

5. Agregar un paso Decide de condición con la expresión ‘Cama1.Capacity.Allocated == 1 &&

Cama2.Capacity.Allocated == 2 && … && Cama24.Capacity.Allocated ==1’. Esta
expresión es verdad cuando todas las camas de adultos (1 a 24) están siendo ocupadas.
6. En la salida True insertar un paso Assign, donde a la variable “CamasAdultosOcupadas” se
le asignará el valor 1.
7. En la salida False insertar un paso Assign, donde a la variable “CamasAdultosOcupadas” se
le asignará el valor 0.
8. La combinación de lo anterior hace que la variable “CamasAdultosOcupadas” esté seteada
en 1 cuando todas las camas de adultos estén procesando y en 0 cuando alguna esté
disponible.
9. Desde el nodo después del Triage situar 2 caminos, uno hacia la Sala de Espera de Adultos y
otra hacia la Sala de Espera de la Businesss Office. En el primero el peso deberá ser
‘CamasAdultosOcupadas==0’ y en el segundo será “CamasAdultosOcupadas”. Esta
lógica se puede emplementar como en la Fig. N° 4.8.
Fig. N° 4.8 Esquema de Ruteo de Pacientes desde Triage

39
10. De forma análoga se puede hacer algo similar para pacientes no emergentes del tipo
Pediátrico y Fast Track, donde cada uno tendrá su propia cola del tipo Sala de Espera. Los
pacientes Emergentes y de Trauma irán directamente a su Sala de Espera para luego ser
llevados a una cama.
Los pacientes en la Sala de Espera de la Business Office deberán esperar su turno para pasar
en forma individual a la oficina. Por lo tanto el servidor BusinessOfficer es un recurso que se debe
captar y luego libertar. Una forma de implementarlo es la siguiente:
1. En Definiciones, Listas, crear una nueva lista de Nodos llamada “BusinessOfficeNodo” que
estará compuesto sólo por el nodo “Input@BusinessOfficer1”.
2. En el nodo de salida de la Sala de Espera de la Business Office cambiar las siguientes
propiedades en Routing Logic:
o Entity Destination Type: Select From List
o Node List Name: BusinessOfficeNodos
o Blocked Routing Rule: Select Available Only
Desde el nodo de salida del Business Officer se conecta un camino hacia la sala de espera de
adultos, ingresando como peso la expresión ‘Is.Adulto’. De forma similar se conectan los caminos
para salas de espera de Pediátricos y de Fast Track.
Hacia Sala de Hacia Sala de

Desde Sala de Espera Fast Track Hacia Sala de
Espera Pediátricos
Espera BO Espera Adultos
Fig. N° 4.9 Ruteo de Pacientes desde Business Office

40
Se debe definir los grupos de camas disponibles para distintos tipos de pacientes. Éstos
tienen distintas camas a su disposición dependiendo de su gravedad o si se movilizan en ambulancia.
Para esto, en Definiciones, Listas, se deben crear las listas de nodos mostradas en la Tabla N° 4.4.
Tabla N° 4.4 Grupos de Camas expresadas como Listas de Nodos

Nombre de la lista Nodos Nº total de camas
CamasAdultos Input@Cama1 – Input@Cama24 24
CamasPediatricos Input@Cama25 – Input@Cama34 10
CamasFastTrack Input@Cama35 – Input@Cama44 10
CamasTrauma Input@Cama45 – Input@Cama50 6
CamasAdultosEmergentes Input@Cama1 – Input@Cama24, 25
Input@Cama50
CamasPediatricosEmergentes Input@Cama25 – Input@Cama34, 11
Input@Cama50
CamasFastTrackEmergentes Input@Cama35 – Input@Cama44, 11
Input@Cama50
CamasAdultosAmbulancia Input@Cama1 – Input@Cama24, 27
Input@Cama43, Input@Cama44,
Input@Cama49
CamasPediatricosAmbulancia Input@Cama25 – Input@Cama34, 13
Input@Cama43, Input@Cama44,
Input@Cama49
CamasFastTrackAmbulancia Input@Cama35 – Input@Cama44, 11
Input@Cama49
CamasTraumaAmbulancia Input@Cama45 – Input@Cama50, 8
Input@Cama43, Input@Cama44
Cabe señalar que para los pacientes en ambulancia, es recomendable agregar como último
nodo la entrada a su respectiva sala de espera, para redirigirlos en caso de que exista ninguna otra
cama disponible.
Es posible asignarle un destino a las entidades cambiando las propiedades del nodo de
transferencia de salida de las salas de espera. Por ejemplo, para que los pacientes adultos se dirijan
hacia el grupo de camas de adultos se debe cambiar lo siguiente en Routing Logic:
• Entity Destination Type: Select From List
• Node List Name: CamasAdultos
• Blocked Routing Rule: Select Available Only
41
De esta forma la entidad seleccionará su destino desde la lista CamasAdultos, sólo si hay
alguno disponible. En caso de que no lo haya, la entidad quedará bloqueada esperando
disponibilidad.
Si se desea que pacientes de distinta gravedad se dirijan hacia distintos grupos de camas
desde una misma sala de espera, existe la opción de separar las entidades en pacientes emergentes y
no emergentes a la salida de la sala de espera, como se muestra en la Fig. N° 4.10.
Hacia camas de Hacia camas

Adulto Emergente de Adulto
Paciente es Adulto Paciente es Adulto

Emergente No Emergente
Salida de
Sala de Espera
Fig. N° 4.10 Esquema de Ruteo de Pacientes desde Sala de Espera

Los caminos que conectan la salida de la sala de espera con los nodos de transferencia tienen
pesos ‘Paciente.Gravedad==3’ para emergentes y ‘Paciente.Gravedad!=3’ para no emergentes. En
los nodos de transferencia se puede cambiar las propiedades para que las entidades sean dirigidas a
sus respectivos grupos de camas. Esta lógica se puede utilizar para demás salas de espera.
Además, según lo ingresado en las propiedades del objeto personalizado Paramédico (punto
4.2.6), los transportes le darán prioridad a pacientes emergentes y los llevarán para ser atendidos
antes que a otra gravedad.
42
4.4.2 Horarios de Atención de Pacientes Fast-Track
En el caso de los pacientes Fast Track, se debe poner especial atención con el hecho que las
camas están disponibles sólo desde 11:00 a 23:00 hrs. Para lograr esto, se debe modificar las
siguientes propiedades de cada cama de Fast Track, en Lógica de Proceso:
• Capacity Type: WorkSchedule
• Work Schedule: HorarioFastTrack
Con esto, la capacidad de las camas cambiará de 1 a 0, dependiendo de la hora y según lo

ingresado en la tabla de Schedule llamada “HorarioFastTrack” (punto 4.3.1).
Si el destino de la sala de espera de Fast Track son sólo las camas de Fast Track, los
pacientes que ingresen fuera del horario quedarán atascados, ya que las camas de destino tendrán
capacidad 0. Existe entonces la opción de agregar un tercer nodo de transferencia a la salida, que
envíe a los pacientes Fast Track a camas normales, en caso que las camas de Fast Track no estén
disponibles. Se puede disponer nodos a la salida, efectuando un procedimiento similar al anterior,
como lo muestra la Fig. N° 4.11.
Hacia camas Hacia camas

Hacia camas
Fast Track Fast Track no
de adultos
emergentes emergentes
(1) Camas Fast Track no

disponibles
(2) Camas Fast Track disponibles y

paciente no emergente
(1) (2) (3)
(3) Camas Fast Track disponibles
y paciente emergente
Salida de
Sala de Espera
de Fast Track
Fig. N° 4.11 Esquema de Ruteo de Pacientes Fast Track desde Sala de Espera
43
En la figura anterior, los pesos en los caminos deben ser las siguientes expresiones:
(1) Cama35.Capacity == 0. Las camas de Fast Track están deshabilitadas.
(2) Cama35.Capacity && Paciente.Gravedad == 3. Las camas de Fast Track están
habilitadas y el paciente es emergente.
(3) Cama35.Capacity && Paciente.Gravedad != 3. Las camas de Fast Track están
habilitadas y el paciente es no emergente.
Cabe señalar que para saber la capacidad de las camas de Fast Track es suficiente con
preguntar la capacidad de sólo una de ellas, ya que todas tienen el mismo horario.
4.4.3 Pacientes que se van sin Tratamiento (LWT)
Se desea modelar pacientes que, debido a las grandes esperas, se vayan de la sala de
emergencias sin recibir atención. En el modelo de simulación se asumirá que el 30% de los
pacientes que esperan por más de 2,5 horas, se van sin tratamiento. La simulación revisará cada 1
hora si los pacientes llevan esperando más de 2,5 horas en las colas del Triage y de las Salas de
Espera de Adultos, Fast Track y Trauma. Un 30% de esas entidades serán destruidas y
contabilizadas, mientras que el resto seguirá esperando por al menos una hora más [1].
Al momento de realizar este modelo, el software no permite retirar entidades directamente de

una cola de un Servidor. Por esta razón se cambió la capacidad del buffer de entrada a 0 para luego
poder insertar las entidades a un nuevo buffer, donde éstas pueden ser buscadas y retiradas.
Para mover las entidades del buffer de entrada del Triage a otro provisorio, se debe realizar
lo siguiente:
1. La entidad Paciente ya tiene agregado un estado discreto llamado “TiempoEnCola” en la

ventana Definiciones, Estados. Éste llevará un seguimiento del tiempo en el que cada
paciente entra a la sala de Triage. Con la variable creada, luego se le podrá asignar un valor.
2. En Definiciones, Elementos, hacer clic en Storage para crear un nuevo Almacenamiento y
nombrarlo “Almacenamiento”.
44
3. En el nodo de entrada del servidor (Triage) agregar un Add-On Process Trigger haciendo
doble clic en “Entered”. Se creará automáticamente un proceso llamado
“Input_Triage1_Entered”. Este proceso será llamado cada vez que una entidad entre al
nodo.
4. En la ventana de Procesos, en el proceso recién creado, agregar un paso Assign, donde se le
asignará a la variable Paciente.TiempoEnCola el valor ‘TimeNow’ (tiempo actual de
simulación). Con esto, cada entidad tendrá registrado en el estado TiempoEnCola, el valor de
la hora cuando ingresó al Triage.
5. En el mismo proceso agregar un paso Insert, donde el Nombre del Queue State será
‘Almacenamiento.Queue’ (Fig. N° 4.12). Este paso insertará las entidades que entren al
Triage en la cola de almacenamiento llamada “Almacenamiento”.
Fig. N° 4.12 Proceso de Inserción de Entidades en Cola de Almacenamiento

6. De vuelta en la ventana Facility, agregar otro Add-On Process Trigger al nodo de entrada del
Triage, haciendo doble clic en “Exited”. Se creará automáticamente un proceso llamado
“Input_Triage1_Exited”. Este proceso será llamado cada vez que una entidad salga del
nodo.
7. En la ventana de Procesos, en el nuevo proceso, agregar un paso Remove para quitar
entidades desde la ‘Almacenamiento.Queue’ (Fig. N° 4.13).
Fig. N° 4.13 Proceso de Remoción de Entidades en Cola de Almacenamiento

45
8. Los dos procesos Input_Triage1_Entered y Input_Triage1_Exited utilizan una cola de

almacenamiento para que la entidad espere al servidor. Esta cola puede ser animada al
agregar una Detached Queue con el nombre ‘Almacenamiento.Queue’, desde la pestaña
Animation en la ventana Facility. Esta cola reemplazará a la cola de entrada del Triage.
En esta nueva cola de almacenamiento las entidades están esperando y se puede ahora buscar
las que estén mucho tiempo. Para realizarlo en el modelo se debe hacer lo siguiente:
9. En la ventana Facility, insertar un objeto Source y conectarlo con un Sink. El tiempo de

llegadas de las entidades debe estar basado en cuan seguido se desea buscar entidades
esperando mucho tiempo en las colas. En este caso será cada 1 hora.
10. En el nodo de transferencia del objeto Source recién insertado, agregar un Add-On Process
Trigger llamado “LWTTriage” en “Entered”.
11. Definir “Indice” como un estado discreto del modelo en la ventana Definiciones, panel de
Estados.
12. En el proceso recién creado, agregar un paso Search y cambiar las siguientes propiedades:
• Basic Logic
o Collection Type: QueueState. Se busca en una cola.
o Queue State Name: Almacenamiento.Queue. Nombre de la cola donde se busca.
o Match Condition: (TimeNow-Candidate.Paciente.TiempoEnCola) > 2.5. Se
busca entidades del tipo Paciente que lleven en cola más de 2.5 horas. Este
número se puede cambiar según se desee.
• Advanced Options
o Save Index Found: Indice
13. En la salida Found del paso Search, agregar un paso Decide, basado en una probabilidad de
0.3.
14. En la salida True del paso Decide, insertar un paso Remove para quitar el 30% de las
entidades que cumplan con las condiciones de la búsqueda. Cambiar las siguientes
propiedades:
• Basic Logic
46
o Queue State Name: Almacenamiento.Queue. Nombre de la cola de donde se

retira.
• Advanced Options
o Removal Type: AtRankIndex
o Rank Index: Indice
15. Reconectar la salida Original del paso Remove hacia la entrada del paso Search, para seguir
buscando en la cola entidades que esperen mucho tiempo.
16. En Definiciones, Elementos, agregar una Tally Statistic llamada “LWT”.
17. A la salida del paso Remove, insertar un paso Tally para registrar la duración del tiempo que
la entidad esperó antes de ser retirada. El nombre de la TallyStatistic es ‘LWT’ y el valor es
‘TimeNow - Paciente.TiempoEnCola’.
18. A continuación del paso Tally, agregar un paso Destroy, para destruir la entidad y su Token.
El proceso LWTTriage debería verse como el de la Fig. N° 4.14.
Fig. N° 4.14 Proceso de Pacientes que se van sin tratamiento (LWT) en Triage
Este procedimiento puede efectuarse de forma análoga para las salas de espera. Los buffers
de entrada también deben ser deshabilitados y reemplazados por colas de almacenamiento, pero esta
vez no se debe escribir un nuevo valor en la variable Paciente.TiempoEnCola ya que el tiempo de
entrada en el sistema es uno sólo y es al entrar al Triage. Se deben crear nuevas colas de
Almacenamiento, una para cada sala de espera.
47
Se puede agregar nodos básicos a continuación del objeto Source que revisa cada 1 hora y
agregarles Add-On Process Triggers para que gatillen los procesos de LWT para cada sala de
espera, como lo muestra la Fig. N° 4.15.
LWT
Sala de
LWT Triage Espera
Fast Track
LWT LWT
Sala de Sala de
Espera Espera
Adultos Trauma
Fig. N° 4.15 Nodos para Gatillar Procesos de LWT

En todos los procesos que revisen a los pacientes sin tratamiento en las salas de espera, es
necesario que guarden las estadísticas en el mismo Tally Statistic llamado “LWT”. El número de
pacientes que se van se agregará a esa lista.
Para tener un indicador en el modelo del número de pacientes que se van sin tratamiento, se
puede agregar en la ventana Facility, pestaña Animation, una Etiqueta de Estado con la expresión
‘LWT.NumberObservations’. También se puede agregar una etiqueta para que el indicador se vea
como la Fig. N° 4.16.
Fig. N° 4.16 Indicador se Pacientes que se van sin Tratamiento

4.4.4 Agravamiento de Pacientes en Espera
Se desea modelar que pacientes de gravedad urgente puedan empeorar su salud debido a largas
esperas. Se utiliza un procedimiento similar al de modelar pacientes que se van sin tratamiento. La
48
simulación asumirá que un 10% de los pacientes clasificados como Urgentes empeorará su
condición a Emergente si es que llevan más de 2,5 horas esperando en Triage o en las Salas de
Espera. Para agravar pacientes en Triage se hace lo siguiente:
1. En la ventana Facility, es posible utilizar el mismo objeto Source agregado anteriormente

para pacientes que se van sin tratamiento (Fig. N° 4.15) para que la simulación busque
entidades cada 1 hora. Si se desea buscar en una tiempo distinto, se puede agregar otro
Source con distinto tiempo de llegadas.
2. Insertar un nuevo Nodo Básico y agregar un Add-On Process Trigger llamado
“MasGravedadTriage” en “Entered”.
3. En el proceso recién creado, agregar un paso Search y cambiar las siguientes propiedades en
Basic Logic:
• Collection Type: QueueState
• Queue State Name: Almacenamiento.Queue
• Match Condition: (TimeNow-Candidate.Paciente.TiempoEnCola) > 2.5
4. En la salida Found del paso Search, agregar un paso Decide, basado en condición con la
expresión ‘Paciente.Gravedad == 2’.
5. En la salida True, agregar otro paso Decide, basado en una probabilidad de 0.1.
6. En la salida True, insertar un paso Assign para darle a la variable de estado
‘Paciente.Gravedad’ un valor de 3. Agregar otra asignación para darle a la variable
‘Paciente.Priority’ un valor de 2.
El proceso MasGravedadTriage debería verse como el de la Fig. N° 4.17.
Fig. N° 4.17 Proceso para Agravamiento de Pacientes

49
Se puede realizar lo anterior de forma análoga para las demás salas de espera.
4.4.5 Transportes
Se desea que paramédicos transporten a los pacientes desde las salas de espera hacia las camas y
luego hacia fuera de la sala de emergencias. En este caso habrá 4 paramédicos permanentemente de
turno.
1. En la ventana Facility, insertar en el modelo 4 entidades Paramédico.

2. En Definiciones, Listas, crear una lista de Transportes llamada “Paramedicos” compuesta
por las 4 entidades Paramédico recién añadidas.
3. En cada Nodo de Transferencia donde se necesite que las entidades sean recogidas, se debe
agregar lo siguiente en las propiedades de Lógica de Transporte:
• Ride on Transporter: True
• Transporter Type: From List
• Transporter List Name: Paramedicos
Estas propiedades se deben modificar en todos los nodos a la salida de salas de espera, camas
y nodos a la llegada de ambulancias.
4. Se debe elegir un lugar donde los paramédicos iniciarán su recorrido y donde estarán en caso
de inactividad. En este lugar se coloca un Nodo Básico y se conecta con la red existente. El
nombre del Nodo Básico debe coincidir con el Nodo Inicial que se ingresó en las
definiciones, al momento de crear la entidad Paramédico, por ejemplo, “BasicNode52”
(punto 4.2.6).
5. Al crear la entidad Paramedico, se configuró que su acción al estar inactivo sería
estacionarse en casa (Park at Home), por lo que se debe crear una cola para que los
transportes se estacionen. En la vista Facility, pestaña Animation, hacer clic en Detached
Queue y se dibuja una cola cerca del nodo inicial. En las propiedades de la cola, cambiar el
estado a BasicNodeXX.ParkingStation.InProgress, donde “XX” es el número del nodo
inicial.
50
4.5. Comentarios
Del modelo realizado se observa que su confección requirió una demanda de tiempo
considerable y presentó una complejidad relativamente alta para el desarrollo de lógicas complejas,
sin embargo este trabajo servirá como base para ser adaptado a otros sistemas de salud, donde se
espera que la reutilización de los objetos definidos y sus propiedades signifique una modelación
simple con una disminución importante del tiempo de desarrollo.
51
Capítulo 5. Modelamiento en Simio v/s Modelamiento en

Flexsim HC
5.1. Introducción
En este capítulo se establecen las diferencias encontradas entre realizar un modelo en el
software Simio y en Flexsim HC. Este último es un simulador orientado a objeto, especialmente
creado para representar casos de sistemas de salud. Se compara el desarrollo de modelos en ambos
software tomando en cuenta aspectos como el ingreso de las secuencias de los pacientes en la
instalación, lógica, rendimiento de los programas a la hora de correr los modelos, concordancia de
datos obtenidos, entre otros.
5.2. Secuencias
En Simio existen diversas maneras de definir las secuencias de las entidades. Una de ellas es
predefinirlas mediante una tabla de secuencias, donde se especifica cada uno de los nodos por los
cuales la entidad debe pasar (Fig. N° 5.1 (a)). Para esto, cada tipo de entidad debe tener una
secuencia asociada para que ésta siempre sea la ingresada en tabla, lo que se realiza modificando sus
propiedades (Fig. N° 5.1 (b)). Luego, cada nodo también debe tener ingresado en sus propiedades
que sigan una secuencia. Dada la complejidad y las características del modelo realizado en este
trabajo, se decidió que esta metodología no era la más adecuada, debido a que las tablas de
secuencias se utilizan usualmente para secuencias fijas, mientras que en muchos casos se necesitaba
discriminar entre distintos posibles destinos y muchos nodos eran recorridos por distintos tipos de
entidades.
52
(a)
(b)
Fig. N° 5.1 Ingreso de Secuencias - Simio

(a) Tabla de Secuencias, (b) Propiedades de Entidad
Otra alternativa para establecer secuencias es utilizar los nodos de transferencia, donde se
puede definir para cualquier entidad un próximo destino, ya sea fijo o de una lista de nodos (Fig. N°
5.2), tal como se hizo en el punto 4.4.1.
Fig. N° 5.2 Propiedades de Nodo de Transferencia para Secuencias – Simio

Simio también ofrece la opción de definir rutas mediante la apertura y cierre de caminos. Los
caminos (paths) tienen un peso que por defecto es 1, pero que puede ser modificado por otro valor o
incluso una expresión que representan la probabilidad de que una entidad pase por ese camino. Estas
expresiones también pueden ser del tipo booleanas, es decir que son verdaderas o falsas y que
retornarán un valor de 1 ó 0. De esta manera, cuando el peso del camino resulta ser 0, éste quedará
53
bloqueado. En la Fig. N° 5.3 se ingresó una expresión que abrirá o cerrará el paso, dependiendo de
existen camas disponibles o no. Este procedimiento se utilizó muchas veces en este trabajo y un
ejemplo se explica en el punto 4.4.1, Fig. N° 4.8.
Fig. N° 5.3 Propiedades de Caminos para Secuencias – Simio

En Flexsim HC la gran parte de la definición de secuencias se encuentra en los Tracks. En

éstos se definen todas las actividades que el paciente efectuará en el sistema, incluidos sus
movimientos. En la Fig. N° 5.4 se observa que la primera actividad, llamada ‘10_mov_a_triage’ es
del tipo “Paciente Viaja Desatendido”, es decir el primer movimiento del paciente está definido
como ir por sí solo desde la entrada hacia el área de Triage. Aquí también se define la próxima área
del paciente, la que en este caso está ingresada como una función avanzada.
54
Fig. N° 5.4 Ingreso de Secuencias en Tracks - Flexsim HC

En Flexim HC la ruta del paciente va predestinada desde su creación, según los movimientos
ingresados en los Tracks. Si en algún momento fuera necesario añadir una lógica más compleja a los
movimientos del paciente, Flexsim HC permite modificar una función avanzada que bajo una cierta
condición o probabilidad, elija una próxima actividad, lleve al paciente a otra área, cambie su
estado, etc (Fig. N° 5.5). Esta función avanzada se especifica ingresando parámetros a opciones
dadas por el software o programando código en lenguaje C++ para lógica más compleja.
55
Fig. N° 5.5 Funciones Avanzadas en Secuencias - Flexsim HC

5.3. Lógica de modelamiento
En Simio, a diferencia de otros lenguajes de simulación, se hace una diferencia notoria entre
el modelo físico y el modelo lógico. En la vista Facility, el modelo se construye tomando en cuenta
la disposición física de los elementos que constituyen el sistema, los que se enlazan para que las
entidades fluyan en él, como lo harían en una instalación en la realidad. Las entidades pueden tener
su propio comportamiento inteligente, ya que tienen la posibilidad de tomar decisiones, rechazar
peticiones, descansar, etc. Pueden ser creados y destruidos dinámicamente, moverse en una red de
enlaces y nodos, moverse en el espacio 3D, entrar y salir de objetos fijos. Algunos ejemplos de
entidades pueden ser pacientes, vehículos, clientes, piezas de trabajo, etc [4]. Un ejemplo de
entidades moviéndose en un modelo de Simio se observa en la Fig. N° 5.6.
56
Fig. N° 5.6 Ejemplo de Entidades Fluyendo en el Modelo Físico – Simio

En Simio la programación requerida por el usuario es reducida ya que la lógica se programa

en la vista Procesos a través de los bloques de un proceso, ingresando parámetros en las propiedades
de los pasos. El movimiento de una entidad hacia o fuera de un objeto puede detonar un Trigger
(gatillo) que llama a un proceso y lo ejecuta. Un proceso está compuesto por bloques que son
recorridos, no por entidades, sino por un concepto introducido por Simio como “Token”. En Simio,
un Token es una unidad que está asociada a una entidad y que reside dentro de un proceso. Es
creado al principio de éste, fluye por los bloques ejecutando pasos y finalmente es destruido. Los
pasos que ejecutan efectúan acciones, tales como asignar un nuevo valor a una variable, decidir
entre alternativas, esperar a que ocurra un evento, destruir entidades, retener un token por un cierto
tiempo, ejecutar otros procesos, entre otros. Un proceso en Simio se ilustra en la Fig. N° 5.7.
Fig. N° 5.7 Ejemplo de Proceso – Simio

En Flexsim HC, la disposición del modelo se hace ingresando objetos desde una biblioteca,
donde existen salas de espera, camas, personal, entradas, salidas, etc (Fig. N° 5.8). Para modelar los
pacientes, se puede crear un patrón que describa el comportamiento de un grupo de pacientes a
través de todo el sistema. Estos patrones se llaman “Tracks” y es un menú donde se ingresa la
información de todos los movimientos y actividades que el paciente realiza dentro del sistema. En
éstos se crea una lista de la secuencia del paciente y se definen los tiempos de proceso asociados a
cada actividad.
57
Fig. N° 5.8 Disposición del Modelo - Flexsim HC

Por ejemplo, la Fig. N° 5.9 muestra la actividad de atención al paciente llamada

“70_doc_check1”. Ésta ha sido definida como del tipo proceso, su predecesora es la toma de datos
de la enfermera, su tiempo de proceso está asociado a una distribución Weibull, se realiza en la
ubicación actual del paciente y el personal que lo realizará será el grupo de médicos
“PhysicianGroup1”.
58
Fig. N° 5.9 Ingreso de Parámetros en Tracks - Flexsim HC

5.4. Herramientas adicionales
5.4.1 Experimentos
Simio ofrece una herramienta para realizar experimentos llamada Experimenter (Fig. N°
5.10). En este modo la animación del modelo no es lo prioritario, ya que se replican distintos
escenarios para obtener información sobre la variabilidad en el sistema y llegar a conclusiones
válidas estadísticamente desde el modelo. Se debe definir una o más propiedades que se puedan
cambiar para ver el impacto en el desempeño del sistema. Estas propiedades pueden utilizarse para
variar parámetros como la velocidad de las cintas transportadoras, el número de operadores
disponibles o el criterio de decisión para la selección del próximo cliente en el proceso, los que son
referenciadas por uno o más objetos en el modelo. Se pueden crear varios experimentos por modelo,
por ejemplo uno para tiempos de proceso y otro para evaluar tamaños de colas o niveles de dotación
de personal. Simio aprovecha la cantidad de núcleos del computador para correr múltiples réplicas a
la vez, por ejemplo, un computador con un procesador de dos núcleos podrá correr dos réplicas a la
vez. Las últimas versiones de Simio ofrecen añadir una o más Respuestas o Restricciones al
59
experimento. Una Respuesta puede ser cualquier expresión válida y es típicamente un indicador de
desempeño clave que es de particular interés en los escenarios de comparación y que se desplegarán
directamente en la tabla de experimentos y en el cuadro de respuestas. Una restricción es una
expresión que debe satisfacerse para que el escenario sea válido. En Simio existen dos maneras para
visualizar los resultados del experimento. La primera es la Tabla Pivote (Pivot Table), la que está
diseñada para que el analizador pueda arreglar o clasificar la información desde distintas
perspectivas al arrastrar las columnas de la tabla. La otra manera de visualizar los resultados es
mediante un Informe (Report) tradicional, que muestra para cada parámetro de interés los resultados
de los distintos escenarios que se definieron.
Fig. N° 5.10 Experimenter – Simio

Flexsim HC también ofrece la herramienta de un gestor de experimentos, la cual no difiere

en grandes aspectos de Simio. Es posible definir distintos números de variables, escenarios y
réplicas, como se muestra en la Fig. N° 5.11.
60
Fig. N° 5.11 Experiment Manager - Flexsim HC

La pestaña de medidas de desempeño ofrece especificar las medidas de salida a evaluar para
cada escenario. Al final de cada réplica las funciones de medida de desempeño son ejecutadas y
registradas, y una vez terminado el experimento se pueden visualizar los resultados de éstas en una
ventana como la de la Fig. N° 5.12 o en forma de tablas e informes. Además es posible ingresar
funciones avanzadas para ejecutar alguna acción al momento de comenzar o finalizar experimentos,
réplicas o escenarios.
61
Fig. N° 5.12 Visualización de Medidas de Desempeño - Flexsim HC

5.4.2 Analizadores de Datos de Entrada y Salida
Al momento de realizar este trabajo, Simio (versión 3.43) no ofrece un sistema integrado
para ajuste de distribuciones estadísticas o análisis de datos de salida. Sin embargo recomiendan el
uso de softwares tales como Stat::Fit, ExpertFit o StartTools para luego ingresar datos a Simio como
distribuciones o tablas. Simio incluye herramientas de análisis de salida como las tablas pivote o
cuadros SMORE para asistencia en comparación de datos de respuesta. Los cuadros SMORE
(Medición de Riesgo y Error de Simio) es una herramienta gráfica que ayuda a analizar y comparar
escenarios al desplegar los valores esperados y sus múltiples niveles de variabilidad asociados, en
forma de una carta que muestra valores máximos, mínimos, percentiles, intervalos de confianza,
media, etc (Fig. N° 5.13).
62
Fig. N° 5.13 Cuadros SMORE – Simio

Fuente: Ayuda Simio.
Para un análisis adicional en Simio, es posible exportar datos de salida a otros programas. El
formato de datos de salida es de valores separados por coma (CSV) y es compatible con la mayoría
de programas de análisis de datos, incluyendo Microsoft Excel. Para obtener estos archivos, es
necesario crear una rutina dentro del modelo, definiendo elementos, agregando procesos con pasos,
etc, tal como en el ejemplo SimBit “WritingToAFile”. En el caso de la ejecución de un experimento,
se crearán distintos archivos, uno por cada réplica realizada. No es posible ingresar todos los datos
en un solo archivo de forma automática, debido a que Simio corre más de una réplica a la vez, una
por cada procesador que el computador tiene, lo que significaría tratar de escribir en el mismo
archivo al mismo tiempo.
Flexsim HC, por su parte posee integrada la herramienta ExpertFit, con la cual es posible
hacer ajuste de curvas, comparaciones gráficas, tests de bondad de ajuste, evaluación de modelos,
etc, además de permitir la importación y exportación de datos en formato hoja de datos de Excel
(archivos .xls).
63
5.4.3 Otras herramientas
Adicionalmente a sus productos estándar, Simio ofrece una herramienta de optimización en

simulación llamada OptQuest, que mejora las capacidades analíticas de Simio al buscar de forma
automática los controles de entrada para maximizar o minimizar algún objetivo.
5.5. Rendimiento
Para analizar el rendimiento de ambos software de simulación, se creó un modelo simple de
atención médica, consistente en pacientes adultos y niños que ingresan con distinta severidad a una
sala de triage, luego a sus respectivas salas de espera para ser atendidos en camas y finalmente ser
despachados. El diagrama de este ejemplo se observa en la Fig. N° 5.14.
Sala de Espera Camas

Adultos Adultos (4)
Triage
Llegada Salida
Sala de Espera Camas

Adultos 70%
Niños Niños (2)
Niños 30%
Emergentes 10%
Urgentes 30%
No Urgentes 60%
Fig. N° 5.14 Diagrama de Sistema de Sala de Emergencias Simplificado

Este modelo se corrió en Simio y en Flexsim HC en 10 réplicas de 5.000 horas cada una, con
el objeto de concluir sobre el rendimiento de los softwares en un mismo computador. Cabe señalar
que se utilizó una tasa de llegada de un paciente cada 10 min, con los tiempos de procesos y de
llegadas similares al modelo realizado anteriormente.
Los resultados de rendimiento son los que se observan en la Tabla N° 5.1:

64
Tabla N° 5.1 Rendimiento en Computador de Simio y Flexsim HC

Llegadas de Pacientes cada 10 min
Software de Tiempo promedio real Tiempo real
Simulación por cada réplica total de ejecución
Simio 0:02:53 hrs 0:07:22 hrs
Flexsim HC 0:08:15 hrs 1:22:30 hrs
Se observa que el tiempo total de ejecución en Flexsim HC fue 11,19 veces mayor que el de
Simio. Flexsim HC tardó 08:15 min en promedio en cada réplica y las fue realizando en serie, es
decir una después de la otra. Simio, por otra parte, aprovecha el número de núcleos del ordenador
para ejecutar más de una réplica a la vez. En este caso todas las simulaciones se realizaron en un
computador con procesador Intel Core I3, donde Simio ejecutó 4 réplicas al mismo tiempo, lo que
redujo considerablemente el tiempo total. Por esta razón el tiempo total de ejecución en Simio no
coincide con la suma de cada réplica por separado.
Un aspecto que influyó de manera considerable los tiempos de ejecución de los programas
fue la cantidad de pacientes por hora que llegaban a la sala. Para este caso se simuló con una tasa de
llegada exponencial de un paciente cada 10 min. Sin embargo, si este valor se reduce a un paciente
cada 15 min, los resultados de los tiempos de ejecución son los mostrados en la Tabla N° 5.2.
Tabla N° 5.2 Rendimiento en Computador de Simio y Flexsim HC

Llegadas de Pacientes cada 15 min
Software de Tiempo promedio real Tiempo real
Simulación por cada réplica total de ejecución
Simio 0:01:02 hrs 0:02:46 hrs
Flexsim HC 0:04:30 hrs 0:43:00 hrs
Se observa que si se reduce las llegadas a un paciente cada 15 min, Simio tuvo mejor
desempeño aún, siendo en este caso 15,6 veces más rápido que Flexsim HC. Estas diferencias con el
ejemplo anterior se deben a que la cantidad de entidades existentes en el modelo durante la
simulación afectan de gran manera el tiempo de ejecución de los programas, especialmente en casos
65
de salud, donde los tiempos de proceso y de espera pueden ser relativamente altos y donde se
producen largas colas.
5.6. Concordancia de datos
5.6.1 Consideraciones
Se utilizó la misma comparación de los dos simuladores para el modelo simple de la Fig. N°
5.14 y se utilizó los datos de salida para verificar si concuerdan estadísticamente.
Se estudió si el tiempo de ciclo y el tiempo de espera del triage son equivalentes

estadísticamente cuando los datos son obtenidos desde Simio y desde Flexsim HC, para un tiempo
de simulación de 2 semanas (336 horas) y para un número de réplicas calculado para ambos casos,
según se indica más adelante en este capítulo.
El tiempo de ciclo corresponde al tiempo desde que el paciente ingresa al sistema, hasta que
es despachado. En Simio se registró como un estado discreto el tiempo de ingreso y el de salida de
cada paciente, y se calculó la diferencia de éstos. En Flexsim HC, por su parte, se utilizó la opción
de cálculo automático de tiempo promedio en sistema en las mediciones de desempeño de los
experimentos.
Para el tiempo de espera del Triage, en Simio se registró como un estado discreto el instante
cuando el paciente hace ingreso al nodo del Triage y el instante justo cuando comienza a ser
“procesado” (atendido) y se calculó la diferencia para cada paciente. Esta diferencia de tiempos
corresponde al período en que el paciente está esperando ser atendido. En Flexsim HC, en las
medidas de desempeño de los experimentos, se definió como medida el tiempo medio para la sala de
espera del Triage.
Para calcular el número de réplicas necesarias se utilizó la siguiente fórmula [7]:

S ∙ t ,/
=
k
66
donde
t: estadístico de la distribución t student.
k: desviación absoluta máxima permitida sobre la media de la distribución a
simular.
S2: estimador de la varianza de la distribución a simular.
Para el tiempo de ciclo se corrieron tres réplicas piloto de una duración de 2 semanas (336
horas) para determinar la varianza. Se obtuvieron los siguientes valores de varianza y número total
de muestras, respectivamente:
S21 = 190.990, 69 n1 = 639

S22 = 93.513,19 n2 = 624
S23 = 70.664,06 n3 = 650
Por lo tanto la varianza ponderada es:
n − 1 S + n − 1 S + n! − 1 S!

= = 117.509,8
n + n + n! − 3
Se escogen los siguientes valores:
t ,/ = 1,64 para un 90% de confianza

k = 90 min
Se tiene entonces
n = 39,02 ≈ 39 réplicas
67
De igual forma se realizaron los cálculos para los tiempos de espera del triage, corriendo tres
réplicas piloto de una duración de 2 semanas (336 horas) para determinar la varianza. Se obtuvieron
los siguientes valores de varianza y número total de muestras, respectivamente:
S21 = 0,47701 n1 = 658

S22 = 0,56747 n2 = 634
S23 = 0,54675 n3 = 671
Por lo tanto la varianza ponderada es:
n − 1 S + n − 1 S + n! − 1 S!

S = = 0,53
n + n + n! − 3
Se escogieron los siguientes valores:
t ,/ = 1,96 para un 95% de confianza

k = 0,2 min
Se tiene entonces
n = 50,91 ≈ 51 réplicas
68
5.6.2 Resultados de los experimentos
A. Tiempos de Ciclo
Los resultados de las simulaciones se observan en la Tabla N° 5.3.
Tabla N° 5.3 Tiempo Medio de Ciclo (min) por Réplica

Réplica Simio Flexsim HC
1 546.436543 881.83
2 367.720779 684.32
3 419.973239 427.63
4 604.215331 484.12
5 915.365814 590.41
6 764.313262 422.92
7 448.3019 750.83
8 489.933537 1161.73
9 785.708802 750.12
10 1142.952 1105.6
11 644.933433 702.8
12 495.146243 734
13 588.953549 436.69
14 544.547419 904.47
15 575.776105 834.63
16 995.252724 707.38
17 829.390907 836.65
18 586.995708 474.47
19 981.095562 330.91
20 397.218592 540.4
21 578.099029 908.67
22 821.971914 481.79
23 460.299766 493.67
24 516.33689 508.53
25 377.913325 931.34
26 868.548457 797.11
27 455.721158 423.83
28 521.059295 577.97
29 455.626276 740.65
30 751.145616 1190.85
31 670.7777 1061.25
32 395.020008 296.32
33 591.254823 1085.17
34 434.491706 690.22
35 474.04196 461.23
36 699.145285 477.55
37 951.356185 423.74
38 974.856138 587.01
39 336.750209 769.35
69
En la Tabla N° 5.4 se indican las estadísticas descriptivas:
Tabla N° 5.4 Estadísticas Descriptivas, Tiempos de Ciclo

(a) Simio, (b) Flexsim HC
Simio Flexsim HC
Media 627.1448 Media 683.798974

Error típico 33.5228962 Error típico 38.4110466
Mediana 578.099029 Mediana 690.22
Desviación estándar 209.35042 Desviación estándar 239.876909
Varianza de la muestra 43827.5983 Varianza de la muestra 57540.9316
Curtosis -0.44901272 Curtosis -0.64586225
Coeficiente de asimetría 0.72271172 Coeficiente de asimetría 0.47798337
Rango 806.201792 Rango 894.53
Mínimo 336.750209 Mínimo 296.32
Máximo 1142.952 Máximo 1190.85
Suma 24458.6472 Suma 26668.16
Cuenta 39 Cuenta 39
(a) (b)
En las Fig. N° 5.15 y Fig. N° 5.16 se observan los diagramas de dispersión para las réplicas
en Simio y en Flexsim HC, respectivamente.
70
Tiempo de Ciclo Promedio

SIMIO
1400
1200
1000
Minutos
800
600
400
200
0
0 5 10 15 20 25 30 35 40
Réplicas
Fig. N° 5.15 Gráfico Tiempo de Ciclo Promedio v/s Réplicas – Simio

Tiempo de Ciclo Promedio

FLEXSIM HC
1400
1200
1000
Minutos
800
600
400
200
0
0 5 10 15 20 25 30 35 40
Réplicas
Fig. N° 5.16 Gráfico Tiempo de Ciclo Promedio v/s Réplicas - Flexsim HC

71
Con el software Statgraphics se obtuvo el diagrama Box Plot de la Fig. N° 5.17, que muestra
una comparación de los resultados de ambos programas de simulación.
Box-and-Whisker Plot
FlexsimHC
Simio
0 200 400 600 800 1000 1200
Fig. N° 5.17 Gráfico de Cajas, Tiempos de Ciclo

Los gráficos de las Fig. N° 5.15, Fig. N° 5.16 y Fig. N° 5.17 muestran que no hay grandes
diferencias estadísticas entre los resultados de ambos programas de simulación.
Utilizando el mismo software estadístico se realizó una prueba de hipótesis para la

comparación de las medias, previa prueba para la igualdad de varianzas. Se obtuvieron los
siguientes resultados en el software Statgraphics [8]:
72
Comparison of Standard Deviations

---------------------------------
FlexsimHC Simio
------------------------------------------------------------
Standard deviation 239,877 209,35
Variance 57540,9 43827,6
Df 38 38
Ratio of Variances = 1,31289
95,0% Confidence Intervals

Standard deviation of FlexsimHC: [196,038;309,148]
Standard deviation of Simio: [171,091;269,806]
Ratio of Variances: [0,688458;2,50369]
F-tests to Compare Standard Deviations
Null hypothesis: sigma1 = sigma2
(1) Alt. hypothesis: sigma1 NE sigma2

F = 1,31289 P-value = 0,405238
(2) Alt. hypothesis: sigma1 > sigma2

F = 1,31289 P-value = 0,202619
(3) Alt. hypothesis: sigma1 < sigma2

F = 1,31289 P-value = 0,797381
Comparison of Means
-------------------
95,0% confidence interval for mean of FlexsimHC: 683,799 +/- 77,7593

95,0% confidence interval for mean of Simio: 627,145 +/- 67,8637
95,0% confidence intervals for the difference between the means:
assuming equal variances: 56,6542 +/- 101,54
not assuming equal variances: 56,6542 +/- 101,57
t tests to compare means
Null hypothesis: mean1 = mean2
(1) Alt. hypothesis: mean1 NE mean2

assuming equal variances: t = 1,11125 P-value = 0,269963
not assuming equal variances: t = 1,11125 P-value = 0,270027
(2) Alt. hypothesis: mean1 > mean2

(3) Alt. hypothesis: mean1 < mean2

73
Como las desviaciones estándar no difieren significativamente (valor-p = 0,405238 > 0,05),
se tiene que el intervalo de confianza del 95% para la diferencia de los valores promedio está dado
por
)*+,+- − )./012+,34 ± 6 = 56,6542 ± 101, 54,
donde d = 101, 54 (error de muestreo) [7].
El intervalo anterior contiene al 0, de donde se concluye que no existe diferencia

estadísticamente significativa entre los valores promedio entregados por ambos softwares de
simulación. Esto se puede afirmar con un 95% de confianza.
B. Tiempos de Espera en Triage

Los resultados de las simulaciones se observan en la Tabla N° 5.5.
Tabla N° 5.5 Tiempo Medio de Espera en Triage (min) por Réplica

Réplica Simio Flexsim HC Réplica Simio Flexsim HC
1 0.14265701 0.94 27 0.20028069 0.79
2 0.15735791 0.82 28 0.14145648 0.61
3 0.16957148 0.73 29 0.16686409 0.76
4 0.15409994 0.71 30 0.1295646 0.99
5 0.1533015 0.82 31 0.18533579 0.98
6 0.1826585 0.61 32 0.24041288 0.44
7 0.17118647 0.71 33 0.12529526 0.89
8 0.2079508 0.9 34 0.13616579 0.76
9 0.17241661 0.77 35 0.17806086 0.63
10 0.15596503 0.78 36 0.16758501 0.69
11 0.21645214 0.7 37 0.20027985 0.71
12 0.19190543 0.86 38 0.13920095 0.69
13 0.17185813 0.86 39 0.18822997 0.93
14 0.16389731 0.83 40 0.20973826 0.68
15 0.22615836 0.6 41 0.1056755 0.93
16 0.22274857 0.84 42 0.12044328 0.82
17 0.18102222 0.49 43 0.18670172 0.83
18 0.17892669 0.74 44 0.1906315 0.55
19 0.1388495 0.59 45 0.23226371 0.6
20 0.13302474 0.75 46 0.11914193 0.61
21 0.20059476 0.78 47 0.15807147 0.72
22 0.16423949 0.62 48 0.15232065 0.76
23 0.15940755 0.8 49 0.15250597 0.69
24 0.19343221 0.72 50 0.19790404 0.98
25 0.19421152 0.74 51 0.17396258 0.76
26 0.12409692 0.67

74
En la Tabla N° 5.6 se indican las estadísticas descriptivas:
Tabla N° 5.6 Estadísticas Descriptivas, Tiempos de Espera en Triage

(a) Simio, (b) Flexsim HC
Simio Flexsim HC
Media 0.17109968 Media 0.74862745

Error típico 0.00440751 Error típico 0.01736578
Mediana 0.17118647 Mediana 0.75
Desviación estándar 0.03147592 Desviación estándar 0.12401644
Varianza de la muestra 0.00099073 Varianza de la muestra 0.01538008
Curtosis -0.4857221 Curtosis -0.08919627
Coeficiente de asimetría 0.09884803 Coeficiente de asimetría -0.09372978
Rango 0.13473738 Rango 0.55
Mínimo 0.1056755 Mínimo 0.44
Máximo 0.24041288 Máximo 0.99
Suma 8.72608361 Suma 38.18
Cuenta 51 Cuenta 51
(a) (b)
En las Fig. N° 5.18, y Fig. N° 5.19 se observan los diagramas de dispersión para las réplicas
en Simio y en Flexsim HC, respectivamente.
75
Tiempo Promedio de Espera en Triage

SIMIO
1.2
1
0.8
Minutos
0.6
0.4
0.2
0
0 5 10 15 20 25 30 35 40 45 50
Réplicas
Fig. N° 5.18 Gráfico Tiempo Promedio de Espera en Triage v/s Réplicas – Simio
Tiempo Promedio de Espera en Triage

FLEXSIM HC
1.2
1
0.8
Minutos
0.6
0.4
0.2
0
0 5 10 15 20 25 30 35 40 45 50
Réplicas
Fig. N° 5.19 Gráfico Tiempo Promedio de Espera en Triage v/s Réplicas – Flexsim HC
Con el software Statgraphics se obtuvo el diagrama Box Plot que se muestra en la Fig. N°
5.20, donde se compara los resultados de ambos programas de simulación.
76
Box-and-Whisker Plot
Simio T
FlexsimHC T
0 0,2 0,4 0,6 0,8 1
Fig. N° 5.20 Gráfico de Cajas, Tiempos de Espera en Triage

Los gráficos de las Fig. N° 5.18, Fig. N° 5.19 y Fig. N° 5.20 muestran que sí hay
diferencias significativas entre las medias y las desviaciones estándar en los datos obtenidos con
cada programa de simulación, lo que se verifica al realizar pruebas estadísticas para la comparación
de las medias e igualdad de varianzas.
77
Comparison of Standard Deviations

---------------------------------
Simio T FlexsimHC T
------------------------------------------------------------
Standard deviation 0,0314759 0,124016
Variance 0,000990733 0,0153801
Df 50 50
Ratio of Variances = 0,0644167
95,0% Confidence Intervals

Standard deviation of Simio T: [0,0263362;0,039127]
Standard deviation of FlexsimHC T: [0,103766;0,154162]
Ratio of Variances: [0,0367685;0,112855]
F-tests to Compare Standard Deviations
Null hypothesis: sigma1 = sigma2
(1) Alt. hypothesis: sigma1 NE sigma2

F = 0,0644167 P-value = 0,0
(2) Alt. hypothesis: sigma1 > sigma2

F = 0,0644167 P-value = 1,0
(3) Alt. hypothesis: sigma1 < sigma2

F = 0,0644167 P-value = 0,0
Comparison of Means
-------------------
95,0% confidence interval for mean of Simio T: 0,1711 +/- 0,00885276

95,0% confidence interval for mean of FlexsimHC T: 0,748627 +/- 0,0348803
95,0% confidence intervals for the difference between the means:
assuming equal variances: -0,577528 +/- 0,0355456
not assuming equal variances: -0,577528 +/- 0,035885
t tests to compare means
Null hypothesis: mean1 = mean2
(1) Alt. hypothesis: mean1 NE mean2

assuming equal variances: t = -32,2346 P-value = 0,0
not assuming equal variances: t = -32,2346 P-value = 0,0
(2) Alt. hypothesis: mean1 > mean2

(3) Alt. hypothesis: mean1 < mean2

78
Como las desviaciones estándar difieren significativamente (valor-p = 0 < 0,05), se tiene que
el intervalo de confianza del 95% para la diferencia de los valores promedio está dado por
)*+,+- − )./012+,34 ± 6 = −0,577528 ± 0,035885,
donde d = 0,035885 (error de muestreo).
El intervalo anterior no contiene al 0, de donde se concluye que sí existe diferencia

estadísticamente significativa entre los valores promedio entregados por ambos software de
simulación, siendo los tiempos de espera que arroja Simio significativamente inferiores a los
tiempos de espera que resultan de la simulación con Flexsim HC. Esto se puede afirmar con un 95%
de confianza.
79
Capítulo 6. Conclusiones
6.1. Sumario
• Se investigó sobre la evolución de los softwares de simulación de evento discreto y las
características de un sistema orientado a objeto.
• Se desarrolló un modelo de simulación de evento discreto de una sala de emergencias
mediante el software Simio, aprovechando gran parte de sus herramientas. La información
sobre el sistema, los datos y parámetros a ingresar fueron obtenidos de un trabajo realizado
con anterioridad.
• Se detallaron los pasos propuestos a seguir para el correcto desarrollo del modelo realizado
en el software Simio.
• Se comprobó la complejidad y las ventajas de realizar un modelo de sistema de salud en un
lenguaje orientado a objeto como Simio.
• A partir de un modelo complejo, se realizó de forma simple un modelo más sencillo y se
obtuvieron datos de resultados como tiempo de ciclo y tiempo de espera en salas de espera.
• Se realizó una comparación entre los softwares Simio y Flexsim HC para simular un sistema
de salud, tomando en cuenta criterios tales como características de modelamiento, obtención
de datos de salida, rendimiento y homogeneidad de datos resultantes.
6.2. Conclusiones
• Es factible modelar un sistema de salud relativamente complejo mediante el software de
simulación de evento discreto Simio. Las herramientas y opciones de Simio permitieron
modelar un sistema que incluye: diversas clasificaciones de pacientes (por edad, origen,
severidad, características de enfermedad o lesión), distintas secuencias de los pacientes,
cambios en las llegadas de pacientes y en los recursos durante el día, pacientes que se van sin
tratamiento, pacientes que se agravan con el tiempo, entre otros. Los resultados obtenidos
son coherentes y el modelo resultó libre de errores tras su compilación.
• En una primera instancia, realizar un modelo de sistema de salud de este tipo en Simio
resulta complejo, sin embargo éste sirve como base para adaptarlo de forma sencilla a otros
casos.
80
• Existen diferencias en la forma de definir la lógica y las secuencias en Simio con respecto a
Flexsim HC. Simio es un software que no requiere programación por parte del modelador
sino que las rutinas se definen mediante tablas, parámetros y diagramas de bloques. Flexsim
Hc, por su parte, tiene menús y opciones adaptadas especialmente para casos de salud, sin
embargo para agregar rutinas más complejas se debe hacer uso de programación.
• Al correr varias réplicas de un sistema simple en los softwares Simio y Flexsim HC, se
verifica que el primero presenta un mayor rendimiento en un mismo computador. Los
tiempos que demora en correr el programa dependen del número de entidades existentes
dentro del modelo durante su ejecución y en este trabajo se encuentra que Simio es hasta
15,6 veces más rápido que Flexsim HC.
• Al ejecutar un mismo modelo simple en Simio y en Flexsim HC se obtuvieron tiempos de
ciclo promedio de 683,8 min en Flexsim HC y de 627,1 en Simio. Se verifica que para los
tiempos promedio de ciclo, las desviaciones estándar no difieren (valor-p = 0,405238) y se
tiene una diferencia de valores promedio entre ambos software igual a 56,6542 ± 101, 54
min. Este intervalo incluye al 0, por lo tanto se puede afirmar con un 95% de confianza que
no existen diferencias estadísticamente significativas entre estos tiempos promedio.
• Para el caso de los tiempos de espera del triage, obtuvieron tiempos medios de espera de
0,17 min en Simio y de 0,75 en Flexsim HC. Sse tiene que las desviaciones estándar sí
difieren significativamente (valor-p = 0) y el valor de confianza es −0,577528 ± 0,035885
min. Este intervalo no incluye al 0, por lo que se afirma con un 95% de confianza que sí
existe una diferencia significativa entre los valores arrojados por ambos softwares, siendo los
tiempos arrojados por Simio inferiores a los de Flexsim HC.
• Es recomendable utilizar el software de simulación de evento discreto Simio para modelar
sistemas de salud, en caso de que se utilice como herramienta de análisis de forma regular,
ya que los objetos creados de forma personalizada en un comienzo, pueden utilizarse para
representar otros sistemas similares. En caso de utilizarse en forma esporádica, se
recomienda utilizar Flexsim HC, que ya viene con una biblioteca de objetos de atención
médica.
81
6.3. Trabajo Futuro

En el futuro se podrá utilizar lo realizado en este trabajo para emplear el software Simio en
una aplicación real de sistema de salud u otro rubro, o utilizarlo para optimizar buscando los
controles de entrada para maximizar o minimizar algún objetivo mediante la herramienta OptQuest.
La realización de un modelo de sistema de salud en Simio, permite comprender cómo
adaptar las herramientas que ofrece el software, para representar actividades características de este
rubro. Con esto, surge la oportunidad para desarrollar en el futuro una versión del software diseñada
exclusivamente para esta industria, tal como Flexsim HC fue creado a partir de la versión estándar
de Flexsim.
82
Bibliografía
[1] J.A. Sepúlveda, F. Baesler, W. Thompson, “The Use of Simulation for Process Improvement
in an Emergency Department”, Industrial Engineering and management Systems, University
of Central Florida, Orlando, FL, USA, 2003.
[2] C. D. Pedgen, “Intelligent Objects: The Future of Simulation”, Simio LLC, Sewickley, PA,
USA.
[3] C. D. Pedgen, D. T. Sturrock, “Introduction to Simio”, in Proceedings of the 2010 Winter

Simulation Conference, Simio LLC, Sewickley, PA, USA.
[4] Simio LLC, “Simio Reference Guide, Version 3.0”, 2010.
[5] Archivo de Ayuda, FlexsimHC 2.771, 2010.
[6] J. Sepúlveda, F. Ramis, L. Neriz, M. Bull, “Using Object Oriented Simulation for Designing
Healthcare Units”, in Proceedings of the 2009 Industrial Engineering Research Conference,
Orlando, FL, USA.
[7] D. C. Montgomery, G. C. Runger, “Probabilidad y Estadística Aplicadas a la Ingeniería”,

Limusa-Wiley, 2da Ed., 2004.
[8] Archivo de Ayuda, Statgraphics v15.
[9] D.L. Heflin, C.R. Harrel, “Healthcare Simulation Modelling and Optimization Using
Medmodel”, in Proceedings of the 1998 Winter Simulation Conference.
[10] S.M. Sanchez, D.M. Ferrin, T. Ogazon, J.A. Sepúlveda, T.J. Ward, “Emerging Issues in
Healthcare Simulation” in Proceedings of the 2000 Winter Simulation Conference, New
York, 1999-2003.
[11] C.D. Pedgen, “An Introduction to Simio for Arena Users”, Simio LLC, Sewickley, PA,
USA, 2009.

Tesis Usando SIMIO PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis Usando SIMIO PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DEL BÍO-BÍO Profesor Patrocinante:

FACULTAD DE INGENIERÍA Dr. Francisco Ramis L.

Tesis para optar al grado de:

Desarrollo de un Modelo de Sistema de Salud

Concepción, Mayo de 2011 Marcos Fernando Goldemberg Vargas

UNIVERSIDAD DEL BÍO-BÍO Profesor Patrocinante:

Desarrollo de un Modelo de Sistema de Salud

Marcos Fernando Goldemberg Vargas

Tesis para optar al grado de

Magíster en Ingeniería Industrial

5.4.1 Experimentos ............................................................................................................................................ 58

1.1. Introducción General

1.2. Trabajos Previos

En este trabajo se presenta la experiencia con un modelo de simulación desarrollado en un

Actualmente, los lenguajes de simulación raramente contienen las herramientas y algoritmos

1.2.2 Hipótesis de Trabajo

1.3.1 Objetivo General

Desarrollar en el software de simulación de evento discreto orientado a objeto Simio un

1.3.2 Objetivos Específicos

1.4. Alcances y Limitaciones

1.5. Temario y Metodología

Capítulo 2. Antecedentes Generales

2.2. Modelamiento en Simio

2.2.1 Objetos y su Jerarquía

Fig. N° 2.1 Clases de Objetos en Simio

Capítulo 3. Modelo de Sala de Emergencias

3.2. Análisis del Sistema

• Estación de Camas de Trauma: 6 camas reservadas para casos de trauma.

Camas Sala de Espera

Camas Adultos Business

Ingreso por Ingreso a Pie

Fig. N° 3.1 Layout de Sala de Emergencias

3.3. Clasificación de Pacientes

o Llegada en ambulancia: Los pacientes transportados en ambulancia entran a la

3.4. Datos de Entrada

Tabla N° 3.1 Parámetros Utilizados para la Simulación

PACIENTES NO- Adulto Pediátrico

PACIENTE No-Ambulancia Ambulancia

La tasa de llegada de pacientes es variable en el día según el horario y es la que se indica en

Tabla N° 3.2 Pacientes Promedio por Hora

3.5. Flujo de Pacientes

Tabla N° 3.3 Secuencia Seguida por Pacientes Según su Clasificación

Tabla N° 3.4 Disponibilidad de Recursos

• De 09:00 a 11:00 hrs 25

• De 11:00 a 23:00 hrs 29

• De 23:00 a 11:00 hrs 0

3.7. Tiempos de Proceso

Tabla N° 3.5 Tiempos de Proceso

Capítulo 4. Construcción del Modelo en Simio

4.2. Creación de Objetos Personalizados

4.2.1 Entidades (Pacientes)

• En la ventana de Navegación se crea una nueva entidad llamada “Paciente”.

Fig. N° 4.1 Entidad Personalizada como Paciente

• Hacer una subclase de un Servidor y nombrarlo “Triage”.

4.2.3 Businesss Office

• Hacer una subclase de un Servidor y nombrarlo “BusinesssOfficer”.

• Hacer una subclase de un Servidor y nombrarlo “Cama”.

Fig. N° 4.2 Servidor Personalizado como Cama

4.2.5 Salas de Espera

• Hacer una subclase de un Servidor y nombrarlo “SalaEspera”.

• Hacer una subclase de un Vehículo y nombrarlo “Paramédico”.

Fig. N° 4.3 Transporte Personalizado como Paramédico

4.3. Ingreso de Datos