Desarrollo de un servicio de asistencia al triaje integrable en sistemas de telemedicina

(1)

Escuela T ´ecnica Superior de Ingenier´ıa Inform ´atica

Grado en Ingenier´ıa de la salud

Desarrollo de un servicio de asistencia al triaje integrable

en sistemas de telemedicina

Development of a triage support service which can be

integrated into telehealth systems

Realizado por

MIGUEL GONZ ´

ALEZ SOSA

Dirigido por

JOS ´

E MAR´IA ´

ALVAREZ PALOMO

FERNANDO MORENO JABATO

Departamento

DEPARTAMENTO DE LENGUAJES Y CIENCIAS DE LA

COMPUTACI ´

ON

UNIVERSIDAD DE M ´ALAGA M ´alaga, septiembre de 2019.

(2)

(3)

(4)

Resumen

Palabras clave optimizaci ´on de recursos sanitarios, triaje, telemedicina, arquitectura de software, sistemas distribuidos, microservicios,customer relationship management

(5)

(6)

Abstract

Keywords: optimization of health resources, triage, telehealth, software architechtu-re, distributed systems, microservices, customer relationship management

(7)

(8)

´Indice general

1. Introducci ´on 1

1.1. Motivaci ´on . . . 2

1.2. Impacto . . . 2

1.3. Objetivos . . . 3

2. Estado del arte 5 2.1. La metodolog´ıa del triaje . . . 6

2.2. Productos y programas inform ´aticos . . . 8

3. Metodolog´ıa 11 3.1. Fases de trabajo . . . 12

4. An ´alisis del problema 13 4.1. An ´alisis de requisitos . . . 13

4.1.1. Requisitos no funcionales . . . 13

4.1.2. Requisitos funcionales . . . 14

4.1.3. Casos de uso . . . 14

4.2. Soluci ´on propuesta . . . 22

5. Dise ˜no e implementaci ´on 27 5.1. Arquitectura software . . . 27

5.1.1. Arquitectura a nivel de macrodise ˜no . . . 27

5.1.2. Arquitectura a nivel de microdise ˜no . . . 29

5.2. Interfaz de usuario . . . 37

5.2.1. Acceso . . . 38

(9)

5.2.3. Pantalla principal del profesional sanitario . . . 39

5.2.4. Pantalla principal del teleoperador . . . 40

5.2.5. Buscador . . . 40

5.2.6. Pantalla de carga . . . 42

5.2.7. Triaje parcial . . . 42

5.2.8. Triaje completo . . . 44

5.2.9. Triaje pendiente . . . 46

5.3. An ´alisis de las herramientas . . . 48

5.3.1. Herramientas de desarrollo . . . 50

5.3.2. Tecnolog´ıas y est ´andares . . . 53

5.3.3. VueJS . . . 57

6. Verificaci ón y validaci ón 59 6.1. Pruebas unitarias autom áticas . . . 59

6.2. Pruebas manuales . . . 62

7. Conclusiones y l´ıneas futuras 65 7.1. Limitaciones . . . 66

7.2. L´ıneas futuras . . . 66

(10)

´Indice de figuras

2.1. Ejemplo de algoritmo de triaje del Sistema de Triaje de Manchester . . 7

4.1. Diagrama de casos de uso (I) . . . 20

4.2. Diagrama de casos de uso (II) . . . 21

4.3. Flujo de trabajo en la atenci ´on telef ´onica . . . 23

4.4. Flujo de trabajo en la atenci ´on telef ´onica haciendo uso del servicio de triaje . . . 25

5.1. La arquitectura del sistema propuesta . . . 28

5.2. Diagrama de secuencia de una petici ´on a un endpoint protegido del servicio de triaje . . . 29

5.3. La arquitectura limpia . . . 30

5.4. Reglas de dependencias entre las diferentes capas de la aplicaci ´on . . 37

5.5. Pantalla de acceso . . . 38

5.6. Pantalla principal del administrador . . . 39

5.7. Pantalla principal del profesional sanitario . . . 39

5.8. Pantalla principal del teleoperador . . . 40

5.9. Buscador . . . 41

5.10.Opciones de iniciar triaje parcial o completo disponibles despu ´es de se-leccionar el algoritmo en el buscador . . . 41

5.11.Pantalla de carga . . . 42

5.12.Inicio del proceso de triaje parcial . . . 43

5.13.Confirmaci ´on y finalizaci ´on del triaje parcial . . . 43

5.14.Confirmaci ´on y finalizaci ´on del triaje parcial con estado cr´ıtico . . . 44

5.15.Inicio del proceso de nuevo triaje completo . . . 45

5.16.Confirmaci ´on y finalizaci ´on del triaje completo . . . 45

(11)

5.18.Opci ´on de completar un triaje pendiente desactivada si no hay ninguno en cola . . . 47

(12)

1

Cap´

ıtulo

Introducci ´

on

Gestionar la alta demanda de los servicios de urgencia hospitalaria es un proce-so cr´ıtico a la hora garantizar los recurproce-sos sanitarios necesarios para los caproce-sos con mayor urgencia. Para ello se han desarrollado estrategias de clasificaci ón de los de-mandantes del servicio, que reciben el nombre detriaje [1] o protocolo de Recepci ón, Acogida y Clasificaci ón (RAC), como prefieren llamarlo en la Sociedad Espa ñola de Enfermer´ıa de Urgencias (SEEU) [2]. Este sistema de gesti ón del riesgo cl´ınico se usa, con diferentes enfoques, en todo el mundo. En un primer momento, esta clasificaci ón depend´ıa directamente de la mezcla de experiencia e intuici ón de los facultativos m ás versados. M ás tarde, para permitir la aplicaci ón de estos triajes por parte de enfer-meros y m édicos menos experimentados, se desarrollaron algoritmos m ás formales, constituyendo un sistema que toma en cuenta la queja principal de la visita, el cuadro sintom ático y las se ñales vitales con una estratificaci ón en un n úmero fijo de niveles de urgencia.

M ás necesario a ún es este sistema en los casos de pandemia, en los que los recur-sos son m ás demandados. Es por esto que los sistemas de informaci ón est án siendo integrados en el sector sanitario permitiendo una gesti ón m ás eficaz y facilitando el escalado de los servicios de urgencia.

(13)

1.1. Motivaci ´on

como primer filtro para el ahorro de recursos hospitalarios y la disminuci ´on del n ´umero de casos no urgentes derivados al servicio de urgencias.

1.1. Motivaci ´

on

Un ejemplo de la informatizaci ón del servicio sanitario es el uso de CRMs (Custo-mer Relationship Management). Salud Responde, un centro de informaci ón y servicios de salud del Servicio Andaluz de Salud (SAS), utiliza este tipo de sistema para asistir la atenci ón a los ciudadanos que la demanden. La informaci ón y la asistencia se orga-niza en varios niveles de especializaci ón y dependiendo de la dificultad de la consulta del ciudadano es atendida por diferentes perfiles de profesionales [3].

Ya sea en el ámbito telem ático o no, para derivar el caso al nivel de atenci ón que corresponda se aplican triajes. El triaje consta de varias preguntas dirigidas al paciente con el objetivo de conocer el cuadro sintom ático y realizar la clasificaci ón de éste seg ún un algoritmo que toma en cuenta los distintos signos y s´ıntomas en relaci ón con la queja principal.

En el a ño 2009, con la pandemia de la gripe A, el sistema de Salud Responde se apoy ó en un sistema de asistencia de aplicaci ón del triaje de dicha enfermedad, cuyo resultado representa un caso de éxito: el personal t écnico pudo dar respuesta a mu-chos m ás casos que habitualmente con un grado de confianza alto [4]. Sin embargo, el desarrollo de este sistema se limit ó al triaje de la gripe A y no ha sido readaptado para otras situaciones de riesgo.

Para este tipo de procedimientos se requieren conocimientos m édicos. Por lo tanto, aunque se disponga de un servicio telem ático, el n úmero de profesionales sanitarios para aplicar los triajes es un factor limitante que no permite escalar el servicio de forma óptima. Sin embargo, la posibilidad de realizar parcialmente el triaje por parte de profesionales no sanitarios disminuye el n úmero de sanitarios necesarios para la realizaci ón del proceso.

1.2. Impacto

(14)

