Aplicación de la simulación de eventos discretos en el sector sanitario. Construcción de un gemelo digital para el proceso de extracciones de laboratorio

Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Menci´ on en Computaci´ on Aplicaci´ on de la simulaci´ on de eventos discretos en el sector sanitario. Construcci´ on de un gemelo digital para el proceso de extracciones de laboratorio Autor: D. Christian Berruezo Fern´andez Tutor: D. Pablo Federico S´anchez Mayoral 2 A mi familia y en especial a mi padre, all´ı donde est´es, siempre ser´as mi ´angel de la guarda. 1 2 Agradecimientos Mis primeras palabras no pueden ser sino de agradecimiento y compromiso. A D. Diego Vecillas Mart´ın, mi tutor del Hospital Universitario R´ıo Hortega (HURH) por haber confiado en m´ı en todo momento para la realizaci´on de proyectos conjuntos, adem´as, por su inestimable ayuda, confianza y ense˜nanza, sin las cuales hubiera sido imposible la realizaci´on de este trabajo. Ante todas las dificultades que se han presentado en todo este tiempo, siempre ha estado dispuesto a dedicarme su tiempo y su conocimiento. Su importante aporte y participaci´on ha facilitado las cosas para que este trabajo llegue a un feliz t´ermino. Este trabajo es parte tuya. Me faltar´ıan d´ıas en mi vida para mostrarle todo mi agradecimiento. Quisiera agradecer tambi´en a varias personas la ayuda que me han prestado en la realizaci´on de este Trabajo de Fin de Grado. Entre ellas, y en primer lugar, a mis profesores, por todo lo que me han ense˜nado y lo que me han transmitido durante estos a˜nos. Gracias a todo el personal que he conocido en el HURH, sobre todo, al personal del Servicio de Extracciones. Gratamente agradecidos con Nuria Tirador, Carmen Pe˜nalosa y Mar´ıa Antonia Fern´andez. En este momento est´an en mi recuerdo las personas que me han animado y apoyado durante todo este tiempo. A ellos muchas gracias. 1 2 Resumen Hoy en d´ıa el sector sanitario es uno de los m´as grandes y con mayor crecimiento del mundo. La innovaci´on es constante y las pol´ıticas de gesti´on de pacientes est´an en el punto de mira. En los pr´oximos a˜nos se incrementar´a notablemente la automatizaci´on de diversos procesos que requerir´an de la estad´ıstica y de la inform´atica para su ´optimo desarrollo. Este Trabajo de Fin de Grado se centra en la simulaci´on de eventos discretos en el sector sanitario. La necesidad de estudiar con antelaci´on qu´e aparece en la literatura, es clave para la gesti´on de los servicios hospitalarios. Estos modelos de simulaci´on supusieron grandes avances en el sector industrial y ha sido recientemente cuando se han empezado a aplicar al sector sanitario. Posteriormente, se presentar´a un nuevo caso de estudio desarrollado para el Hospital Universitario R´ıo Hortega de Valladolid. Este caso de estudio consistir´a en el desarrollo de la construcci´on de un gemelo digital mediante la simulaci´on de eventos discretos del Servicio de Extracciones de este hospital. El desarrollo del gemelo digital as´ı como los gr´aficos se han realizado con el software FlexSim y R. Palabras clave Simulaci´on de eventos discretos, FlexSim, Optimizaci´on, Proceso hospitalario, Flujo de pacientes, Servicio de extracciones, R 3 4 Abstract Nowadays, healthcare sector is one of the largest and most promising in the world. Innovation is constant and patient management policies are the focus in the present. In the next few years, the automation of various processes will be increased significantly and will require of statisticians and computer engineers for their optimal development. This bachelor’s thesis focuses on discrete event simulation (DES) in the health sector. We are going to develop a systematic review to collect everything that appears in the literature about DES applied in the healthcare services. These simulation models made great advances in the industrial sector and recently they have begun to be applied to the health sector. A new case study is develop, a digital twin of the Collection Service of the Hospital Universitario R´ıo Hortega (Valladolid) is built applying DES. FlexSim was used to build the digital twin and the R software to create the graphs. Keywords Discrete event simulation (DES), FlexSim, Optimization, Health care, Patient flow, Blood collecting service, R 5 5.2. Plano de planta del servicio de extracciones . . . . . . . . . . . . . . . . . . . . . 67 5.3. Flujograma del paciente en el servicio de extracciones con esperas . . . . . . . . . 73 5.4. Flujograma completo en FlexSim . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.5. Flujograma en FlexSim - Parte I . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.6. Flujograma en FlexSim - Parte II . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.7. Flujograma en FlexSim - Parte com´un . . . . . . . . . . . . . . . . . . . . . . . . 79 5.8. Flujograma en FlexSim - extracciones (Tipo 1) . . . . . . . . . . . . . . . . . . . 81 5.9. Flujograma en FlexSim - extracciones (Tipo 2) . . . . . . . . . . . . . . . . . . . 83 5.10. Flujograma en FlexSim - Muestras (Tipo 3) . . . . . . . . . . . . . . . . . . . . . 84 5.11. Flujograma en FlexSim - Abandono del Servicio de Extracciones . . . . . . . . . 84 6.1. Plano del Servicio de Extracciones en 3D (puertas, paredes y ventanas) . . . . . 86 6.2. Plano de planta del Servicio de Extracciones en 3D (vista TOP) . . . . . . . . . 86 6.3. Plano del Servicio de Extracciones en 3D . . . . . . . . . . . . . . . . . . . . . . 87 6.4. Plano del Servicio de Extracciones en 3D (vista TOP) . . . . . . . . . . . . . . . 88 6.5. Mapa de calor del plano de planta (inicio) . . . . . . . . . . . . . . . . . . . . . . 91 6.6. Mapa de calor del plano de planta (media ma˜nana) . . . . . . . . . . . . . . . . . 92 6.7. Dashboardpersonal .................................. 93 6.8. Dashboardpacientes.................................. 95 6.9. Diagrama de caja (BoxPlot) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 6.10. Experimenter (OptQuest) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 B.1. Ventana inicial FlexSim) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 B.2.LicenciaFlexSim .................................... 113 B.3. Instalar licencia FlexSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 B.4. Devolver licencia FlexSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 B.5. Actualizar licencia FlexSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 B.6. Detalle instalaci´on FlexSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 B.7.AvisoFlexSim ..................................... 116 B.8.Actualizaci´onFlexSim ................................. 116 B.9. Barra de herramientas FlexSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 12 B.10.Entorno HealthCare FlexSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 B.11.NuevomodeloFlexSim................................. 118 B.12.RunTime........................................ 118 B.13.A˜nadir un plano al modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 B.14.Visualparedes ..................................... 120 B.15.Propiedades de paredes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 B.16.Visualizaci´on del plano en el modelo . . . . . . . . . . . . . . . . . . . . . . . . . 121 B.17.Visualizaci´on del plano en el modelo (vista TOP) . . . . . . . . . . . . . . . . . . 121 B.18.A* Navigation - panel de opciones . . . . . . . . . . . . . . . . . . . . . . . . . . 122 B.19.A*Navigation ..................................... 123 B.20.A* Navigator properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 B.21.Recursos de tipo localizaci´on (Location) . . . . . . . . . . . . . . . . . . . . . . . 124 B.22.Recursos de tipo personal (Staff) . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 B.23.Recursos Multilocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 B.24.A˜nadirgrupos...................................... 126 B.25.Toolbox ......................................... 126 B.26.Propiedades de los grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 B.27.PatientFlows...................................... 127 B.28.HCActivitySets.................................... 128 B.29.HCResources...................................... 128 B.30.Properties........................................ 129 B.31.A˜nadir un Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 B.32.Library ......................................... 130 B.33.Otrosrecursos...................................... 130 B.34.Flujogramazona .................................... 131 B.35.Propiedadeszona.................................... 131 B.36.EnterZone ....................................... 132 B.37.WaitforEvent ..................................... 132 B.38.ExitZone ........................................ 133 13 B.39.A˜nadir estad´ısticas a dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 B.40.Pinestad´ısticas..................................... 134 B.41.A˜nadirundashboard.................................. 135 B.42.ParametersTable.................................... 135 B.43.ModelInput....................................... 136 B.44.Tiposdegr´aficas .................................... 136 B.45.Estad´ısticaspeople................................... 137 B.46.Variasestad´ısticas ................................... 137 B.47.Estad´ısticasStaff.................................... 138 B.48.Ejemplo dashboard staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 B.49.Opciones del dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 B.50.Propiedades del dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 14 Lista de Tablas 2.1. Riesgo 01 - P´erdida de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2. Riesgo 02 - Recursos computacionales insuficientes . . . . . . . . . . . . . . . . . 23 2.3. Riesgo 03 - Aver´ıa del ordenador . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.4. Riesgo 04 - P´erdida de licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.5. Riesgo 05 - P´erdida de acceso a internet . . . . . . . . . . . . . . . . . . . . . . . 24 2.6. Riesgo06-Enfermedad ................................ 25 2.7. Riesgo 07 - Complejidad elevada de las tareas . . . . . . . . . . . . . . . . . . . . 25 2.8. Riesgo 08 - Retrasos excesivos en la planificaci´on . . . . . . . . . . . . . . . . . . 25 2.9. Riesgo 09 - Insuficientes art´ıculos relacionados con el tema de estudio en la revisi´on sistem´atica ....................................... 26 2.10. Riesgo 10 - Insuficientes datos para la elaboraci´on del gemelo digital . . . . . . . 26 2.11. Matriz de impacto-probabilidad de riesgos antes de aplicar acciones de reducci´on y/omitigaci´on ..................................... 27 2.12. Matriz de impacto-probabilidad de riesgos despu´es de aplicar acciones de reducci´on y/omitigaci´on ..................................... 27 2.13.Listadetareas ..................................... 28 2.14. C´alculo de tiempos h´abiles en el proyecto . . . . . . . . . . . . . . . . . . . . . . 30 2.15.Remuneraci´onpersonal................................. 30 2.16. C´alculo del coste y amortizaci´on del equipo inform´atico . . . . . . . . . . . . . . 31 2.17. C´alculo del coste del material consumible . . . . . . . . . . . . . . . . . . . . . . 32 2.18. C´alculo de costes indirectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.19. C´alculo de las horas dedicadas por el personal . . . . . . . . . . . . . . . . . . . . 32 2.20. C´alculo del coste asociado a la fase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 33 15 2.21. C´alculo del coste asociado a la fase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.22. C´alculo del coste asociado a la fase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.23. C´alculo del coste asociado a la fase 5 . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.24. C´alculo del coste asociado a la fase 6 . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.25. C´alculo del coste y tiempo total del proyecto con personal del Sacyl . . . . . . . 36 2.26. C´alculo del coste y tiempo total del proyecto sin personal del Sacyl . . . . . . . . 37 3.1. Estrategia de b´usqueda en las bases de datos . . . . . . . . . . . . . . . . . . . . 48 3.2. Distribuci´on de las publicaciones por pa´ıses . . . . . . . . . . . . . . . . . . . . . 50 3.3. Distribuci´on de las publicaciones por tipos . . . . . . . . . . . . . . . . . . . . . . 51 3.4. Distribuci´on del software utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . 56 16 Cap´ıtulo 1 Introducci´on 1.1. Contexto El sector sanitario es uno de los m´as grandes y con mayor crecimiento del mundo [ 1 ]. Llevar a cabo una pol´ıtica de gesti´on de pacientes no es sencillo, m´as a´un cuando un hospital se enfrenta a la variabilidad de los recursos disponibles en cada momento as´ı como a mantener un equilibrio entre la demanda y la capacidad. En la Figura 1.1 se analiza la evoluci´on del n´umero de pacientes en lista de espera estructural en el Sistema Nacional de Salud (SNS) a nivel nacional desde el a˜no 2006 as´ı como el tiempo medio de espera en la Figura 1.2. Los datos se han obtenido en [ 2 ]. Se observa un elevado incremento de las listas de espera desde el a˜no 2010 y del tiempo medio de espera en los dos ´ultimos a˜nos. La primera parte de este trabajo de investigaci´on consiste en la realizaci´on de una revisi´on sistem´atica de la literatura (RSL) sobre los eventos discretos aplicados en el sector sanitario, los datos se obtuvieron de las bases de datos PubMed, Scopus y WOS ya que la mayor´ıa de los art´ıculos relevantes en nuestro ´area de investigaci´on se encuentran disponibles en ellas. Para poder realizar esta revisi´on de la literatura se han seguido una serie de pasos que son importantes para conseguir que la revisi´on sea eficiente y est´e completa. La segunda fase de este trabajo est´a enfocada a realizar un gemelo digital del Servicio de Extracciones perteneciente al Hospital Universitario R´ıo Hortega (HURH) [ 3 ] a trav´es de t´ecnicas de simulaci´on de eventos discretos. Realizar cambios en el ´ambito sanitario sin antes haber hecho alg´un estudio que demuestre su mejora hace que el paciente sea el principal perjudicado. En esta fase se cuenta con datos reales de dicho servicio. Para poder llevar a cabo este TFG, se han necesitado varios meses en los que se ha tenido que aprender a manejar el software de simulaci´on de eventos discretos FlexSim [ 4 ], que hace uso del lenguaje de programaci´on C++. Se ha acudido al hospital para realizar un estudio del servicio hospitalario con el fin de que el gemelo digital fuera similar a la realidad del servicio. 17 0e+00 2e+05 4e+05 6e+05 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 Año Pacientes Fuente: Sistema de Información de listas de espera del SNS (SISLE-SNS) RD 605/2003 Evolución del número de pacientes en lista de espera estructural Figura 1.1: Evoluci´on del n´umero de pacientes en lista de espera 0 50 100 150 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 Año Tiempo medio de espera (días) Fuente: Sistema de Información de listas de espera del SNS (SISLE-SNS) RD 605/2003 Evolución del tiempo medio del paciente en lista de espera estructural Figura 1.2: Evoluci´on de la demora 18 El objetivo es analizar dicho proceso en la actualidad, estudiar la viabilidad y en el futuro dise˜nar varios escenarios de este servicio. En este TFG no se valida el modelo programado ni se dise˜nan varios escenarios. Habr´ıa que hacerlo para poder experimentar y obtener conclusiones v´alidas del servicio pero es una tarea que requiere de tiempo y est´a fuera del alcance en este proyecto. Una vez que en el futuro se valide el modelo, la nueva informaci´on obtenida con los modelos de simulaci´on nos permitir´a gestionar y analizar datos sobre la gesti´on y optimizaci´on de forma que se demuestre que las predicciones de los modelos obtenidos que definen este proceso hospitalario tienen relevancia en la vida real como la mejora de costes, mejora de tiempos, etc. 1.2. Motivaci´on personal Antes de empezar a estudiar el doble Grado en Ingenier´ıa Inform´atica y Estad´ıstica ya ten´ıa un cierto inter´es por el sector sanitario. A medida que fui avanzando de cursos e investigando por mi cuenta fue cuando me di cuenta del potencial que tienen la inform´atica y la estad´ıstica en el sector sanitario. A diario se almacenan cantidades ingentes de datos para su futuro uso, sin embargo, muchas veces se quedan almacenados pero no tratados. Uno de los objetivos del Big Data es transformar los datos para convertirlos en informaci´on ´util que nos ayude a mejorar el sistema sanitario en beneficio de todos. Al mismo tiempo que cursaba mis estudios, tambi´en realizaba voluntariado en Cruz Roja Espa˜nola en el ´area de las Emergencias y la Log´ıstica, donde he tocado muchos puestos diferentes y he podido conocer como funcionaba en el resto de Espa˜na, como en Madrid, Valladolid, Soria y Pamplona. Realic´e las pr´acticas de empresa en el Hospital Universitario R´ıo Hortega con mi tutor D. Diego Vecillas Mart´ın, qui´en me introdujo en el ´ambito sanitario explic´andome su funcionamiento, objetivos a tratar y las posibilidades de trabajar juntos en proyectos para optimizar la asistencia m´edica. 1.3. Objetivos A continuaci´on, se exponen los objetivos de este Trabajo de Fin de Grado: 1. Realizar una revisi´on sistem´atica de la literatura sobre la aplicaci´on de la simulaci´on de eventos discretos al sector sanitario. 2. Entender los conceptos principales de un evento discreto y un gemelo digital. 3. Construcci´on de un gemelo digital del Servicio de Extracciones perteneciente al Hospital Universitario R´ıo Hortega con datos reales. 19 1.4. Alcance Este proyecto consta de varias partes, en primer lugar, la revisi´on sistem´atica tiene como objetivo conocer que aparece en la literatura sobre la simulaci´on de eventos discretos en el sector sanitario. Esta revisi´on nos permitir´a concluir el uso que se est´a dando a este tipo de modelado en el presente, la relevancia que conlleva y los servicios m´edicos en los que est´e implicado. A continuaci´on, se deber´an comprender los conceptos de los eventos discretos as´ı como el comportamiento del personal del Servicio de Extracciones del HURH y de su flujo de pacientes. Este servicio ser´a modelado mediante un gemelo digital con el software de simulaci´on FlexSim. 1.5. Estructura de la memoria Esta memoria sigue la estructura especificada en la gu´ıa docente para la asignatura TFG del Grado de Ingenier´ıa Inform´atica de la Universidad de Valladolid [5]. Siguiendo al presente cap´ıtulo de introducci´on, donde se expone el contexto, la motivaci´on y los objetivos de este trabajo, se encuentran los siguientes cap´ıtulos: Cap´ıtulo 2. Plan de proyecto : en este cap´ıtulo se expone la metodolog´ıa seguida en la realizaci´on del proyecto as´ı como la planificaci´on del mismo. Cap´ıtulo 3. Revisi´on sistem´atica de la literatura : en este cap´ıtulo se realiza un an´alisis y comparaci´on de los documentos publicados sobre la simulaci´on de eventos discretos en el sector sanitario en las bases de datos PubMed, Scopus y WOS. Cap´ıtulo 4. Simulaci´on de eventos discretos : en este cap´ıtulo se describen los eventos discretos y la metodolog´ıa de la simulaci´on. Cap´ıtulo 5. Caso de estudio : 1 en este cap´ıtulo se describe con detalle el Servicio de Extracciones del HURH, los objetivos, an´alisis de datos, as´ı como el modelo conceptual y su programaci´on. Cap´ıtulo 6. Construcci´on del modelo en FlexSim : 1 en este cap´ıtulo se realiza la construcci´on del gemelo digital del Servicio de Extracciones en FlexSim. Cap´ıtulo 7. Conclusiones y trabajo futuro : en este cap´ıtulo se exponen las conclusiones obtenidas con la realizaci´on de este proyecto as´ı como posibles formas de mejora o trabajo futuro. Por ´ultimo, se puede encontrar la bibliograf´ıa y los ap´endices de este proyecto. 1Las estad´ısticas que aparecen no se corresponden con la realidad del servicio. 20 Cap´ıtulo 2 Plan de proyecto 2.1. Metodolog´ıa Este proyecto implica una carga de trabajo elevada. Supone, adem´as, la construcci´on de un gemelo digital mediante simulaci´on de eventos discretos para el proceso de las extracciones de laboratorio, por lo que al no resultar familiar en el campo de estudio del alumno, ser´a inevitablemente necesario contar con ayuda hospitalaria y explorar diferentes documentos publicados sobre los eventos discretos en el sector sanitario. Las metodolog´ıas tradicionales son adecuados para proyectos grandes en los que se parte de unos requisitos del sistema bien definidos como es este caso y se desea evitar volver a trabajar en tareas que ya se han dado por finalizadas. De esta manera, para este proyecto se ha decidido seguir una adaptaci´on del cl´asico modelo en cascada propio de la Ingenier´ıa del Software [ 6 , 7 ]. La adaptaci´on se puede ver en la Figura 2.1 y nos sirve para llevar a cabo el desarrollo de la construcci´on de un gemelo digital del Servicio de Extracciones mediante la simulaci´on de eventos discretos. Este modelo impone al proyecto una estructura, consiste en una secuencia de actividades que va desde obtener los requisitos pudiendo hacer previamente un estudio de viabilidad hasta el despliegue. Una vez que la actividad est´e completada, debe darse de paso y se avanza a la siguiente etapa. Es posible que una etapa posterior pueda revelar la necesidad de una modificaci´on en una etapa anterior pero se debe tratar como una excepci´on ya que no es deseable volver atr´as en el tiempo ya que se tienen unas fechas determinadas. Es indispensable validar el proyecto antes de poder experimentar con ´el, si bien, una vez validado la experimentaci´on concluye que no es representativa de la realidad, se puede volver tantas fases atr´as como sean necesarias para su correcto desarrollo. Se realizar´an reuniones peri´odicas con los tutores, D. Pablo Federico S´anchez Mayoral y D. Diego Vecillas Mart´ın, para comprobar el progreso del proyecto y acordar las siguientes tareas a desarrollar. 21 ID Descripci´on Estimado Real 2 Gesti´on de riesgos: identificar los riesgos, analizar los riesgos y desarrollar planes de protecci´on y contingencia para reducir su exposici´on. 4 h 2 h 15 min 3 Plan de trabajo: identificar las tareas a realizar, estimar su esfuerzo en horas y realizar una planificaci´on temporal de las mismas. 15 h 12 h 20 min 4 Estudio econ´omico. 7 h 6 h - Revisi´on sistem´atica de la literatura 146 h 152 h 50 min 5 Familiarizaci´on con las bases de datos. 6 h 4 h 6 Metodolog´ıa. 10 h 8 h 20 min 7Obtenci´on y clasificaci´on de los art´ıculos. 100 h 105 h 8 Extracci´on de conclusiones. 30 h 35 h 30 min -Obtenci´on de datos del Servicio de Extracciones 15 h 13 h 15 min 9Limpieza y adaptaci´on de la BBDD para evaluar el proceso de las extracciones. 8 h 7 h 10 Creaci´on del diagrama de flujo 2 h 1 h 30 min 11 Redacci´on del proceso seguido. 5 h 4 h 45 min - Eventos discretos. 16 h 15 h 30 min 12 Recopilaci´on de informaci´on sobre los gemelos digitales y su descripci´on. 8 h 8 h 15 min 13 Metodolog´ıa 8 h 7 h 15 min - Caso de estudio 24 h 18 h 45 min 14 Servicio de Extracciones en el HURH 4 h 3 h 30 min 15 Modelo conceptual 4 h 3 h 16 Programaci´on flujogramas en FlexSim 16 h 12 h 15 min - Construcci´on del modelo en FlexSim 90 h 89 h 55 min 17 Construcci´on del 3D 30 h 27 h 20 min 18 Piscinas de recursos 8 h 6 h 19 Programaci´on de pacientes 40 h 45 h 20 min 20 V´ıas cl´ınicas 10 h 9 h 15 min 21 Estad´ısticas y experimentador 3 h 2 h - Otros 30 h 28 h 10 min 22 Redacci´on del manual 15 h 14 h 10 min 23 Elaboraci´on de la presentaci´on de la defensa 15 h 14 h Total 355 h 342 h Tabla 2.13: Lista de tareas 28 2.3.3. Calendario Las 355 horas estimadas del proyecto se han repartido empezando el proyecto el d´ıa 22 de febrero de 2021 y finalizando el 7 de julio de 2021. En la Figura 2.2 se muestra el diagrama de Gantt del proyecto. Figura 2.2: Diagrama de Gantt 2.4. Estudio de costes Este estudio de costes tiene como objetivo mostrar una evaluaci´on aproximada de los costes necesarios y la influencia de cada una de las partes consideradas en el desarrollo del trabajo de fin de grado. Para su valoraci´on, se tienen en cuenta los costes asociados al personal necesario, materiales, amortizaciones de los equipos inform´aticos y servicios indirectos del proyecto. 2.4.1. Horas efectivas y tasas horarias del personal En esta secci´on se muestran las horas y las semanas laborables efectivas de cada uno de los profesionales que han participan en la realizaci´on de este proyecto. El objetivo es mostrar la valoraci´on de los costes asociados a los profesionales en base a la duraci´on de este TFG desarrollado en las etapas de la Tabla 2.14 29 Concepto Valor D´ıa inicio per´ıodo 22/02/2021 D´ıa fin de per´ıodo 07/07/2021 Per´ıodo (d´ıas) 135 S´abados y Domingos 38 D´ıas festivos Valladolid 5 D´ıas de vacaciones 8 D´ıas media baja m´edica 8 D´ıas Cursos Formativos 9 Total d´ıas h´abiles 67 Total horas efectivas 335 Total semanas h´abiles 9,6 Tabla 2.14: C´alculo de tiempos h´abiles en el proyecto Los salarios de los profesionales se han establecido seg´un los salarios seg´un las retribuciones percibidas por el personal del Sacyl en 2021 [8]. A partir de los sueldos medios asociados a cada uno de ellos en un per´ıodo de 5 meses y de las horas efectivas trabajadas, se calculan las tasas de cada empleado por hora y por semana en la Tabla 2.15. En el proyecto se cuenta con un director del proyecto, un supervisor de enfermer´ıa responsable de verificar los modelos de simulaci´on, un enfermero que debe ense˜nar el proceso del Servicio de Extracciones y resolver las dudas pertinentes, un auxiliar administrativo correspondiente al personal de recepci´on del Servicio de Extracciones cuya labor es explicar su trabajo y resolver dudas al ingeniero; de forma similar el TCAE. El ingeniero deber´a, aprender el proceso, simularlo virtualmente y generar la documentaci´on pertinente. Concepto Director Enfermero (Supervisor) Enfermero Auxiliar administrativo TCAE Ingeniero inform´atico Sueldo bruto (€/mes) 4415.30 2376.98 2065.51 1338.66 1330.12 2704.69 Total anual 59 553.50 32 138.82 27 756.58 18 215.88 18 122.82 36 014.54 Seguridad Social (35 %) 20 843.73 11 248.59 9714.8 6375.56 6342.99 12 605.09 Coste (€/hora) 34.62 18.69 15.85 10.59 10.54 20.94 Coste (€/semana) 1145.26 618.05 533.78 350.31 348.52 692.59 Coste total proyecto 20 576.5 11 884.9 10 327.55 6693.3 6650.6 13 523.45 Tabla 2.15: Remuneraci´on personal El coste horario se obtiene al dividir el total anual entre el n´umero de horas efectivas reales de trabajo. A partir del 1 de enero de 2021 se establece una jornada anual de 1.720 horas efectivas reales de trabajo [9]. El coste total del proyecto ha sido calculado para el periodo de 5 meses de duraci´on. 30 2.4.2. Amortizaciones del equipo inform´atico En la Tabla 2.16 se detallan los costes asociados a los equipos inform´aticos, software y hardware. Se consideran un periodo de amortizaci´on de 5 a˜nos, con una cuota lineal y valor residual nulo; por lo que los costes totales se reparten de forma equitativa entre los 5 a˜nos del periodo correspondiente. En este proyecto, la amortizaci´on de los equipos es proporcional a los 5 meses de duraci´on respecto al total de 1 a˜no. Hardware Concepto Coste (€) Cantidad Coste total (€) MacBook Pro de 16 pulgadas Intel Core i9, 2.3 GHz, 64 GB RAM 3601.59 1 3601.59 Monitor BenQ GW2280 21.5” 96 1 96 Soporte monitor 26.99 1 26.99 Teclado Razer Ornata Chroma 79.99 1 79.99 Adaptador Ofima USB C 8 en 1 49.99 1 49.99 Rat´on ergon´omico 12 1 12 Impresora HP OfficeJet 6950 99 1 99 Software Concepto Coste (€) Cantidad Coste total (€) FlexSim 16 500 1 16 500 Microsoft 365 69 1 69 R 0 1 0 Python 0 1 0 Overleaf 0 1 0 Total a amortizar 20 534.56 Tipo Periodo Amortizaci´on (€) Anual 5 a˜nos 4106.91 Semanal 394.9 78.89 Diaria 11.25 2.25 Horaria 7.03 1.4 Tabla 2.16: C´alculo del coste y amortizaci´on del equipo inform´atico 2.4.3. Coste del material consumible En este apartado se calcula el coste de los materiales consumibles por persona utilizados en el desarrollo del proyecto y hora de trabajo. 31 Concepto Coste (€) Papel impresora 75 Suministros impresora 210 Otros 40 Coste anual total por persona 325 Coste horario por persona 0.19 Tabla 2.17: C´alculo del coste del material consumible 2.4.4. Costes indirectos En la Tabla 2.18 se detallan los costes indirectos del proyecto. Estos costes son los asociados a los consumos de servicios b´asicos tales como la electricidad, el tel´efono, agua, etc. Se muestran las tasas de coste calculadas por trabajador en valor anual, horario y de duraci´on del proyecto para cada uno de estos conceptos. Concepto Coste (€) Tel´efono e internet 115 Electricidad 50 Otros 300 Coste anual total por persona 465 Coste horario por persona 0.27 Coste proyecto por persona 193.755 Tabla 2.18: C´alculo de costes indirectos 2.4.5. Tiempos asociados a cada fase del proyecto En la Tabla 2.19 se muestran los tiempos asociados a cada fase del proyecto por cada uno de los empleados descritos en la Tabla 2.15 Personal Fase 1 Fase 2 Fase 3 Fase 4 Fase 5 Fase 6 Director 15 10 0 24 5 0 Enfermero (Supervisor) 0 0 0 0 1 0 Enfermero 0 0 0 0 5 0 Aux. Administrativo 0 0 0 0 2 0 TCAE 0 0 0 0 2 0 Ing. Inform´atico 0 30 100 40 55 130 Tabla 2.19: C´alculo de las horas dedicadas por el personal 32 2.4.6. Costes asignados a las fases del proyecto A continuaci´on, se desglosa el gasto total del proyecto por cada fase. Se tienen en cuenta las horas que cada persona destina a cada parte del proyecto as´ı como el salario y los costes estimados del material. 1. Necesidad encontrada En la etapa inicial interviene el director cuya labor es encontrar la necesidad de la realizaci´on del proyecto para su justificaci´on. Debe organizar los recursos y contar con la colaboraci´on del servicio implicado que interviene en este proyecto. El tiempo dedicado por empleado se detalla en la Tabla 2.19, los costes de esta fase en la Tabla 2.20. Concepto Horas Coste (€/hora) Coste total (€) Personal Director 15 34.62 519.3 Enfermero (Supervisor) 0 18.69 0 Enfermero 0 15.85 0 Aux. Administrativo 0 10.59 0 TCAE 0 10.54 0 Ing. Inform´atico 0 20.94 0 Amortizaci´on Equipo inform´atico 25 1.4 35 Material consumible Varios 2 0.19 0.38 Costes indirectos Varios 16 0.27 4.32 Coste total fase 1 559 Tabla 2.20: C´alculo del coste asociado a la fase 1 2. Recopilaci´on de informaci´on La fase de recogida de informaci´on es necesaria tanto para el director como para el ingeniero inform´atico. La comunicaci´on entre ambos es esencial para que el proyecto se realice de forma satisfactoria y que se cumplan los objetivos resolviendo, el director, las dudas planteadas. 33 Concepto Horas Coste (€/hora) Coste total (€) Personal Director 10 34.62 346.2 Enfermero (Supervisor) 0 18.69 0 Enfermero 0 15.85 0 Aux. Administrativo 0 10.59 0 TCAE 0 10.54 0 Ing. Inform´atico 30 20.94 628.2 Amortizaci´on Equipo inform´atico 60 1.4 84 Material consumible Varios 8 0.19 1.52 Costes indirectos Varios 73 0.27 19.71 Coste total fase 2 1079.63 Tabla 2.21: C´alculo del coste asociado a la fase 2 3. Revisi´on sistem´atica No se detalla el coste de una revisi´on sistem´atica, se trata de un trabajo acad´emico impropio de una consultora empresarial. 4. Formaci´on FlexSim En esta fase tanto el director como el ingeniero inform´atico reciben formaci´on acerca del software que se va a desarrollar para la construcci´on del modelo. Concepto Horas Coste (€/hora) Coste total (€) Personal Director 24 34.62 830.88 Enfermero (Supervisor) 0 18.69 0 Enfermero 0 15.85 0 Aux. Administrativo 0 10.59 0 TCAE 0 10.54 0 Ing. Inform´atico 40 20.94 837.6 Amortizaci´on Equipo inform´atico 72 1.4 100.8 Material consumible Varios 15 0.19 2.85 Costes indirectos Varios 70 0.27 18.9 Coste total fase 4 1791.07 Tabla 2.22: C´alculo del coste asociado a la fase 4 34 5. Desarrollo del modelo La principal fase del presente proyecto, el desarrollo del modelo, requiere de la participaci´on de todos los empleados considerados ya que estos ser´an los responsables de que el modelo se desarrolle de forma satisfactoria aportando todo su conocimiento sobre el servicio. Es desarrollado enteramente por el ingeniero inform´atico, que requiere la colaboraci´on del resto de empleados de la organizaci´on para despejar dudas con el objeto de que el modelo se ajuste a la realidad. Concepto Horas Coste (€/hora) Coste total (€) Personal Director 5 34.62 173.1 Enfermero (Supervisor) 1 18.69 18.69 Enfermero 5 15.85 79.25 Aux. Administrativo 2 10.59 21.18 TCAE 2 10.54 21.08 Ing. Inform´atico 55 20.94 1151.7 Amortizaci´on Equipo inform´atico 70 1.4 98 Material consumible Varios 15 0.19 0.95 Costes indirectos Varios 80 0.27 21.6 Coste total fase 5 1585.99 Tabla 2.23: C´alculo del coste asociado a la fase 5 6. Elaboraci´on de la documentaci´on En esta etapa se desarrolla toda la documentaci´on relativa al trabajo realizado. Una vez escrita, se enviar´a para su revisi´on y aprobaci´on. Esta tarea es responsable del director. Concepto Horas Coste (€/hora) Coste total (€) Personal Director 0 34.62 0 Enfermero (Supervisor) 0 18.69 0 Enfermero 0 15.85 0 Aux. Administrativo 0 10.59 0 TCAE 0 10.54 0 Ing. Inform´atico 130 20.94 2722.2 Amortizaci´on Equipo inform´atico 180 1.4 252 Material consumible Varios 50 0.19 9.5 Costes indirectos Varios 190 0.27 51.3 Coste total fase 6 3035 Tabla 2.24: C´alculo del coste asociado a la fase 6 35 2.4.7. Coste total del proyecto incluyendo al personal del Sacyl En la Tabla 2.25 se muestra el coste total del proyecto. Este coste consiste en la suma de los costes de cada una de las fases que componen el proyecto. Se detalla adem´as el tiempo total requerido por el personal para su realizaci´on. 1 Fase Horas Coste (€) Fase 1 15 559 Fase 2 40 1079.63 Fase 4 64 1791.07 Fase 5 70 1585.99 Fase 6 130 3035 Total 319 8050.69 Tabla 2.25: C´alculo del coste y tiempo total del proyecto con personal del Sacyl Se ha calculado el coste para 319 horas de trabajo que llevan las fases 1, 2, 4, 5 y 6. No se calcula el precio de la fase 3 (revisi´on sistem´atica) al resultar un trabajo acad´emico impropio de la consultor´ıa empresarial. La mayor parte del tiempo del proyecto se requiere en la recopilaci´on de la informaci´on, formaci´on y desarrollo. Sin el correcto desarrollo de estas etapas, es improbable que el modelo adquiera una validez real. El desarrollo de la documentaci´on es elevada. La documentaci´on debe ser lo suficientemente detallada como para que cualquier usuario que no conozca el ´ambito de estudio del proyecto, sea capaz de entenderlo y seguirlo sin un elevado esfuerzo. En la Subsecci´on 2.4.8 se calcula el coste sin contabilizar los empleados del Sacyl. No habr´a mucha diferencia respecto al coste de incluirlos visto en la Tabla 2.25 pero, en las siguientes tareas de validaci´on y experimentaci´on del modelo construido, previsiblemente conllevar´a un coste elevado debido a que es tarea esencial de dicho personal. 1 A estos costes habr´ıa que aplicarlos el Margen Comercial y los Impuestos Indirectos (IVA, recargo de equivalencia, etc.) para calcular el precio a cobrar en un hipot´etico cliente. 36 2.4.8. Coste total del proyecto no incluyendo al personal del Sacyl Dado que el personal del Sacyl forma parte de los costes asumidos por ellos, podemos obtener un presupuesto m´as realista. En este caso ´unicamente se contabilizan los puestos del director, ingeniero y auxiliar administrativo. Los costes se muestran en la Tabla 2.26 se muestra el coste total del proyecto. 2 Fase Horas Coste (€) Fase 1 15 559 Fase 2 40 1079.63 Fase 4 64 1791.07 Fase 5 62 1466.68 Fase 6 130 3035 Total 311 7931.38 Tabla 2.26: C´alculo del coste y tiempo total del proyecto sin personal del Sacyl Se ha calculado el coste para 311 horas de trabajo que llevan las fases 1, 2, 4, 5 y 6. En este caso tampoco se calcula el precio de la fase 3 (revisi´on sistem´atica) al resultar un trabajo acad´emico impropio de la consultor´ıa empresarial. 2 A estos costes habr´ıa que aplicarlos el Margen Comercial y los Impuestos Indirectos (IVA, recargo de equivalencia, etc.) para calcular el precio a cobrar en un hipot´etico cliente. 37 0 5000 10000 15000 1985 1990 1995 2000 2005 2010 2015 2020 Año RSL publicadas Fuente: PubMed Evolución del número de metaanálisis publicados en PubMed Figura 3.4: Evoluci´on del n´umero de metaan´alisis publicados en PubMed El volumen creciente de publicaciones cient´ıficas, la dispersi´on de las mismas, la calidad, las dificultades de acceso, la disponibilidad, barreras idiom´aticas, la necesidad de estar actualizado y la falta de tiempo entre otras causas, justifican la necesidad de publicar documentos que resuman toda la informaci´on disponible de un mismo tema. Estos art´ıculos son las llamadas revisiones sistem´aticas de la literatura y tratan de cubrir esa necesidad para facilitar el acceso a trav´es de un estudio a gran cantidad de informaci´on sintetizada al investigador. Es necesario que estas revisiones sean de calidad y sigan una serie de especificaciones para que la presentaci´on de los resultados se expresen de forma clara y concisa para que lleguen a ser ´utiles, ya que estos art´ıculos servir´an para la toma de decisiones. En el a˜no 1999 se public´o la declaraci´on QUOROM (QUality Of Reporting Of Meta-analysis) [ 17 ], consiste en un diagrama de flujo y una lista de comprobaci´on (tambi´en llamada checklist) con 18 ´ıtems que se deb´ıan tener en cuenta a la hora de publicar los metaan´alisis de los ensayos cl´ınicos en las revistas m´edicas. El objetivo era establecer unas normas haciendo ´enfasis en la s´ıntesis estad´ıstica para mejorar la presentaci´on de los resultados de los ensayos cl´ınicos animando a los autores a proporcionar toda aquella informaci´on necesaria para interpretar y utilizar adecuadamente los resultados obtenidos. Una RSL no es sin´onimo de calidad, podemos encontr´arnoslas buenas y mejorables. Se deben tener en cuenta las limitaciones a las que se hacen frente como la calidad de las publicaciones, 44 la informaci´on disponible, la val´ıa del investigador, as´ı como las discrepancias entre los ensayos cl´ınicos [18]. QUOROM no logr´o una gran aceptaci´on entre los investigadores a pesar de que el n´umero de RSL que se publican anualmente es muy elevado como se puede ver en la Figura 3.5. Un estudio del 2010 estim´o que a diario se publicaban once RSL [ 19 ] mientras que hoy en d´ıa estamos entorno a ochenta y siete. 0 10000 20000 30000 1967 1972 1977 1982 1987 1992 1997 2002 2007 2012 2017 2020 Año RSL publicadas Fuente: PubMed Evolución del número revisiones sistemáticas de la literatura publicadas en PubMed Figura 3.5: Evoluci´on del n´umero revisiones sistem´aticas de la literatura publicadas en PubMed En 2009 naci´o la declaraci´on PRISMA (Preferred Reporting Items for Systematic reviews and Meta-Analyses) [ 20 ](Preferred Reporting Items for Systematic reviews and Meta-Analyses) fruto de la evoluci´on y ampliaci´on de QUOROM, no limit´andose ´unicamente a los meta-an´alisis sanitarios, sino que tambi´en es ´util para cualquier otro tipo de estudio. PRISMA cuenta con 27 ´ıtems [ 21 ] y un diagrama de flujo [ 22 ]. Esta declaraci´on recibi´o un gran apoyo por parte de revistas biom´edicas de alto impacto e instituciones de prestigio como (Cochrane). En 2013 la Revista Espa˜nola de Salud P´ublica tambi´en adopt´o PRISMA en sus normas de publicaci´on [ 23 ]. A continuaci´on, vamos a mostrar el diagrama de flujo PRISMA a nuestro proyecto, este diagrama describe el flujo de informaci´on a trav´es de las diferentes fases que se llevan a cabo en la revisi´on sistem´atica de la literatura. Muestra el n´umero de registros identificados, incluidos y excluidos, as´ı como las razones de las exclusiones. (Para mejorar la comprensi´on, el uso y 45 la difusi´on de la declaraci´on PRISMA se puede consultar la siguiente referencia, en la que se encontrar´a un documento con ejemplos y explicaciones en los que se presenta el significado y la justificaci´on de cada elemento de la lista de verificaci´on). 46 PRISMA 2020 Diagrama de flujo 2291 registros identificados en las b´usquedas en las BBDD 0 registros adicionales identificados en otras fuentes N´umero de registros tras eliminar duplicados (n = 1380) N´umero total de registros cribados (n = 1380) Publicaciones a recuperar (n = 649) Publicaciones analizadas para su elegibilidad (n = 510) Estudios incluidos en la revisi´on (n = 248) Informes de estudios incluidos (n = 492) Registros eliminados basados en el t´ıtulo y abstract (n = 731) Art´ıculos no recuperados (n = 139) N´umero total de art´ıculos de texto completo excluidos (n = 18) Razones: • No sanitario • No se aplican eventos discretos • Datos insuficientes Identificaci´onCribadoInclusi´on Figura 3.6: Diagrama de flujo PRISMA de la informaci´on a trav´es de las diferentes fases de una revisi´on sistem´atica de la literatura 47 3.2. Fuentes de informaci´on y estrategia de b´usqueda En esta Secci´on se muestran los criterios de b´usqueda de los art´ıculos analizados. BBDD Fecha de b´usqueda Consultas Publicaciones PubMed 17 de marzo de 2021 “discrete-event simulation”[tiab] AND (“health care”[tiab] OR “hospital*”[tiab]) 210 Scopus 17 de marzo de 2021 TITLE-ABS-KEY ((“discrete-event simulation”) AND (hospital* OR (“health care”))) AND PUBYEAR > 2009 AND PUBYEAR < 2021 AND (LIMIT-TO (LANGUAGE, “English”)) 997 WOS 17 de marzo de 2021 (discrete-event simulation) AND (hospital* OR “health care”) 1.084 Tabla 3.1: Estrategia de b´usqueda en las bases de datos 3.3. Resultados En este capitulo no se pretende dar una recomendaci´on general sobre los modelos a utilizar, muchos documentos no s´olo utilizan los eventos discretos sino que tambi´en hacen uso de la din´amica de sistemas (SD) y/o de la simulaci´on basada en agentes (ABS). AnyLogic es el primer programa que contiene los tres. Sin embargo no ha sido el prop´osito principal de este trabajo, como s´ı lo es en otras revisiones sistem´aticas. A lo largo de estas secciones se mostrar´an las estad´ısticas 1de los art´ıculos. La gran mayor´ıa de los casos de estudio se centraron en una unidad hospitalaria mientras que en otros se pretend´ıa realizar un modelo gen´erico para el hospital. Las opiniones de los diversos investigadores var´ıan sobre la viabilidad de la reutilizaci´on de modelos ya implementados [ 24 ], pero es dif´ıcil imaginar que mil centros de atenci´on primaria necesiten mil modelos de simulaci´on diferentes. Se ha mencionado atenci´on primaria pero es v´alido cualquier servicio m´edico. La Figura 3.6 se muestra el diagrama de flujo PRISMA con los registros identificados y las razones de su exclusi´on. Se identificaron 2291 registros de los cuales 210 pertenec´ıan a PubMed, 997 a Scopus y 1084 a WOS. Despu´es de eliminar 911 duplicados, se revisaron 1380 de los cuales se eliminaron 731 en base al t´ıtulo y abstract. De los 649 art´ıculos que cumpl´ıan los criterios para estudiarlos m´as a fondo, 139 fueron eliminados tras no estar disponibles. Los 510 restantes fueron descargados y le´ıdos, 18 fueron excluidos por no tratarse de un art´ıculo sanitario, no se 1 Solo se mostrar´an una parte de las estad´ısticas de los art´ıculos analizados porque los resultados formar´an parte de una publicaci´on de mayor impacto. No se detalla m´as porque es una investigaci´on en curso de gran relevancia. 48 aplicaban los eventos discretos o los datos eran insuficientes. Finalmente nos hemos quedado con 492 art´ıculos que cumplen los criterios de inclusi´on de los cuales 230 eran casos de estudio. En el Ap´endice C se distinguen los casos de estudio con el resto de art´ıculos. Entre los 492 art´ıculos analizados, 216 (42 %) se llevaron a cabo en Europa, 206 (40 %) en Am´erica del Norte, 6 (1 %) en Am´erica del Sur, 63 (12 %) en Asia, 22 (4 %) en Ocean´ıa y 6 (1 %) en ´ Africa. Es posible que la suma no coincida con los art´ıculos totales. Esto se debe a que varias publicaciones fueron realizadas por varios autores en distintos pa´ıses y se han contabilizado todos los pa´ıses part´ıcipes en las publicaciones. En la Figura 3.7 se muestran los 10 pa´ıses con mayor n´umero de publicaciones. En concordancia con el art´ıculo [ 25 ], se aprecia una gran variedad de pa´ıses aunque la mayor´ıa de las publicaciones proced´ıan de Estados Unidos y de Reino Unido. En la Tabla 3.2 se puede apreciar de forma m´as detallada las estad´ısticas de todos los pa´ıses. 153 85 37 26 20 18 16 14 12 10 China Alemania Francia España Australia Países Bajos Italia Canada GB EEUU 0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 Número de publicaciones País Figura 3.7: Top 10 pa´ıses con mayores publicaciones 49 Pa´ıs N´umero de art´ıculos ( %) EEUU 153 (29.5) GB 85 (16.4) Canada 37 (7.1) Italia 26 (5.0) Pa´ıses Bajos 20 (3.9) Australia 18 (3.5) Espa˜na 16 (3.1) Francia 14 (2.7) Alemania 12 (2.3) China 10 (1.9) Brasil 9 (1.7) Colombia 9 (1.7) Suecia 9 (1.7) Singapur 8 (1.5) Turqu´ıa 7 (1.3) Austria 5 (1.0) B´elgica 5 (1.0) Ir´an 5 (1.0) Irlanda 5 (1.0) Jordania 5 (1.0) Emiratos ´ Arabes Unidos 4 (0.8) Hong Kong 4 (0.8) India 4 (0.8) Jap´on 4 (0.8) Malasia 4 (0.8) Nueva Zelanda 4 (0.8) Noruega 4 (0.8) Polonia 4 (0.8) Rusia 3 (0.6) Egipto 2 (0.4) Grecia 2 (0.4) Suiza 2 (0.4) Taiw´an 2 (0.4) Camer´un 1 (0.2) Chile 1 (0.2) Costa Rica 1 (0.2) Dinamarca 1 (0.2) Finlandia 1 (0.2) Indonesia 1 (0.2) L´ıbano 1 (0.2) M´exico 1 (0.2) Marruecos 1 (0.2) Om´an 1 (0.2) Pakist´an 1 (0.2) Palestina 1 (0.2) Portugal 1 (0.2) Puerto Rico 1 (0.2) Serbia 1 (0.2) Sud´africa 1 (0.2) Corea del sur 1 (0.2) T´unez 1 (0.2) Tabla 3.2: Distribuci´on de las publicaciones por pa´ıses 50 En la Figura 3.8 se puede apreciar que, en general, el n´umero de publicaciones han ido aumentando en el tiempo de forma m´as o menos similar para los tipo caso de estudio, investigaci´on aplicada, te´orico-conceptual. Las revisiones sistem´aticas tambi´en aumentan pero de forma m´as paulatina ya que estas abarcan un gran numero de art´ıculos mientras que los libros y las encuestas (survey) parecen estancarse. En la Tabla 3.3 se pueden apreciar las estad´ısticas por tipo de publicaciones. 0 50 100 150 200 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 Año Número de publicaciones Tipo de artículo Investigación aplicada Caso de estudio Libro Revisión sistemática Survey Teórico-conceptual Publicaciones acumuladas de la literatura sanitaria en la que se emplean eventos discretos por tipo de artículo Figura 3.8: Publicaciones acumuladas por tipo de art´ıculo (N = 492) Tipo de publicaci´on N´umero de art´ıculos ( %) Investigaci´on aplicada 100 (29.5) Caso de estudio 229 (16.4) Libro 11 (7.1) Revisi´on sistem´atica 33 (5.0) Te´orico-conceptual 110 (3.9) Survey 9 (3.5) Tabla 3.3: Distribuci´on de las publicaciones por tipos Se ha analizado la coocurrencia entre los t´ıtulos y los abstract. La coocurrencia nos permite detectar y agrupar aquellos conceptos que est´an ´ıntimamente relacionados en un conjunto de publicaciones o registros. La idea b´asica es que podemos llegar a encontrar conceptos que 51 aparezcan juntos en varias publicaciones, esto muestra que existe una relaci´on subyacente que posiblemente sea de gran relevancia. En nuestro caso analizar la coocurrencia nos puede servir para realimentar una nueva b´usqueda sistem´atica. Se realiz´o una b´usqueda con las consultas especificadas en la Secci´on 3.2 y se puede refinar con nuevas palabras clave fruto de la coocurrencia. Esta estrategia es muy v´alida y puede generar buenos resultados cuando se eval´ua sobre varios centenares de publicaciones. Cuanto mayor es la frecuencia de aparici´on dos conceptos juntos en un conjunto de registros y menor es su aparici´on de forma separada en el resto de registros, mayor es la coocurrencia. Por ejemplo, si muchas publicaciones contienen las palabras “coche” y “contaminaci´on”, estos conceptos se pueden agrupar en una regla de coocurrencia, (coche & contaminaci´on). En otro ejemplo, si los conceptos “jam´on serrano”, “tomate” y “aceite” aparecen m´as a menudo agrupados que separados, se agrupar´an en una regla de coocurrencia de conceptos, (jam´on serrano & tomate & bocadillo). Las palabras “discrete event simulation”, “model”, “patient”, “health care” y “time” son las que m´as frecuentemente presentan un mayor grado de pares coocurrentes con 465, 349, 306, 240 y 235 ocurrencias respectivamente lo que nos sugiere que han recibido una cierta relevancia en la literatura. Si pretendemos refinar a´un m´as la literatura debemos acudir a las palabras que contienen una gran relevancia y a trav´es de sus pares concurrentes obtendremos las palabras m´as relevantes en base a esa especificaci´on y podremos usarlas como palabras clave. En el mapa de la Figura 3.9 podemos ver la estructura de la red de coocurrencia y se muestran los cl´usters (n´ucleos) obtenidos en diferentes colores, en ellos aparece la palabra m´as relevante y las relacionadas. Ha sido desarrollado mediante VOSviewer [ 26 ] y se ha precisado de la realizaci´on de un fichero que contiene un diccionario de palabras similares para evitar que palabras como “health care” y “healthcare” figuren de forma separada cuando el significado es el mismo o; “des”, “discrete event simulation” y “discrete-event” entre otras. El tama˜no del nodo representa la frecuencia de las palabras, as´ı pues “discrete event simulation” ocupa la posici´on central y es la de mayor tama˜no. El grosor de la l´ınea es proporcional a lo ligada que est´a la conexi´on entre las dos palabras, la distancia entre dos palabras en la visualizaci´on nos indica como de relacionadas se encuentran en t´erminos de coocurrencia. Las palabras “health care”, “cost” y “study” est´an muy pr´oximas a “discrete event simulation”. VOSviewer presta m´as atenci´on a un a similaridades indirectas por medio de una tercera palabra [ 27 ]. Por ejemplo en nuestro caso, la palabra “patient” coocurre con muchas otras palabras como “time”, “data”, “procedure”, “volume”, “reduction”, “rate”. Por lo tanto, la localizaci´on de una palabra depende del n´umero de otras palabras con las que tengan una coocurrencia o similaridad positiva. Cuanto m´as alta sea la similaridad indirecta por medio de una tercera palabra, m´as cerca estar´an esas palabras entre ellas. Puede darse el caso de que ciertas palabras que tenga una peque˜na asociaci´on en realidad sean ´utiles pero apenas aparecen debido a las restricciones de la editorial o revista sobre el n´umero y la elecci´on de palabras clave de los autores. 52 Se ofrece otra forma de visualizaci´on de las relaciones de las palabras en forma de mapa de calor en la Figura 3.10. Con esta gr´afica se aprecia la densidad de una forma m´as sencilla, va desde el color azul, que representa una baja densidad pasando por el color verde, que representa una densidad media y por ´ultimo el color rojo, que representa una densidad alta. Cuanto mayor sea el n´umero de t´erminos alrededor de un nodo y mayor sea la frecuencia de esos t´erminos, el punto se aproximar´a al color rojo. Por el contrario, cuantos menos t´erminos haya alrededor de un punto y menor sea la frecuencia de los t´erminos, el punto tirar´a a un color azulado. Figura 3.9: Red de coocurrencia entre las palabras del t´ıtulo y abstract de los 492 art´ıculos analizados Los mapas de densidad muestran las palabras m´as relevantes y la estructura de la red. Se aprecia como en las zonas amarillas hay menos palabras que en las zonas verdes lo que es un indicador de que hay un menor n´umero de palabras b´asicas relevantes y muchas otras tienden a ser inmaduras o vagas. Se muestran muy bien en la Figura 3.10 los cinco campos o palabras bien distintas de las que habl´abamos en un principio: ”discrete event simulation”, ”model”, ”patient”, ”health care” y ”time”. 53 60 Cap´ıtulo 4 Simulaci´on de eventos discretos 4.1. Introducci´on Por m´ultiples razones, la simulaci´on ha sido ampliamente difundida e implementada en el sector sanitario. A pesar de que la metodolog´ıa dominante es la simulaci´on de eventos discretos, numerosos proyectos han implementado la din´amica de sistemas, la simulaci´on basa en agentes y m´etodos h´ıbridos o combinados. El software se ha ido adaptando incrementalmente al sector sanitario permitiendo unos mejores modelos, visualizaciones m´as realistas y herramientas de desarrollo m´as intuitivas. La simulaci´on en este sector se ha implementado en servicios m´edicos muy diferentes como ve´ıamos anteriormente en la Figura 3.12, incluso en otros servicios que afecten de forma directa o indirecta a estos como puede ser la cocina, lavander´ıa, limpieza, etc. Los problemas frecuentes a los que se enfrenta el sector sanitario son a los flujos de pacientes, escasez de personal, horarios, falta de recursos, etc. La reorganizaci´on en la cadena log´ıstica es crucial para los servicios m´edicos si se pretenden tener optimizados en el presente. El sistema sanitario es muy complejo debido a que las personas atienden las necesidades m´edicas de otras personas. Es muy importante que los servicios proyecten una imagen positiva, trabajen bien en equipo, as´ı como cuidar otros aspectos para evitar que a otras partes del sistema aparentemente no relacionadas se filtren interacciones no deseadas. 4.2. Simulaci´on de eventos discretos En los ´ultimos 50 a˜nos los hospitales han hecho frente al gran incremento de demandas para ofrecer tratamientos de calidad minimizando los costes e incrementando la satisfacci´on de los pacientes [29, 30]. La simulaci´on de eventos discretos consiste en una t´ecnica de simulaci´on que sirve para analizar un proceso de un servicio para contestar preguntas o resolver problemas. Este tipo de 61 simulaci´on es din´amica, se tiene en cuenta la progresi´on del sistema con el tiempo frente a los sistemas est´aticos que son una foto fija. Se usa para modelar sistemas que cambian de estado en instantes concretos como resultado de eventos espec´ıficos. Es una herramienta que permite modelar de forma estoc´astica , podemos tener en cuenta que no tenemos la certeza completa de lo que estamos observando y eso lo plasmamos en el modelo. Esto es muy ´util para manejar diferentes niveles de abstracci´on con lo que estamos modelando, no es necesario hacer el m´ınimo detalle de todo lo que queremos modelar si no podemos seguir las propiedades estad´ısticas de lo que estamos modelando (p. ej., si estamos modelando una intervenci´on quir´urgica, podr´ıamos entretenernos en modelar todos los movimientos del cirujano teniendo en cuenta que nos interesa el tiempo que tarda en operar, nos deber´ıamos fijar en demasiados detalles como el tipo de intervenci´on que se est´a realizando, la gravedad del paciente, complicaciones del paciente durante la intervenci´on, la destreza del cirujano, tambi´en podr´ıamos hacer unas ecuaciones que modelaran como va cortando el cirujano al paciente, si se equivoca o no se equivoca o, podr´ıamos hacer una distribuci´on de probabilidad que representara el hist´orico de lo que m´as tardan las intervenciones y ya con eso tendr´ıamos esa parte resuelta del modelo). Lo que se pretende con la simulaci´on es centrarnos en los aspectos fundamentales y otros aspectos dejarlos modelados de forma estad´ıstica y avanzar de forma m´as sencilla en el modelo, el modelo debe contener ´unicamente aquellos elementos de la realidad necesarios para contestar la pregunta o resolver el problema. Cuando tenemos un manejo del tiempo discreto, no nos quedamos con todos los instantes del tiempo sino que hacemos un peque˜no muestreo y solo nos quedamos con los eventos m´as importantes (p. ej., nos interesa modelar el movimiento de cambiarnos de una silla a otra. Lo ´unico que nos importa con los eventos discretos es que primero estamos sentados en la silla A y dentro de 3 segundos estamos sentados en la silla B, eso es lo que vamos a modelar, primer evento estar en la silla A, siguiente evento llegada a la silla B). Es decir, la simulaci´on de eventos discretos se usa para modelar sistemas que cambian de estado en unos instantes concretos como resultado de la ocurrencia de eventos espec´ıficos. Otra caracter´ıstica de los eventos discretos es que permiten interacciones entre los elementos , podemos modelar de forma natural como interaccionan los actores que participan en el sistema ya se a trav´es de una competencia por recursos por ejemplo o simplemente que las acciones de un elemento afectan a otro. La simulaci´on de eventos discretos ha sido ampliamente utilizada para la planificaci´on y simulaci´on de servicios hospitalarios (servicio de urgencias, citaciones, etc) como se ha visto en el Cap´ıtulo 3. En el sector sanitario, este tipo de simulaci´on se puede centrar en mejorar gestionar la capacidad de camas, horarios de los trabajadores, admisi´on de pacientes y programaci´on de citas, utilizaci´on de recursos auxiliares (farmacia, laboratorios, etc) as´ı como rastrear a los pacientes e incorporar todo tipo de caracter´ısticas como su historial m´edico o el riesgo basal. Tambi´en nos 62 permite modelar los flujos de pacientes y tiempos de espera con lo cual podemos hacer previsiones a corto, medio o largo plazo. Los pacientes interact´uan con el modelo y pueden experimentar eventos en cualquier momento discreto. A mayores, la simulaci´on de eventos discretos (DES) proporciona la flexibilidad de incorporar recursos o capacidades expl´ıcitamente y tener en cuenta las interdependencias entre pacientes debido a los recursos o capacidades limitadas. La DES por tanto nos sirve como herramienta basada en la evidencia que con la informaci´on obtenida a trav´es de la simulaci´on, permite al personal responsable del hospital evaluar la eficiencia de los servicios m´edicos existentes y reconfigurar los protocolos de atenci´on a pacientes para mejorar la eficiencia del sistema sin alterar al sistema actual. En este proyecto se desarrolla la simulaci´on de eventos discretos del proceso de extracciones de sangre del Hospital Universitario R´ıo Hortega. 4.3. Metodolog´ıa de la simulaci´on El desarrollo de la simulaci´on sigue una metodolog´ıa Step Wise. Este tipo de metodolog´ıa trata de responder a la pregunta: ¿Qu´e hago ahora?. Es muy ´util tanto para peque˜nos como para grandes proyectos. Seguir los pasos que se describen a continuaci´on de esta metodolog´ıa que se describen a continuaci´on, son fundamentales para el correcto desarrollo del modelo de simulaci´on. [31] 1)Establecer los objetivos: el primer paso del proceso del desarrollo de la simulaci´on es determinar los objetivos que se buscan. Podemos centrarnos en buscar todos los objetivos posibles y detallarlos al m´aximo pero en la simulaci´on de eventos discretos lo m´as recomendable es centrarnos en no m´as de dos o tres objetivos. De este modo la b´usqueda ser´a m´as espec´ıfica, se reducir´a la complejidad del modelo y ser´a viable en t´erminos de recursos y tiempo. Los objetivos de la simulaci´on de eventos discretos que se buscan en este trabajo se especifican en el Cap´ıtulo 5 en la Secci´on 5.2. 2)Recogida de datos: esta fase es muy importante para poder desarrollar el modelo correctamente. Durante esta fase de recopilaci´on de datos e informaci´on del servicio que se vaya a modelar debe ser lo suficientemente detallada para poder cumplir con los objetivos. No se debe caer en la sobreespecificaci´on o en recoger m´as datos de los necesarios ya que puede ser muy costoso en t´erminos de esfuerzo, de tiempo del proyecto y en t´erminos de privacidad (ver m´as en la Secci´on 5.3.1 del Cap´ıtulo 5). Tampoco se debe caer en la subespecificaci´on, la informaci´on debe poder describir de forma similar a la realidad el proceso, si no se tiene la informaci´on necesaria no podremos modelar correctamente. Una visi´on m´as detallada de los datos de nuestro proyecto se ofrecen en la Secci´on 5.3 del 63 Cap´ıtulo 5. Los datos deben ser procesados y depurados antes de poder utilizarlos en la simulaci´on, es una tarea ardua que requiere gran cantidad de tiempo pero imprescindible para la buena consecuci´on de los objetivos. 3)Construcci´on del modelo: el desarrollo del modelo de simulaci´on de eventos discretos involucra procesar todos los datos recopilados e integrarlos en el modelo. Para ello es necesario primero tener el modelo conceptual del proceso a simular y que debe mapear y describir el flujo del proceso. Se puede ver en la Secci´on 5.4 del Cap´ıtulo 5. 4)Verificaci´on y validaci´on: este paso involucra toda la confirmaci´on necesaria para poder verificar que todo lo desarrollado se ha realizado de la forma correcta. En nuestro proyecto contamos con el personal del servicio de extracciones, el cual se encargar´a de verificar en un futuro que el modelo desarrollado representa la realidad. Validar el modelo implica que este se ajuste a los flujos de pacientes y del personal. As´ı como los tiempos. Los tiempos iniciales deben ser de las distribuciones que ajusten nuestros datos o, en su debida medida, utilizar una distribuci´on m´as gen´erica de flujos de pacientes. 5)Ensayos: ¿Qu´e pasar´ıa si...? Esa es la pregunta a la que debemos responder en esta fase. Un modelo de simulaci´on debe probar diferentes escenarios para determinar los efectos que provocan las diferencias de estos en el proceso modelado. Una vez que el modelo se ha validado, es posible crear diferentes escenarios de diversos modos, reestructurando las localizaciones, modificando los tiempos de atenci´on al paciente, aforo de la sala de espera, etc. 6)Recopilaci´on de datos del modelo: las estad´ısticas finales obtenidas del modelo de simulaci´on, una vez analizadas, ser´an labor de estudio del personal responsable para tomar decisiones de optimizaci´on del servicio en base a la viabilidad de los escenarios modelados. 64 Cap´ıtulo 5 Caso de estudio 5.1. Proceso de extracciones Esta secci´on no hubiera sido posible sin la colaboraci´on de Mar´ıa Antonia y Nuria Tirador, ambas trabajadoras de este servicio y que nos han explicado detalladamente el funcionamiento del mismo. El servicio de extracciones del HURH opera de lunes a viernes excepto festivos, con un horario general de 8:00 a 15:00 dependiendo del box. La mayor´ıa de los pacientes tienen una visi´on muy sesgada de lo que consiste el proceso de extracciones, solo saben que les van a extraer sangre o a recoger una muestra pero es aqu´ı donde empieza el proceso y que terminar´a cuando el m´edico reciba los an´alisis del paciente. Este proceso puede variar desde unos minutos a varias semanas o incluso meses, dependiendo de la urgencia y del tipo del an´alisis efectuado al paciente. Una vez que se obtiene la extracci´on del paciente, es trabajo de los profesionales del laboratorio llevar a cabo los an´alisis, fundamentales para el diagn´ostico, pron´ostico y seguimiento de las enfermedades. Este proceso es muy extenso y complejo en funci´on del tipo de an´alisis que se ha de llevar a cabo y no es de nuestro inter´es en nuestro estudio. En nuestro proyecto ´unicamente nos centraremos la simulaci´on del proceso de extracci´on de sangre al paciente sin entrar en modelar la fase posterior que es el an´alisis de las muestras. Este servicio se realiza enteramente en la segunda planta del HURH y consta de las siguientes secciones: Kiosko: el paciente introduce su historia cl´ınica en el kiosko y recibe un ticket con un identificador de la cita. Recepci´on A - B: el paciente entrega el volante al personal, se escanea y se registra el procedimiento a realizar al paciente, en ese momento el paciente queda en espera a que se le llame desde box o muestras (dependiendo de la prueba). El paciente debe esperar en la sala de espera hasta que sea mostrado en las pantallas su identificador de la cita. Kiosko 2: refuerzo de recepci´on. 65 Muestras: el paciente entrega las muestras (orina, heces, semen, etc). BOX 1: box de extracci´on de sangre de refuerzo. BOX 2: box de extracci´on de sangre que opera de 8:00 a 15:00. BOX 3: box de extracci´on de sangre que opera de 8:00 a 11:30. BOX 4: box de extracci´on de sangre que opera de 8:00 a 14:00. BOX 5: box de extracci´on de sangre que opera de 8:00 a 10:30. BOX 6: box de extracci´on de sangre de menores de edad de 8:00 a 10:15. En las ´epocas en las que coinciden grandes festivos como Semana Santa, Navidad se aprecia un gran descenso en este servicio, el motivo es que este servicio ´unicamente trabaja los d´ıas h´abiles. Sin embargo, a la vuelta de las festividades se produce un gran incremento coincidiendo normalmente con el lunes o martes siguiente. En verano tambi´en se aprecia un gran descenso del servicio de las extracciones. Este descenso comienza en junio y se acent´ua notablemente en agosto. Se debe a que los pacientes normalmente durante estos meses abandonan su lugar de residencia habitual y los m´edicos se encuentran de vacaciones por lo que las consultas se reducen y eso conlleva directamente una reducci´on del n´umero de citaciones en las extracciones. A la vuelta del verano, se aprecia un gran incremento de las extracciones sobre todo en el mes de septiembre, en el cual no pasa desapercibido el incremento de m´as de 2000 pacientes con respecto al mes de agosto, como se puede ver en el gr´afico derecho de la Figura 5.1 el cual, es el mismo gr´afico que el de su izquierda pero ampliado para que se visualice el flujo de pacientes. En la Figura 5.2 podemos ver el plano de este proceso. 66 0 500 1000 1500 2000 2500 mar. may. jul. sep. nov. ene. Mes Número de citaciones 1800 2000 2200 2400 mar. may. jul. sep. nov. ene. Mes Número de citaciones Evolución del número de citaciones entre febrero de 2019 y 2020 Figura 5.1: Evoluci´on del n´umero de citaciones en el servicio de extracciones comprendidas en el periodo entre febrero de 2019 y febrero de 2020 SALA DE ESPERA BOX 1 BOX 2 BOX 3 BOX 4 BOX 5BOX 6 MUESTRAS RECEPCIÓN ASEO PUBLICO LAB ASEO SECRETARIA LIMPIEZA CAMILLAS EXTRACCIONES ESPECIALES Figura 5.2: Plano de planta del servicio de extracciones 67 5.2. Objetivos El primer objetivo del proyecto es comprender en su totalidad el funcionamiento del servicio de extracciones del HURH. Para ello ha sido necesario acudir en varias ocasiones a este servicio de modo que se pudiera observar la variabilidad entre d´ıas y distintas franjas horarias. La simulaci´on llevada a cabo nos permitir´a corregir las posibles deficiencias del servicio. No todos los fallos son atribuibles al personal, m´as bien, el personal siempre intenta hacer su trabajo lo mejor posible. Donde se pueden detectar fallos es en el protocolo de atenci´on, en el sistema inform´atico provocando una larga espera o incluso que el servicio no est´e construido de la forma m´as ´optima. Nuestro objetivo principal es simular la realidad para virtualmente detectar las ineficiencias que por cualquier raz´on en el servicio en el d´ıa a d´ıa no se aprecia la causa de los mismos. 5.3. An´alisis de datos Contamos con los datos reales recogidos de los pacientes a los que se les realiz´o una extracci´on de sangre entre el 1 de febrero de 2019 hasta el 1 de febrero de 2020. En ese periodo de tiempo se han realizado un total de 29 891 extracciones, con una actividad diaria aproximada de 121 pacientes. Este servicio da cobertura al ´area de Salud de Valladolid Oeste que cuenta con una poblaci´on de referencia de m´as de 250 000 usuarios [ 32 ]. El servicio de extracciones realiza las peticiones anal´ıticas tanto de Atenci´on Especializada como de Primaria, ya que cualquier especialidad m´edica es susceptible de ser solicitante de pruebas diagn´osticas. Contamos con 900 820 instancias y 10 atributos: Turno: identificador de la cita. Historia cl´ınica: identificador de la historia cl´ınica del paciente. D´ıa de la cita. Hora de la cita. Origen: puesto de origen del paciente. Destino: puesto de destino del paciente. Hora de presencia en origen: hora en la que el paciente llega al servicio de extracciones. Hora de llamada en destino: hora en el que el paciente es llamado para realizarse toma de la muestra. Hora de atenci´on en destino: hora en la que se realiza la toma de la muestra al paciente. Tipo de cita (normal o expr´es): prioridad de la cita. Se ha llevado a cabo un profundo filtrado y depuraci´on de los datos originales. Es una de las primeras fases del preprocesado de los datos de entrada y se pretende eliminar las redundancias, inconsistencias, ruido, identificar outliers o valores extremos, valores desconocidos, etc. 68 Varias instancias de los datos con los que contamos presentan valores desconocidos para algunos atributos. Los atributos que presentan instancias desconocidas son los relativos al destino, las horas de presencia en origen, de llamada en destino y de atenci´on en destino. Se pueden llevar a cabo varias aproximaciones para dar un valor a estos datos desconocidos entre las que destacan: Uso de constante global: si existen muchos valores ausentes y estos no se encuentran distribuidos de manera uniforme, se pude utilizar un valor unknown para predecir la clase. Uso de la media, mediana y moda del atributo: esto es mejor realizarlo por clases. Uso del valor m´as probable: J48 y pr´acticamente todos los m´etodos de ´arboles de decisi´on incorporan un procedimiento para tratar la presencia de valores desconocidos creando un ´arbol con probabilidades. Esto asume una suposici´on que no siempre se cumple (el hecho de que un valor de un atributo sea desconocido es independiente de la clase). En muchas aplicaciones esto no es cierto y hay valores que son ausentes porque alguien no ha querido proporcionar el valor para una determinada clase. Este tipo de aproximaciones modifican el conjunto de datos por lo que debemos de ser precavidos. Lo mejor es eliminar las instancias para las que hay valores ausentes, el resto de opciones siempre ser´an malas. Eliminar el ruido (es una modificaci´on de la se˜nal original, no deseada y que la corrompe) de los datos depende de como vayamos a utilizar despu´es el clasificador. En cuanto al ruido de los atributos, puede ser mejor dejarlo. Si el clasificador va a ser utilizado en un entorno en el que hay ruido, es mejor no eliminarlo. Si por el contrario el clasificador se va a utilizar en un entorno en el que se puede eliminar el ruido, entonces es mejor eliminarlo. El ruido en la clase puede ser sistem´atico (aparece por la propia naturaleza del medidor), el cual es mejor dejarlo o, puede ser asistem´atico (aparece por una mala manipulaci´on de los datos), el cual es mejor eliminarlo. Nos encontramos con outliers o valores extremos de pacientes que pueden perjudicar a la simulaci´on. Por ejemplo, pacientes que hayan tardado m´as de 20 minutos en Muestras. Una forma sencilla de darnos cuenta de que son outliers es usar ´unicamente datos que se queden con el 95 % de la poblaci´on omitiendo el 2.5 % superior e inferior. Una vez que se haya procedido a la depuraci´on de los datos, se deben procesar m´as detalladamente antes de llevarlos a cabo en la simulaci´on. Es importante destacar que la recopilaci´on de datos, depuraci´on, procesado de la base de datos as´ı como la obtenci´on de distribuciones estad´ısticas una vez validado el modelo, abarca la mayor parte del tiempo del desarrollo de la simulaci´on. La validaci´on y la obtenci´on de las distribuciones estad´ısticas del modelo no est´a en el alcance de este TFG. 69 Figura 5.5: Flujograma en FlexSim - Parte I 76 Figura 5.6: Flujograma en FlexSim - Parte II 77 5.5. Programaci´on del flujograma En esta Secci´on se va a explicar de forma detallada la programaci´on de cada tipo de paciente realizada. Todos los pacientes tienen una parte com´un, esta parte es la que se muestra en la Figura 5.7. 5.5.1. Espera kiosko Este bloque modela el proceso que sigue un paciente para adquirir el n´umero de cita. Al inicio, hay una bandera negra en la que pone “Inicio Kiosco”, la bandera significa que es un milestone o token y comienza a contar el tiempo en ese momento. “Esperar” lo que modela es la espera en la cola, el paciente se queda esperando detr´as del paciente inmediatamente anterior a ´el, de forma que no se sit´ua visualmente encima, es un comportamiento para representar la realidad de forma visual. “Adquirir kiosko” modela que el paciente solicita el kiosko, es decir, se pone a la cola, es como coger un turno. Cuando el kiosko se libera, es decir, le toca su turno, debe “Caminar a kiosko”. La obtenci´on del n´umero de la cita lleva un tiempo de “Procesamiento” de unos 20 segundos. El paciente debe liberar el kiosko, por eso se programa “Abandonar kiosko”. “Set prioridad” sirve para establecer una etiqueta de prioridad de la cita de los pacientes en funci´on de si es expr´es o normal en base a unos porcentajes. El milestone o token de Fin Kiosko toma la medici´on de tiempo de ese momento, que es cuando se libera el kiosko y se pasa a la siguiente fase. 5.5.2. Espera recepci´on En este caso se modela la espera de un paciente para registrar su prueba en recepci´on. En el anterior bloque ten´ıamos un milestone que era “Fin kiosko”, este token nos sirve para marcar el fin del anterior bloque y el inicio del actual. El paciente debe esperar a que se le llame para acudir a recepci´on, es por esto por lo que aparece “Adquirir recepcionistas”, porque puede ser llamado por cualquiera de las disponibles. En el caso de que no estuvieran libres, el paciente debe esperar en la sala de espera hasta que se le notifica, por eso la flecha derecha de puntos discontinuos. El paciente debe adquirir la sala de espera (si no hay hueco, “pide” turno para sentarse, cuando un paciente lo libera, se sienta), se dirige a ella “Caminar a sala de espera” y si hay huecos disponibles se sienta. Espera a que el recepcionista se liberen y le llamen, cuando le toca su turno libera la sala de espera “Abandonar sala de espera” y se dirige al mostrador “get ubicaci´on” y “Caminar a recepci´on”. En este caso es necesario modelar esa etiqueta porque el paciente en realidad no adquiere una ubicaci´on, sino que adquiere al personal, por eso es necesario mandarle detr´as del mostrador, para que su comportamiento sea similar a la realidad. “Rotaci´on paciente” es la programaci´on llevada a cabo para que se sit´ue enfrente del mostrador. 78 Figura 5.7: Flujograma en FlexSim - Parte com´un 79 El registro del tipo de prueba lleva un tiempo de administraci´on “Procesamiento”, se ha fijado en 163 segundos. Cuando finaliza, se abandona recepci´on “Liberar recepcionistas”. Se registra el tiempo con el milestone “Registro recepci´on”. Se programan los tipos de pacientes (1, 2 ´o 3) en funci´on de la prueba que van a realizarse, en base a unos porcentajes. 5.5.3. Paciente de Tipo 1 - Extracciones En la Figura 5.8 se muestra el bloque de programaci´on de un paciente que ´unicamente acude a realizarse extracciones. En primer lugar, se establece, mediante unos porcentajes, el n´umero de extracciones que se deben realizar los pacientes. As´ı unos acudir´an ´unicamente a realizarse una ´unica extracci´on mientras que otros, tendr´an una serie de curvas. Extracciones adulto: De forma similar al proceso seguido anteriormente, para adquirir una localizaci´on tiene que, de alguna forma, pedir una especie de ticket, esto se representa con “Adquirir BOX”. Si el BOX est´a ocupado, el paciente vuelve a acudir a la sala de espera “Adquirir sala de espera”, “Caminar a sala de espera”, “Adquirir BOX”. Una vez que es llamado para acudir a BOX, “Adquirir enfermeras” y “Abandonar sala de espera”. Si el paciente fuera llamado directamente al finalizar en recepci´on, no requerir´ıa acudir a la sala de espera por lo que tomar´ıa la primera v´ıa, la de la flecha izquierda no salteada. El paciente se dirige al BOX “Caminar a BOX”, se realiza una medici´on de tiempo “Inicio extracci´on A” que requiere un tiempo de “Procesamiento”, en nuestro caso, establecido en 122 segundos y se resta una extracci´on “extraccionesPorHacer–”, se libera a la enfermera “Liberar enfermeras”, se abandona (libera) el BOX “Abandonar BOX” y se realiza una medici´on de tiempos “Fin extracci´on A”. Se comprueba el n´umero de extracciones que le quedan al paciente por realizar “quedan extraccionesPorHacer?” y, si es igual a 0, contin´ua por la flecha “B” para abandonar el servicio. Curvas: Este bloque es similar al anterior, lo ´unico que var´ıa es que se le a˜nade obligatoriamente un “Tiempo de espera” en funci´on del tipo de prueba. Adem´as, existen ahora dos salas de espera, la de la l´ınea discontinua hace referencia a zona trasera, donde se localizan las camillas y las sillas adicionales. La flecha “A” comprueba otra vez el n´umero de extracciones que le quedan al paciente y si a´un le faltan por hacer, vuelve a repetirse el bloque. As´ı hasta que abandona el servicio por la flecha “B”. 80 Figura 5.8: Flujograma en FlexSim - extracciones (Tipo 1) 81 5.5.4. Paciente de Tipo 2 - Extracciones pedi´atricas En la Figura 5.9 se muestra el bloque de programaci´on de un paciente pedi´atrico que acude a realizarse una extracci´on. Este bloque es similar al paciente de Tipo 1, sin embargo, es el asociado a pediatr´ıa. La ´unica diferencia es que en este caso el paciente acude al BOX 6 (pediatr´ıa) mientras que en el anterior, acude a cualquiera entre el 1 y el 5. 5.5.5. Paciente de Tipo 3 - Muestras En la Figura 5.10 se muestra el bloque de programaci´on gen´erico de un paciente que acude a muestras. Todo aquel paciente que acude al Servicio de Extracciones con una cita que conlleva una muestra, en primer lugar, es llamado por Muestras para entregarla. Posteriormente, el paciente puede que deba realizarse a mayores unas extracciones de sangre. Esto se decide en el “decide”, donde en base a unos porcentajes se decide si el paciente es adulto o pedi´atrico y, luego, se establece en el label de las extracciones por hacer, tambi´en en base a unos porcentajes. Los bloques siguientes son similares a los explicados anteriormente por lo que no se explican. 5.5.6. Abandono del Servicio de Extracciones En la Figura 5.11 se muestra el bloque de programaci´on en el que un paciente abandona el Servicio de Extracciones. Cuando el paciente acaba, se dirige a la salida (que en este caso es la puerta de entrada) “Caminar a la salida”, y se elimina el paciente del visual del programa “Eliminar paciente” y “Sink”. 82 Figura 5.9: Flujograma en FlexSim - extracciones (Tipo 2) 83 Figura 5.10: Flujograma en FlexSim - Muestras (Tipo 3) Figura 5.11: Flujograma en FlexSim - Abandono del Servicio de Extracciones 84 Cap´ıtulo 6 Construcci´on del modelo en FlexSim En este cap´ıtulo se explica de forma resumida el proceso seguido para la construcci´on del modelo del Servicio de Extracciones del Hospital Universitario R´ıo Hortega. El c´odigo desarrollado a partir de las librer´ıas de FlexSim para la construcci´on del gemelo digital, consta en el Ap´endice A. Una explicaci´on m´as detallada de su construcci´on consta en un manual que yo mismo he elaborado de cara a los proyectos que puedan surgir en el futuro. En el Ap´endice B aparece el manual completo. Flexsim es el software de simulaci´on 3D de eventos discretos que se utiliza en el HURH. Este programa nos permite programar (C++), modelar, analizar, visualizar y tomar decisiones para la mejora en base a las estad´ısticas obtenidas de los servicios m´edicos que se programen. Para poder modelar el proceso de este proyecto de forma que se asemeje a la realidad se ha contado con la colaboraci´on del personal del Servicio de Extracciones. 6.1. Construcci´on del 3D En primer lugar, insertamos en FlexSim el plano de planta visto en la Figura 5.2, lo ajustamos a las medidas con las que decidamos trabajar en el modelo y posteriormente levantamos las paredes del Servicio de Extracciones junto a las ventanas, con sus respectivos ajustes visuales. Por ´ultimo se sit´ua al personal, objetos (mesas, sillas, ba˜nos, puertas, etc.). El resultado se muestra en las siguientes figuras: 85 coincide con la realidad, es mera coincidencia. Figura 6.6: Mapa de calor del plano de planta (media ma˜nana) 6.6. Estad´ısticas La representaci´on de las llegadas de los pacientes se puede realizar de dos formas, bien en base a los datos de citaciones y programar las llegadas conforme a las citas o, en base los datos reales obteniendo las distribuciones estad´ısticas subyacentes de los datos de llegada registrados, con los retrasos y adelantos de los pacientes. Las estad´ısticas obtenidas del modelo aportan valor a la simulaci´on, nos permitir´an, en un futuro, estudiar la viabilidad de las mejoras que se puedan incorporar al servicio. Todas las estad´ısticas se obtienen en tiempo real, podemos modificar el ritmo que queremos que tome la simulaci´on, que se adapte al tiempo real, que se adelante o incluso que se ralentice. Las estad´ısticas finales del modelo no forman parte de este TFG por motivos de alcance, sin embargo, se muestran unas estad´ısticas para visualizar los dashboards. Las estad´ısticas que figuran en las siguientes im´agenes no tienen que ver con las reales. Ser´an una tarea futura cuando el modelo haya sido validado. En la Figura 6.7 se muestra el dashboard del personal que atiende en el Servicio de Extracciones. La gr´afica titulada como “Total personal” es una agrupaci´on de los tiempos con su respectivo porcentaje en cada estado de todo el personal. Situando el cursor encima de cada color, nos indica el porcentaje correspondiente a ese estado, en este caso nos muestra que el 72.15 % del 92 Figura 6.7: Dashboard personal 93 tiempo el personal ha estado libre. Difiere mucho de las estad´ısticas reales porque en este modelo a´un no se han podido incorporar las horas de trabajo de cada box como vimos en el Cap´ıtulo Caso de estudio Secci´on 5.1. En este modelo se ha programado que todos los boxes atiendan el mismo tiempo: de 8:00 a 15:00. C´odigo de estados: idle: ocioso. ProvidingCare: atendiendo al paciente. inTransit: en tr´ansito (tiempo o porcentaje desplaz´andose). En la gr´afica nombrada “Grupos personal” se muestran las estad´ısticas agrupadas por grupos, cada grupo contiene los miembros vistos en la piscina de recursos en la Secci´on 6.2 de este mismo cap´ıtulo. Por eso en este caso aunque las enfermeras y la enfermera pedi´atrica quiz´as ser´ıa l´ogico que perteneciesen al mismo grupo, se han programado de forma independiente para obtener las estad´ısticas por separado ya que la labor difiere. La correspondiente a “Enfermeras boxes 1 a 5” muestra las estad´ısticas detalladas del grupo de enfermeras que atienden a los boxes 1 a 5 (es decir, no est´a incluida la enfermera pedi´atrica, que pertenece al box 6). Esta gr´afica se puede obtener para cualquier grupo, podr´ıamos haber obtenido la correspondiente a las recepcionistas (2 miembros). En cuanto al “Porcentaje de utilizaci´on”, se muestra por grupos de personal, el porcentaje de utilizaci´on (ocupaci´on) de los mismos en cada hora. En la Figura 6.8 se muestra el dashboard de los pacientes que acuden al Servicio de Extracciones. Estas estad´ısticas nos sirven tanto para comprender al paciente como para entender las posibles deficiencias del Servicio modelado. En la gr´afica “Tiempo de estancia”, como bien menciona el t´ıtulo, hace referencia al tiempo medio de estancia (en minutos) de un paciente en el servicio de extracciones. Esta estad´ıstica se puede ver penalizada por los pacientes que acuden a realizarse curvas, ya que estas pueden prolongarse hasta 5 horas y no representa el tiempo de atenci´on medio (no de espera). Este problema tambi´en se plantea en la gr´afica del “Tiempo medio en estado” pues un paciente que se realice curvas, debe esperar 1h entre extracciones, por lo que en todo ese tiempo permanecer´a “idle”, es decir, ocioso. Una posible soluci´on a esto se encuentra en separar los tipos de pacientes, donde supuestamente, se espera que un paciente que acude a realizarse una extracci´on o a entregar una muestra, no se prolongue mucho su estancia. La asociada a “Distancia media recorrida” muestra la distancia media recorrida (en metros) en el servicio desde que entra el paciente hasta que abandona el lugar. Esta gr´afica no nos muestra, sin embargo, el tiempo destinado a desplazarse. S´ı lo hace la gr´afica de “Tiempo medio en estado”. 94 Figura 6.8: Dashboard pacientes 95 “Tiempo medio en espera” es un gr´afico box-plot (diagrama de caja) en el que se muestran las medidas de la Figura 6.9. [ 36 ] En este caso el paciente que m´as tiempo ha estado en el servicio ha permanecido en este 165.93 minutos, mientras que el paciente m´as r´apido ha sido de 4.29 minutos. La mediana ha sido de 17.55 minutos. Figura 6.9: Diagrama de caja (BoxPlot) La gr´afica de “Tiempo medio en estado” muestra los porcentajes en funci´on del tiempo consumido en cada estado, siendo estos: inTransit: en desplazamiento. ReceivingDirectCare: recibiendo atenci´on sanitaria. ReceivingIndirectCare: recibiendo atenci´on no sanitaria (recepci´on). idle: ocioso. inLine: en la cola de espera. “Milestone-Milestone Times” indica los tiempos medidos entre hitos (milestones). En kiosco medimos el tiempo desde que llega al Servicio de Extracciones, espera a la cola del kiosco, interact´ua con ´el y lo libera. En Recepci´on, desde que libera el kiosco, es decir, recibe su n´umero de cita, espera a ser atendido por recepci´on, lo atienden y libera recepci´on. Lo que se muestra es el proceso asociado a cada parte. En extracciones, desde que espera a ser llamado por los boxes, hasta que le llaman y los abandona. De forma similar en extracci´on pedi´atrica y en muestras. “Contenido de pacientes” muestra el n´umero total de pacientes que se encuentran en el Servicio de Extracciones en cada momento. El modelo no est´a validado y las estad´ısticas no corresponden con la actualidad. En la realidad, a partir de las 11 no se suelen acumular pacientes, cuando hay una mayor acumulaci´on es entre las 8 y las 11, m´as concretamente entre las 9:30 y las 10:30. 96 Las ´ultimas dos gr´aficas que nos faltan por comentar son las de “Pacientes que han entrado” y “Pacientes que han salido”, de este modo, podemos saber el n´umero de pacientes atendidos en este caso los que han entrado se corresponden con los que han salido por lo que no tendr´ıamos pacientes sin atender. Todas las estad´ısticas mostradas se pueden exportar a PNG, HTML o a CSV para su posterior an´alisis y/o visualizaci´on. 6.7. Experimentador (OptQuest) El alcance de este TFG no nos permite modelar diferentes escenarios. FlexSim contiene una herramienta de optimizaci´on denominada OptQuest. Nos permite elegir entre los diferentes escenarios programados. En la Figura 6.10 se muestra un ejemplo de la ventana del experimentador, nos permite escoger entre las diferentes soluciones y nos proporciona, adem´as, los mejores resultados. Esta imagen nada tiene que ver con nuestro modelo, ha obtenida de [37] como ejemplo ilustrativo. Figura 6.10: Experimenter (OptQuest) 97 98 Cap´ıtulo 7 Conclusiones El proyecto desarrollado en este documento permite concluir que se han cumplido todos los objetivos planteados en este proyecto. Teniendo en cuenta todo lo aprendido durante los meses que se ha llevado a cabo este proyecto, quedo gratamente sorprendido por la amabilidad y profesionalidad de los trabajadores del HURH. 7.1. Trabajo realizado En el presente documento se ha desarrollado un proyecto real modelando el Servicio de Extracciones perteneciente al HURH. Este proyecto nos ha permitido establecer, conocer y entender las fases que se deben seguir para el correcto desarrollo de un modelo de simulaci´on v´alido y ´util. Ha sido necesario realizar una revisi´on sistem´atica para conocer el estado actual y la relevancia de la aplicaci´on de eventos discretos en el sector sanitario. Tambi´en ha sido imprescindible acudir a dicho servicio para aprender su funcionamiento as´ı como aprender a manejar FlexSim. Se han aplicado m´etodos estad´ısticos para el an´alisis de los datos de la revisi´on sistem´atica de la literatura, para el filtrado de la base de datos del Servicio de Extracciones as´ı como el an´alisis de los datos que lo contienen. La aleatoriedad ha sido el eje vertebrador de la modelizaci´on y la experimentaci´on, no se debe modelar un proceso de forma similar pues ser´ıa una mera representaci´on de la realidad que no aportar´ıa valor y siempre conllevar´ıa al mismo escenario. La simulaci´on se ha realizado en base a los eventos discretos, se ha descrito el funcionamiento del simulador FlexSim as´ı como la construcci´on de un modelo desde cero. 99 7.2. Algunas reflexiones consideradas importantes La utilizaci´on de t´ecnicas de simulaci´on de eventos discretos en el sector sanitario permite obtener grandes mejoras de cara al paciente como la reducci´on de los tiempos de espera, reducci´on de los costes, reducci´on del tiempo de proceso, etc. De hecho, se ha realizado una extensa revisi´on sistem´atica de los eventos discretos en el sector sanitario y las mejoras conseguidas. Tanto los pacientes como el personal sanitario se ven beneficiados en la aplicaci´on de estas t´ecnicas de simulaci´on. El inconveniente que se puede ver en la utilizaci´on de una aplicaci´on existente para la simulaci´on de eventos discretos es el coste econ´omico que su uso supone. Sin embargo, utilizar este tipo de aplicaciones se muestra como una buena opci´on para el correcto desarrollo de un sistema de simulaci´on al contar con un soporte especializado y estar optimizada. Abordar la construcci´on de un gemelo digital, en particular, o el an´alisis de datos previo, as´ı como aprender el funcionamiento de un servicio m´edico, o revisiones de la literatura existente del objeto de estudio, en general, en un idioma distinto al espa˜nol supone un esfuerzo mayor. La utilizaci´on de un gemelo digital en el sector sanitario reduce notablemente el esfuerzo de desarrollo de nuevos protocolos actualizados a la demanda del presente. Como inconvenientes de la utilizaci´on de un gemelo digital radica en la poca o nula publicaci´on de los modelos utilizados; y no solo de los aplicados en otros hospitales, sino en otras industrias. Esto es debido a la pol´ıtica de confidencialidad de la empresa. La construcci´on de un gemelo digital fuera de un programa espec´ıfico de simulaci´on como FlexSim, Arena, Simul8, Anylogic, ProModel, etc., haciendo uso de lenguajes como R tiene sentido ´unicamente si se trata m´as bien de un proyecto de investigaci´on que se prolonga en el tiempo y con un extenso equipo de desarrolladores detr´as. Crear un sistema de este tipo no es sencillo y la falta de transparencia conlleva una mayor dificultad a˜nadida, adem´as de la carencia de soporte y modelos, lo que implica tirarse de cabeza a una piscina sin conocer su contenido. 7.3. Trabajo futuro En primer lugar, el modelo debe ser validado. Es un requisito indispensable para seguir avanzando en la simulaci´on y para la toma de decisiones. Una vez que este modelo quede validado, se puede pasar al siguiente paso, que es la experimentaci´on con diferentes escenarios; los cuales, nos aportar´an diferentes estad´ısticas y ser´a labor nuestra su an´alisis junto con las propuestas de optimizaci´on del servicio. Finalmente, ser´an los responsables del servicio los que realicen la toma de decisiones de las propuestas de mejora. 100 Este estudio ha abierto una nueva l´ınea de investigaci´on en el Hospital Universitario R´ıo Hortega que ser´a llevada a cabo por la Unidad de Log´ıstica y Procesos la cual se dedicar´a a la planificaci´on, estudio, simulaci´on y optimizaci´on de nuevos servicios en este hospital mediante la creaci´on de gemelo digitales con FlexSim. El Hospital Universitario R´ıo Hortega de Valladolid ser´a pionero aplicando t´ecnicas de simulaci´on y optimizaci´on como las expuestas en este documento en otros servicios hospitalarios. La verificaci´on y validaci´on de los escenarios desarrollados forman parte del personal responsable del servicio y se desarrollar´an como tarea futura. La metodolog´ıa desarrollada permite que sean v´alidos y cre´ıbles al ajustarse a la realidad del proceso. 7.4. Competencias La simulaci´on es una disciplina que permite representar, modelar, as´ı como entender el comportamiento de sistemas complejos y predecir su comportamiento futuro. La simulaci´on proporciona al desarrollador el conocimiento y las herramientas necesarias para la construcci´on de modelos complejos de simulaci´on, mediante la utilizaci´on de lenguajes est´andar as´ı como el an´alisis previo de los datos de entrada, el dise˜no de los escenarios y el an´alisis final destinado a los resultados de la simulaci´on para la toma de decisiones. Para poder efectuar una simulaci´on, el desarrollador debe tener una serie de competencias que considero que he trabajado en este TFG [38]. 7.4.1. Competencias b´asicas Ser capaz de demostrar conocimiento, as´ı como tener la capacidad de aplicaci´on de los principios, metodolog´ıas y ciclos de vida de la Ingenier´ıa del Software. Saber utilizar de forma apropiada teoremas, procedimientos y herramientas de la Ingenier´ıa Inform´atica en todos los aspectos (requisitos, an´alisis, dise˜no, desarrollo, pruebas, despliegue, mantenimiento) de manera que se plasme el conocimiento en el modelo. 7.4.2. Competencias espec´ıficas Valorar las necesidades del cliente, ser capaz de especificar los requisitos estableciendo unos compromisos aceptables dentro de la limitaci´on del tiempo de desarrollo, implementaci´on y despliegue, costes. Dise˜nar soluciones apropiadas a lo solicitado mediante t´ecnicas de Ingenier´ıa Inform´atica respetando los aspectos sociales, legales, ´eticos y econ´omicos. 101 [38] Universidad Polit´ecnica de Catalunya. Simulaci´on. URL https://www.fib.upc. edu/es/estudios/grados/grado-en-ingenieria-informatica/plan-de-estudios/ asignaturas/SIM. [39] Flexsim healthcare tutorial. URL https://docs.flexsim.com/en/21.1/Tutorials/ FlexSimHC/OverviewFlexSimHC/. 108 Ap´endices 109 Ap´endice A Repositorio Todo el c´odigo desarrollado a partir de las librer´ıas de FlexSim para la construcci´on del gemelo digital, as´ı como de R para la programaci´on de las gr´aficas consta en la documentaci´on de este TFG y en el repositorio: https://github.com/christianberruezo/TFG_informatica 111 112 Ap´endice B Manual FlexSim En el presente ap´endice se explica de forma detallada el proceso para la construcci´on de un modelo digital mediante el uso de FlexSim. Es conveniente seguir el proceso detallado por orden, de principio a fin para que la creaci´on del modelo sea la correcta. B.1. Licencias Al iniciar FlexSim nos encontraremos una ventana inicial como la siguiente: Figura B.1: Ventana inicial FlexSim) A la derecha se especifican las licencias instaladas, como se puede ver en la siguiente imagen. Figura B.2: Licencia FlexSim 113 Para poder instalar las licencias de las que dispongamos debemos seguir el siguiente proceso. Acudimos a la pesta˜na Help – License Activation y nos aparecer´a la siguiente ventana: Figura B.3: Instalar licencia FlexSim En esa ventana podemos a˜nadir nuevas licencias, copiaremos el c´odigo de la licencia en el campo Activation ID y posteriormente pinchamos en Activate. La licencia de ExpertFit se activa de forma id´entica a la de FlexSim. La licencia solo puede estar instalada en un ´unico ordenador por lo que para que otra persona haga uso de ella debemos eliminarla del ordenador y activarla en el otro. Para poder hacer esto vamos a la pesta˜na Return: 114 Figura B.4: Devolver licencia FlexSim Cuando FlexSim lanza una nueva versi´on de dicho software es necesario actualizar la licencia de la que disponemos. Para ello nos dirigimos a la pesta˜na “Upgrade Licenses” y le damos a “Request Upgrades”. Figura B.5: Actualizar licencia FlexSim FlexSim nos avisar´a cuando hay una nueva versi´on cuando aparezca un tri´angulo amarillo de advertencia donde se detalla la versi´on instalada. 115 Figura B.6: Detalle instalaci´on FlexSim Situando el cursor encima de dicho tri´angulo se nos permite la opci´on de actualizar la licencia de una forma m´as sencilla. Figura B.7: Aviso FlexSim Figura B.8: Actualizaci´on FlexSim B.2. Entorno HealthCare Para poder pasar a este entorno debemos pulsar sobre el siguiente icono y nos aparecer´a un bot´on en el que pone Healthcare. Lo pulsamos. Figura B.9: Barra de herramientas FlexSim 116 Se nos mostrar´a ahora un entorno totalmente diferente: Figura B.10: Entorno HealthCare FlexSim B.3. Construcci´on del modelo B.3.1. Primeros pasos con FlexSim Creamos un nuevo modelo. Tambi´en se puede hacer en File, New Model. Se nos abrir´a esta ventana al crear un nuevo modelo. Es muy importante tener claro las medidas que se van a utilizar, de lo contrario deberemos crear un modelo nuevo o ponderar. Solamente se puede modificar a posteriori tanto la hora de inicio del modelo como la fecha. 117 B.3.6. Recursos En este apartado se presentan los distintos recursos de los que dipone FlexSim para el modelado. En Location encontramos los recursos a utilizar. Estos recursos se modelan. Cualquiera de las formas que existen se las puede cambiar la est´etica si no se asemejan a la realidad. Debemos situar los recursos como se encuentran en la realidad. Figura B.21: Recursos de tipo localizaci´on (Location) En Staff (personal) encontramos los diferentes roles de los sanitarios. 124 Figura B.22: Recursos de tipo personal (Staff) En Multilocation encontramos las salas de espera y en Waiting Line la cola de espera. Las salas de espera pueden modificarse para que tengan la misma capacidad que en la realidad. Activamos Edit Mode para poder poner la capacidad que nos interesa. Luego lo desmarcamos. Adquire As Single Unit quiere decir que solo se puede usar una silla. Figura B.23: Recursos Multilocation B.3.7. Creaci´on de piscinas de recursos / grupos Las piscinas de recursos son grupos de personas u objetos que tienen en com´un ciertas propiedades. Se pueden crear en Toolbox – Groups – click derecho – Add group – escogemos el grupo que queremos. 125 Una buena pr´actica de programaci´on es crear grupos aunque actualmente solo haya una enfermera, por poner un ejemplo. Ya que a lo largo del modelo ser´a m´as sencillo a˜nadir m´as personal al no tener que modificar el diagrama de flujo, ya que estar´a a˜nadido al grupo. Solo faltar´ıa a˜nadir el nuevo personal al grupo. Figura B.24: A˜nadir grupos El resultado ser´a de la siguiente forma: Figura B.25: Toolbox Se puede modificar la asignaci´on del personal a los pacientes. Group Rank quiere decir que, por ejemplo, de 2 m´edicos siempre elige primero el que est´a libre. Es todo lo contrario a utilization, este ´ultimo equilibra las atenciones. 126 Figura B.26: Propiedades de los grupos B.4. L´ogica del modelo B.4.1. Diagrama de flujo de pacientes El bot´on de la Figura B.27 nos sirve para crear un flujograma o diagrama de flujo de los pacientes. Figura B.27: Patient Flows Nos encontramos ante dos posibles v´ıas para su desarrollo, queda a elecci´on del programador escoger la que le resulte m´as sencilla o adecuada para el modelo. Opci´on 1: Crear un diagrama de flujo ´unico para cada tipo de paciente (depuraci´on sencilla y visualmente sencillo de entender). Opci´on 2: Crear un ´unico diagrama de flujo con todos los tipos de pacientes (depuraci´on m´as compleja, visualmente dificultoso de entender, pero proporciona una visualizaci´on r´apida en busca de errores). En Library encontramos los siguientes bloques preprogramados pero f´acilmente editables. 127 Figura B.28: HC Activity Sets Estos recursos ya no est´an preprogramados, nos sirve para programar a nosotros el flujo. Figura B.29: HC Resources Existen muchas m´as herramientas, esto viene muy bien explicado en [39]. Conviene destacar el recuadro de Max Wait Timer, al poner tiempo 0.0 lo que se hace es una comprobaci´on instant´anea del recurso. Si el recurso est´a ocupado el paciente va a la sala de espera (hay que modelarlo). Si no marcamos Max Wait Timer el paciente se quedar´a esperando en el ´ultimo lugar adquirido. 128 Figura B.30: Properties B.4.2. Flujos de pacientes (llegadas/arrivals) A continuaci´on, vamos a ver los Arrivals, es la l´ogica que crea los pacientes. Se pueden distinguir varias opciones, en primera instancia debemos crear un diagrama que represente las llegadas, para ello vamos a la carpeta Arrivals y lo creamos. Este diagrama es ´unico y exclusivo para modelar las llegadas de los pacientes. Debemos realizar un an´alisis estad´ıstico de estas para poderlas representar antes de comenzar la simulaci´on si es que no disponemos de los datos o no est´an especificados. Figura B.31: A˜nadir un Process Flow Distinguimos varios tipos de llegadas: Inter-Arrival Source: modela las llegadas entre pacientes (no puede ser negativas: no se adelantan los pacientes). Schedule Source: llegada de pacientes seg´un el tiempo de FlexSim. Date Time Source: sirve para modelar las citas de los pacientes en base al d´ıa, hora y n´umero de pacientes. Event-Triggered Source: llegadas seg´un un evento. 129 Figura B.32: Library Importante: si las llegadas de los pacientes se ajustan mediante una distribuci´on estad´ıstica hay que revisar las unidades del modelo y de la distribuci´on. En el caso en el que no coincidan habr´a que ponderar. B.4.3. Otros recursos Assign labels: creaci´on de labels para programar tipos de pacientes, prioridades, etc. Delay: retraso (tiempo especificado). Custom code: bloque de programaci´on. Decide: decisor, elige por d´onde va el token. Milestone: hitos, se registra cada vez que se llega a ellos. Figura B.33: Otros recursos B.5. Estad´ısticas / dashboards B.5.1. Zonas/Zone En Process Flows – Add a General Process Flow a˜nadimos un diagrama General. Este no modela las llegadas de los pacientes, sino el comportamiento de los pacientes en Zone (zonas). Sirve ´unica y exclusivamente para obtener las estad´ısticas de los pacientes en estas zonas. 130 Es relevante en el caso de que queramos llevar a cabo un modelado m´as complejo y detallado como por ejemplo el comportamiento de los pacientes seg´un su tipolog´ıa en la sala de espera (no modela tiempos, esos se modelan por prioridad en el caso de que un paciente por su tipo de gravedad deba de pasar antes que otro triado leve). Se muestra en la Figura B.34 el nuevo Process Flow de la zona de la sala de espera. Zone tiene tantos tokens como haya en esa zona. Lo podemos hacer de dos formas: teniendo las salas de espera en un grupo o por separadas. Depende de la realidad. El token del paciente en esteProcess Flow no tiene necesariamente que coincidir con el nombre del token del paciente en Arrivals. Figura B.34: Flujograma zona A continuaci´on, se muestra el modelado de las zonas: Figura B.35: Propiedades zona En este modelo disponemos de dos salas de espera separadas, denominadas Chairs1 yChairs2. Nos interesa obtener las estad´ısticas del tiempo de los pacientes en estas zonas. La primera 131 sala de espera (Chairs1) se modela de forma similar a la segunda. En Event ponemos OnEntry porque lo que nos interesa es contar desde que el paciente entra en la zona. El token del paciente en este caso se llama propiamente “paciente” y se le asigna (assign) la operaci´on. Figura B.36: Enter Zone En la Figura B.36 se modifica nada. Atendiendo a la Figura B.37, seleccionamos el objeto que nos interesa, en nuestro caso el grupo (piscina de recursos) de la sala de espera. En ese grupo se encuentran Chairs1 yChairs2. En la asignaci´on se escribe el token del paciente seg´un como lo hayamos nombrado en Source y la operaci´on es match (que coincida). Figura B.37: Wait for Event Por ´ultimo, modelamos que el paciente salga. De este modo quedan registradas todas las estad´ısticas del paciente desde que entra hasta que sale de la sala de espera. 132 Figura B.38: Exit Zone Para obtener las estad´ısticas, pinchamos en el icono Zone y donde se˜nala la flecha. Figura B.39: A˜nadir estad´ısticas a dashboard Se nos abrir´a la siguiente ventana: 133 140 Ap´endice C Referencias de la Revisi´on Sistem´atica de la Literatura En las referencias [40-269] encontraremos los casos de estudio analizados. El resto de art´ıculos analizados en la revisi´on sistem´atica y que tambi´en forman parte de los resultados, se pueden encontrar en las referencias [270-529]. 141 142 Referencias [40] M. Abdelghany and A. B. Eltawil. Linking approaches for multi-methods simulation in healthcare systems planning and management. International Journal of Industrial and Systems Engineering, 26(2):275–290, 2017. [41] A. A. Abdul Pari, J. Simon, J. Wolstenholme, J. R. Geddes, and G. M. Goodwin. Economic evaluations in bipolar disorder and a systematic review and critical appraisal. Bipolar Disord, 16(6):557–82, 2014. [42] T. K. Abe, B. M. Beamon, R. L. Storch, and J. Agus. Operations research applications in hospital operations and part i. IIE Transactions on Healthcare Systems Engineering, 6(1):42–54, 2016. [43] T. K. Abe, B. M. Beamon, R. L. Storch, and J. Agus. Operations research applications in hospital operations and part iii. IIE Transactions on Healthcare Systems Engineering, 6(3):175–191, 2016. [44] L. Aboueljinane, E. Sahin, Z. Jemai, and J. Marty. A simulation study to improve the performance of an emergency medical service and application to the french val-de-marne department. Simulation Modelling Practice and Theory, 47:46–59, 2014. [45] H. H. A. Afzali, J. Karnon, and J. Gray. A critical review of model-based economic studies of depression and modelling techniques, model structure and data sources. PharmacoEconomics, 30(6):461–482, 2012. [46] H. H. A. Afzali, J. Karnon, and J. Gray. A proposed model for economic evaluations of major depressive disorder. European Journal of Health Economics, 13(4):501–510, 2012. [47] P. M. Aguiar, T. M. Lima, and S. Storpirtis. Systematic review of the economic evaluations of novel therapeutic agents in multiple myeloma and what is the reporting quality? Journal of Clinical Pharmacy and Therapeutics, 41(2):189–197, 2016. [48] V. Ahalt, N. T. Argon, S. Ziya, J. Strickler, and A. Mehrotra. Comparison of emergency department crowding scores and a discrete-event simulation approach. Health Care Manag Sci, 21(1):144–155, 2018. 143 [49] N. Ahmad, N. A. Ghani, A. A. Kamil, and R. Mat Tahar. Modeling emergency department using a hybrid simulation approach. volume 229 LNEE, pages 701–711. Springer Verlag, 2013. [50] Z. Ahmed, T. Elmekkawy, and S. Bates. Developing an efficient scheduling template of a chemotherapy treatment unit and a case study. Australas Med J, 4(10):575–88, 2011. [51] K. B. Ahsan, M. R. Alam, D. G. Morel, and M. A. Karim. Emergency department resource optimisation for improved performance and a review. Journal of Industrial Engineering International, 15:253–266, 2019. [52] A. Ajdari, L. N. Boyle, N. Kannan, J. Wang, F. P. Rivara, and M. S. Vavilala. Simulation of the emergency department care process for pediatric traumatic brain injury. Journal for Healthcare Quality, 40(2):110–118, 2018. [53] O. Al-Araidah, A. Boran, and A. Wahsheh. Reducing delay in healthcare delivery at outpatients clinics using discrete event simulation. International Journal of Simulation Modelling, 11(4):185–195, 2012. [54] K. Al Badi. Discrete event simulation and pharmacy process re-engineering. Int J Health Care Qual Assur, 32(2):398–411, 2019. [55] A. Ala and F. Chen. Alternative mathematical formulation and hybrid meta-heuristics for patient scheduling problem in health care clinics. Neural Computing and Applications, 32(13):8993–9008, 2020. [56] F. Albuquerque De Almeida, M. J. Al, R. Koymans, J. Riistama, S. Pauws, and J. L. Severens. Impact of hospitalisation on health-related quality of life in patients with chronic heart failure. Health and Quality of Life Outcomes, 18(1), 2020. [57] E. Alfonso, X. Xie, V. Augusto, and O. Garraud. Modelling and simulation of blood collection systems and improvement of human resources allocation for better cost-effectiveness and reduction of candidate donor abandonment. Vox Sanguinis, 104(3):225–233, 2013. [58] M. H. Alhaag, T. Aziz, and I. M. Alharkan. A queuing model for health care pharmacy using software arena. Institute of Electrical and Electronics Engineers Inc. [59] A. A. Alhaider, N. Lau, P. B. Davenport, and M. K. Morris. Distributed situation awareness and a health-system approach to assessing and designing patient flow management. Ergonomics, 63(6):682–709, 2020. [60] F. Alkhaldi and A. Alouani. Systemic design approach to a real-time healthcare monitoring system and reducing unplanned hospital readmissions. Sensors (Switzerland), 18(8), 2018. [61] F. A. Alkhaldi and A. T. Alouani. Systemic design approach to reducing rates of unplanned hospital readmissions. volume 2017-December, pages 43–49. Institute of Electrical and Electronics Engineers Inc. 144 [62] F. Allen, S. Montgomery, M. Maruszczak, J. Kusel, and N. Adlard. Convergence yet continued complexity and a systematic review and critique of health economic models of relapsing-remitting multiple sclerosis in the united kingdom. Value in Health, 18(6):925–938, 2015. [63] M. Allen, A. Bhanji, J. Willemsen, S. Dudfield, S. Logan, and T. Monks. A simulation modelling toolkit for organising outpatient dialysis services during the covid- 19 pandemic. PLoS ONE, 15(8 August), 2020. [64] T. T. Allen. Introduction to discrete event simulation and agent-based modeling and Voting systems, health care, military, and manufacturing. Introduction to Discrete Event Simulation and Agent-based Modeling and Voting Systems, Health Care, Military, and Manufacturing. Springer London, 2011. [65] M. M. Alvarado, T. G. Cotton, L. Ntaimo, E. P´erez, and W. R. Carpentier. Modeling and simulation of oncology clinic operations in discrete event system specification. Simulation, 94(2):105–121, 2018. [66] G. H. Anderson, P. J. Jenkins, D. A. McDonald, R. Van Der Meer, A. Morton, M. Nugent, and L. A. Rymaszewski. Cost comparison of orthopaedic fracture pathways using discrete event simulation in a glasgow hospital. BMJ Open, 7(9):e014509, 2017. [67] D. Antonelli, G. Bruno, and T. Taurino. Analysis of patient flows in elective surgery and modelling and optimisation of the hospitalisation process. International Journal of Services and Operations Management, 31(4):513–529, 2018. [68] M. Arafeh, M. A. Barghash, E. Sallam, and A. AlSamhouri. Six sigma applied to reduce patients’ waiting time in a cancer pharmacy. International Journal of Six Sigma and Competitive Advantage, 8(2):105–124, 2014. [69] A. Arisha and W. Rashwan. Modeling of healthcare systems and past, current and future trends. volume 0, pages 1523–1534. Institute of Electrical and Electronics Engineers Inc. [70] D. A. Asamoah, R. Sharda, H. N. Rude, and D. Doran. Rfid-based information visibility for hospital operations and exploring its positive effects using discrete event simulation. Health Care Manag Sci, 21(3):305–316, 2018. [71] A. B. Asl and M. G. Khan. Studying the effect of online medical applications on patients healing time and doctors utilization using discrete event simulation. Institute of Electrical and Electronics Engineers Inc. [72] M. M. Asrar, D. P. Lad, S. Prinja, and D. Bansal. A systematic review of economic evaluations of treatment regimens in multiple myeloma. Expert Rev Pharmacoecon Outcomes Res, pages 1–11, 2020. [73] T. M. Assi, K. Rookkapan, J. Rajgopal, V. Sornsrivichai, S. T. Brown, J. S. Welling, B. A. Norman, D. L. Connor, S. I. Chen, R. B. Slayton, Y. Laosiritaworn, A. R. Wateska, S. R. 145 Wisniewski, and B. Y. Lee. How influenza vaccination policy may affect vaccine logistics. Vaccine, 30(30):4517–4523, 2012. [74] V. Augusto, O. Rejeb, X. Xie, S. Aloui, L. Perrier, P. Biron, and T. Durand. Performance evaluation of health information systems using aris modeling and discrete-event simulation. volume 2016-February, pages 1503–1514. Institute of Electrical and Electronics Engineers Inc. [75] F. Badilla-Murillo, B. Vargas-Vargas, O. V´ıquez-Acu˜na, and J. Garc´ıa-Sanz-Calcedo. Analysis of the installed productive capacity in a medical angiography room through discrete event simulation. Processes, 8(6), 2020. [76] S. Bae, J. Karnon, G. Crane, T. Bessen, J. Desai, P. Crowe, and S. Neuhaus. Costeffectiveness analysis of imaging surveillance in stage ii and iii extremity soft tissue sarcoma and an australian perspective. Cost Effectiveness and Resource Allocation, 18(1), 2020. [77] N. Bahou, C. Fenwick, G. Anderson, R. van der Meer, and T. Vassalos. Modeling the critical care pathway for cardiothoracic surgery. Health Care Manag Sci, 21(2):192–203, 2018. [78] A. E. Bair, W. T. Song, Y. C. Chen, and B. A. Morris. The impact of inpatient boarding on ed efficiency and a discrete-event simulation study. Journal of Medical Systems, 34(5):919– 929, 2010. [79] A. Bal, C. Ceylan, and C. Ta¸co˘glu. Using value stream mapping and discrete event simulation to improve efficiency of emergency departments. International Journal of Healthcare Management, 10(3):196–206, 2017. [80] C. Banditori, P. Cappanera, and F. Visintin. Investigating the relationship between resources balancing and robustness in master surgical scheduling. volume 61, pages 149–162. Springer New York LLC. [81] J. F. Bard, Z. Shu, D. J. Morrice, D. E. Wang, R. Poursani, and L. Leykum. Improving patient flow at a family health clinic. Health Care Management Science, 19(2):170–191, 2016. [82] R. Bareˇs, J. Griffiths, V. Knight, J. Williams, K. Baboolal, and A. Nelson. Simulating bed capacity and evaluating the impact of healthcare service transfers. pages 358–362. [83] C. Baril, V. Gascon, and S. Cartier. Design and analysis of an outpatient orthopaedic clinic performance with discrete event simulation and design of experiments. Computers and Industrial Engineering, 78:285–298, 2014. [84] C. Baril, V. Gascon, J. Miller, and C. Bounhol. The importance of considering resource’s tasks when modeling healthcare services with discrete-event simulation and an approach using work sampling method oa. Journal of Simulation, 11(2):103–114, 2017. 146 [85] C. Baril, V. Gascon, J. Miller, and N. Cˆot´e. Use of a discrete-event simulation in a kaizen event and a case study in healthcare. European Journal of Operational Research, 249(1):327–339, 2016. [86] C. Baril, V. Gascon, and D. Vadeboncoeur. Discrete-event simulation and design of experiments to study ambulatory patient waiting time in an emergency department. Journal of the Operational Research Society, 70(12):2019–2038, 2019. [87] M. Barton, S. McClean, J. Gillespie, L. Garg, D. Wilson, and K. Fullerton. Is it beneficial to increase the provision of thrombolysis?- a discrete-event simulation model. QJM, 105(7):665–673, 2012. [88] P. Barton, J. P. Sheppard, C. M. Penaloza-Ramos, S. Jowett, G. A. Ford, D. Lasserson, J. Mant, R. M. Mellor, T. Quinn, P. M. Rothwell, D. Sandler, D. Sims, and R. J. McManus. When has service provision for transient ischaemic attack improved enough? a discrete event simulation economic modelling study. BMJ Open, 7(11):e018189, 2017. [89] D. M. Bean, P. Taylor, and R. J. B. Dobson. A patient flow simulator for healthcare management education. BMJ Simul Technol Enhanc Learn, 5(1):46–48, 2019. [90] M. Beckmann, E. Paterson, and A. Smith. Redesigning induction of labour processes. Aust N Z J Obstet Gynaecol, 58(3):315–320, 2018. [91] L. Bedoya-Valencia and E. Kirac. Evaluating alternative resource allocation in an emergency department using discrete event simulation. Simulation, 92(12):1041–1051, 2016. [92] D. Ben-Tovim, J. Filar, P. Hakendorf, S. Qin, C. Thompson, and D. Ward. Hospital event simulation model and arrivals to discharge–design, development and application. Simulation Modelling Practice and Theory, 68:80–94, 2016. [93] B. Berg, B. Denton, H. Nelson, H. Balasubramanian, A. Rahman, A. Bailey, and K. Lindor. A discrete event simulation model to evaluate operational performance of a colonoscopy suite. Medical Decision Making, 30(3):380–387, 2010. [94] T. Bessen, D. M. K. Keefe, and J. Karnon. Does one size fit all? cost utility analyses of alternative mammographic follow-up schedules, by risk of recurrence. International Journal of Technology Assessment in Health Care, 31(5):281–288, 2016. [95] A. M. Best, C. A. Dixon, W. D. Kelton, C. J. Lindsell, and M. J. Ward. Using discrete event computer simulation to improve patient flow in a ghanaian acute care hospital. Am J Emerg Med, 32(8):917–22, 2014. [96] T. Bolt, S. Bayer, M. Kapsali, and S. Brailsford. An analytical framework for group simulation model building. Health Systems, 2020. [97] M. T. Booker, R. J. O’Connell, B. Desai, and V. A. Duddalwar. Quality improvement with discrete event simulation and a primer for radiologists. J Am Coll Radiol, 13(4):417–23, 2016. 147 [98] S. Borg, H. Nahi, M. Hansson, D. Lee, J. Elvidge, and U. Persson. Cost effectiveness of pomalidomide in patients with relapsed and refractory multiple myeloma in sweden. Acta Oncologica, 55(5):554–560, 2016. [99] R. J. Boucherie, E. W. Hans, and T. Hartmann. Health care logistics and space and accounting for the physical build environment. [100] D. Bouzon Nagem Assad and T. Spiegel. Improving emergency department resource planning and a multiple case study. Health Syst (Basingstoke), 9(1):2–30, 2020. [101] J. Bowers, M. Ghattas, and G. Mould. Exploring alternative routes to realising the benefits of simulation in healthcare. Journal of the Operational Research Society, 63(10):1457–1466, 2012. [102] J. Bowers, G. Mould, and C. Marshall. Location of services and the impact on healthcare quality and insights from a simulation of a musculoskeletal physiotherapy service. Journal of the Operational Research Society, 66(7):1212–1221, 2015. [103] B. D. Bradley, S. R. C. Howie, T. C. Y. Chan, and Y. L. Cheng. Estimating oxygen needs for childhood pneumonia in developing country health systems and a new model for expecting the unexpected. PLoS ONE, 9(2), 2014. [104] Sally C. Brailsford, Tillal Eldabi, Martin Kunc, Navonil Mustafee, and Andres E. Osorio. Hybrid simulation modelling in operational research and a state-of-the-art review. European Journal of Operational Research, 278(3):721–737, 2019. [105] E. Oliveira BRP, J. A. de Vasconcelos, J. F. F. Almeida, and L. R. Pinto. A simulationoptimisation approach for hospital beds allocation. Int J Med Inform, 141:104174, 2020. [106] C. S. Brust and R. Clark. System simulation as decision data in heathcare it. volume 2015-January, pages 1317–1328. Institute of Electrical and Electronics Engineers Inc. [107] A. S. Burns, A. Santos, C. L. Cheng, E. Chan, N. Fallah, D. Atkins, M. F. Dvorak, C. Ho, H. Ahn, J. Paquet, B. K. Kwon, and V. K. Noonan. Understanding length of stay after spinal cord injury and insights and limitations from the access to care and timing project. J Neurotrauma, 34(20):2910–2916, 2017. [108] N. C. B¨uy¨ukkaramikli, S. de Groot, R. Riemsma, D. Fayter, N. Armstrong, P. Portegijs, S. Duffy, J. Kleijnen, and M. J. Al. Ribociclib with an aromatase inhibitor for previously untreated, hr-positive, her2-negative, locally advanced or metastatic breast cancer and an evidence review group perspective of a nice single technology appraisal. PharmacoEconomics, 37(2):141–153, 2019. [109] H. Cai and J. Jia. Using discrete event simulation (des) to support performance-driven healthcare design. Health Environments Research and Design Journal, 12(3):89–106, 2019. 148 [110] J. R. Campbell, J. C. Johnston, V. J. Cook, M. Sadatsafavi, R. K. Elwood, and F. Marra. Cost-effectiveness of latent tuberculosis infection screening before immigration to lowincidence countries. Emerging Infectious Diseases, 25(4):661–671, 2019. [111] J. R. Campbell, J. C. Johnston, L. A. Ronald, M. Sadatsafavi, R. F. Balshaw, V. J. Cook, A. Levin, and F. Marra. Screening for latent tuberculosis infection in migrants with ckd and a cost-effectiveness analysis. Am J Kidney Dis, 73(1):39–50, 2019. [112] Jonathon R. Campbell, James C. Johnston, Mohsen Sadatsafavi, Victoria J. Cook, R. Kevin Elwood, and Fawziah Marra. Cost-effectiveness of post-landing latent tuberculosis infection control strategies in new migrants to canada. Plos One, 12(10), 2017. [113] L. A. Campbell, J. T. Blake, G. Kephart, E. Grunfeld, and D. MacIntosh. Understanding the effects of competition for constrained colonoscopy services with the introduction of population-level colorectal cancer screening. Med Decis Making, 37(2):253–263, 2017. [114] H. Cao and S. Huang. Principles of scarce medical resource allocation in natural disaster relief and a simulation approach. Medical Decision Making, 32(3):470–476, 2012. [115] C. Caprara, F. Visintin, and F. Puggelli. Crowding in paediatric emergency department, a review of the literature and a simulation-based case study. volume 210, pages 293–295. Springer New York LLC. [116] C. Caprara, F. Visintin, and F. Puggelli. Crowding in paediatric emergency department, a review of the literature and a simulation-based case study. volume 210, pages 293–295. Springer New York LLC. [117] R. Carmen, M. Defraeye, and I. Van Nieuwenhuyse. A decision support system for capacity planning in emergency departments. International Journal of Simulation Modelling, 14(2):299–312, 2015. [118] J. J. Caro. Discretely integrated condition event (dice) simulation for pharmacoeconomics. PharmacoEconomics, 34(7):665–672, 2016. [119] J. J. Caro, A. H. Briggs, U. Siebert, and K. M. Kuntz. Modeling good research practicesoverview and a report of the ispor-smdm modeling good research practices task force-1. Medical Decision Making, 32(5):667–677, 2012. [120] J. J. Caro, J. M¨oller, and D. Getsios. Discrete event simulation and the preferred technique for health economic evaluations? Value Health, 13(8):1056–60, 2010. [121] G. Celano, A. Costa, S. Fichera, and G. Tringali. Linking six sigma to simulation and a new roadmap to improve the quality of patient care. Int J Health Care Qual Assur, 25(4):254–73, 2012. [122] M. A. Centeno and K. A. Diaz. Simulating health care systems and a tutorial. volume 2016-February, pages 1835–1849. Institute of Electrical and Electronics Engineers Inc. 149