Tesis Usando SIMIO

UNIVERSIDAD DEL BÍO-BÍO FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA INDUSTRIAL

Profesor Patrocinante:

Dr. Francisco Ramis L.

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 DEPARTAMENTO DE INGENIERÍA INDUSTRIAL

Dr. Francisco Ramis L.

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. 1.2.

INTRODUCCIÓN GENERAL .................................................................................................................................. 10 TRABAJOS PREVIOS ........................................................................................................................................... 11

1.2.1 1.2.2

Discusión .................................................................................................................................................. 11 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. 2.2.

HISTORIA ........................................................................................................................................................... 14 MODELAMIENTO EN SIMIO ................................................................................................................................. 16

2.2.1

Objetos y su Jerarquía .............................................................................................................................. 16

CAPÍTULO 3. MODELO DE SALA DE EMERGENCIAS ...................................................................................... 19 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7.

IANTRODUCCIÓN .................................................................................................................................................. NÁLISIS DEL SISTEMA ...................................................................................................................................... 19 19 CLASIFICACIÓN DE PACIENTES .......................................................................................................................... 20 DATOS DE ENTRADA .......................................................................................................................................... 21 FLUJO DE PACIENTES ......................................................................................................................................... 23 RECURSOS.......................................................................................................................................................... 24 TIEMPOS DE PROCESO ........................................................................................................................................ 25

CAPÍTULO 4. CONSTRUCCIÓN DEL MODELO EN SIMIO ............................................................................... 26 4.1. 4.2.

INTRODUCCIÓN .................................................................................................................................................. 26 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. 5.2.

INTRODUCCIÓN .................................................................................................................................................. 51 SECUENCIAS ...................................................................................................................................................... 51

5.3. 5.4.

DE MODELAMIENTO L HÓGICA ERRAMIENTAS ADICIONALES.............................................................................................................................. ........................................................................................................................... 55 58

7 5.4.1 5.4.2 5.4.3

Experimentos ............................................................................................................................................ 58 Analizadores de Datos de Entrada y Salida ............................................................................................. 61 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. 6.2. 6.3.

SUMARIO ........................................................................................................................................................... 79 CONCLUSIONES .................................................................................................................................................. 79 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, srcen, 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 srcinal (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 Pediátricos

Sala de Espera Pediátricos

Camas Adultos

Business Office

Camas Trauma Triage Paramédicos Sala de Espera Business Office

Sala de Espera Adultos

Ingreso por Ambulancia

Ingreso a Pie

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 LLEGADA

Total de Casos

% de Número de Pacientes

Ambulancia

234

22%

No-Ambulancia

828

78%

22

PACIENTES NOAMBULANCIA

Adulto

Pediátrico

Emergente

8%

8%

Urgente

65%

80%

No Urgente

27%

12%

Total de Casos

1.026

342

PACIENTE ENVIADO A

No-Ambulancia

Ambulancia

Adulto

53 %

67 %

Fast-track

17 %

3%

Pediatrico

28 %

12 %

Trauma Número de Casos

2% 703

18 % 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

0 a 1:59 2 a 7:59 8 a 10:59 11 a 18:59 19 a 21:59 22 a 23:59

hora 5.3 3.7 68.1 10.4 12.9 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

FASTTRACK

AMBULANCIA

Triage

Triage

Triage

Cama

Espera BO

Espera BO

Espera BO

Atención

BO

BO

BO

BO

Espera Pediátricos

Espera Adultos

Espera Adultos

- Espec.

Cama Pediátricos

Cama Adultos

Cama Fast-Track

Atención

Atención

Atención

BO

BO

BO

- Espec. Despacho

- Espec. Despacho

Despacho

Despacho

Fuente: J.A. Sepúlveda, 2003.

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

Fuente: J.A. Sepúlveda, 2003.

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 Triage Business Office Cama niños Cama adultos Cama Fast Track

Tiempo proceso erla(2.5,2 ) norm( 5,2.2 ) gamm(75,2.58) 70+weib(342,1.6) 9+gamm(60,2.22) tria(90,300,540) 4+erla(30,3)

Comentario Todos Todos No Urgente & Urgente Emergente No Urgente & Urgente Emergente 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”.

•

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.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”.

•

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.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 Fuente: Elaboración propia.

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, Externo, cambiar la apariencia del símbolo y las colas.

•

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

o

o

Processing Time: 0 Input Buffer Capacity: 200 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

o

Idle Action: Park at Home. Cuando el vehículo esté libre se irá al nodo inicial para estacionarse en una cola. 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 Fuente: Elaboración propia.

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.Normal(5,2.2))/60

Random.Gamma(2.58,75) 4+Random.Erlang(30,3)

Random.Gamma(2.58,75) 4+Random.Erlang(30,3)

70+Random.Weibull(1.6,342) 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)

Fuente: Elaboración propia.

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 0 a 1:59

Nº de Pacientes por hora 5.3

2 a 7:59

3.7

8 a 10:59

68.1

11 a 18:59 19 a 21:59

10.4 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

Day 1, 07:00:00 Day 1, 08:00:00

3.7 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

Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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

% %

+%

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 Fuente: Elaboración propia.

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.

Rate Table: TasaLlegada . Add-On Process o

•

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:

o



1 – 24:

Adultos



25 – 34:

Pediátricos



35 – 44:

Fast Track



45 – 50:

Trauma

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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.

Desde Sala de Espera BO

Hacia Sala de Espera Fast Track

Hacia Sala de Espera Adultos

Hacia Sala de Espera Pediátricos

Fig. N° 4.9 Ruteo de Pacientes desde Business Office Fuente: Elaboración propia.

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

, , , , ,

,

,

, , , ,

,