ser-Cap´ıtulo 1. Introducci ´on

vicio de triaje que aqu´ı presentamos para la extensi ´on de un CRM existente, podemos conseguir los siguientes beneficios adicionales:

◦ Reducci ´on del tiempo de respuesta.

◦ Clasificaci ´on de los casos m ´as precisa.

◦ Minimizaci ´on de errores de factor humano t´ıpico de las tareas repetitivas.

◦ Minimizaci ´on de desplazamientos innecesarios. En este punto en concreto po-demos identificar que el beneficio afecta a diferentes niveles:

• A nivel cl´ınico, ya que se evita el contacto de personas relativamente sanas con individuos con enfemedades contagiosas y disminuye la probabilidad de propagaci ´on;

• A nivel social, porque favorece la opini ón del ciudadano al obtener un servi-cio m ás c ómodo y con mejor gesti ón de recursos;

• Y a nivel econ ómico ya que, como demuestran diversos informes [6, 7, 8, 9], la proporci ón de casos inadecuados en el servicio de urgencias oscila entre el 20 % y el 80 %. En 2017, el servicio de urgencias hospitalarias de Anda-luc´ıa registr ó 4.310.874 casos en urgencias [10]. Si siendo conservadores, consideramos que el 30 % de esas consultas pueden haber sido inadecua-das y teniendo en cuenta que el precio medio de consulta de urgencias en Andaluc´ıa es de 250e [11], m ás de 300.000.000e estar´ıan destinados inapropiadamente.

◦ Gesti ón m ás eficiente de los recursos del servicio de salud. El 31.7 % del pre-supuesto en Andaluc´ıa se destin ó a Sanidad en 2018, lo que se traduce en 9.735.000.000e, unos 1.158e por andaluz. Se incluye aqu´ı la partida de Mu-tualismo Administrativo y otras partidas que no est án directamente relacionadas con los recursos e infrastructura del servicio de salud, pero nos sirve para enten-der la magnitud de la responsabilidad que conlleva optimizar este proceso.

1.3. Objetivos

(15)

1.3. Objetivos

de un CRM u otro tipo de sistema cualquiera. Con este software se conseguir á auto-matizar, en cierto grado y con la cooperaci ón de un trabajador sanitario o no sanitario, la aplicaci ón de triajes para la clasificaci ón de pacientes. Actualmente, este proceso depende de un facultativo, independientemente de si el servicio es telem ático o pre-sencial, y es un factor limitante en este tipo de tareas.

Este sistema ser á capaz de realizar una evaluaci ón y, por consiguiente, una cla-sificaci ón de un paciente en el nivel de emergencia correspondiente en funci ón de la informaci ón recopilada durante la anamnesis1telef ónica, haciendo uso de un conjunto de protocolos previamente almacenados. Con este objetivo, el programa permitir á car-gar y almacenar nuevos protocolos de intervenci ón para diferentes “quejas principales” o “motivos de llamada”. Un requisito adicional es que el sistema sea auditable, de for-ma que queden registradas todas las acciones que se realicen o intenten realizarse sobre el sistema.

Desde el punto de vista t ´ecnico, se deben implementar estos requisitos en un ser-vicio web con las funcionalidades CRUD (Create, Read, Update, Delete) sobre los algoritmos de triaje y losendpointsrelacionados con las evaluaciones de un paciente.

(16)

2

Cap´

ıtulo

Estado del arte

En el desarrollo de soluciones software no se concibe la elaboraci ón de un proyec-to de calidad sin la colaboraci ón de los experproyec-tos del dominio que se esta abordando durante el modelado y aceptaci ón de las iteraciones a lo largo de todo el proceso. El enfoque de desarrollo software por excelencia para dominios y entornos de negocio complejos, el dise ño guiado por el dominio (Domain Driven Design, DDD) [12], indi-ca que el equipo de desarrollo y expertos de dominio deben cooperar para crear y madurarlenguajes ubicuos [13] manteniendo sucesivas reuniones, con el objetivo de elaborar un modelo de dominio rico [14] y evitar confusiones originadas por la am-big üedad y la subjetividad del lenguaje natural.

(17)

2.1. La metodolog´ıa del triaje

A d´ıa de hoy los protocolos de triaje se ejecutan en condiciones de “normalidad” debido a la masificaci ón de los servicios de urgencia hospitalaria por factores como la utilizaci ón de estos servicios para la atenci ón de situaciones no urgentes [15]. Sin embargo, su origen reside en las necesidades de controlar el flujo de demandantes en situaciones de emergencia extrema como en cat ástrofes (Mass-Casualty Indicents, MCI) y pandemias [16, 17, 18]. M ás tarde, el triaje telef ónico nacer´ıa para convertirse en el canal principal de solicitud de atenci ón entre el paciente y la central que gestiona los recursos sanitarios.

Diferentes sistemas de triaje estructurado se han desarrollado y aplicado alrededor del mundo mostrando mayor eficacia con respecto a los triajes basados en la expe-riencia de los m édicos [19] entre los cuales est án; la Australian Triage Scale (ATS); la Canadian Emergency Department Triage and Acuity Scale (CTAS); el Manchester Triage System (MTS) [20]; el Emergency Severity Index (ESI); y el Sistema Espa ñol de Triaje (SET) adoptado por la Sociedad Espa ñola de Medicina de Emergencias (SE-MES) a partir del Model Andorr á de Triatge (MAT). En Espa ña se han implementado principalmente el Sistema Espa ñol de Triaje y el Sistema de Triaje de Manchester junto con otros de implantaci ón local [15]. Todos los nombrados son triajes de 5 niveles de urgencia:

◦ Nivel I: prioridad absoluta con atenci ´on inmediata y sin demora.

◦ Nivel II: situaciones muy urgentes de riesgo vital, inestabilidad o dolor muy inten-so.

◦ Nivel III: urgente pero estable hemodin ámicamente con potencial riesgo vital que probablemente exige pruebas diagn ósticas y/o terap éuticas.

◦ Nivel IV: urgencia menor, potencialmente sin riesgo vital para el paciente.

◦ Nivel V: no urgencia. Poca complejidad en la patolog´ıa o cuestiones administra-tivas, citaciones, etc.

(18)

Cap´ıtulo 2. Estado del arte

derecha). Si no se halla ninguno de los discriminantes, se contin ´ua del mismo modo con el nivel inmediatamente inferior (flecha hacia abajo).

Figura 2.1| Ejemplo de algoritmo de triaje del Sistema de Triaje de Manchester.

La situaci ón de alerta de pandemia requiere un tipo de actuaci ón especial enfo-cado a evitar la propagaci ón de la misma [21] procurando que los pacientes sospe-chosos de contraer la enfermedad mantengan el m´ınimo contacto con los pacientes de enfermedades comunes. Adem ás se desarrollantriajes avanzadosque incluyen un protocolo de actuaciones validado por el equipo m édico y de enfermer´ıa, como la rea-lizaci ón de determinadas pruebas complementarias y acciones terap éuticas previas al diagn óstico. El triaje telef ónico y los triajes de autoevaluaci ón han demostrado fun-cionar eficazmente especialmente para evitar el desbordamiento de las instalaciones y el contagio en situaciones de pandemia, y han minimizado el n úmero de traslados innecesarios [22, 23, 24, 25].

(19)

2.2. Productos y programas inform ´aticos

triaje telef ´onico y funciona de la siguiente forma:

1. Un teleoperador recepciona la llamada del paciente. La tarea del teleoperador es descartar los niveles de emergencia I y II. En el caso de que se den las condicio-nes para que se considere nivel I o II, se env´ıa un transporte de emergencia y/o atenci ´on al paciente.

2. En el caso de que sean descartados los dos niveles m ás urgentes, la llamada se deriva a un enfermero o m édico que valida el triaje del operador y profundiza en la anamnesia para la clasificaci ón del paciente en los niveles III, IV o V.

Con la llegada de la informatizaci ón y las nuevas tecnolog´ıas en el sector sanita-rio se han desarrollado productos IT que dan soporte a este proceso, agiliz ándolo y llev ándolo un paso m ás all á en cuanto a estructuraci ón y minimizaci ón de subjetividad [26].

2.2. Productos y programas inform ´aticos

