Simulación de un servicio de urgencias mediante Arena

Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de Organización Industrial Simulación de un Servicio de Urgencias mediante Arena Autor: Rafael Silva López Tutor: Roberto Domínguez Cañizares Dpto. Organización Industrial y Gestión de Empresas I Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2022 iii Trabajo Fin de Grado Grado en Ingeniería de Organización Industrial Simulación de un Servicio de Urgencias mediante Arena Autor: Rafael Silva López Tutor: Roberto Domínguez Cañizares Profesor Contratado Doctor Dpto. Organización Industrial y Gestión de Empresas I Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2022 v Trabajo Fin de Grado: Simulación de un Servicio de Urgencias mediante Arena Autor: Rafael Silva López Tutor: Roberto Domínguez Cañizares El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2022 El Secretario del Tribunal vii Por mi familia, que siempre ha sacado lo mejor de mí. Gracias a mi pareja y a mis amigos, quienes han sabido apoyarme en este largo camino. Y en memoria de mi abuelo Andrés, primer ingeniero de la familia. ix Agradecimientos A mis padres, Ignacio y Amalia, por su desmesurado esfuerzo en darme siempre la mejor educación posible y enseñarme que nada bueno en esta vida viene fácil ni gratis, todo lo que merece la pena requiere luchar por ello. A mi hermano Ignacio, que siempre ha sido un hombro donde apoyarse y quien me ha ayudado a encaminarme a ser la mejor versión de mí mismo. A mi pareja Carmen, por su apoyo incondicional y sus ánimos en los peores y mejores momentos. A mi difunto abuelo Andrés, en quien ví el ingeniero que quería llegar a ser. Agradecer también a mi profesor, Don Roberto Domínguez Cañizares, su esfuerzo, tiempo y dedicación. Los cuales han hecho posible la realización de este Trabajo de Fin de Grado. Rafael Silva López Graduado en Ingeniería de Organización Industrial Sevilla, 2022 ÍNDICE DE TABLAS Tabla 1. Tiempos de demora en la atención al paciente según el SET ................................................................. 7 Tabla 2. Distribuciones estocásticas de cada proceso según la gravedad del paciente [9] ................................. 10 Tabla 3. Porcentajes del flujo de atención en el HUVR con los años [10] ......................................................... 10 Tabla 4. Capacidad de los recursos según turno ................................................................................................. 43 Tabla 5. Pasos tratamiento según secuencia ....................................................................................................... 45 Tabla 6. Valor de capacidad del personal según el turno tras la reducción ........................................................ 58 Tabla 7. Comparativa métricas definidas por el usuario..................................................................................... 58 Tabla 8. Comparativa métricas definidas por AS ............................................................................................... 59 xvii ÍNDICE DE FIGURAS Ilustración 1. Diagrama del proceso de análisis [6] .............................................................................................. 2 Ilustración 2. Diagrama del proceso de diseño [6] ............................................................................................... 2 Ilustración 3. Flujo de Pacientes en el SU [8] ...................................................................................................... 8 Ilustración 4. Pasos del proceso de admisión y tratamiento de pacientes en el SU. [9] ..................................... 11 Ilustración 5. Áreas de aplicación de la simulación según la abstracción del modelo [5] .................................. 12 Ilustración 6. Etapas de un proyecto de simulación [14] .................................................................................... 16 Ilustración 7. Representación de la jerarquía según el nivel de modelado [15] ................................................. 17 Ilustración 8. Captura de pantalla plantilla Basic Process ................................................................................. 19 Ilustración 9. Captura de pantalla plantilla Advanved Process........................................................................... 19 Ilustración 10. Captura de pantalla plantilla Advanced Transfer ....................................................................... 20 Ilustración 11. Captura de pantalla plantilla Flow Process ................................................................................ 20 Ilustración 12. Captura de pantalla plantilla Statistics ........................................................................................ 20 Ilustración 13. Captura Interfaz Usuario AS ....................................................................................................... 21 Ilustración 14. Modelado de las llegadas de pacientes al SU ............................................................................. 24 Ilustración 15. Modelado de las llegadas de pacientes ....................................................................................... 25 Ilustración 16. Atributo para D2D ...................................................................................................................... 25 Ilustración 17. Modelado de la clasificación de los MdL................................................................................... 26 Ilustración 18. Porcentaje de llegadas según el modo [9] .................................................................................. 26 Ilustración 19. Módulos para la recopilación de estadísticas de los MdL .......................................................... 26 Ilustración 20. Flujo de pacientes según su MdL ............................................................................................... 27 Ilustración 21. Envío a UCI de pacientes de derivación..................................................................................... 27 Ilustración 22. Bloque 1 (Etapa de admisión) del modelo de simulación .......................................................... 28 Ilustración 23. Módulo decide [Tipo Prioridad] ................................................................................................. 28 Ilustración 24. Porcentaje de pacientes por categoría de prioridad .................................................................... 29 Ilustración 25. Modelado de la asignación de atributos según la prioridad ........................................................ 29 Ilustración 26. Modelado del proceso de Admisión ........................................................................................... 30 Ilustración 27. Bloque 2 (Etapa de Triaje) del modelo de simulación ............................................................... 31 Ilustración 28. Modelado llegada paciente código ............................................................................................. 31 Ilustración 29. Probabilidad de paciente de código ............................................................................................ 32 Ilustración 30. Modelado actuaciones para pacientes de código ........................................................................ 32 Ilustración 31. Modelado outcomes actuaciones de código ............................................................................... 33 Ilustración 32. Modelado proceso de triaje ........................................................................................................ 33 Ilustración 33. Bloque 3 (Etapa de Consulta) del modelo de simulación........................................................... 34 Ilustración 34. Sub-bloque 3.1 Llegada a consulta ............................................................................................. 34 Ilustración 35. Tiempo de consulta en función de las visitas a consultas realizadas .......................................... 35 Ilustración 36. Recursos involucrados en el proceso de consulta ....................................................................... 35 Ilustración 37. Flujo de pacientes de primera consulta....................................................................................... 35 Ilustración 38. Modelado secuenciación del tratamiento ................................................................................... 36 Ilustración 39. Routing según el tratamiento de los pacientes............................................................................ 36 Ilustración 40. Flujo de pacientes que revisitan consulta ................................................................................... 36 Ilustración 41. Modelado de la repetición de pruebas diagnósticas ................................................................... 37 Ilustración 42. Asignación de secuencia para la repetición de prueba ............................................................... 38 Ilustración 43. Recopilación de estadísticas de las altas de pacientes ................................................................ 38 Ilustración 44. Sub-bloque 3.2 Pruebas y actuaciones ....................................................................................... 39 Ilustración 45. Bloque 4 (Etapa de Descarga) del modelo de simulación .......................................................... 40 Ilustración 46. Plantilla Basic Process ................................................................................................................ 41 Ilustración 47. Módulo de datos Attribute .......................................................................................................... 41 Ilustración 48. Módulo de datos Entity .............................................................................................................. 42 Ilustración 49. Módulo de datos Queue.............................................................................................................. 42 Ilustración 50. Módulo de datos Resource ......................................................................................................... 42 Ilustración 51. Modelado fallos difractómetro ................................................................................................... 43 Ilustración 52. Módulo de datos Schedule ......................................................................................................... 43 Ilustración 53. Módulo de datos Set ................................................................................................................... 43 Ilustración 54. Módulos datos plantilla Advanced Transfer............................................................................... 44 Ilustración 55. Módulo de datos Station Data..................................................................................................... 44 Ilustración 56. Módulo de datos Sequence ......................................................................................................... 44 Ilustración 57. Módulos datos plantilla Statistics ............................................................................................... 45 Ilustración 58. Módulo de datos Tally ................................................................................................................ 45 Ilustración 59. Módulo de datos Counter ........................................................................................................... 46 Ilustración 60. Módulos datos plantilla Advanced Process ................................................................................ 46 Ilustración 61. Módulo de datos Advanced Set .................................................................................................. 46 Ilustración 62. Módulo de datos Expression ....................................................................................................... 47 Ilustración 63. Módulo de datos Failure ............................................................................................................. 47 Ilustración 64. Set Up de la simulación .............................................................................................................. 48 Ilustración 65. Total Time y Number In de los pacientes en el modelo ............................................................. 52 Ilustración 66. Tiempos en cola para cada proceso del modelo ......................................................................... 53 Ilustración 67. Error AS por exceso del máximo de entidades simultáneas posibles ......................................... 53 Ilustración 68. Utilización instantánea y number busy de los recursos del modelo ........................................... 54 Ilustración 69. Métricas between e interval medidas para diversos sucesos....................................................... 55 Ilustración 70. Valor para los contadores de diversos sucesos ........................................................................... 56 Ilustración 71. Schedule llegadas escenario de saturación ................................................................................. 57 Ilustración 72. Schedule llegadas escenario ocioso ............................................................................................ 57 Ilustración 73. Comparativa del LoS y D2D según el escenario......................................................................... 58 Ilustración 74. Comparativa SU según el escenario ........................................................................................... 59 Ilustración 75. Comparativa NB según el escenario ........................................................................................... 60 xix Notación AS D2D Arena software Door to Doctor / Tiempo hasta primera consulta HUVR IU LoS RD SET Hospital Universitario Virgen del Rocío Instantaneous Utilization Lenght of Stay / Duración de la estancia Radiodiagnóstica (e.g. Prueba RD) Sistema Español de Triaje SP Sistema Productivo/ Sistema de Producción SU Servicio de Urgencias MdL Modo(s) de Llegada TBA TBP Time Between Arrivals Time Between Pruebas 1 1 INTRODUCCIÓN 1.1 La problemática de la atención hospitalaria Dentro del paradigma sanitario, encontramos una problemática perteneciente al ámbito de la gestión sanitaria, la cual, ha recibido una gran atención por parte de la comunidad científica debido a la gran importancia que ha ido cobrando en estas últimas décadas. Se trata de la problemática de la gestión de la atención hospitalaria. Esta problemática se encuentra en un punto álgido de su existencia puesto que, tras la llegada de la pandemia mundial del COVID-19, se ha hecho aún más notoria la necesidad de optimizar la eficiencia de los procesos que conforman el servicio de atención hospitalaria. Esta imperante necesidad se ha visto se completamente reflejada en la sobresaturación de los sistemas sanitarios a nivel mundial ante un aumento repentino y considerable de la demanda de pacientes. Dichos sistemas sanitarios, se vieron incapaces de gestionar sus limitados recursos para afrontar esta grave pandemia a pesar de los esfuerzos titánicos realizados para que el impacto fuese el menor posible. Es por lo anterior, y por el creciente avance científico sanitario, por lo que la gestión de la atención hospitalaria ha sido y está siendo objeto de múltiples estudios que tratan de abordar la misma con múltiples enfoques, modelos más o menos complejos, y con diversas metodologías. Todo, con el fin de tratar de analizar y mejorar la atención hospitalaria, logrando así alcanzar objetivos como la reducción del tiempo medio que permanecen los pacientes en el hospital, el decremento de la tasa de mortalidad, la mejora de la eficiencia de los recursos disponibles y otros muchos más. Dentro del ámbito hospitalario, identificamos un área en concreto cuya calidad del servicio dado se ve enormemente influenciada por la gestión de la atención. Esta es la unidad de urgencias o comúnmente conocida como SU o simplemente urgencias. Dentro de esta unidad, la optimización de la gestión de la atención dada puede marcar la diferencia entre tratar a un paciente a tiempo o no hacerlo, lo que puede llegar a acarrear consecuencias fatales como la muerte. En las investigaciones del SU, la literatura hace referencia a dos subbloques: el operativo y el táctico. Para el sub-bloque operativo, la principal problemática y sobre la que se sigue trabajando en optimizar, es la secuenciación de pacientes. Esta es de vital importancia puesto que con el paso de los años se ha evidenciado que tiene un impacto realmente significativo en la calidad de la atención dada. Acentuándose este impacto aún más para los servicios de urgencias, donde la secuenciación de pacientes permite tratar con prioridad a aquellos que realmente lo necesitan, de forma que se salvan un número considerable de vidas sacrificando parcialmente el servicio proporcionado a pacientes no urgentes. Por otro lado, el táctico, engloba todos los problemas con un enfoque temporal a medio-largo plazo de la gestión de los recursos disponibles y de las diversas configuraciones posibles. En este sub-bloque encontramos múltiples decisiones a nivel táctico. La más importante es la gestión de los turnos de trabajo del personal de urgencias (así como la minimización del impacto por faltas de personal). La toma de decisiones en ambos sub-bloques tienen afectaciones directas en esta problemática, la cual ha sido abordada por varios autores y con múltiples enfoques como el empleo de metaheurísticas [1], el uso de metamodelos [2], modelos de programación lineal [3], modelos de simulación [4], etc. Pero en nuestro caso, nos interesa un enfoque en particular, la simulación de procesos. 1.2 Simulación de procesos Decir que el modelado y la simulación de procesos han sido metodologías de vital importancia en la resolución de problemas complejos (especialmente en estas últimas décadas), no es ni mucho menos un disparate. Y que serán aún más importantes en el futuro, lo es menos aún todavía. Vivimos en una sociedad donde el desarrollo industrial y tecnológico es prácticamente exponencial. Estos avances tan acelerados conllevan la necesidad de abarcar conceptos cada vez más complejos, y de la forma más rápida posible; es necesario dar con la solución, aún más importante es hacerlo a tiempo, pero tampoco se deben dejar de lado los costes de encontrar dicha solución. Es en este mismo paradigma, donde surge la necesidad de la simulación de los procesos. Esto se puede apreciar de forma intrínseca a su definición; la simulación hace referencia al conjunto de métodos y aplicaciones que buscan imitar el comportamiento de sistemas reales, generalmente en una computadora, con el fin de ser capaces de construir un modelo que pueda manipularse para obtener respuestas a preguntas sobre la naturaleza de dicho sistema. [5] Al crear un modelo de simulación basado en un sistema real, se logran varios objetivos, entre ellos:  Analizar el sistema existente Podemos comprender con gran nivel de detalle (en función de la afinidad del modelo con el sistema real) el comportamiento del sistema, simplemente evaluándolo múltiples veces y bajo distintas situaciones o escenarios. Y, en base a los resultados obtenidos, idear mejoras aplicables al sistema real, mejorando dicho sistema de forma continua. Ilustración 1. Diagrama del proceso de análisis [6]  Diseñar nuevos sistemas Si hay un sistema ya existente para el proceso a simular, podemos enfrentarnos al problema con nuevos modelos para obtener otras soluciones que minimicen los aspectos negativos del sistema real y se adapten al proyecto. Ilustración 2. Diagrama del proceso de diseño [6] La simulación es, por ende, un medio que nos permite entender comportamientos propios de un sistema bajo unas determinadas condiciones (que nosotros podemos variar a nuestro gusto), sin necesidad alguna de experimentar con el sistema real. Lo cual, cumple con las exigencias del paradigma ya comentado: ser capaces de estudiar y dar respuesta a aspectos del comportamiento de un proceso complejo de forma rápida y económicamente viable. 3 1.3 Objetivos de este Proyecto El fin último de este trabajo de fin de grado, es construir un modelo de simulación aproximado de un SU que nos permita analizar el sistema existente, identificando así sus fortalezas y debilidades, para posteriormente idear mejoras aplicables al sistema real o incluso plantear la posibilidad de rediseñarlo si fuese necesario. Se habla de un modelo aproximado y no uno exacto puesto que, la información disponible del sistema real es limitada, así como lo es la versión del software de simulación utilizado que corresponde a la versión (demo) para estudiantes de Arena Software (AS). Los objetivos específicos de este trabajo son: 1. Sacar conclusiones coherentes y acordes al comportamiento del sistema real a partir de los resultados obtenidos al simular el modelo. 2. Estudiar cómo reacciona el modelo y cómo varían los resultados que arroja la simulación ante diferentes situaciones o escenarios. 3. Identificar las fortalezas y debilidades del modelo construido, proporcionando soluciones o mejoras para estas últimas. 1.4 Estructura del Proyecto La estructura de este trabajo está basada en 6 capítulos que se abordaran siguiendo una cierta linealidad en el contenido que se va tratando. Con esto, se pretende que el lector de este proyecto pueda entender lo explicado en cada capítulo apoyándose en los conceptos vistos en los anteriores, refrescando siempre que resulte necesario, conceptos un tanto complejos y de forma muy puntual. El primer y segundo capítulo son los capítulos introductorios. El primero está orientado al proyecto que se acomete, dando contexto a los conceptos de atención hospitalaria y la simulación de procesos y su creciente importancia hoy en día, así como definiéndose la estructura y los objetivos de este estudio. El segundo capítulo, servirá para introducir y abordar con la profundidad necesaria, los procesos y el funcionamiento de un SU semejante al del HUVR, el cual tomaremos como referencia. Tratando el concepto de SU, sus aspectos clave, las etapas que lo componen y representando de forma gráfica el flujo de pacientes a lo largo del mismo. En el tercer capítulo, se presenta la metodología elegida, introduciendo esta con cierta brevedad y justificando su elección sobre otras. Asimismo, se aborda de forma ágil y concisa las fases necesarias para acometer un proyecto de simulación, para finalmente terminar explicando una serie de conceptos clave para que el lector pueda entender con soltura el funcionamiento del software Arena. El cuarto, se centrará exclusivamente en explicar cómo se ha elaborado el modelo en Arena, definiendo el rol que desempeña cada uno de los bloques que lo componen y haciendo hincapié en los aspectos más interesantes o complejos que se han encontrado a la hora de modelar el sistema. Por último, se verá con detalle el input definido para cada uno de sus módulos de datos del modelo. Al comienzo del quinto capítulo, se presentan los informes de Arena, para posteriormente realizar un análisis de los resultados obtenidos al simular el modelo original, así como para una serie de escenarios definidos. Estos últimos, serán comparados con el escenario base y entre sí. Quedando esta comparativa plasmada en una serie de gráficas y tablas. Y finalmente, en el capítulo 6, se exponen una serie de conclusiones con relación al modelo desarrollado indicando sus puntos débiles y fuertes, así como proponiendo mejoras o soluciones aplicables al mismo. Anexo: Recogerá capturas del informe generado al simular el escenario base. 1.5 Fuentes consultadas Para la realización de este TFG, se han consultado múltiples fuentes de información como pueden ser artículos científicos que abordan la problemática de la logística hospitalaria, varias memorias anuales publicadas por el HUVR en su página web, trabajos de fin de carrera y de fin de máster de compañeros de la escuela, y otras muchas fuentes las cuales son referenciadas a lo largo de este documento. Pero cabe destacar que, han sido dos, las que han resultado de mayor ayuda de cara a la elaboración de este proyecto. Estas han sido: la memoria del año 2020 del HUVR y el trabajo de fin de máster “Algoritmos de Optimización para el servicio de urgencias: Caso de estudio en el Hospital Universitario Virgen del Rocío” del antiguo alumno de la escuela David Gómez Medina. 5 11 3 METODOLOGÍA APLICADA 3.1 La simulación de procesos De forma muy similar a como sucede en el ámbito industria, con la búsqueda de “óptimos” (volúmenes óptimos, beneficios óptimos, ritmos óptimos de producción, etc.), en el paradigma hospitalario, también se buscan otro tipo de óptimos más relacionados con la capacidad de atención, con la eficiencia en la gestión del paciente y la calidad del servicio dado. Buscándose en ambas situaciones la reducción de cuellos de botella, de tiempos de proceso, congestiones del sistema… El primer paso que cometer en la búsqueda de la mejora continua de cualquier proceso es siempre el análisis de la situación actual o de partida. Existen para ello múltiples herramientas que permiten evaluar el estado de funcionamiento en el que se encuentra un sistema. Ejemplos de estas son los Análisis DAFO (Debilidades, Amenazas, Fortalezas y Oportunidades), el estudio de curvas de rendimiento, la reingeniería de procesos, la gestión de la calidad y, por último, pero no menos importante, la simulación y posterior análisis de resultados. Pero de entre todas estas herramientas, de forma cada vez más habitual y debido a su ya comentadas rapidez y viabilidad económica, el uso modelos de simulación se constituye como una de las opciones más viables y llamativas para la mejora de procesos. Todo proyecto de simulación consiste en la elaboración de un modelo (lo más acertado posible) para posteriormente simularlo bajo múltiples escenarios, y una vez obtenidos los resultados, realizar un análisis data driven con el objetivo de mejorar o rediseñar los procesos existentes en el modelo para finalmente estudiar cuales de todos estos cambios y mejoras ideados son viables tanto desde una perspectiva económica como de aplicación en la práctica. Un aspecto clave en el modelado de cualquier sistema, es identificar el carácter del modelo de simulación que se va a construir. Un modelo puede clasificarse en las siguientes 4 tipologías: 1) Estático o Dinámico 2) Continuo o Discreto 3) Determinista o Estocástico 4) Cerrado o Abierto Respecto a la primera clasificación, nuestro modelo será de carácter dinámico, puesto que sus variables de estado poseen una dependencia temporal. Estas se verán afectadas en su valor con el paso del tiempo. Para identificar la segunda tipología de nuestro modelo, nos serviremos de la analogía realizada en la sección 2.2 Enfoque Productivo del SU. Los sistemas productivos (considerando el SU como tal) siempre hacen uso de programas que empleen la simulación por eventos discretos. La razón por la que se recurre a tipo de modelos de simulación es debido a que la gran mayoría de procesos que podemos encontrar en cualquier tipo de organización, pueden ser descritos o definidos por una serie de eventos que suceden en un conjunto discreto de instantes de tiempo. La simulación por eventos discretos se caracteriza porque sus sistemas cambian su estado con cada ocurrencia de un evento. Ejemplos de eventos para nuestro caso puede ser la entrada de un paciente, el fin de un proceso de consulta, la liberación de un recurso… Hasta el momento hemos identificado el modelo como dinámico y discreto, lo siguiente que necesitamos saber es si será determinista o estocástico. Por mera experiencia, sabemos que, en los sistemas reales, existe una cierta tendencia a lo caótico que no es nunca considerada en los denominados “sistemas ideales” (deterministas) mientras que esta tendencia sí es considerada en los modelos estocásticos por medio de variables aleatorias. El implicar a una variable aleatoria conlleva al desconocimiento de la salida del sistema. Es decir, para una misma entrada, son posibles múltiples y diferentes salidas. 12 Es por este motivo por el que los modelos estocásticos son los más afines al comportamiento real de los sistemas. Sabiendo lo cual, podemos afirmar con total confianza que un SU se identifica con un modelo estocástico y uno muy caótico, además. Esto se ve perfectamente en variables aleatorias como la demanda (pacientes), la disponibilidad de recursos (personal) o los tiempos de proceso, los cuales son componentes con una alta repercusión en el comportamiento de nuestro “falso” SU. Además de todo lo anterior, un aspecto relevante que no se ha comentado es el nivel de abstracción del modelo, este es un aspecto determinante en la elección del método de simulación. Para un hospital (SU) lo habitual es un nivel intermedio puesto que queremos modelar el sistema a nivel táctico. Un nivel más bajo podría suponer modelar acciones como interacciones de pacientes en los habitáculos del hospital, cosa que no es ni sencilla ni necesaria para los fines buscados con este modelo de simulación. Para nivel de abstracciones medias-bajas se usa la simulación por eventos discretos. Ilustración 5. Áreas de aplicación de la simulación según la abstracción del modelo [5] Para la última tipología, podemos identificar nuestro modelo como abierto ya que este está sometido a continuas interacciones de influencias externas. Una vez se ha clasificado el modelo, en nuestro caso como dinámico, discreto, estocástico y abierto, se debe decidir cómo se va a construir el mismo. Podemos decantarnos por 2 opciones:  Lenguajes de simulación de propósito general (Java, Python, C++, etc.)  Paquetes de simulación Para la elaboración del modelo de simulación de este proyecto, se ha elegido la segunda opción. Las razones que justifican el uso de un paquete de simulación son 5 principalmente:  Están diseñados específicamente para la simulación de procesos (características específicas).  Poseen una mayor facilidad del uso de la interfaz, del diseño y mantenimiento de los modelos.  La detección de errores es más sencilla y el mismo software proporciona alertas concisas del tipo de error.  El uso de un paquete conlleva una considerable reducción del tiempo de programación.  Pueden poseer un mayor coste en licencias software, pero abaratan el coste total del proyecto. 13 Dentro de los paquetes de simulación, encontramos una subdivisión de los softwares de simulación:  Orientados a aplicaciones (Automod, ProModel, OPNET Modeler, ProcessModel, MedModel)  De propósito general (Arena, ExtendSIm, Simio, Anylogic, SIMUL8) De las dos opciones que encontramos en esta subdivisión, se ha escogido la segunda, dado que los softwares de simulación de propósito general son aptos para múltiples ámbitos de aplicación, pueden traer características especiales y en algunos casos se pueden ampliar sus funciones por medio de la instalación de paquetes Como ya se ha dicho al comienzo de este trabajo, para este modelo se ha elegido usar el software Arena Simulation. Esta elección no solo está basada en las ventajas que acabamos de comentar, también se apoya en que a diferencia de otros softwares de simulación, la versión demo que ofrece AS para estudiantes proporciona un enorme abanico de opciones de modelado a pesar de estar limitada hasta un cierto punto en lo que respecta a la dimensión del modelo. Una vez hemos definido la herramienta que vamos a usar para aplicar un proceso de mejora a un sistema real, vamos a tratar con cierto detalle las fases que debemos abordar al acometer un proyecto de simulación. 3.2 Fases de un proyecto de simulación Al la hora de acometer un proyecto de modelado, simulación y optimización de un proceso o una serie de procesos, es necesario enfrentar el problema de forma ordenada y coherente, asegurando el éxito en el desarrollo de cada fase de forma que hay una linealidad que nos encamina a lograr los objetivos planteados y evita que retrocedamos a modificar fases anteriores salvo en casos muy puntuales y tratando siempre de que la afectación en las fases posteriores sea mínima. Previo a tratar estas fases, cabe mencionar que este trabajo de fin de carrera no se puede identificar al completo con un proyecto de simulación, puesto que este no parte desde 0 sino que comienza sobre una problemática ya definida y cuantificada. Como veremos a continuación, las fases que sí podemos identificar con este trabajo son las fases 5 (Recopilación de información), 6 (Diseño del modelo) y de forma muy escueta las fases 8 (Estudio de alternativas) y 9 (Análisis de las diferentes soluciones). La fase 7 no se ha incluido ya que como se ha comentado anteriormente, la información del sistema a modelar es limitada e insuficiente como para validar el modelo de simulación realizado. Sabiendo lo anterior, vamos a ver cada una de las fases de un proyecto de simulación: 3.2.1 Definición de la problemática Es crucial que esta fase quede perfectamente definida ya que constituirá los cimientos de nuestro modelo de simulación. El modelo a generar dependerá inmensamente de la definición del problema a abordar y de los objetivos que se quieren cumplir con su resolución. Por lo que es recomendable demorarse en esta fase para evitar a toda costa realizar suposiciones erróneas o caer en enfoques inadecuados. 3.2.2 Formulación y cuantificación de los objetivos En este paso, se especificarán sin dejar lugar a dudas los objetivos a alcanzar con la simulación del sistema real cuya problemática definimos anteriormente. Es muy importante que todos los objetivos queden cuantificados. Es decir, aquellos que sean cualitativos deben ser traducidos a métricas específicas. Todo objetivo al final de esta fase debe ser: preciso, inequívoco, realista (en términos de recursos y tiempo) y cuantitativo. 3.2.3 Descripción y suposiciones del modelo Describir un modelo consiste en concretar todos y cada uno de los elementos que lo componen y que, por ende, participan en él. Para el caso de AS, Estos elementos son los ya comentados anteriormente en el apartado 3.3 Nociones básicas de Arena. 14 Por último y no menos importante, es necesario también considerar todas las suposiciones posibles sobre nuestro sistema. Esto servirá para dar claridad a cómo fluyen las entidades en el modelo, así como a caer en la cuenta de ciertos aspectos en el flujo de este. 3.2.4 Definición de posibles soluciones alternativas A pesar de que esta fase pueda parecer poco importante o innecesaria para la elaboración de nuestro modelo, puede ser crucial de cara a futuras transformaciones. Esto se debe a que, si se diseña el modelo considerando otras posibles soluciones, luego será mucho más sencillo modificar el modelo para obtener otro con diferentes soluciones. Por lo que, al considerar esta fase, dotamos al modelo de una flexibilidad ante cambios que puede resultar muy interesante. 3.2.5 Recopilación de información En este paso se procederá a recopilar todos aquellos datos e información posibles para modelar los inputs del modelo tratando de asemejarse lo máximo posible al modelo real. No toda esta información será útil ya que, antes de hacer uso de ella, tendrá que pasar por un proceso de validación. Una vez es validada, la usaremos para comparar los datos reales con los outputs obtenidos en el modelo al usarla. Un aspecto para mencionar de este paso es la complejidad de este. Puesto que podemos encontrar múltiples problemas a la hora de recabar la información necesaria, como, por ejemplo: • No siempre existirán fuentes de información disponibles o quizás lo estén, pero solo durante un tiempo limitado. • La extracción de datos puede incurrir en unos costes demasiado elevados. En estos casos será necesario estudiar otras alternativas como el uso de datos ya existentes de otros modelos similares o el empleo de estimaciones y análisis de sensibilidad. • La extracción requiera de un tiempo excesivo. Si esto sucede lo recomendable será filtrar la información o priorizarla en función de su utilidad y afinidad. 3.2.6 Diseño del modelo El modelo a generar deberá ser diseñado teniendo en mente todas las recomendaciones/normas comentadas en los pasos anteriores. Este deberá ser construido por fases o bloques con los que podremos jugar posteriormente para crear otros nuevos modelos de simulación. Un aspecto muy importante en el diseño es el equilibrio complejidad – realismo. Según las necesidades del proyecto, o bien se priorizará la sencillez de modelado (plazos más cortos) o la semejanza del modelo respecto al sistema real (outputs más afines a la realidad). Una práctica recomendable es diseñar el modelo de forma escalada, esto es, diseñar un modelo inicial que funcione y se adapte a las necesidades buscadas, pero no de forma estricta e ir mejorándolo sobre esta base ya existente. Si se intenta simular un modelo muy complejo desde cero, es probable incurrir en unos tiempos no deseados de modelado o incluso no llegar a completar el modelo a tiempo y que este peque de bloques menos desarrollados que otros. Por otro lado, un modelo demasiado sencillo tiene la desventaja de proporcionar resultados poco orientativos o muy dispares de los reales. En resumen, todo modelo de simulación debe ser diseñado con el grado de detalle necesario para la consecución de los objetivos del proyecto y la correcta representación del sistema real, ni más ni menos. 3.2.7 Validación y verificación Una vez se ha diseñado el modelo, hay que asegurar la validez de este. Esto se lleva a cabo realizando dos pasos; una validación y una verificación. La primera busca comprobar cuán afín es el modelo que se ha desarrollado. Esta comprobación se lleva a cabo comparando los resultados obtenidos al simular el modelo con los obtenidos al medir el sistema real. En base a estos resultados, se estudia si la variación es aceptable o no. 15 Por otro lado, el objetivo de la verificación es ver si se ha cometido algún error a la hora de implementar el modelo, así como estudiar si existe redundancia en los elementos del modelo (ineficiencia). Para lograr esto, se hace uso del debugging o depuración siempre y cuando el software posea herramientas capaces de ello. 3.2.8 Estudio de las alternativas En este paso, se tratará de determinar y recopilar todos aquellos aspectos de interés para el proyecto acometido para todas y cada una de las alternativas contempladas (algunas quedarán descartadas en el paso 4). Estos aspectos pueden ir desde los inputs necesarios para cada una de ellas, hasta el número de réplicas a realizar para que los resultados sean fiables. Para realizar estos análisis, nos serviremos de herramientas como la generación de gráficas, intervalos de confianza, informes con métricas y estadísticas relevantes… 3.2.9 Análisis de las diferentes soluciones Una vez aunada toda la información final obtenida en la fase anterior, se llevará a cabo un análisis de resultados del modelo cuyo fruto sean una serie de conclusiones que permitan comprender el funcionamiento en detalle tanto del modelo simulado como del real. Pudiendo llegar a conocer el modelo hasta tal punto que sabríamos: • Qué outputs se van a obtener al utilizar unos inputs concretos. • Qué recursos/procesos son cuellos de botella y cómo erradicarlos • Qué parte del modelo es más ineficiente y por qué • Cómo se comporta el modelo ante cambios inesperados (demanda, variación de tiempos de proceso, averías…) 16 A continuación, se muestra un diagrama de flujo como ayuda visual, el cual resume todos los pasos vistos en este apartado. Ilustración 6. Etapas de un proyecto de simulación [14] Una vez hemos definido las características de nuestro modelo, elegido el método de simulación, así como el software que usaremos para modelarlo y comprendemos las diferentes las etapas que debemos seguir en un proyecto de simulación, es momento de profundizar en el funcionamiento de la herramienta escogida para el desarrollo de este proyecto de simulación. Arena software. 17 3.3 Introducción a Arena Software Arena Software es uno de los más conocidos softwares de simulación de propósito general, este fue desarrollado por Systems Modeling y adquirido por la empresa americana Rockwell Automation en el año 2000. Su funcionamiento se basa en un modelado jerárquico que combina lenguajes de alto nivel que aportan una facilidad en el modelado gracias a una serie de módulos e interfaces intuitivas, así como lenguajes de bajo nivel (SIMAN, Visual Basic y C/C++) que dotan de flexibilidad al modelo. En Arena el modelo está orientado a procesos mientras que la simulación se desarrolla orientada a eventos. Al encontrarse el modelo orientado a procesos, se hace posible apreciar la experiencia que las entidades tienen a su paso por el sistema. La estructura del modelo es similar a la de un diagrama de flujo, por lo que mismas entidades pueden tener un diferente paso a lo largo del modelo. Ilustración 7. Representación de la jerarquía según el nivel de modelado [15] 18 Entre los usos más habituales de este software encontramos el diseño de procesos de fabricación, la gestión de cadenas de suministro, el control de puertos marítimos, la gestión de centros de atención telefónica, así como otras aplicaciones en los sectores militar, sanitario y educativo. 3.4 Elementos de un modelo de simulación en Arena Software Previo a tratar con detalle las particularidades del modelo de simulación desarrollado para este proyecto, vamos a abordar rápidamente las nociones básicas necesarias para entender cómo funciona AS. Comenzaremos realizando una distinción entre los diferentes elementos que podemos identificar en cualquier modelo de simulación generado en Arena. Teniendo cada uno de estos elementos una responsabilidad relativa al flujo del modelo. Estos son los siguientes: 3.4.1 Entidades Representan los elementos que avanzan por el flujo del sistema, causando cambios de estado en el mismo, así como interactuando entre sí dando lugar a diversos flujos. Son el componente dinámico del modelo del modelo de simulación. Para nuestro caso, las entidades corresponderán a los pacientes, quienes serán tratados de forma que su estado evolucionará a lo largo del sistema. 3.4.2 Atributos Permiten dar un aspecto diferenciador a entidades semejantes por medio de la asignación de atributos con un valor predeterminado. Esto da juego a: forzar el paso por ciertos caminos del flujo, asignar distintos tiempos de procesos a una misma entidad, así como proporcionar otras características propias de las entidades. De forma que un atributo se comporta como una variable local. 3.4.3 Recursos Corresponden a los elementos necesarios para poder llevar a cabo un proceso, ya sea personal (operario), un equipamiento (herramientas) o un equipo (máquinas). Los recursos son componentes estáticos del modelo que se pueden encontrar en 3 tipos de estados diferentes: ocioso o libre, ocupado y en falla (no disponible). En el modelo generado para este proyecto encontramos los siguientes recursos: 3.4.4 Colas También denominadas Buffers en el ámbito de los sistemas productivos. Las colas contienen a las entidades mientras se encuentran esperando previo a realizar un proceso, el cual no pueden realizar o bien porque el recurso se encuentre ocupado o porque este se encuentre en estado de falla.. 3.4.5 Variables Representan información previamente definida, la cual aporta o refleja una determinada característica del sistema, son independientemente del total de entidades presentes en el mismo y su valor puede estar sometido a diferentes cambios a lo largo de su paso por el modelo. Arena maneja 2 tipos de variables globales: 1) Variables definidas por el mismo software. Algunos ejemplos son el número de entidades en la cola, la cantidad de recursos que se encuentran ocupados, el valor del tiempo de simulación… 2) Variables definidas por el usuario. Las variables no aportan información de una entidad en concreto, sino que especifican a todo el sistema. Por otro lado, estas pueden ser referenciadas desde cualquier otro módulo. 19 3.4.6 Acumuladores estadísticos Permiten obtener métricas del rendimiento, así como otras muchas estadísticas del sistema durante la simulación. Todos los acumuladores toman el valor inicial de 0. Además, estos pueden ser definidos por el usuario, así como pueden apoyarse en variables predefinidas que se comporten como acumuladores. 3.4.7 Reloj de Simulación Es principal variable principal del modelo de simulación. En ella se recoge el valor actual del tiempo de simulación el cual definirá el transcurso de los eventos. 3.5 Plantillas de módulos en Arena Software Una vez manejamos los distintos tipos de elementos del software, es momento de tratar los elementos que conforman los modelos generados con el mismo. Cada elemento que compone un modelo de simulación recibe el nombre de módulo. En Arena estos módulos se muestran agrupados en diferentes plantillas según su aplicación o aportación al modelo. Existen múltiples plantillas diferentes, las más relevantes son: 3.5.1 Procesos básicos Agrupa todos aquellos módulos que sirven para simular llegadas, salidas, procesos y tomas de decisiones (lógicas) muy básicas. Ilustración 8. Captura de pantalla plantilla Basic Process 3.5.2 Procesos Avanzados Dentro de esta plantilla encontramos los módulos que permiten crear lógicas más complejas y otras funciones como el acceso a bases de datos o ficheros externos al modelo. Ilustración 9. Captura de pantalla plantilla Advanved Process 26 ¿Tipo Paciente? (Módulo decide) La función de este módulo es simular los diferentes tipos de medios en los que puede llegar un paciente, los cuales (de menor a mayor probabilidad) son: Helicóptero (0.5%), coche de policía (0.7%), derivación (1.3%), ambulancia (12.5%) y a pie (85%). Ilustración 17. Modelado de la clasificación de los MdL El valor de estas probabilidades está altamente basado en el diagrama de sectores mostrado a continuación, procedente de un artículo científico [9] que aborda esta misma problemática, solo que al haber considerado un MdL que no se considera en el artículo (llegada por derivación), hay ligeras variaciones en los porcentajes. Ilustración 18. Porcentaje de llegadas según el modo [9] Estadísticas *modo de llegada* (Módulo record) Si seguimos el flujo de los diferentes tipos de llegada, nos encontramos con los módulos que a continuación se muestran: Ilustración 19. Módulos para la recopilación de estadísticas de los MdL 27 Su función es registrar estadísticas de interés para este estudio como pueden ser el número de llegadas de cada modo; (count) Llegadas_*modo de llegada*. O el tiempo que pasa entre cada llegada de un tipo de modo; (time between) TBA_*modo de llegada*. Go to: UCI (Módulo Go to Label) Ilustración 20. Flujo de pacientes según su MdL Una vez se recogen las estadísticas de cada tipo de llegada, ocurren varios sucesos interesantes: 1) El flujo de los pacientes que llegan en helicóptero NO pasa por el módulo decide “¿Tipo Prioridad?”, el cual sirve para otorgar al paciente de una categoría de nivel de prioridad según el SET. Esto se debe a que, para este modelo de simulación, se ha hecho el supuesto de que todo paciente que llegue en helicóptero será un paciente muy grave, entendiendo por esto que tendrá un nivel de prioridad 1. 2) Los pacientes que llegan por derivación son enviados directamente a la UCI, este supuesto se ha realizado en base a información obtenida tras hablar con parte del personal que trabaja/ha trabajado en el HUVR, quienes indicaban que, si se produce un ingreso al SU por derivación, es porque es necesario enviar al paciente a la unidad de cuidados intensivos. Ilustración 21. Envío a UCI de pacientes de derivación 3) Para el caso de los pacientes que llegan en coche de policía, ambulancia o a pie, sus flujos sí pasaran por el módulo decide “¿Tipo Prioridad?”, donde se les asignará una categoría que será determinante en los tratamientos/actuaciones durante su estancia en el SU. 28 4.2.2 Bloque 1 - Admisión En esta etapa del modelo, los pacientes serán categorizados según su nivel de prioridad de acuerdo con el SET, y pasarán o no por admisión, en función de su nivel de prioridad. La admisión es un paso opcional en el proceso de ingreso puesto que su único objetivo es recopilar información del paciente para identificarlo, así como registrar su estancia en el SU. Ilustración 22. Bloque 1 (Etapa de admisión) del modelo de simulación Tipo Prioridad (Módulo decide) En este módulo se dividirá el flujo de pacientes en función de su nivel de prioridad. Ilustración 23. Módulo decide [Tipo Prioridad] 29 Para determinar qué cantidad de pacientes se identificarán con cada categoría de prioridad, nos serviremos de una aproximación obtenida en este estudio [9]. A continuación, se muestra un diagrama de sectores con las respectivas cantidades: Ilustración 24. Porcentaje de pacientes por categoría de prioridad Paciente NV. *Prioridad según SET* (Módulo assign) Una vez el flujo se divide tras la clasificación según el nivel de prioridad, cada tipo de paciente pasará por un módulo assign donde se le asignará:  El atributo T_Consulta que diferenciará la duración de la atención en consulta de cada paciente según su prioridad. A mayor prioridad menor tiempo de consulta.  El atributo T_Triaje que funciona de forma similar al atributo anterior solo que aplica para el proceso de triaje.  El atributo Prioridad que asigna el nivel de esta.  El tipo de entidad Prioridad *nivel* que a pesar de parecer redundante al ya contar con un atributo que defina el nivel de prioridad, este tipo de entidad o entity type, nos servirá para asignar diferentes imágenes a cada tipo de paciente, así como para asignarle una secuencia de tratamiento, cosa que veremos más adelante. Ilustración 25. Modelado de la asignación de atributos según la prioridad 30 Admisión (Módulo process) Este es el primer módulo de tipo process que encontramos en nuestro modelo, conforme avancemos encontraremos muchos más. Estos módulos funcionan de forma que cuando una entidad llega al mismo, se ejecuta una acción determinada que requerirá de un tiempo determinado y de unos recursos determinados. Es necesario mencionar que si llegan entidades al módulo y los recursos utilizados en el mismo están ocupados, las entidades deberán esperar en cola hasta que se liberen todos los recursos necesarios. Para el caso del proceso de Admisión:  La acción que realizar es un Seize Delay Release. Lo que significa que la entidad liberará el/los recurso/s una vez transcurrido el tiempo especificado.  El recurso (resource) que se ocupará en este proceso será 1 recepcionista.  Y el tiempo que llevará realizar este proceso (Delay Type) vendrá definido por una distribución Triangular; TRIA(2, 5, 7.5) Ilustración 26. Modelado del proceso de Admisión 31 4.2.3 Bloque 2 - Triaje Previo a abordar los procesos y módulos de esta etapa del modelo, es interesante mencionar un aspecto destacable del modelado de un SU el cual podemos ver perfectamente en esta etapa. A diferencia de como ocurre en el sistema real, dónde la categoría del paciente es asignada una vez este ha pasado por el triaje, en el modelo de simulación la categoría es asignada antes de que el paciente pase por este proceso. Esto se debe a que la única forma de asignar diferentes tiempos de triaje a los pacientes según su prioridad es asignando esta misma (y su valor de tiempo de triaje) de forma previa al proceso de triaje, identificado en este modelo por “Triaje SET”. Ilustración 27. Bloque 2 (Etapa de Triaje) del modelo de simulación En este bloque, el flujo se divide en dos corrientes principales la primera, correspondiente a los pacientes de código, quienes se saltarán la etapa de triaje por su urgencia. Y la segunda, la de los pacientes no tan graves que pasarán por triaje (con un tiempo menor cuanto menor sea su prioridad). Un código es una situación de un paciente muy grave que requiere de una atención urgente por parte de personal específico. Los códigos más destacados son: Infarto, Ictus y Trauma. Ilustración 28. Modelado llegada paciente código En este modelo de simulación, los códigos de urgencias han sido simulados de forma muy abreviada y sin entrar en mucha complejidad en lo que respecta a su tratamiento. Se ha tomado la decisión Sólo podrán ser pacientes de código, aquellos que hayan sido categorizados con Prioridad I y cuyo paso por el módulo decide “¿Se trata de un Código?” sea TRUE. 32 ¿Se trata de un código? (Módulo decide) Ilustración 29. Probabilidad de paciente de código La probabilidad de que un paciente de nivel de prioridad I corresponda a un código será del 65% puede parecer un porcentaje excesivo, pero si contamos con que solo un 1% del total de pacientes tiene esta prioridad y que este nivel supone un estado realmente grave del paciente, es lógico pensar que muchos de estos casos se corresponderán con un código. Actuaciones Código (Módulo process) De este módulo cabe mencionar la necesidad de múltiples recursos, cómo se puede ver, para cada paciente de código que requiera de actuación, serán necesarios 2 médicos, 2 enfermeros y 1 cama. Ilustración 30. Modelado actuaciones para pacientes de código Outcome actuaciones código Tras realizar las actuaciones pertinentes en un paciente de código, pueden darse dos situaciones (determinadas en el decide “¿Se ha logrado estabilizar?” con una probabilidad del 90% para el caso verdadero). Estos escenarios son:  El paciente ha sido estabilizado por lo que es enviado a la unidad de cuidados intensivos (UCI) para hacer un seguimiento exhaustivo de su evolución.  No ha sido posible estabilizarlo, es decir, ha fallecido o lo hará en un futuro cercano. Por lo que se recogen las estadísticas con el módulo “Fallecidos” y estos pacientes salen del sistema con el módulo dispose “Fallecimiento”. 33 Ilustración 31. Modelado outcomes actuaciones de código Triaje SET (Módulo process) Todos aquellos pacientes cuyo nivel de prioridad va del V al II inclusive o cuyo nivel es I, pero no son de código, pasarán por el proceso de triaje. Este módulo se caracteriza principalmente por tener la expresión T_Triaje ya comentada anteriormente en el Bloque 1) Admisión, y por usar dos recursos; 1 enfermero y 1 slot (hueco) en la sala de triaje. Ilustración 32. Modelado proceso de triaje 4.2.4 Bloque 3 - Consulta Esta ha resultado ser la etapa cuyo modelado ha sido el más complejo de realizar de todas. Como es dicho en el mundo de la medicina, “cada paciente es un mundo” y esto es cierto hasta un punto. En la etapa de consulta entran múltiples factores en juego, algunos de los más importantes son: número de veces que se ha pasado por consulta, tipología del paciente, tratamientos pertinentes, recursos necesarios, priorización de pacientes más graves, fallos/errores en los diagnósticos, tiempos de downtime de máquinas… Es por ello y por muchos motivos más, por lo que se ha decidido simplificar el proceso de consulta apoyándose en los siguientes supuestos: 1) No se considerarán tipologías sintomáticas, sino que cada paciente tendrá una secuencia de tratamiento con un número de pruebas previamente determinado y acorde a su nivel de prioridad. 2) A mayor número de visitas a consulta, menor será el tiempo de consulta de dicho paciente, es decir, el tiempo de consultas será siempre inversamente proporcional al número de visitas. 3) Mientras más veces revisite la consulta un paciente, menor será la probabilidad de que lo haga de nuevo. 4) La prioridad en las colas de la mayoría de los procesos vendrá determinada por el nivel de prioridad. Esto será visto con detalle más adelante. 34 Ilustración 33. Bloque 3 (Etapa de Consulta) del modelo de simulación Tal y como se puede apreciar en la captura anterior, en este bloque se encuentran la mayor parte de los módulos de nuestro modelo de simulación, por lo que a diferencia de como se ha procedido en etapas anteriores, en este bloque analizaremos de forma superficial los distintos caminos que el flujo puede tomar, así como la función de los módulos más interesante. Eso sí, tratando en todo momento de no dejar atrás ningún aspecto clave o de interés del modelo. Además de lo anterior, tal y como se ve en la imagen, se ha decidido dividir la etapa de consulta en dos subbloques que analizaremos uno a uno para posteriormente relacionarlos. Al primero lo denominaremos por “3.1) Llegadas a consulta” y al segundo “3.2) Pruebas y actuaciones”. Bloque 3.1 - Llegada a Consulta En la captura que sigue, podemos observar los módulos pertenecientes a este sub-bloque de la etapa de consulta. Ilustración 34. Sub-bloque 3.1 Llegada a consulta 35 Siguiendo el camino desde donde lo dejamos en la etapa anterior; process Triaje SET. Vemos que el flujo sigue hasta llegar a la etapa de consulta. La consulta está modelada con un módulo process con dos aspectos a destacar; el tiempo de proceso viene definido por la expresión que se muestra a continuación: Ilustración 35. Tiempo de consulta en función de las visitas a consultas realizadas Esta expresión viene a traducirse en que, por cada visita a consulta realizada, el tiempo de consulta se reducirá en un 12%. Por ende, cuando el paciente vuelva a pasar por consulta, su tiempo de proceso será: 𝑇_𝑐𝑜𝑛𝑠𝑢𝑙𝑡𝑎 (1 + 𝑉𝑖𝑠𝑖𝑡𝑎𝑠_𝑐𝑜𝑛𝑠𝑢𝑙𝑡𝑎 ∗ 0.12) Ecuación 1. Expresión tiempo de consulta en función del número de visitas En cuanto al segundo aspecto a destacar; es que en este process aparecen dos nuevos recursos: el facultativo y el slot de la sala de consulta: Ilustración 36. Recursos involucrados en el proceso de consulta Siguiendo el flujo, el siguiente módulo que nos encontramos es un decide; “¿Es su Primera Consulta?”. Llegados a este punto, el flujo quedará dividido en los pacientes que ya han pasado por consulta y los que todavía no lo han hecho. Esta condición se estudiará contemplando si el atributo Visitas_Consulta es distinto de 0. Vamos a estudiar ambos casos. Caso 1: Primera vez que el paciente pasa por consulta Ilustración 37. Flujo de pacientes de primera consulta Una vez el paciente termina el proceso de consulta, este es enviado al record “D2D Metric” dónde se comparará el valor del TNOW que se le asignó al atributo D2D en el instante de su llegada, con el valor del reloj de simulación en el preciso instante en el que termina el proceso de consulta. Siguiendo con el flujo, llegamos a un módulo decide “¿Primera Consulta?” donde la condición de verdad será que valor del atributo Visitas_Consulta sea igual a 0, cosa que se cumplirá siempre que al paciente no se le haya asignado una secuencia de tratamiento previamente. 42 4.3.2 Entidad Para las entidades, encontramos 6 registros. El primero, llamado “Paciente” representa a todas las entidades del modelo previo a que el paciente reciba una categoría. Mientras que el resto corresponden a los tipos de prioridad de tratamiento. A pesar de que ya contamos con el atributo “Prioridad”, se ha definido un tipo de entidad con el fin de asignar de manera más sencilla la secuencia de tratamiento a cada paciente según su gravedad. Ilustración 48. Módulo de datos Entity 4.3.3 Cola Como podemos ver a continuación, la prioridad en la gran mayoría de las colas de los distintos procesos del modelo está determinada por la prioridad de tratamiento más baja. O lo que es lo mismo; cuanto menor sea el valor del atributo prioridad de un paciente, mayor será su prioridad (valga la redundancia) en la cola del proceso en el que se encuentre esperando. Ilustración 49. Módulo de datos Queue 4.3.4 Recurso En la imagen que sigue a este párrafo, podemos ver un listado de todos los recursos que existen en este modelo de simulación acompañados de los parámetros que los definen: capacidad y su tipo, regla de programación de capacidad, tiempos de comportamientos determinados y fallos. Ilustración 50. Módulo de datos Resource 43 Es interesante mencionar que el único recurso para el que se han modelado fallos es el difractómetro, el cual fallará según la expresión definida en Fallo_Radiografia bajo la regla de fallo Preempt. Esta regla actúa de forma que, si el paciente está realizando una prueba RD y el difractómetro falla, el paciente no podrá reanudar la prueba (dónde la dejó) hasta que la máquina sea reparada. Ilustración 51. Modelado fallos difractómetro 4.3.5 Programación Horaria El módulo de datos schedule contiene las programaciones definidas para los 2 turnos existentes en nuestro modelo, el diurno y el nocturno, ambos de 12 horas de duración. Estas programaciones determinan la capacidad que tendrá un recursos de capacidad variable según el turno en el que se encuentre. Así como el valor de la expresión que definirá las llegadas de pacientes. En nuestro caso, los recursos de capacidad variable son los recepcionistas, enfermos, facultativos y médicos. Ilustración 52. Módulo de datos Schedule Se ha elaborado la Tabla 4 para resumir el valor programado según el turno: Tabla 4. Capacidad de los recursos según turno Recurso Turno Diurno Turno Nocturno Recepcionista 2 1 Enfermero 10 8 Facultativo 8 7 Médico 4 3 Llegadas Pacientes POIS(8) POIS(14) 4.3.6 Conjunto El módulo Set nos permite definir en un mismo grupo (al cual podremos llamar desde los módulos lógicos) distintos valores de un tipo de elemento como puede ser un tipo de entidad. Ilustración 53. Módulo de datos Set 44 La siguiente plantilla que encontramos es Advanced Transfer. Esta contiene 2 módulos de datos usados en este modelo; Station Data y Sequence. Ilustración 54. Módulos datos plantilla Advanced Transfer 4.3.7 Datos Estación Contiene todas las estaciones que hemos definido en nuestro modelo. Para el caso que nos ocupa, estas estaciones corresponden a las posibles pruebas o pasos del tratamiento de los pacientes. Ilustración 55. Módulo de datos Station Data 4.3.8 Secuencia Este es el módulo de datos más interesante de nuestro modelo, contiene las secuencias de tratamiento para cada uno de los posibles casos que pueden existir en el paso de un paciente por el SU. Tenemos una secuencia por prioridad y secuencias de repetición de pruebas concretas. Ilustración 56. Módulo de datos Sequence 45 A continuación, en la Tabla 5 se muestran los pasos del tratamiento de cada una de las secuencias: Tabla 5. Pasos tratamiento según secuencia Pruebas → ↓ Secuencias Actuación Prueba RD Trat. Sillón Analítica Extracción Antígenos Receta Prioridad I 1 2 3 4 5 Prioridad II 1 3 4 2 Prioridad III 2 3 1 4 Prioridad IV 2 1 3 Prioridad V 1 Analítica 1 Prueba RD 1 Antígenos 1 Sillón 1 Pasamos a la 3ª plantilla que contiene módulos de datos usados en este modelo. Esta es “Statistics”. Los módulos de datos que hemos usado de esta plantilla son 2: Tally y Counter Ilustración 57. Módulos datos plantilla Statistics 4.3.9 Conteo El módulo contiene un listado de todos los tiempos para los cuales se ha decidido recopilar estadísticas usando el tipo de estadística Time Between de los módulos record. Mencionar que TBA hace referencia a time between arrivals y TB a time between. Ilustración 58. Módulo de datos Tally 46 4.3.10 Contador Por otro lado, counter contiene todas aquellas estadísticas de conteo recopiladas en módulos record con el type count. Ilustración 59. Módulo de datos Counter La última plantilla de módulos que contiene datos esenciales para nuestro modelo es la de Advanced Process. De esta plantilla sólo se han usado 3 módulos de datos: Advanced Set, Expresion y Failure Ilustración 60. Módulos datos plantilla Advanced Process 4.3.11 Conjunto Avanzado Este módulo de datos nos permite agrupar conjuntos de elementos más complejos que no podríamos agrupar con un set. En este modelo se ha usado para agrupar todas las secuencias posibles de tratamiento en un conjunto vectorial llamado Secuencias. Ilustración 61. Módulo de datos Advanced Set 47 Es importante no confundir el módulo de datos sequence con este módulo. Mientras que en el primero se definen los pasos de cada una de las secuencias, en este segundo se agrupan las mismas en un vector dónde cada posición representará un tipo de secuencia. 4.3.12 Expresión En este módulo solo tenemos 1 expresión definida, esta es Tiempo Desplazamiento y nos será de ayuda para simular el paso del paciente de una prueba a otra. Esta expresión está definida como una distribución Normal de media 7.5 min. y desviación típica de 2 minutos. Ilustración 62. Módulo de datos Expression 4.3.13 Fallo Contiene la expresión que simulará el fallo del difractómetro comentado en el módulo de datos resource. La expresión está definida por una Normal(10,3) y simula la necesidad de reajustar la máquina. Ilustración 63. Módulo de datos Failure 48 4.4 Set Up de la simulación Habiendo definido la estructura modular del modelo y los datos de este, el último paso es definir la configuración con la que se va a correr la simulación: Ilustración 64. Set Up de la simulación Esta configuración nos indica que, al correr esta simulación, se realizarán 50 réplicas, para las cuales la única condición de terminación será que el número de pacientes que han ingresado a la UCI sea igual a 200. Por otro lado, se establece que la unidad de tiempo utilizada tanto en la simulación como en los informes generados será la hora. 49 50 5 ANÁLISIS DE RESULTADOS Llegados a este punto y una vez habiendo explicado en detalle el modelo y su funcionamiento, es momento de pasar al análisis de resultados. Esto es estrictamente necesario ya que por muy bien realizado (desde un punto de vista funcional) que esté un modelo, si los resultados que arroja no son coherentes, no se está cumpliendo la función para la cual fue diseñado; obtener resultados lo más afines posibles a los que obtendríamos simulando el sistema real. El software de Arena facilita enormemente el análisis de resultados proporcionando un informe en el cual se recogen las principales métricas de interés de una simulación, así como aquellas que nosotros hayamos añadido. Este informe se genera de forma automática una vez se termina de correr la simulación. Antes de pasar a ver los aspectos clave del informe obtenido al correr la simulación del modelo definitivo, se va a realizar una breve introducción a los informes de AS para familiarizarse con algunos conceptos que nos serán de gran ayuda para comprender los valores obtenidos. 5.1 Introducción a los informes de Arena La dimensión de los informes de AS variará en función del modelo simulado y de las métricas añadidas por el usuario, pero por norma general, los informes siempre tendrán 3 pestañas: Entity, Queue y Resource. En el caso de nuestro modelo contaremos con 1 pestaña adicional; User Specified. A continuación, vamos a ver en detalle el contenido de cada una de ellas. Esta introducción y su contenido están basadas en [5]. Todas las pestañas contienen estos 4 valores para cada una de las métricas mostradas: - Average - Half Width - Minimum Average - Maximum Average El Half Width servirá como indicador de la variabilidad de los valores obtenidos. Valores altos (relativos a la media) indican alta variabilidad en los resultados. 5.1.1 Pestaña Entity Métricas relativas al tiempo  VA Time: tiempo total que pasa la entidad ocupando recursos.  WaitTime: tiempo total que pasa la entidad esperando en colas.  Total Time: tiempo total que pasa la entidad en el sistema. Otras métricas  NumberIn: número de entidades que entran en el sistema.  NumerOut: número de entidades que salen del sistema.  WIP: promedio de entidades en el sistema (siendo procesadas + en cola). 5.1.2 Pestaña Queue  WaitingTime: tiempo de espera promedio que pasa una entidad en la cola.  NumberWaiting: número promedio de entidades que esperan en la cola. 51 5.1.3 Pestaña Resource  Instantaneous Utilization: promedio de utilización del tipo de recurso. Su valor se aproximará a: - 1  si el tipo de recurso (incluyendo todos los recursos de este tipo) está ocupado durante todo el tiempo de simulación. - 0  si nunca se usa el tipo de recurso.  Scheduled Utilization: tiempo promedio que pasan los recursos ocupados, dividido por el tiempo programado promedio.  NumberBusy: cantidad promedio de recursos de este tipo ocupada durante la simulación. 5.1.4 Pestaña User Specified Aquí se recogen todos los datos recogidos por el usuario con módulos record. Distinguimos 2 grupos:  Tally - Between - Interval  Counter - Count 5.2 Escenario base A continuación, se mostrarán las métricas más representativas de cada una de las pestañas del informe que AS ha generado para nuestro modelo original. Debido a la ya comentada imposibilidad de validar el modelo, se ha decidido considerar que los resultados obtenidos al correr esta simulación representarán nuestros valores de referencia o, dicho de otra forma, el escenario base. Esta consideración se realiza en vista a la posterior comparativa que se realizará con otros escenarios en los que se variarán las condiciones del sistema, capacidades de recursos, distribuciones estocásticas de los procesos, etc. 58 A continuación, se muestra en la Tabla 6, los valores de capacidad resultantes de los recursos tras aplicar la reducción del 20%. Tabla 6. Valor de capacidad del personal según el turno tras la reducción Recursos KVar Turno Diurno Turno Nocturno Recepcionista 2 1 Enfermero 8 6 Facultativo 6 5 Médico 3 2 5.4 Comparativa casos de estudio Para la realización de esta comparativa, se ha decidido hacer uso de dos tablas, en la Tabla 7 podemos ver los valores de las métricas definidas por el usuario para cada uno de los escenarios y ídem para las métricas definidas por AS en la Tabla 8. Además, cada una de ellas irá acompañada de una gráfica que permitirá una comparativa visual más ágil. Tabla 7. Comparativa métricas definidas por el usuario Escenario LoS Prior. I LoS Prior. II LoS Prior. III LoS Prior. IV LoS Prior. V D2D Base 2.075 3.353 2.189 1.819 1.093 1.261 Saturación 2.513 3.542 2.364 2.010 1.397 1.387 Ocioso 1.886 3.124 2.098 1.736 0.872 1.217 Reducción K 2.485 3.370 2.260 1.991 1.288 1.323 Ilustración 73. Comparativa de LoS y D2D según el escenario Como podemos ver en la Ilustración 73, las métricas definidas por el usuario alcanzan sus valores máximos en el escenario de saturación (como era de esperar), el siguiente escenario con valores más altos es el de reducción de capacidad, seguido del escenario base y, por último, el ocioso. 59 Tabla 8. Comparativa métricas definidas por AS Métrica Escenario Base Escenario Saturación Escenario Ocioso Escenario Reducción K SU Recepcionista 0.405 0.563 0.393 0.476 SU Enfermero 0.613 0.723 0.513 0.635 SU Facultativo 0.541 0.682 0.501 0.594 SU Médico 0.291 0.395 0.191 0.326 NB Recepcionista 0.621 0.750 0.531 0.674 NB Enfermero 5.518 5.994 4.982 5.751 NB Facultativo 4.060 4.943 3.863 4.573 NB Médico 1.020 1.236 0.919 0.985 Aclarar que solo se han estudiado los valores para los recursos de personal, ya que todo proceso que implique un recurso material o maquinaria consumirá también de recursos personales. Por lo que la saturación se producirá siempre antes en estos primeros. Es lógico; no se puede usar una máquina o realizar un tratamiento sin un personal que lo realice. Ilustración 74. Comparativa SU según el escenario Para el caso de la utilización programada, se da un comportamiento muy similar al de las métricas D2D y LoS vistas anteriormente. Solo que, en vez de mayores valores de tiempo, tenemos mayores valores de utilización de los recursos de personal. Como era de esperar, los mayores valores de utilización ocurren en el escenario de saturación mientras que los menores valores ocurren en el ocioso. 60 Ilustración 75. Comparativa NB según el escenario Tal y como se aprecia en la Ilustración 75, sucede exactamente la misma situación que se ha comentado para las métricas anteriores, la tendencia de valores de number busy siempre decrece cuánto menos saturado se encuentre el sistema o mayor capacidad exista para los recursos de personal. 61 62 6 CONCLUSIONES Nos encontramos en el último capítulo de este trabajo de fin de carrera, en él, serán expuestas una serie de conclusiones extraídas no solo de los resultados obtenidos de las simulaciones realizadas sino también del proceso de construcción del modelo, así como de las limitaciones que conllevaba el uso de una versión demo de un software de simulación. Además de estas conclusiones, se identificaran y trataran de forma breve y concisa las fortalezas y debilidades del modelo generado. El SU está caracterizado por ser un sistema altamente eficiente, pero también considerablemente caótico en la práctica. A pesar de que los procesos que tienen lugar en él están altamente estandarizados, en la realidad el SU es un sistema totalmente reactivo cuyo comportamiento puede cambiar de forma drástica con la llegada de un paciente. Todo esto sin mencionar las múltiples variables que afectan al funcionamiento natural de este. Uno de los objetivos de este proyecto era la construcción de un modelo de simulación que fuese lo más aproximado posible al sistema real. Y pese a que se ha tratado arduamente de que así fuese, el modelo generado dista mucho de ser realmente afín al sistema real. Otro factor que ha jugado un papel determinante en la construcción del modelo, han sido las limitaciones del software Arena. Estas restricciones de tamaño del modelo y del número de entidades simultáneas permitidas, han incurrido en dos formas o posibilidades de elaborar el modelo: la primera, reduciendo su escala (y por ende sus resultados) para posteriormente re-escalarlo. Y la segunda, realizando ciertos supuestos que sacrificaban la validez de ciertos datos del modelo (reducción de esperas en colas a mínimos). En este trabajo se decidió seguir la segunda opción puesto que, si algún día se desease modelar con mayor detalle un SU, la situación de partida más favorable sería haciéndolo con un modelo a escala. Un aspecto que también es necesario mencionar, es la falta de validez o verificación del modelo generado. Como se ha comentado varias veces a lo largo de este proyecto, la información que se tiene sobre el comportamiento de un SU a nivel de subprocesos es limitada y varía bastante en la forma de representar ciertos sucesos de un estudio a otro. Esta falta de validación de los datos obtenidos implica que el modelo no sea considerado como válido, puesto que realmente no sabemos cuán afín es a la realidad (fin último de la simulación de procesos). A pesar de ello, en este trabajo se ha decidido realizar el supuesto de considerar el escenario base como válido para así comparar las salidas y comportamiento del modelo ante diferentes entradas. 6.1 Debilidades y fortalezas Por otro lado, en lo que respecta al modelo, sus fortalezas y debilidades pueden resumirse de la siguiente forma: Fortalezas - El modelo demuestra una reacción adecuada y acorde al comportamiento real de sistema para ciertos escenarios (véanse los escenarios de ociosidad y saturación). - A pesar de ser un modelo relativamente sencillo, contempla aspectos muy interesantes de cara a afrontar esta problemática, cómo puede ser la priorización de pacientes en procesos y sus colas, recursos con capacidad variable, consideración de distribuciones estocásticas, flujos para múltiples casuísticas… - Si se usara la versión completa de Arena, evitando limitaciones en la construcción y simulación del modelo, el margen de mejora es considerable. Esto podría verse reflejado perfectamente en los resultados de ciertos datos (tiempos en cola, ajustando recursos al máximo posible). 63 Debilidades - Los resultados de la simulación no son fiables puesto que no se ha validado el modelo. - En situaciones puntuales, la simulación proporciona valores que a priori no parecen coherentes. Por ejemplo, la obtención de un menor tiempo de estancia del paciente (Los) para el escenario de saturación que para el ocioso. - Durante su simulación, el modelo es altamente sensible a crashear durante momentos pico de demanda. Lo que incurre en no concluir la simulación y, por ende, no conocer los resultados obtenidos hasta la réplica que tuvo el error. - Con relación al punto anterior, cuándo AS termina una simulación por un error de exceso del máximo de entidades simultáneas, no es posible ver qué proceso ha sido el que más entidades acumulaba a no ser que se ejecute el modelo con animaciones en velocidad reducida, opción en absoluto recomendable en modelos de gran dimensión. 6.2 Recomendaciones para futuras líneas de investigación Por último, se van a definir una serie de recomendaciones de cara a futuras propuestas de continuación de esta línea de investigación: - Si se desea que el modelo sea preciso, es estrictamente necesario realizar una recopilación de información exhaustiva proveniente de fuentes fiables como pueden ser servicios de urgencias de diferentes hospitales (mientras mayor sea el tamaño de la muestra mejor) u estudios que aborden la problemática con cierta validez científica. - El uso de la versión completa del software de simulación es altamente recomendable puesto que, al no tener limitaciones, el modelo (siempre y cuando su construcción sea adecuada) podrá siempre correr la simulación. Y pese a que los resultados que esta arroje puedan no sean precisos, se tendrá una serie de valores sobre los que pivotar en lugar de estar constantemente rediseñando el modelo por restricciones en la ejecución de la simulación. En sistemas tan complejos como es el que nos ocupa, una buena práctica que nos puede ser de gran ayuda es seleccionar el número mínimo de variables posibles que tengan la máxima afectación en el comportamiento del sistema posible (ley de Pareto y análisis de sensibilidad) 64 65 7 REFERENCIAS [1] M. C. J. -.. N. I. &. K. S. Harzi, «Using the hybrid ILS/VND method for solving the patients scheduling problem in emergency department: A case study,» Procedia Computer Science, 2018. [2] M. &. Y. M. Yousefi, «Human resource allocation in an emergency department: A metamodel-based simulation optimization.,» Kybernetes, 2020. [3] M. C. J. -.. N. I. &. K. S. Harzi, «Scheduling patients in emergency department by considering material resources,» Procedia Computer Science, 2017. [4] E. T. M. I. M. L. E. F. &. L. E. Cabrera, «Simulation optimization for healthcare emergency departments,» Procedia Computer Science, 2012. [5] R. D. Cañizares, «Trasparencias de clase,» de Modelado y Simulación de Sistemas Industriales. [6] A. P. López, «Trabajo de Fin de Grado,» de Análisis de Variantes de Sistema CONWIP Multiproducto para el Control de la Producción, 2018. [7] Hospital Galenia, «hospitalgalenia.com,» [En línea]. Available: https://hospitalgalenia.com/que-es-el- servicio-de-urgencias-de-un-hospital/. [8] G. M. David, «Trabajo de Fin de Máster,» de Algoritmos de optimización para el servicio de urgencias: caso de estudio en el Hospital Universitario Virgen del Rocío, 2021. [9] L. Deboya-Valencia y E. Kirac, «Evaluating alternative resource allocation in an emergency department using discrete event simulation,» Sage Journals, 2016. [10] Hospital Virgen del Rocío, «Memoria Hospitalaria HUVR,» 2020. [11] M. Yousefi, «Human resource allocation in an emergency department: A metamodel-based simulation optimization,» Kybernetes, 2020. [12] J.-F. I. &. S. Marwa Harzi, «Using the hybrid ILS/VND method for solving the patients scheduling problem in emergency department: A case study,» Procedia Computer Science, 2018. [13] B. H. N. P. D. &. W. J. L. Easter, «Designing efficient emergency departments: Discrete event simulation of internal-waiting areas and split flow sorting,» American Journal of Emergency Medicine, 2019. [14] V. A. Maya, «https://aguinagasimulacion.wordpress.com/,» 2016. [En línea]. Available: https://aguinagasimulacion.wordpress.com/2016/09/06/componentes-y-etapas-de-la-simulacion/. [15] Autor anónimo, «Trabajo de Fin de Grado,» de Sistemas con Logística de Retorno: Aplicación al caso de contenedores retornables, 2017. 66 67 8 ANEXO Informe generado por Arena Software al simular el escenario base 74