Fuente: Elaboración propia.

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 Adulto Emergente

Hacia camas de Adulto

Paciente es Adulto Emergente

Paciente es Adulto No Emergente

Salida de Sala de Espera

Fig. N° 4.10 Esquema de Ruteo de Pacientes desde Sala de Espera Fuente: Elaboración propia.

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 de adultos

(1)

Hacia camas Fast Track emergentes

(2)

Hacia camas Fast Track no emergentes

(1)

Camas Fast Track no disponibles

(2)

Camas Fast Track disponibles y paciente no emergente

(3)

Camas Fast Track disponibles y paciente emergente

(3)

Salida de Sala de Espera de Fast Track

Fig. N° 4.11 Esquema de Ruteo de Pacientes Fast Track desde Sala de Espera Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Espera Fast Track

LWT Triage

LWT Sala de Espera Adultos

LWT Sala de Espera Trauma

Fig. N° 4.15 Nodos para Gatillar Procesos de LWT Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 Adultos

Camas Adultos (4)

Triage Llegada

Salida

Adultos 70% Niños 30% Emergentes 10% Urgentes 30% No Urgentes 60%

Sala de Espera Niños

Camas Niños (2)

Fig. N° 5.14 Diagrama de Sistema de Sala de Emergencias Simplificado Fuente: Elaboración propia.

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 Flexsim HC

0:02:53 hrs 0:08:15 hrs

0:07:22 hrs 1:22:30 hrs

Fuente: Elaboración propia.

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 Simulación

Tiempo promedio real por cada réplica

Tiempo real total de ejecución

Simio

0:01:02 hrs

0:02:46 hrs

Flexsim HC

0:04:30 hrs

0:43:00 hrs

Fuente: Elaboración propia.

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]: 



∙

 ,/  



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.

S 2:

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: 2 =S190.990, 69 1 2 S93.513,19 2

2 = S70.664,06 3

=

n

1

= 639

n

2

= 624

n

3

= 650

Por lo tanto la varianza ponderada es:





  − 1 

+   − 1  +  + + −3

  − 1 

Se escogen los siguientes valores:  ,/= 1,64

para un 90% de confianza

k = 90 min Se tiene entonces n = 39,02 39 réplicas ≈

117.509,8

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: = 0,47701 S21

n

= 0,56747 S22 = 0,54675 S23

n n

1

= 658

= 634 3 = 671 2

Por lo tanto la varianza ponderada es:





  − 1 

+   − 1  +  + + −3

  − 1 

Se escogieron los siguientes valores:  ,/= 1,96

para un 95% de confianza

k = 0,2 min Se tiene entonces n = 50,91 51 réplicas ≈

0,53

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 1

.

.

2

.

.

3

.

.

4

.

.

5

.

.

6

.

. .

.

.

.

.

.

10

.

.

11

.

12

.

13 14

. .

. .

15

.

.

16

.

.

1

.

.

1

.

.

1

.

.

20

.

21

.

.

22

.

.

23

.

24

.

.

. .

.

25

.

.

26

.

.

2

.

.

2

.

.

2

.

.

30

.

.

31

.

.

32

.

33

.

.

34

.

.

35

.

.

.

36

.

.

3

.

.

3

.

.

3

.

.

Fuente: Elaboración propia.

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

.

.

.

. .

. .

. .

.

.

.

.

. .

.

.

. .

. .

(a)

.

(b) Fuente: Elaboración propia.

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

Fig. N° 5.15 Gráfico Tiempo de Ciclo Promedio v/s Réplicas – Simio Fuente: Elaboración propia.

Fig. N° 5.16 Gráfico Tiempo de Ciclo Promedio v/s Réplicas - Flexsim HC Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 assuming equal variances: t = 1,11125 P-value = 0,134981 not assuming equal variances: t = 1,11125 P-value = 0,135013 (3) Alt. hypothesis: mean1 < mean2 assuming equal variances: t = 1,11125 P-value = 0,865019 not assuming equal variances: t = 1,11125 P-value = 0,864987

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

 − 



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 1

.

.

2

.

.

3

.

.

4

.

.

5 6

.

.

.

.

.

.

.

.

.

.

10

.

.

11

.

.

12 13

. .

. .

14 15

.

.

.

.

2

.

.

2

.

.

2

.

.

30

.

.

31

.

.

32

.

.

33

.

.

34

.

.

35

.

.

36

.

.

3

.

.

3

.

.

3

.

.

40

.

.

41

.

.

42

.

.

16

.

.

1

.

.

43

.

.

.

.

1

.

.

44

1

.

.

45

.

.

20

.

.

46

.

.

4

.

.

4

.

.

4

.

.

50

.

.

51

.

.

21

.

.

22

. .

. .

23 24

.

.

25

.

.

26

.

.

Fuente: Elaboración propia.

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

.

.

.

.

.

.

.

.

.

. .

.

.

.

.

. .

.

. .

. .

(a)

(b) Fuente: Elaboración propia.

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

.

. . . .

Fig. N° 5.18 Gráfico Tiempo Promedio de Espera en Triage v/s Réplicas – Simio Fuente: Elaboración propia.

.

. . . .

Fig. N° 5.19 Gráfico Tiempo Promedio de Espera en Triage v/s Réplicas – Flexsim HC Fuente: Elaboración propia.

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 Fuente: Elaboración propia.

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 assuming equal variances: t = -32,2346 P-value = 1,0 not assuming equal variances: t = -32,2346 P-value = 1,0 (3) Alt. hypothesis: mean1 < mean2 assuming equal variances: t = -32,2346 P-value = 0,0 not assuming equal variances: t = -32,2346 P-value = 0,0

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

 − 



−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, srcen, 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.