El estado del arte en el ´ambito de los productos de asistencia al triaje se concentra casi totalmente en el sector privado. Numerosos productos comerciales se ofrecen para dar soporte a los procesos de clasificaci ´on:

◦ web e-PAT (Programa de Ayuda al Triaje del SET) [27]. Est á implantado en m ás de 100 hospitales de Espa ña y Latinoam érica. Ofrece asistencia a triaje de adul-tos, triaje pedi átrico, triaje telef ónico y triaje embarcado para ambulancias, as´ı como triajes para emergencias de incidentes de m últiples v´ıctimas. web e-PAT es propiedad de la empresa Treelogic.

◦ Infermedica [28]. Es una empresa que ha desarrollado una plataforma de soporte a servicios m édicos como diagn óstico y triaje, adem ás de otros m ás enfocados al desarrollador. Tienen productos listos para ser usados por los usuarios finales como unchat-bot para realizar un triaje o primer diagn óstico y un programa para dar soporte al triaje telef ónico por parte de los enfermeros.

◦ ehCOS Triage de Everis [29]. Basado en el Sistema de Triaje de Manchester, pero no se especifica que d ´e soporte al triaje telef ´onico.

(20)

Cap´ıtulo 2. Estado del arte

TeamHealth [34] que, o utilizan sistemas de triaje no estandarizados o no lo es-pecifican.

Los productos comerciales no suelen tener una especificaci ón t écnica p ública. El web e-PAT s´ı que descubre algunas de las tecnolog´ıas de las que hace uso. Utiliza el est ándar ICD-9 para clasificar las quejas principales en categor´ıas sintom áticas. Tambi én hace uso de est ándares de comunicaci ón entre sistemas sanitarios como el de mensajer´ıa HL7. Infermedica hace uso del est ándar SNOMED CT para ma-pear conceptos m édicos al hacer uso de su ontolog´ıa propietaria. SNOMED CT es especialmente útil para este tipo de mapeos y extracci ón de las quejas en textos no-estructurados [35, 36].

Hasta ahora, todas las estrategias utilizadas en los productos del mercado se ba-san en reglas: algoritmos en cascada haciendo uso de diferentes discriminantes1_para

la clasificaci ón de los pacientes. Sin embargo, en el campo de la investigaci ón est án surgiendo nuevos planteamientos que ayudar´ıan a aprovechar de manera m ás efecti-va las bondades de la inform ática. Un enfoque novedoso y eficaz es usar tecnolog´ıas de la web sem ántica y la computaci ón ubicua, ontolog´ıas y razonadores, como pro-ponen S ánchez et al. (2011) [37] y demuestran Wunschet al. (2017) [38]. San Pedro et al. (2004) [39] proponen un sistema m óvil de asistencia a la decisi ón tomando en cuenta estrategias basadas en reglas, como las ya mencionadas, y otras basadas en soft computing, como la l ógica difusa, útiles cuando la informaci ón que se obtiene del paciente es escasa o incompleta.

Abad-Grau et al. (2008) [40] ya revisaron los sistemas computacionales basados en m étodos tradicionales de triaje e indicaron la necesidad de evolucionar hacia las tecnolog´ıas sem ánticas y abrieron paso a estrategias basadas en machine learning, todav´ıa bajo un fuerte desarrollo, pero que viene progresando desde hace tiempo par-tiendo desde los modelos bayesianos [41] y explorando algoritmos m ás sofisticados como redes neuronales o m áquinas de soporte vectorial de manera muy promete-dora [42, 43, 44]. Sin embargo, Schenkel y Wears (2018) [45] han advertido de las limitaciones de estos m étodos, sobre todo en cuanto a los datos de entrenamiento: si se utilizan las decisiones de un humano, el modelo aprender á los sesgos y vicios que causan las imperfecciones de los sistemas actuales. Adem ás de utilizar machi-ne learning para predecir el nivel de emergencia de un paciente, se ha aprovechado para mejorar el proceso de anamnesis, elaborando herramientas para la sugerencia y el autocompletado de t érminos de las ontolog´ıas en la interfaz de usuario [46, 47] y

(21)

2.2. Productos y programas inform ´aticos

(22)

3

Cap´

ıtulo

Metodolog´ıa

Para llevar a cabo este proyecto se ejecut ó una metodolog´ıa “ ágil” que, aunque no corresponda espec´ıficamente con alguna de las conocidas, se nutre de su esencia. El m étodo consiste en hacer continuas iteraciones de tiempo variable (seg ún los requisi-tos a implementar) con un m áximo de dos semanas. En cada iteraci ón se ejecutaron las distintas fases del proceso de desarrollo software (An álisis de requisitos; Dise ño; Implementaci ón). Se consider ó como objetivo de la fase de prototipado el generar pe-que ños productos pe-que muestren las funcionalidades desarrolladas en cada iteraci ón. Al final de cada iteraci ón, el autor del proyecto (el alumno) se reuni ó con los clientes (los tutores) para valorar el resultado obtenido y establecer los objetivos de la siguiente iteraci ón.

(23)

3.1. Fases de trabajo

de bases de datos, el gestor de colas, etc. Al final del sprint nos reun´ıamos para revisar los objetivos y definir los del siguiente sprint.

3.1. Fases de trabajo

A continuaci ´on se enumeran las fases de trabajo en las que consisti ´o el Trabajo de Fin de Grado:

◦ Estudio inicial.

• Investigaci ón del estado del arte. Explorar proyectos, tecnolog´ıas y herra-mientas ya implementadas con el mismo objetivo, relacionado o que puedan ser útiles para nuestros proyectos para determinar qu é se ha alcanzado y qu é puntos de mejora y necesidad presenta el mercado. Llegar a conocer en profundidad los medios en los que se apoyar á el software para llevar a cabo la soluci ón. Tambi én profundizar en la materia de la ingenier´ıa del software para conseguir un software mantenible, seguro y fiable.

• An álisis de requisitos. Estudiar y comprender los principales requisitos que debe cumplir el producto del TFG y sus posibles puntos cr´ıticos. Especificar los casos de uso. Una peque ña parte del an álisis de requisitos se realiz ó al inicio de cada iteraci ón para la revisi ón e inclusi ón de nuevos requisitos.

◦ Dise ño. Dise ño l ógico del software a implementar para cumplir los requisitos mencionados en el apartado anterior.

◦ Implementaci ´on. Llevar a cabo la implementaci ´on de los casos de uso acordados con el cliente de forma iterativa.

◦ Redacci ón de memorias y documentaci ón. Describir el trabajo realizado y pro-veer informaci ón acerca de los resultados.

(24)

4

Cap´

ıtulo

An ´alisis del problema

En esta secci ón se especifican los requisitos funcionales y no funcionales que han madurado durante la etapa inicial y las iteraciones de la fases de desarrollo y que describir´ıan un producto m´ınimo viable, junto con los respectivos casos de uso en forma de texto y un diagrama UML de casos de uso. A continuaci ón, se propone una soluci ón a nivel conceptual que se amolda a dicha especificaci ón.

4.1. An ´alisis de requisitos

Puesto que el proyecto no se desarroll ´o para un cliente definido, estos requisitos han sido determinados por nosotros y validados por los co-directores del trabajo de fin de grado.

4.1.1. Requisitos no funcionales

Los requisitos no funcionales del producto m´ınimo viable son los siguientes:

◦ El servicio ser ´a agn ´ostico a la presencia de otros servicios y sistemas.

◦ El servicio debe poder ser integrable en un sistema externo.

(25)

4.1. An ´alisis de requisitos

◦ El servicio debe tener una disponibilidad cercana al 100 % de las veces en que un usuario intente accederlo.

◦ El servicio tendr ´a soporte multiplataforma.

◦ El servicio contar ´a con un manual de usuario y documentaci ´on sobre las APIs.

◦ El servicio trabajar á con informaci ón sem ánticamente interoperable.

◦ El software desarrollado ser ´a f ´acilmente mantenible y extensible.

4.1.2. Requisitos funcionales

Los requisitos funcionales del producto m´ınimo viable son los siguientes:

◦ El sistema debe gestionar distintos roles de usuario, entre los que estar ´an, como m´ınimo, teleoperador, facultativo y administrador.

◦ El administrador debe poder insertar nuevo algoritmo de triaje.

◦ El administrador debe poder actualizar un algoritmo de triaje.

◦ El administrador debe poder leer los algoritmos de triajes existentes.

◦ El administrador debe poder eliminar un algoritmo de triaje.

◦ El teleoperador debe poder descartar o confirmar que un paciente requiere asis-tencia m ´edica urgente.

◦ El facultativo debe poder recibir y revisar el pre-triaje realizado por un teleope-rador y obtener la clasificaci ón del paciente en la escala de emergencia dada la informaci ón recopilada (discriminantes, cuadro sintom ático, factores de riesgo).

4.1.3. Casos de uso

(26)

Cap´ıtulo 4. An ´alisis del problema

CU1 Un usuario administrador inserta un nuevo triaje.

Actor principal:Usuario con rol de administrador.

Participantes:Usuario administrador, teleoperadores, enfermeros/m ´edicos reguladores, beneficiarios del servicio de antenci ´on sanitaria.

Sistema:M ´odulo de gesti ´on de triajes.

Precondici ón: el usuario ha accedido a la aplicaci ón, est á autenticado en el sistema, tiene rol de administrador y se encuentra en la p ágina principal de administrador.

Garant´ıa m´ınima: se notificar ´a al usuario si ocurre un error en el registro del nuevo triaje.

Garant´ıa de éxito: el nuevo triaje quedar á registrado en el sistema y se notificar á al usuario el éxito del proceso.

Escenario principal de ´exito:

1. El usuario selecciona la opci ´on “insertar nuevo triaje”.

2. El sistema muestra un formulario de registro de un nuevo triaje.

3. El usuario completa correctamente el formulario.

4. El usuario selecciona la opci ´on “enviar”.

5. El sistema muestra una notificaci ´on de “registro exitoso”.

6. El sistema muestra la p ´agina de detalle del nuevo triaje.

CU2 Un usuario administrador visualiza la p ´agina de detalle de un triaje existen-te.

Precondici ón: el usuario ha accedido a la aplicaci ón, est á autenticado en el sistema, tiene rol de administrador y se encuentra en la p ágina principal de administrador.

Garant´ıa m´ınima:se notificar ´a al usuario en caso de que ocurra un error.

Garant´ıa de éxito:el sistema mostrar á la p ágina de detalle del triaje.

(27)

1. El usuario selecciona la opci ´on “ver detalles”de uno de los triajes del cat ´alogo, haciendo uso o no del buscador.

2. El sistema muestra la p ´agina de detalle del triaje.

CU3 Un usuario administrador actualiza triaje existente.

Precondici ón: el usuario ha accedido a la aplicaci ón, est á autenticado en el sistema, tiene rol de administrador y ha realizado elCU2para el triaje que se desea actualizar.

Garant´ıa m´ınima: se notificar ´a al usuario en caso de que ocurra un error en la actualizaci ´on.

Garant´ıa de éxito:el sistema actualizar á el triaje seleccionado y notificar á al usuario del éxito del proceso.

1. El usuario edita los campos de la p ´agina de detalle a modo de formula-rio.

2. El usuario selecciona la opci ´on “guardar”.

3. El sistema muestra una notificaci ´on de “actualizaci ´on exitosa”.

4. El sistema muestra la p ´agina de detalle del triaje actualizado.

CU4 Un usuario administrador elimina un triaje existente.

Precondici ón: el usuario ha accedido a la aplicaci ón, est á autenticado en el sistema, tiene rol de administrador y ha realizado elCU2para el triaje que se desea eliminar.

(28)

Garant´ıa de éxito:el sistema eliminar á el triaje seleccionado y notificar á al usuario del éxito del proceso.

1. El usuario selecciona la opci ´on de “eliminar”.

2. El sistema muestra un aviso pidiendo la confimaci ´on de la eliminaci ´on del triaje seleccionado.

3. El usuario confirma la eliminaci ´on.

4. El sistema muestra la notificaci ´on del “eliminaci ´on exitosa”.

5. El sistema muestra la p ´agina de cat ´alogo de triajes.

CU5 Un usuario realiza un triaje de detecci ´on de situaci ´on cr´ıtica.

Actor principal:Usuario con rol de teleoperador.

Sistema:M ´odulo de aplicaci ´on de triajes.

Precondici ón: el usuario ha accedido a la aplicaci ón, est á autenticado en el sistema, tiene rol de teleoperador, enfermero-m édico o administrador, se encuentra en la p ágina principal y existe en la base de datos el triaje que se desea evaluar.

Garant´ıa m´ınima: se notificar ´a al usuario en caso de que ocurra un error en la evaluaci ´on.

Garant´ıa de éxito:el sistema indicar á si el paciente est á en estado cr´ıtico o no y, en caso de no estarlo, encolar á el caso para la posterior evaluaci ón completa.

1. El usuario selecciona el algoritmo de triaje que desea evaluar identifica-do por la queja principal con ayuda del buscaidentifica-dor y selecciona la opci ´on “nuevo triaje parcial”.

2. El sistema muestra la p ´agina de asistencia para la evaluaci ´on del triaje.

3. El usuario recorre los discriminantes del algoritmo indicando si se han hallado o no en base a las respuestas del paciente.

4. El sistema muestra si el paciente se encuentra en estado cr´ıtico en base a las respuestas.

(29)

4.2. El usuario vuelve a la p ágina de asistencia para la evaluaci ón del triaje seleccionando la opci ón “volver”. Ir al paso 2.

5. El sistema detecta si el caso es no cr´ıtico y lo a ˜nade a la cola de casos pendientes de evaluaci ´on completa.

6. El sistema muestra la p ´agina principal.

CU6 Un usuario realiza un triaje completo.

Actor principal:Usuario con rol de profesional sanitario.

Precondici ón: el usuario ha accedido a la aplicaci ón, est á autenticado en el sistema, tiene rol de profesional sanitario o administrador, se encuentra en la p ágina principal y existe en la base de datos el triaje que se desea evaluar.

Garant´ıa de ´exito:el sistema indicar ´a el nivel de urgencia del paciente.

1. El usuario selecciona el algoritmo de triaje que desea evaluar identifica-do por la queja principal con ayuda del buscaidentifica-dor y selecciona la opci ´on “nuevo triaje completo”.

2. El sistema muestra la p ´agina de asistencia para la evaluaci ´on del triaje.

4. El sistema muestra el nivel de urgencia asociado al paciente en base a las respuestas.

4.1. El usuario finaliza la evaluaci ´on seleccionando la opci ´on “confirmar”.

(30)

CU7 Un usuario completa un caso no cr´ıtico pendiente.

Actor principal:Usuario con rol de profesional sanitario.

Precondici ón: el usuario ha accedido a la aplicaci ón, est á autenticado en el sistema, tiene rol de profesional sanitario o administrador, se encuentra en la p ágina principal y existe al menos un caso pendiente.

Garant´ıa de ´exito:el sistema indicar ´a el nivel de urgencia del paciente.

1. El usuario selecciona la opci ´on “evaluar un caso pendiente”.

2. El sistema muestra la p ágina de asistencia para la evaluaci ón del triaje y la informaci ón parcial recopilada en el proceso anterior.

4. El sistema muestra el nivel de urgencia asociado al paciente en base a las respuestas.

4.1. El usuario finaliza la evaluaci ´on seleccionando la opci ´on “confirmar”.

(31)

Diagrama de casos de uso

Health professional Telephone operator

Administrator Insertar un

nuevo algoritmo de triaje

Actualizar un algoritmo de

triaje existente

Eliminar un algoritmo de triaje existente

Visualizar todos los algoritmos de

triaje

Visualizar la página de detalle de un

triaje

(32)

Health professional Telephone operator

Administrator Realizar un triaje

de detección de situación crítica

Realizar un triaje completo

Completar un caso no crítico

pendiente

Ver el número de casos pendientes

Ver el número de casos pendientes en

tiempo real

(33)

4.2. Soluci ´on propuesta

4.2. Soluci ´

on propuesta

Aunque las nuevas estrategias que exploran el campo del aprendizaje autom ático y los metadatos sem ánticos y ontol ógicos demuestran un futuro prometedor, a ún est án bajo una fuerte investigaci ón y desarrollo y queda camino para que tenga la suficiente madurez que aporte la confianza necesaria para ser usado en un entorno real. Dicho esto, el servicio de asistencia al triaje que proponemos se basa en clasificaciones ba-sadas en reglas, algoritmos previamente validados por un equipo de expertos. En la secci ón del estado del arte se discute el gran n úmero de est ándares diferentes usados de manera relevante, adem ás de el hecho de la variabilidad de la adopci ón y la con-vivencia de estos en un mismo entorno, como en hospitales de la misma comunidad aut ónoma o incluso de un mismo municipio [15, 49]. En esta soluci ón no se aferra a ninguno de los nombrados espec´ıficamente y es una caracter´ıstica que se presenta como ventaja. Asimismo, como apoyo para el an álisis, dise ño e implementaci ón de la soluci ón, se ha tomado como referencia el Sistema de Triaje telef ónico de Manchester dado que era el m ás accesible en el momento del desarrollo del proyecto.

El flujo de trabajo pensado para dar soluci ´on al problema tiene en cuenta a dos tipos de profesionales:

◦ Teleoperador auxiliar de regulaci ón m édica. Se trata de un profesional no m édico pero entrenado que se encarga de recibir la llamada del paciente y de detectar, de la forma m ás temprana posible, si el paciente se encuentra entre los niveles cr´ıticos del triaje con la ayuda del software.

◦ M ´edico o enfermero regulador. Es el personal cualificado que se encarga de cla-sificar a los pacientes una vez que se han descartados los niveles de emergencia cr´ıticos por parte del teleoperador.

Este enfoque de sistema con teleoperadores como primer filtro se lleva a la pr ´actica en el sistema de triaje telef ´onico del SET. Teniendo en cuenta estos dos tipos de usuarios del sistema, el flujo de trabajo consiste en los siguientes pasos:

◦ Para el teleoperador:

(34)

2. El teleoperador formula las preguntas del algoritmo de triaje para determinar si el paciente se encuentra entre los niveles cr´ıticos de emergencia.

3. a) Si el teleoperador encuentra alguno de los discriminantes que indican que el paciente se ubica en alguno de los niveles cr´ıticos, env´ıa el resul-tado del triaje y despacha los recursos necesarios para cubrir la emer-gencia, concluyendo el proceso.

b) Si el teleoperador no encuentra ning ún discriminante que indique una situaci ón cr´ıtica del paciente, concluye su pre-triaje y despacha la soli-citud de triaje por parte de un m édico o enfermero regulador.

◦ Para el m ´edico o enfermero regulador:

1. El m ´edico solicita recibir una llamada de un paciente en cola del cual haya sido descartado una situaci ´on cr´ıtica.

2. El m ´edico recibe la informaci ´on delpre-triaje realizado por el teleoperador, en el que se incluye la queja principal seleccionada.

3. El m édico realiza las preguntas pertinentes para confirmar o descartar la informaci ón recibida y ampliarla con el objetivo de completar el proceso de clasificaci ón.

Se puede ver un esquema de este flujo de trabajo en la figura 4.3.

Figura 4.3| Flujo de trabajo en la atenci ´on telef ´onica.

(35)

4.2. Soluci ´on propuesta

dar los consejos pertinentes al paciente e indicar qu ´e medidas tomar si la situaci ´on empeora.

Incluyendo nuestro servicio de triaje en este flujo de trabajo, este constar´ıa de 5 participantes diferentes: el paciente que llama para solicitar la atenci ón; el teleopera-dor de regulaci ón m édica, que es un profesional no sanitario pero entrenado para este trabajo; el m édico o enfermero; nuestro servicio de triaje; y un usuario administrador. El teleoperador recibe la llamada del paciente y lo eval úa con la asistencia del servicio de triaje (que adem ás va auditando los usos del mismo) de forma parcial, para encon-trar si el paciente se encuentra entre los niveles por encima del l´ımite de riesgo que ve´ıamos antes. Si, en efecto, el paciente est á en un estado en el que necesita aten-ci ón urgente, el teleoperador despacha los recursos necesarios. Si el estado no es cr´ıtico, el servicio de triaje env´ıa el caso a una cola, a la espera de que un profesional sanitario la reciba. Los m édicos, del otro lado, van consumiendo los casos de la cola y los eval úan tambi én con ayuda del servicio de triaje. Por otro lado, el administrador se encargar´ıa de mantener los algoritmos de triaje, a ñadiendo nuevos, actualiz ándolos o elimin ándolos. As´ı, se definen los 3 roles que va a tener el servicio: teleoperador, que s ólo tendr á permisos para hacer triajes parciales, profesional sanitario, que podr á hacer triajes completos y parciales, y administrador, que podr á realizar cualquier tipo de triaje y cualquier operaci ón sobre los triajes.

En la figura 4.4 se puede ver un esquema que describe el flujo de trabajo teniendo en cuenta nuestro servicio de triaje.

Aunque hemos tomado como sistema de referencia el Sistema de Triaje de Man-chester, el sistema ha sido dise ˜nado para dotarle de la m ´axima flexibilidad a la hora de tratar con triajes estructurados:

◦ N ´umero de niveles de emergencia no fijado.

◦ N ´umero de discriminantes por nivel no fijado.

◦ N ´umero de consejos por nivel no fijado.

◦ Capacidad de incluir preguntas en lenguaje natural (cero o m ´as para cada dis-criminante) con el objetivo de asistir en el proceso de anamnesis al usuario que aplica el triaje.

◦ Capacidad de incluir la definici ´on de cada uno de los discriminantes.

(36)

Figura 4.4 | Flujo de trabajo en la atenci ´on telef ´onica haciendo uso del servicio de triaje.

Algo que todos los triajes telef ónicos deben incluir es una queja, signo o s´ıntoma principal que identificar á el algoritmo en cuesti ón. Algunos ejemplos son abcesos o infecciones locales,dolor de espalda,llanto de beb éy, como un caso especial,petici ón de medicamento.

Es responsabilidad del sistema de triaje utilizado garantizar la cobertura de todas las quejas y posibles situaciones que se puedan dar y la consistencia en sus evalua-ciones, ya que es com ún que los signos principales reportados por un paciente puedan corresponderse con m ás de unaqueja principal que identifican a diferentes algoritmos de triaje. En este sentido, sea cual sea el algoritmo elegido entre los aplicables, el resultado de la clasificaci ón deber´ıa ser el mismo.

(37)

(38)

5

Cap´

ıtulo

Dise ˜

no e implementaci ´

on

5.1. Arquitectura software

En esta secci ón se describe el enfoque que se ha llevado a cabo en cuanto a disposici ón, modularizaci ón, aislamiento y comunicaci ón entre los componentes del sistema.

5.1.1. Arquitectura a nivel de macrodise ˜

no

En esta primera subsecci ón se describe el dise ño de la capa de m ás alto nivel. Concretamente se esclarece cuales ser án los distintos servicios dentro del sistema sanitario y la comunicaci ón entre ellos.

(39)

au-5.1. Arquitectura software

tenticaci ón y autorizaci ón, lo que conllevar´ıa la replicaci ón de los ya existentes en el sistema externo, o mantener la informaci ónfueradel sistema externo en una base de datos propia en el caso de la auditor´ıa. En la figura 5.1 se muestra la arquitectura que asumimos que tendr á el sistema una vez completa la integraci ón y el despliegue.

Figura 5.1| La arquitectura del sistema propuesta.

(40)

Cap´ıtulo 5. Dise ˜no e implementaci ´on

primera vez o cuando eltokense haya expirado.

Client API Gateway _{Auth Service} Triage Service

submit credentials

forward request

return access token

validate credentials

forward response token

send request to triage resource endpoint with access token

forward request

validate token get user information

from token payload return response

forward response

Existing CRM

Figura 5.2| Diagrama de secuencia de una petici ´on a unendpoint protegido del servicio de triaje.

Para el caso de la auditor´ıa, se aprovecha la estrategia de las arquitecturas orien-tadas a eventos que se usan extensamente en entornos distribuidos. Nuestro sistema publicar á eventos a los cuales se puede suscribir cualquier otro componente sin te-ner que extender el servicio de triaje. Estos eventos pueden publicarse a un sistema de colas, como RabbitMQ, y, dado que es un proceso as´ıncrono, en alg ún momento un worker que est é suscrito a éstos lo consume y lo env´ıa al servicio de auditor´ıa del sistema externo para su almacenaje. En nuestro caso, hemos considerado que son eventos de inter és para la auditor´ıa el haber realizado un triaje parcial o el haber realizado un triaje completo.

En definitiva, lo que conseguimos con esta arquitectura es que nuestro servicio est é totalmente desacoplado y sea agn óstico a los distintos servicios que puedan acompa ñarle.

5.1.2. Arquitectura a nivel de microdise ˜

no

(41)

apli-5.1. Arquitectura software

caciones con muy poco acoplamiento e independiente de detalles de implementaci ón, como es el caso de todo lo relacionado con entrada/salida (por ejemplo, el sistema de persistencia, o las interacciones con plataforma o sistema operativo) o el uso de frameworks. Las aplicaciones resultan f ácilmente testeables, extensibles y manteni-bles. Consiste en separar y agrupar los componentes de la aplicaci ón en varias capas “conc éntricas” seg ún el nivel de abstracci ón de su l ógica, por lo que nos hace cum-plir ya en cierto grado el principio de responsabilidad única. Podemos reducir estas capas a las de dominio, aplicaci ón e infraestructura. El dominio se encuentra en el coraz ón del programa y por encima de él se encuentran la capa de aplicaci ón y la de infraestructura, en ese orden.

En la figura 5.3 se puede ver un esquema explicativo de la arquitectura limpia de Robert C. Martin. A la izquierda, la capa amarilla constituye la capa de dominio, la capa roja constituye la capa de aplicaci ón y las capas verde y azul constituyen la capa de infraestructura. A la derecha se clarifica c ómo se satisface el principio de inversi ón de dependencias y el flujo de control.

Figura 5.3| La arquitectura limpia.

(42)

en-Cap´ıtulo 5. Dise ˜no e implementaci ´on

tidades de dominio en datos planos y sus respectivos mapeadores y los casos de uso o application services, que son clases que contienen la l ógica que se encarga de orquestar el comportamiento del dominio en cada uno de los casos de uso de la aplicaci ón. Por último, en la capa m ás externa, se encuentra el c ódigo que de algu-na forma se acopla a algualgu-na tecnolog´ıa ajealgu-na a la aplicaci ón, como los controladores delframework web, las implementaciones de los repositorios o c ódigo con interacci ón con el sistema de ficheros. Estas capas tienen una estricta regla de dependencia de fuera hacia dentro, es decir, la capa dominio no puede depender de ning ún compo-nente de otra capa, la capa de aplicaci ón solo puede depender de la capa de dominio y la capa de infraestructura no tiene restricci ón. Para asegurar esto, se cumple el principio de inversi ón de dependencias y, cuando capas m ás internas interact úan con l ógica de m ás bajo nivel, lo hacen a trav és de interfaces implementadas por capas m ás externas. Esto es, las capas internasexponen puertos y las capas externas pro-veen sus adaptadores. Un ejemplo es la persistencia de los datos: el dominio hace uso de repositorios conociendo únicamente su API, y en la capa de infraestructura se encontrar án los adaptadores que implementen esa API, que podr´ıan ser una im-plementaci ón usando MongoDB o una imim-plementaci ón manteniendo una tabla hash en memoria siendo ambas totalmente intercambiables, cumpliendo con el principio de sustituci ón de Liskov. Este enfoque de puerto-adaptador se basa directamente en el principio de segregaci ón de interfaces y permite, en última instancia, cumplir con el principio abierto-cerrado.

Adem ás de el aislamiento del microservicio de triaje con respecto a su entorno, existe tambi én una separaci ón de la l ógica en el interior de éste en base a la res-ponsabilidad o inter és desde el punto de vista de negocio. Concretamente, se sepa-ra la l ógica de la evaluaci ón de los triajes y su gesti ón de la l ógica relacionada con la identidad y el acceso. Es por esto que existen los directorios identity-access y triage-evaluation. Estos dos entornos distintos reciben el nombre debounded con-texts o contextos limitados, seg ún describe la metodolog´ıa del dise ño guiado por el dominio. Con esto conseguimos mayor mantenibilidad e independencia entre los dos contextos distintos.

(43)

5.1. Arquitectura software

Ciclo de vida de la petici ´on

Para dar una buena visi ón general de alto nivel de c ómo funciona la aplicaci ón respecto a los distintos componentes que se han nombrado en esta secci ón, se explica a continuaci ón el flujo de control durante el ciclo de vida de una petici ón HTTP.

Tradicionalmente, cuando llega una nueva petici ón, ésta pasa por los filtros del framework que haya configurados. Nosotros, para tener mayor control sobre la l ógica que se ejecuta entorno a los casos de uso (o application services) y tener mayor capacidad de reutilizaci ón al no acoplarnos al framework, implementamos una serie deproxies/decoradores que envolver án a las instancias de losapplication servicesen lugar de usar estos filtros delframework.

En el siguiente segmento de c ´odigo se puede ver la l ´ogica del controlador que se ejecuta en el endpoint POST - /triage, que se corresponde con el caso de uso ¨ınsertar nuevo algoritmo triaje”.

@PostMapping

public ResponseEntity insertTriage(

@RequestBody final CreateTriageRequest request, @RequestBody String body,

@RequestHeader("Authorization") String authHeader ) {

new EventPublisherResetApplicationService<>(

new SecuredApplicationService<>(

new TriageJSONSchemaValidationApplicationService<>(

new CreateTriage(repository, mapper), jsonSchema, body ), authService, JWTAuthorizationData.fromAuthorizationHeaderString( authHeader,

(44)

return ResponseEntity.ok().build(); }

Podemos ver que el application service principal que representa el caso de uso,

CreateTriage, est ´a siendo “extendido” por tres decoradores.EventPublisherResetApplicationService se encarga de resetear elevent publisher y configurar los suscriptores que van a

es-cuchar los eventos que se disparen durante la petici ´on, tal y como se ve en el siguiente segmento de c ´odigo.

public class EventPublisherResetApplicationService<S, T extends

ApplicationRequest> implements ApplicationService<S, T> {

private ApplicationService<S, T> proxiedApplicationService;

private EventStore eventStore;

private PendingTriagesQueue queue;

private Channel rabbitMQChannel;

public EventPublisherResetApplicationService(

ApplicationService<S, T> proxiedApplicationService, EventStore eventStore,

PendingTriagesQueue queue, Channel rabbitMQChannel ) {

this.proxiedApplicationService = proxiedApplicationService;

this.eventStore = eventStore;

this.queue = queue;

this.rabbitMQChannel = rabbitMQChannel; }

@Override

public S execute(T request) {

(45)

} }

Despu és, se ejecuta la l ógica del decorador SecuredApplicationService, que se encargar á de autorizar al usuario la ejecuci ón del caso de uso seg ún sus permisos. En este caso, se le inyecta al decorador el puerto AuthorizationService. En el en-torno de producci ón real, un adaptador debe ser implementado haciendo uso de un proveedor externo, como otro microservicio, o incluyendo toda la l ógica necesaria en el mismo adaptador. En este caso, hemos simulado el servicio de autorizaci ón con una implementaci óndummy.

El tercer y ´ultimo decorador, TriageJSONSchemaValidationApplicationService, se encarga de validar el payload de la petici ´on en formato JSON, siguiendo el esque-ma que se encuentra en el repositorio

(applications/main/resources/triage-json-schema.json).

Los application services y sus decoradores deben conocer únicamente interfaces de dominio o componentes de la capa de aplicaci ón para cumplir la regla de depen-dencia. En nuestro caso se cumple para todos los application services principales, aunque para algunas dependencias de los decoradores se ha roto la regla para agili-zar el desarrollo. Como se explicar á en el cap´ıtulo 7, en las conclusiones, este tipo de arquitectura conlleva ingenier´ıa excesiva para dominios poco cambiantes y sencillos.

En cualquier caso, todas las dependencias de los casos de uso y sus decoradores son inyectadas previamente en el controlador haciendo uso del potente contenedor de dependencias delframework.

Siguiendo con el ciclo de vida de la petici ón, una vez llegados a la ejecuci ón del application service principal, éste normalmente necesita recuperar el estado desde alg ún sistema de persistencia. Lo que conoce el caso de uso es una interfaz de domi-nio que representa esta responsabilidad, que tiene una implementaci ón en MongoDB. En el siguiente segmento de c ódigo se muestra la l ógica del caso de uso de evaluar el estado cr´ıtico del paciente, es decir, realizar un triaje parcial.

public CriticalCheckAssesmentOutput execute( CheckForCriticalStateRequest request ) {

ChiefComplaint selectedChiefComplaint = new ChiefComplaint(

new ClinicalFindingId(request.triageChiefComplaintId), null); Triage selectedTriage = repository.find(selectedChiefComplaint);

(46)

throw

TriageDoesNotExistException.withChiefComplaint(selectedChiefComplaint); }

CriticalCheckAssesmentOutput output = selectedTriage.checkForCriticalState( request.findingIds.parallelStream().map(fStr -> new

ClinicalFinding(new ClinicalFindingId(fStr),

null)).collect(Collectors.toList()) );

if (!output.hasCriticalState) { queue.enqueue( CriticalCheckTriageAssessed.create(selectedTriage.chiefComplaint(), output)); EventPublisher.instance().publish( new PendingCasesQueueSizeChanged()); } return output; }

Una vez que el caso de uso consigue las entidades necesarias, ejecuta las ac-ciones pertinentes, que disparan los eventos de dominio correspondientes, de for-ma que los subscribers saben cu ´ando tienen que ejecutarse. En el caso del seg-mento de c ´odigo anterior, si el estado resulta ser no cr´ıtico, se publica el evento PendingCasesQueueSizeChanged, cuyo subscriber es

RabbitMQQueueSizeChangedNotificationSubscriber. Este subscriber se encargar á de publicar altopic queue-sizede RabbitMQ, que es el canal de notificaci ón en tiem-po real del n úmero de casos pendientes. Se puede ver la l ógica descrita en el siguiente segmento de c ódigo.

public class RabbitMQQueueSizeChangedNotificationSubscriber implements

EventSubscriber<PendingCasesQueueSizeChanged> {

private final Channel rabbitMQClient;

private final PendingTriagesQueue queue;

public RabbitMQQueueSizeChangedNotificationSubscriber(Channel rabbitMQClient, PendingTriagesQueue queue) {

this.rabbitMQClient = rabbitMQClient;

this.queue = queue; }

@Override

(47)

long queueSize = queue.numberOfEnqueuedCases();

try {

rabbitMQClient.basicPublish(

"amq.topic",

"queue-size",

null,

Long.toString(queueSize).getBytes()); } catch (IOException e) {

throw new RuntimeException("Couldn’t publish queue size notification.");

} }

@Override

public Class<PendingCasesQueueSizeChanged> subscribedToEventType() {

return PendingCasesQueueSizeChanged.class; }

}

Al final de la ejecuci ón del caso de uso, si fuera necesario, el mapeador de los datos transformar´ıa las entidades en objetos planos de transporte de datos (DTO,data transfer object) y éstos ser´ıan retornados. Puede verse, como ejemplo, el siguiente segmento de c ódigo perteneciente al caso de uso de la evaluaci ón del triaje completo.

AlgorithmLevel output = selectedTriage.fullyAssess(

request.findingIds.parallelStream().map(fStr -> new ClinicalFinding(new

ClinicalFindingId(fStr), null)) .collect(Collectors.toList()), prevAssesment

);

return mapper.mapAlgorithmLevel(output);

Por ´ultimo, estos datos los utilizar´ıa el presentador deframework para representarlo en JSON o el formato que fuere.

(48)

Figura 5.4| Reglas de dependencias entre las diferentes capas de la aplicaci ´on.

5.2. Interfaz de usuario

Como ejemplo de consumidor del servicio de triaje, hemos implementado una in-terfaz web que utiliza todos los casos de uso disponibles en elback-end. Esta interfaz web est á desarrollada en VueJS como una SPA (single page application), que evita re-cargas de la p ágina cuando se cambia de vista aprovechando la t énica de desarrollo AJAX (Asynchronous Javascript and XML).

Los estilos de la interfaz se han desarrollado sin hacer ning ´un uso de frameworks o preprocesadores de CSS.

Con elframework VueJS desarrollamos bas ´andonos en componentes, que son ins-tancias reusables del propio Vue con un nombre concreto que usamos como etiqueta. Por ejemplo:

<TriageProcess

:selectedTriage="selectedTriage"

:step="startingStep"

@confirmed="onConfirmation"

></TriageProcess>

Es un paradigma muy similar a la nueva especificaci ´on de Web Components de la w3c.

(49)

5.2. Interfaz de usuario

5.2.1. Acceso

La autorizaci ´on funciona de forma simulada en el backend esperando tres posi-blestokensque corresponden a los tres roles diferentes de la aplicaci ´on:token-admin,

token-health-professionalytoken-telephone-operator. Por otra parte, en el clien-te se simula la auclien-tenticaci ón, inclien-terceptando las llamadas a cierto endpoint. En nues-tro caso, existen tres usuarios distintos con mismo nombre de usuario y contrase ña: admin,healthprofessionalytelephoneoperator. Con cada una de las credenciales, el cliente web almacenar á el respectivo token de acceso, antes nombrado, que habr á “devuelto” la llamada.

Figura 5.5| Pantalla de acceso.

5.2.2. Pantalla principal del administrador

(50)

Figura 5.6| Pantalla principal del administrador.

5.2.3. Pantalla principal del profesional sanitario

En la figura 5.7 se puede ver la pantalla principal del profesional sanitario. A dife-rencia del administrador, los usuarios con este rol no podr ´an realizar un triaje parcial.

(51)

5.2.4. Pantalla principal del teleoperador

En la figura 5.8 se puede ver la pantalla principal del teleoperador. Los usuarios con este rol solo tienen permitido realizar triajes parciales.

Figura 5.8| Pantalla principal del teleoperador.

5.2.5. Buscador

Un componente en com ún para todos los usuarios es el buscador de la queja prin-cipal de la llamada, que es identificador de cada algoritmo de triaje. En este caso, se cargan todos los triajes almacenados para hacer una b úsqueda en memoria en el pro-pio cliente, puesto que el n úmero de algoritmos de triaje es reducido en un sistema bien dise ñado.

(52)

Figura 5.9| Buscador.

(53)

5.2.6. Pantalla de carga

Uno de los aspectos m ás importantes en el dise ño de interfaces es el de asegurar el ofrecimientofeedback informativo. Por ello, es importante a ñadir pantallas de carga, sobre todo en las simple page applications, donde la pesta ña del navegador nunca recarga.

En nuestra interfaz, aparece la secci ón del contenido de la aplicaci ón en blanco y una animaci ón en el centro de ésta para indicar el estado “cargando”.

Figura 5.11| Pantalla de carga.

5.2.7. Triaje parcial

En la figura 5.12 se puede ver la pantalla del proceso de triaje parcial. A la izquier-da se muestran los discriminantes que pertenecen a los niveles cr´ıticos del algoritmo. Los discriminantes que pertenecen a niveles m ás urgentes aparecen m ás arriba. A la derecha se muestran la queja principal que identifica al algoritmo, el nombre del dis-criminante, su definici ón y las preguntas sugeridas. Abajo se encuentran los botones que sirven para indicar si se ha hallado el discriminante o no, omitir el paso o volver al paso anterior.

(54)

ya que m ás tarde un profesional sanitario se encargar á de evaluar de manera m ás profunda el caso.

Por otro lado en la figura 5.14 se muestra la pantalla de confirmaci ´on y finalizaci ´on habiendo encontrado un estado cr´ıtico y, por lo tanto, mostrando las recomendaciones oportunas mientras llegan los recursos de emergencia.

Figura 5.12| Inicio del proceso de triaje parcial.

(55)

Figura 5.14| Confirmaci ´on y finalizaci ´on del triaje parcial con estado cr´ıtico.

5.2.8. Triaje completo

El caso de la pantalla del triaje completo es parecido al del triaje parcial. A diferen-cia de éste, a la izquierda se muestran los discriminantes de todos los niveles. A la derecha, la informaci ón mostrada por cada discriminador y los botones de navegaci ón son id énticos. Se puede ver en la figura 5.15.

(56)

Figura 5.15| Inicio del proceso de nuevo triaje completo.

(57)

5.2.9. Triaje pendiente

La pantalla del triaje pendiente es id éntica a la del triaje completo, s ólo que utiliza la informaci ón del triaje parcial previo. Se muestra en la figura 5.17.

La opci ´on de evaluar un caso pendiente se muestra desactivada si la aplicaci ´on detecta que no hay casos en cola, como muestra la figura 6.1.

(58)

(59)

5.3. An ´alisis de las herramientas

Para satisfacer el requisito de soporte multiplataforma se ha escogido la plataforma de desarrollo de JVM y, en concreto, el lenguaje de programaci ón Java. Asimismo, el software podr á ser distribuido en un contenedor de Docker, por lo que se facilita la instalaci ón y despliegue en cualquier sistema operativo.

De alta importancia es tambi én dotar al sistema de interoperabilidad sem ántica para facilitar la comunicaci ón entre distintos proveedores y as´ı mejorar los servicios sanitarios. Con este objetivo, es necesario trabajar con vocabularios est ándar para la representaci ón de informaci ón m édica. Desde el inicio del proyecto se preve´ıa usar la ontolog´ıa HPO (Human Phenotype Ontology) para conseguir la interoperabilidad sem ántica y para aprovechar caracter´ısticas propias de las ontolog´ıas, como la ca-pacidad de computar valores de similitud entre conceptos, que se cre´ıan que pod´ıan ser necesarias para dar soluci ón al problema. Tras el estudio del estado del arte, se clarific ó que una mejor opci ón ser´ıa la ontolog´ıa de SNOMED CT. SNOMED CT (Sys-tematized Nomenclature of Medicine – Clinical Terms) tiene versiones bastante m ás maduras en otros idiomas aparte del ingl és, incluso con extensiones localizadas (por ejemplo, hay una versi ón en espa ñol de Espa ña y en espa ñol de Argentina y espa ñol de Uruguay), es el vocabulario sanitario m ás amplio y preciso que existe e incluye los conceptos necesarios para definir todas las quejas principales, todos los hallazgos cl´ınicos y todos los discriminantes. Sin embargo, la HPO incluy ó hace muy poco al-gunos conceptos de signos y s´ıntomas comunes, m ás all á de fenotipos relacionados con enfermedades hereditarias, lo cual se presenta como un problema por su poca madurez. Adem ás, la HPO no ha sido traducida al espa ñol. La principal ventaja de SNOMED CT es que es un vocabulario extensible, de modo que se pueden construir expresiones inequ´ıvocas que identifiquen conceptos m édicos con cualquier nivel de refinamiento. La IHTSDO (International Health Terminology Standards Development Organisation), la organizaci ón que posee SNOMED CT, ha desarrollado una librer´ıa para Java con el objetivo de analizar y validar sint ácticamente estas expresiones, de la cual se hace uso en este programa.

(60)

va-Cap´ıtulo 5. Dise ˜no e implementaci ´on

lidador de los datos que recibe la aplicaci ón. Usando este est ándar, podemos hacer uso de librer´ıas que realicen la validaci ón por nosotros, pas ándole los datos recibidos y elschemaque debe cumplir.

Uno de los requisitos m ás complejos es el de hacer el servicio agn óstico a otros sistemas externos y proveer la capacidad de ser integrable en un CRM. Para dar so-luci ón a esta condici ón es clave la arquitectura del sistema completo. Se ha pensado el servicio de triaje como un microservicio que es, por definici ón, independientemente funcional y que puede ser integrado con otros servicios (en este caso, todo el sistema CRM existente) a trav és de su API expuesta. Se detalla este enfoque en profundidad en la secci ón 5.1.1.

Esta API expuesta por el microservicio puede ser desarrollada sobre diferentes protocolos como HTTP, AMQP o incluso directamente sobre TCP. Sin embargo, HTTP es un candidato suficientemente bueno y conocido como para explorar las otras alter-nativas.

Teniendo claro el principal punto de entrada de la aplicaci ón, una API HTTP, el siguiente paso l ógico es elegir un framework sobre el que apoyarse: no es justifica-ble implementar desde cero toda la l ógica relacionada con la comunicaci ón HTTP y el funcionamiento de un servidor en Java. As´ı pues, un candidato competente es el framework Spring Boot, uno de los m ás usados y conocidos, si no el que m ás.

La persistencia de los algoritmos de triaje se ha realizado haciendo uso del gestor de bases de datos NoSQL MongoDB, debido a su facilidad de uso y manejo de docu-mentos JSON, el formato de datos que se va a utilizar a lo largo de todo el proyecto.

Con respecto a la interfaz web, se ha escogido Vue como framework de desarrollo por su facilidad de aprendizaje, por su entorno de desarrollo modular y flexible y por su rico ecosistema y versatilidad.

(61)

5.3. An ´alisis de las herramientas

trabajar con WebSockets por su mayor facilidad de integraci ´on con Spring Boot y el message broker RabbitMQ, a trav ´es del formato de datos STOMP.

Igualmente, la elecci ón de RabbitMQ como message broker ha sido influida por la facilidad de integraci ón con Spring Boot, aunque tambi én es remarcable ser uno de losmessage broker m ás utilizados.

5.3.1. Herramientas de desarrollo

IntelliJ IDEA

IntelliJ IDEA es un entorno de desarrollo integrado (integrated development envi-ronment, IDE) para desarrollar software. Est á desarrollado por el equipo de JetBrains y est á disponible una edici ón community con una licencia Apache 2 y una edici ón comercial con una licencia propietaria [50].

Entre sus funcionalidades se encuentra una asistencia en la escritura de c ódigo muy potente (autocompletado de c ódigo analizando el contexto, navegaci ón, refacto-rizaci ón, linting o detecci ón de errores y sugerencias para arreglar inconsistencias); herramientas incorporadas e integraci ón con otras herramientas de desarrollo como gestores de dependencias, control de versiones, gestores de bases de datos, Docker, etc.; un gran ecosistema deplugins que permiten a ñadir funcionalidades al IDE; y so-porte de m últiples lenguajes de programaci ón, frameworks y tecnolog´ıas (la mayor´ıa a trav és deplugins).

Visual Studio Code

Visual Studio Code es un editor de c ódigo multiplataforma y con soporte multilen-guaje. Permite abrir uno o m ás directorios que pueden ser guardados como workspa-ces para su reutilizaci ón. Tiene una potente command palette que permite acceder a numerosas caracter´ısticas que no son expuestas en los men ús.

Se puede extender en funcionalidad v´ıaplugins, que est án a disposici ón a trav és de un repositorio central. Una caracter´ıstica notable es la capacidad de crear extensiones que a ñaden asistencia para nuevos lenguajes, apariencias, depuradores, an álisis de c ódigo est ático o linters haciendo uso del Language Server Protocol y conectarse a servicios adicionales.

(62)

pueda usarse en cualquier plataforma, en cualquier lugar y para cualquier lenguaje de programaci ´on [51].

Git

Git es un sistema de control de versiones distribuido para supervisar los cambios en el c ´odigo durante el desarrollo de software. Es dise ˜nado para coordinar el trabajo entre programadores, pero puede ser usado para monitorear cambios en cualquier conjunto de archivos. Sus objetivos incluyen la rapidez, la integridad de los datos y el soporte para flujos de trabajo distribuidos y no lineales.

Fue creado por Linus Torvalds en 2005 para el desarrollo del kernel de Linux con otros desarrolladores del kernel que contribuyeron a su desarrollo inicial. Su principal encargado de mantenimiento desde 2005 es Junio Hamano. Tal y como la mayor´ıa de los otros sistemas de control de versiones distribuido y a diferencia de la mayor´ıa de los sistemas cliente-servidor, cada directorio Git en cada ordenador es un repositorio integral, con la historia completa y con capacidades completas, independientemente de la existencia de conexi ´on a internet o de un servidor central.

Es, adem ´as, software libre y de c ´odigo abierto, distribuido bajo la licencia GPL 2.

Github

GitHub es una empresa que provee de un servicio de alojamiento de c ´odigo para el control de versiones del desarrollo de software usando el anteriormente mencionado Git.

Ofrece todos las funcionalidades del control de versiones distribuido y de la ges-ti ón del c ódigo, adem ás de proveer sus propias prestaciones. Proporciona control de acceso y varias funciones de colaboraci ón como el monitoreo de bugs, peticiones de nuevas caracter´ısticas, gesti ón de tareas ywikis para cada proyecto.