Diseño de la Arquitectura de un Sistema de Apoyo a ...

Diseño de la Arquitectura de un Sistema de Apoyo a Decisiones Clínicas para facilitar el

proceso de Clasificación de Urgencias Hospitalarias, en el contexto de la salud en

Colombia

Luis Felipe Tabares Pérez, [email protected]

Jhonatan Fernando Hernández Silva, [email protected]

Tesis de Maestría presentada para optar al título de Magíster en Ingeniería de Software

Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería con énfasis en

ciencias de la computación

Universidad de San Buenaventura Colombia

Facultad de Ingeniería

Maestría en Ingeniería de Software

Santiago de Cali, Colombia

2018

Citar/How to cite [1]

Referencia/Reference

Estilo/Style:

IEEE (2014)

[1] L. F. Tabares Pérez y J. F. Hernández Silva, “Diseño de la Arquitectura de

un Sistema de Apoyo a Decisiones Clínicas para facilitar el proceso de

Clasificación de Urgencias Hospitalarias, en el contexto de la salud en

Colombia”, Tesis Maestría en Ingeniería de Software, Universidad de San

Buenaventura Cali, Facultad de Ingeniería, 2018.

Maestría en Ingeniería de Software, Cohorte IV.

Laboratorio de Investigación para el Desarrollo de la Ingeniería de Software (LIDIS).

Bibliotecas Universidad de San Buenaventura

• Biblioteca Fray Alberto Montealegre OFM - Bogotá.

• Biblioteca Fray Arturo Calle Restrepo OFM - Medellín, Bello, Armenia, Ibagué.

• Departamento de Biblioteca - Cali.

• Biblioteca Central Fray Antonio de Marchena – Cartagena.

Universidad de San Buenaventura Colombia

Universidad de San Buenaventura Colombia - http://www.usb.edu.co/

Bogotá - http://www.usbbog.edu.co

Medellín - http://www.usbmed.edu.co

Cali - http://www.usbcali.edu.co

Cartagena - http://www.usbctg.edu.co

Editorial Bonaventuriana - http://www.editorialbonaventuriana.usb.edu.co/

Revistas - http://revistas.usb.edu.co/

Biblioteca Digital (Repositorio)

http://bibliotecadigital.usb.edu.co

https://co.creativecommons.org/?page_id=13

https://co.creativecommons.org/?page_id=13

Contenido

Resumen .............................................................................................................................. 11

Abstract ............................................................................................................................... 12

Capítulo 1. Preliminares .................................................................................................... 13

1.1. Introducción ............................................................................................................... 14

1.2. Planteamiento del Problema ...................................................................................... 16

1.3. Hipótesis y Pregunta de Investigación ....................................................................... 18

1.4. Justificación ............................................................................................................... 19

1.5. Objetivos .................................................................................................................... 22

1.5.1. Objetivo General ................................................................................................. 22

1.5.2. Objetivos Específicos .......................................................................................... 22

1.6. Proceso Metodológico ............................................................................................... 23

Capítulo 2. Referentes Teóricos y Contextuales .............................................................. 27

2.1. Marco Teórico ............................................................................................................ 28

2.1.1. Clasificación de Urgencias Hospitalarias ............................................................ 28

2.1.2. Sistema de Apoyo a Decisiones Clínicas ............................................................ 30

2.1.3. Arquitectura de Software .................................................................................... 32

2.2. Estado del Arte ........................................................................................................... 46

2.3. Marco Contextual ...................................................................................................... 52

2.3.1. Las TICs en el sector salud en Iberoamérica ....................................................... 52

2.3.2. El sector salud en Colombia ................................................................................ 59

2.3.3. Triage de Urgencias en Colombia ....................................................................... 61

2.3.4. Contexto del proyecto ......................................................................................... 64

2.4. Marco Legal ............................................................................................................... 66

Capítulo 3. Elicitación de los Requisitos Arquitecturales ............................................... 70

3.1. Métodos ..................................................................................................................... 71

3.2. Resultados .................................................................................................................. 82

3.2.1. Árbol de Utilidad ................................................................................................. 82

3.2.2. Escenarios Refinados .......................................................................................... 85

Capítulo 4. Diseño de la Arquitectura de Software ......................................................... 88

4.1. Métodos ..................................................................................................................... 89

4.2. Resultados .................................................................................................................. 91

4.2.1. Planteamiento de la Solución .............................................................................. 91

4.2.2. Vistas Arquitecturales ....................................................................................... 125

Capítulo 5. Evaluación de la Arquitectura de Software ............................................... 176

5.1. Métodos ................................................................................................................... 177

5.2. Resultados ................................................................................................................ 181

5.2.1. Evaluación mediante ATAM ............................................................................ 181

5.2.2. Evaluación mediante Prototipo ......................................................................... 187

Capítulo 6. Análisis de Resultados .................................................................................. 212

6.1. Discusión de resultados y conclusiones ................................................................... 213

6.1.1. Sector Salud....................................................................................................... 213

6.1.2. Ingeniería de Software ...................................................................................... 214

6.1.3. Ejercicio académico .......................................................................................... 216

6.2. Recomendaciones y Trabajo Futuro ........................................................................ 217

Referencias ........................................................................................................................ 219

Lista de Figuras

Figura 1-1. Problema de Investigación Aplicada ................................................................. 17

Figura 1-2. CDSS como soporte a la entrega de información útil para el Triage ................ 19

Figura 1-3. Metodología propuesta para el proyecto de Investigación Aplicada ................. 23

Figura 2-1. Proceso de Diseño de una Arquitectura de Software. Tomado de [25] ............. 33

Figura 2-2. Pasos del método QAW ..................................................................................... 34

Figura 2-3. Pasos del método ADD según [26] .................................................................... 41

Figura 2-4. Modelo de Vistas 4 + 1 de Philippe Kruchten [28] ........................................... 42

Figura 2-5. Fases del método ATAM ................................................................................... 45

Figura 2-6. Principales Áreas de Aplicación de los CDSS según [24]................................. 49

Figura 2-7. Principales Tipos de CDSS implementados según [36] .................................... 49

Figura 2-8. Principales Fuentes de Información de los CDSS según [36] ........................... 50

Figura 2-9. Ejemplo de Diseño Arquitectural de un Cloud CDSS. Tomado de [46] ........... 51

Figura 2-10. Principales Drivers Arquitecturales de los CDSS según [36].......................... 51

Figura 2-11. Escenario de Triage seleccionado para el estudio ........................................... 65

Figura 4-1. Arquitectura propuesta. Diagrama de alto nivel ................................................ 92

Figura 4-2. Tácticas analizadas para performance. Adaptado de [25], [35] ......................... 96

Figura 4-3. Componentes del patrón "Process Coordinator". Tomado de [25] .................... 97

Figura 4-4. Primera variación del patrón "Process Coordinator" ......................................... 98

Figura 4-5. Segunda variación del patrón "Process Coordinator" ........................................ 99

Figura 4-6. Diseño de componentes con cardinalidad específica ....................................... 100

Figura 4-7. Uso de un Load Balancer para transacciones sincronizadas............................ 100

Figura 4-8. Uso de colas persistentes para transacciones asíncronas ................................. 100

Figura 4-9. Tácticas analizadas para availability. Adaptado de [25], [35] ......................... 102

Figura 4-10. Uso de un Monitor para los componentes principales ................................... 103

Figura 4-11. Uso de un Log de Actividades para los componentes principales ................. 104

Figura 4-12. Uso de rastreo de excepciones para los componentes principales ................. 105

Figura 4-13. Uso de redundancia tipo Cold Spare para el Triage Engine .......................... 106

Figura 4-14. Remoción del componente EHR Service desde el Process Coodinator ........ 108

Figura 4-15. Tácticas analizadas para security. Adaptado de [25], [35] ............................ 109

Figura 4-16. Implementación del Application Delivery Service ........................................ 110

Figura 4-17. Componente de Autenticación y Autorización “Auth Service” .................... 111

Figura 4-18. Flujo de Autenticación basado en oAuth 2.0 [108] ....................................... 112

Figura 4-19. Flujo de Autorización basado en oAuth 2.0 [108] ......................................... 112

Figura 4-20. Limitando acceso a los componentes a través de zonas de seguridad ........... 113

Figura 4-21. Resultado final del Árbol de Tácticas/Decisiones construido iterativamente 118

Figura 4-22. Presentación del escenario principal de la solución propuesta ...................... 125

Figura 4-23. Vista general de módulos de la solución propuesta ....................................... 128

Figura 4-24. Vista de módulos Hospital Emergency Classifier ......................................... 130

Figura 4-25. Vista de módulos Coordinator Service .......................................................... 132

Figura 4-26. Vista de módulos Triage Service ................................................................... 135

Figura 4-27. Vista de módulos EHR Service ..................................................................... 137

Figura 4-28. Vista de módulos Inference Engine ............................................................... 140

Figura 4-29. Vista general de C&C de la solución propuesta ............................................ 143

Figura 4-30. Vista de C&C Hospital Emergency Classifier ............................................... 146

Figura 4-31. Vista de procesos – Registro de una petición ................................................ 155

Figura 4-32. Vista de procesos – Despacho de una petición .............................................. 159

Figura 4-33. Vista de procesos – Aplicación de Triage ..................................................... 162

Figura 4-34. Vista de procesos – Consulta de EHR ........................................................... 166

Figura 4-35. Vista de procesos – Generación de Inferencias ............................................. 170

Figura 4-36. Vista de procesos – Notificación de Resultados ............................................ 173

Figura 4-37. Vista general de Despliegue HEC ................................................................. 175

Figura 5-1. Escenario principal cubierto por el prototipo .................................................. 181

Figura 5-2. Proceso implementado en el prototipo – Registro de una petición.................. 189

Figura 5-3. Proceso implementado en el prototipo – Despacho de una petición ............... 190

Figura 5-4. Proceso implementado en el prototipo – Aplicación de Triage ....................... 191

Figura 5-5. Proceso implementado en el prototipo – Notificación de Resultados ............. 192

Figura 5-6. Componentes y conectores implementados en el prototipo............................. 193

Figura 5-7. Despliegue del prototipo en Amazon Web Services ....................................... 194

Figura 5-8. Tecnologías utilizadas para la implementación del prototipo ......................... 197

Figura 5-9. APDEX (Application Performance Index) generado por Jmeter .................... 199

Figura 5-10. Estadísticas ejecución de escenario ASR-01 ................................................. 200

Figura 5-11. Errores generados en la ejecución del escenario ASR-01 ............................. 200

Figura 5-12. Gráfico de peticiones por segundo que llegaron al sistema ........................... 201

Figura 5-13. Gráfico de respuestas por segundo suministradas por el sistema .................. 201

Figura 5-14. Gráfico de transacciones por segundo que fueron atendidas por el sistema .. 201

Figura 5-15. Gráfico de correlación de Tiempos de Respuesta vs Peticiones .................... 202

Figura 5-16. Gráfico de Cantidad de respuestas vs rangos de Tiempos de Respuesta ....... 202

Figura 5-17. Gráfico de Tiempos de Respuesta promedio vs Clientes concurrentes ......... 203

Figura 5-18. Tiempo de respuesta vs cantidad de peticiones ............................................. 207

Figura 5-19. Tiempo de respuesta vs peticiones después de optimización ........................ 208

Figura 5-20. Tiempo de respuesta vs cantidad de peticiones ............................................. 211

Lista de Tablas

Tabla 1-1. Actividades del Proyecto, por objetivo y fase ..................................................... 25

Tabla 2-1. Resumen de características del Triage. Adaptado de [1], [2] y [21] ................... 29

Tabla 2-2. Resumen de características de los CDSS. Adaptado de [15] y [14] ................... 30

Tabla 2-3. Patrones de diseño. Tomado de [26] ................................................................... 35

Tabla 2-4. Avances en eSalud - Américas y España. Tomado de [62] ................................ 53

Tabla 2-5. Categorías del Triage. Tomado de [71]............................................................... 63

Tabla 2-6. Centros Hospitalarios tomados como muestra .................................................... 65

Tabla 3-1. Desarrollo del QAW para la propuesta de diseño arquitectural .......................... 73

Tabla 3-2. Desarrollo de la revisión sistemática de literatura, adaptado de [24] ................. 78

Tabla 3-3. Árbol de Utilidad................................................................................................. 82

Tabla 3-4. Escenario ASR-01 refinado................................................................................. 85






Tabla 3-10. Escenario ASR-07 refinado............................................................................... 86




Tabla 4-1. Desarrollo del método ADD. Extendido de [26] ................................................ 89

Tabla 4-2. Cubrimiento de escenarios a través de las decisiones arquitecturales .............. 118

Tabla 4-3. Elementos del escenario principal ..................................................................... 126

Tabla 4-4. Relaciones entre los elementos del escenario principal .................................... 127

Tabla 4-5. Elementos de la vista general de módulos ........................................................ 128

Tabla 4-6. Relaciones entre los elementos de la vista general de módulos ........................ 129

Tabla 4-7. Elementos de la vista de módulos del Hospital Emergency Classifier ............. 130

Tabla 4-8. Relaciones entre los elementos de la vista de módulos del HEC ...................... 131

Tabla 4-9. Elementos de la vista de módulos del Coordinator Service .............................. 133

Tabla 4-10. Relaciones entre los elementos de la vista de módulos del Coordinator ........ 134

Tabla 4-11. Elementos de la vista de módulos del Triage Service ..................................... 135

Tabla 4-12. Relaciones entre los elementos de la vista de módulos del Triage Service .... 136

Tabla 4-13. Elementos de la vista de módulos del EHR Service ....................................... 137

Tabla 4-14. Relaciones entre los elementos de la vista de módulos del EHR Service ....... 139

Tabla 4-15. Elementos de la vista de módulos del Inference Engine ................................. 141

Tabla 4-16. Relaciones entre los elementos de la vista de módulos del Inference Engine 142

Tabla 4-17. Elementos de la vista general de C&C ............................................................ 144

Tabla 4-18. Relaciones entre los elementos de la vista general de C&C ........................... 145

Tabla 4-19. Elementos de la vista de C&C del HEC ......................................................... 147

Tabla 4-20. Relaciones entre los elementos de la vista de C&C del HEC ......................... 150

Tabla 4-21. Elementos de la vista de procesos – Registro de una petición ........................ 153

Tabla 4-22. Relaciones entre los elementos – Registro de una petición ............................ 154

Tabla 4-23. Elementos de la vista de procesos – Despacho de una petición ...................... 156

Tabla 4-24. Relaciones entre los elementos – Despacho de una petición .......................... 157

Tabla 4-25. Elementos de la vista de procesos – Aplicación de Triage ............................. 160

Tabla 4-26. Relaciones entre los elementos – Despacho de una petición .......................... 161

Tabla 4-27. Elementos de la vista de procesos – Consulta de EHR ................................... 163

Tabla 4-28. Relaciones entre los elementos – Consulta de EHR ....................................... 164

Tabla 4-29. Elementos de la vista de procesos – Generación de Inferencias ..................... 167

Tabla 4-30. Relaciones entre los elementos – Generación de Inferencias ......................... 168

Tabla 4-31. Elementos de la vista de procesos – Notificación de Resultados.................... 171

Tabla 4-32. Relaciones entre los elementos – Notificación de Resultados ........................ 172

Tabla 5-1. Desarrollo del método ATAM. Extendido de [26], [25] ................................... 178

Tabla 5-2. Evaluación escenario ASR-04 por medio de ATAM ........................................ 181




Tabla 5-6. Sistema de Escalas de Clasificación MTS. Tomado de [112] .......................... 198

Tabla 5-7. Casos de Prueba implementados para ASR-01 ................................................. 198

Tabla 5-8. Casos de Prueba implementados para ASR-07 ................................................. 206

Tabla 5-9. Primeros resultados ejecución de casos de prueba para ASR-07 ...................... 207

Tabla 5-10. Resultados definitivos ejecución de casos de prueba para ASR-07. ............... 208

Tabla 5-11. Casos de Prueba implementados para ASR-08 ............................................... 210

Tabla 5-12. Resultados ejecución de casos de prueba para ASR-08. ................................. 210

11

Resumen

La Clasificación de Urgencias Hospitalarias (Triage) es un proceso que se lleva a cabo en

los servicios de urgencias, en el cual se prioriza el tratamiento de un paciente de acuerdo

con su condición médica. El principal desafío que enfrenta este proceso corresponde a la

carencia de información valiosa, oportuna, pertinente y accesible durante la clasificación, la

cual redunda en la inadecuada priorización de pacientes y recursos clínicos, impactando

negativamente el servicio. En otros países y escenarios, este desafío se ha abordado

mediante el uso de Sistemas de Apoyo a Decisiones Clínicas (CDSS), que son aquellos

sistemas capaces de influenciar las decisiones del personal sanitario y médico a través del

conocimiento e información específica de un paciente, filtrada inteligentemente y

presentada en el momento oportuno. Este proyecto tiene como principal objetivo el

planteamiento de una solución que combina los CDSS con el proceso de Triage, en el

contexto de la salud en Colombia, a través de un ejercicio de investigación aplicada en

Ingeniería de Software, y en particular, desde una perspectiva de arquitectura de software.

Su aporte principal corresponde a la adaptación de buenas prácticas ya establecidas en otros

países y contextos que se encuentran a la vanguardia en CDSS.

Palabras clave: Sistema de apoyo a decisiones clínicas, CDSS, Triage, Clasificación de

pacientes, Servicio de urgencias, Arquitectura de software.

12

Abstract

The Classification of Hospital Emergencies (Triage) is a process that takes place in the

emergency services, in which the treatment of a patient is prioritized according to their

medical condition. The main challenge facing this process is the lack of valuable, timely,

relevant and accessible information during the classification, which results in the

inadequate prioritization of patients and clinical resources, impacting the service

negatively. In other countries and scenarios, this challenge has been addressed using

Clinical Decision Support Systems (CDSS). CDSS are those systems capable of

influencing the decisions of health and medical personnel, through knowledge and specific

information of a patient, intelligently filtered and presented at the right moment. The main

goal of this project is to propose a solution that combines both, the CDSS with the Triage

process, in the context of Colombia's health, through an applied research exercise in

Software Engineering, and, from a software architecture perspective. The main contribution

of this Project consists of adapting well-known and good practices already established in

other countries and contexts which are at the forefront in terms of CDSS implementations.

Keywords: Clinical decision support systems, CDSS, Triage, Patient classification,

Emergency department, Software architecture.

13

Capítulo 1. Preliminares

1.1. Introducción

1.2. Planteamiento del Problema

1.3. Hipótesis y Pregunta de Investigación

1.4. Justificación

1.5. Objetivos

1.6. Proceso Metodológico

14

1.1. Introducción

La Clasificación de Urgencias Hospitalarias (Triage) es un proceso que se lleva a cabo en

los servicios de urgencias, en el cual se prioriza el tratamiento de un paciente de acuerdo

con su condición médica [1]. Este proceso es importante para los servicios hospitalarios

porque permite optimizar los recursos clínicos, tales como, personal sanitario, zonas de

atención, insumos y personal médico, suministrando un adecuado tratamiento a los

pacientes al mismo tiempo [2], [3]. El principal desafío que enfrenta este proceso

corresponde a la carencia de información valiosa, oportuna, pertinente y accesible durante

la clasificación, la cual redunda en la inadecuada priorización de pacientes y recursos

clínicos, impactando negativamente el servicio.

En otros países y escenarios, este desafío se ha abordado mediante el uso de Sistemas de

Apoyo a Decisiones Clínicas (CDSS) [3]–[12]. Por CDSS, se entienden a aquellos sistemas

capaces de influenciar las decisiones del personal sanitario y médico a través del

conocimiento e información específica de un paciente, filtrada inteligentemente y

presentada en el momento oportuno [13]–[15]. En la actualidad (enero de 2018), en las

entidades de niveles de atención básica en Colombia, no se cuenta con este tipo de

sistemas, así como tampoco con las facilidades de acceso a la infraestructura tecnológica

que pueda proveer información a los mismos. Así pues, el abordar el desarrollo de un

CDSS se presenta como una oportunidad para soportar la entrega de información útil al

proceso de Triage, atacando precisamente la carencia de información previamente

nombrada. Sin embargo, esto también genera diversos retos desde el punto de vista de la

Ingeniería de Software, más aún, teniendo en cuenta que en este proceso prima la seguridad

de los pacientes sobre cualquier actividad.

Este proyecto tiene como principal objetivo el planteamiento de una solución que combina

los CDSS con el proceso de Triage, en el contexto de la salud en Colombia, a través de un

ejercicio de investigación aplicada en Ingeniería de Software, y en particular, desde una

perspectiva de arquitectura de software. El aporte principal de este proyecto se encuentra

dentro del marco de la ingeniería de software y corresponde a la adaptación de buenas

prácticas ya establecidas en otros países y contextos que se encuentran a la vanguardia en

15

CDSS. El ejercicio de Ingeniería de Software se centra en las actividades del proceso de

diseño de una arquitectura de software, siguiendo, adaptando y extendiendo los métodos

propuestos por el SEI [16]. Los resultados generados en el proyecto corresponden al

análisis, diseño y validación de una arquitectura de software para un CDSS para apoyar el

proceso del Triage de pacientes en los servicios de urgencias hospitalarias.

El impacto de este proyecto se enmarca en las cinco dimensiones descritas en [17]: La

individual, social, económica, ambiental y técnica, y se puede resumir en la mejora de la

oportunidad de atención de pacientes y el uso de las tecnologías de la información en el

sector salud. Es importante resaltar el aporte generado a la ingeniería de software, dado que

se ha dado un uso formal y a conciencia de las buenas prácticas de diseño de arquitecturas

de software, en un dominio específico.

El presente documento se encuentra estructurado de la siguiente forma: En el Capítulo 1 se

plantea el problema de investigación en términos de la motivación principal, la hipótesis

generada, la pregunta de investigación, que fue resuelta durante el desarrollo del proyecto

de investigación aplicada; la justificación, enmarcada en el impacto generado por la

ejecución del proyecto; los objetivos del mismo y la forma como se estructuró el proyecto

en términos de actividades. En el Capítulo 2 se presentan los referentes teóricos y

contextuales. En los siguientes capítulos, se presentan los métodos y resultados del proceso

de diseño, planteados desde sus tres frentes principales, a saber, la elicitación de requisitos

arquitecturales (Capítulo 3), el diseño arquitectural (Capítulo 4) y la evaluación de la

arquitectura (Capítulo 5). Finalmente, en el Capítulo 6 se muestra el análisis de los

resultados, desde la discusión y conclusiones del ejercicio, así como algunas

recomendaciones y trabajo futuro relacionado con el proyecto.

16

1.2. Planteamiento del Problema

El proceso de Triage tiene una alta importancia para los pacientes que acuden a los

servicios de urgencias suministrados por los centros hospitalarios. En este proceso se asigna

una prioridad de atención a un paciente según su condición médica a través de un proceso

de clasificación, generalmente basado en escalas o niveles. Durante la clasificación se

tienen en cuenta entradas como la información básica del paciente, los signos vitales y la

sintomatología expresada por este mismo, denominada anamnesis [1]. El proceso de

clasificación puede ser complejo cuando la sintomatología expresada por el paciente, así

como la información que se tiene sobre el mismo en la clínica no son suficientes para

asignar la prioridad de atención, impactando directamente la clasificación. Lo anterior se

encuentra aunado a que esta etapa debe ser llevada a cabo en tiempos relativamente cortos

(por lo general, entre 5 y 10 minutos), debido a la congestión de pacientes en los

departamentos de urgencias y a su condición de salud. En estos casos, se requiere de

información precisa y accesible que permita realizar la clasificación de pacientes de forma

adecuada, según la escala de atención de la entidad donde es aplicado el proceso.

En el contexto del sistema de salud en Colombia, el Triage presenta múltiples dificultades,

en las que se destaca la priorización errónea de pacientes por síntomas mal definidos,

cuadros virales y epidémicos no previstos, entre otras causas externas relacionadas con la

falta de información pertinente tanto de fuentes externas como del mismo paciente [18]. En

el País se están llevando a cabo esfuerzos que permiten contribuir al mejoramiento de la

calidad de la salud, por medio de la creación de marcos jurídicos y proyectos encaminados

hacia un modelo integrado del sistema de salud, tales como [19]–[21]. Los proyectos en los

que avanzan las fuentes anteriores apalancan soluciones con enfoques que van más allá de

la operación clínica. Algunos de ellos abordan temas de eficiencia como la mejora en

tiempos de atención, reducción de errores médicos, control de costos, entre otros.

En concordancia con lo anterior, el problema de investigación se establece como la carencia

de información relevante y oportuna durante el proceso de Triage (Figura 1-1), que pudiera

permitir la toma de decisiones relacionadas con la clasificación de un paciente en una

escala de atención determinada. Esta falta de información genera finalmente una

17

inadecuada priorización de pacientes en los servicios de urgencias, impactando

negativamente el servicio. Este problema afecta a pacientes, centros hospitalarios o

servicios de urgencias, entidades promotoras de salud, personal médico y sanitario y, en

general, a todo el sistema de salud.

Figura 1-1. Problema de Investigación Aplicada

Este impacto se puede clasificar en dos grupos principales según su causa y consecuencia:

• Cuando los pacientes son sub-valorados (prioridad asignada menor a la

adecuada): Empeoramiento de la condición de salud o muerte de pacientes, altos

tiempos de espera en situaciones de emergencia, sobrecostos por reingresos,

indicadores de satisfacción negativos, abandono del servicio de urgencias, baja

calidad en la atención, imagen negativa del centro hospitalario o servicio de

urgencias e imagen negativa del sistema de salud en general.

• Cuando los pacientes son sobrevalorados (prioridad asignada mayor a la

adecuada): Afectación de otros pacientes que requieren mayores recursos,

sobrecostos innecesarios e ineficiencia en la utilización de los recursos

hospitalarios.

18

1.3. Hipótesis y Pregunta de Investigación

Teniendo en cuenta el planteamiento anterior, se ha generado la hipótesis de que por medio

de un CDSS se puede apoyar la entrega de información relevante, en forma de alertas y

recomendaciones, al proceso de Triage. Según esta propuesta, el CDSS estaría ubicado

como una herramienta de apoyo al personal sanitario o médico que ejecuta el proceso de

Triage. En este contexto, “apoyo” se refiere a suministrar entradas útiles (como alertas y

recomendaciones) para que finalmente dicho personal genere la clasificación del paciente,

teniendo en cuenta el sistema de escalas utilizado por la clínica y el contexto colombiano.

La Figura 1-2 muestra cómo el CDSS se encuentra enmarcado dentro del proceso de Triage

(Clasificación de Urgencias Hospitalarias).

Dado que el espectro de la implementación de un CDSS es bastante amplio, se ha enfocado

la investigación en la ingeniería de software, específicamente en arquitectura de software,

por lo que se ha planteado la siguiente pregunta, la cual encierra el objetivo principal de la

presente propuesta: ¿Cuál debería ser el diseño de una Arquitectura de Software para la

implementación de un Sistema de Apoyo a Decisiones Clínicas que soporte la entrega de

información relevante al proceso de Clasificación de Urgencias Hospitalarias? La

resolución a esta pregunta constituye el principal resultado del trabajo de investigación

aplicada, enmarcado por sus objetivos descritos en la sección 1.5.

19

Figura 1-2. CDSS como soporte a la entrega de información útil para el Triage

1.4. Justificación

El presente proyecto se justifica desde las 5 dimensiones de la sostenibilidad, a saber, la

individual, social, económica, ambiental y técnica.

• Individual. Lo más importante para resaltar se encuentra en la mejora de la

oportunidad de atención de pacientes que acuden a los servicios de urgencias. El

acceso a las tecnologías sobre las que se enmarca el diseño arquitectural propuesto

permite la adecuada priorización de pacientes en los servicios de urgencias,

utilizando la escala de atención dada por la entidad, mientras que incrementa la

eficiencia operativa de los servicios de urgencias y centros de salud en general,

afectando positivamente el sistema completo. Lo anterior se basa en que la

propuesta tiene como objetivo el diseño de la arquitectura de software de un sistema

que puede facilitar la mejora en los resultados de un proceso crítico, tal como lo es

20

el Triage de pacientes, generando descongestión, mejor utilización de los recursos

clínicos (materiales y humanos) y, por ende, incrementando la oportunidad de que

un paciente reciba un tratamiento adecuado a tiempo. Por otro lado, y teniendo en

cuenta los desafíos a nivel de ingeniería de software sobre los cuales fue propuesto

el modelo de la arquitectura de software, se puede resaltar que la rapidez,

continuidad y precisión con la que se pueden presentar los insumos de información

al proceso de Triage, facilita de igual manera el incremento en la oportunidad de

atención de pacientes.

• Social. En cuanto al sector salud, el presente proyecto busca contribuir de forma

directa y responde a las iniciativas que se llevan a cabo desde las agendas

gubernamentales. En otros países, este tipo de iniciativas han sido exitosas,

logrando impactos positivos en el sector salud en general. Aunado a lo anterior, la

forma cómo este proyecto contribuye al desarrollo de las tecnologías para el sector

salud permite apalancar futuros proyectos que beneficien a los pacientes, entidades

clínicas y al sistema de salud en general. Finalmente, desde el punto de vista del

modelo de arquitectura propuesto y teniendo en cuenta los desafíos que hoy en día

se encuentran en la agenda del ministerio de las tecnologías de información y las

comunicaciones, el presente proyecto busca contribuir con aspectos como la

interoperabilidad, siendo ésta uno de los focos principales en el marco de diferentes

esfuerzos que se llevan a cabo en el país [20].

• Económica. Uno de los objetivos principales de un CDSS es incrementar la

eficiencia en los procesos que tienen qué ver con los servicios de salud. Al

incrementarse esta eficiencia, se espera una optimización en los recursos clínicos, y,

por ende, una optimización en los costos del servicio. Así mismo, el proporcionar

información útil en el proceso de Triage puede mejorar -indirectamente- el

diagnóstico y tratamiento de pacientes, generando así menos posibilidades de

reingresos o re-hospitalizaciones, utilización de seguros médicos, reclamos, entre

otros, lo cual genera un impacto económico bastante positivo para el sector salud.

Desde el punto de vista del modelo arquitectural, el diseño propuesto fue pensado

21

con base en los principales desafíos relacionados con la eficiencia, a saber, la

rapidez e interoperabilidad.

• Ambiental. Este tipo de propuestas tienen un impacto positivo, ya que se contribuye

indirectamente a la disminución del uso del papel, mediante la informatización de

los procesos. En este caso, se busca que las Historias Clínicas de los Pacientes y las

bases de conocimiento tengan un formato electrónico y puedan encontrarse en

repositorios digitales. Proyectos como el propuesto, motivan y aceleran otros

proyectos enfocados a la digitalización de la información en el sistema de salud. De

igual forma, el uso de modelos de despliegue eficientes (e.g. cloud computing) y la

propuesta de un diseño eficiente en recursos impacta directamente el consumo de

energía.

• Técnica. Se genera un impacto a partir del uso de los resultados. Este impacto

corresponde a aquel que se da, de forma directa, durante el ejercicio académico y es

motivado por la retroalimentación en forma de avances y publicaciones. En este

caso, los beneficiarios son, a saber, la universidad, las comunidades estudiantiles y

científicas, los investigadores y practicantes de la Ingeniería de Software para la

salud y las carteras de la salud y las TIC del Gobierno nacional. Cabe destacar la

rigurosidad con la cual fueron aplicados los métodos y técnicas de diseño,

documentación y evaluación de una arquitectura de software. Este aspecto

contribuye directamente con la adopción de buenas prácticas tanto en la academia

como en la industria, en los diferentes niveles de detalle que éstos requieren.

22

1.5. Objetivos

1.5.1. Objetivo General

Diseñar la arquitectura de un sistema de apoyo a decisiones clínicas para el proceso de

clasificación de urgencias hospitalarias, en el contexto del sistema de salud colombiano.

1.5.2. Objetivos Específicos

• Definir los requisitos arquitecturales, restricciones y escenarios de calidad que debe

tener un sistema de apoyo a decisiones clínicas para el proceso de clasificación de

urgencias hospitalarias, en el marco de la salud en Colombia.

• Diseñar y documentar la arquitectura de software de un sistema de apoyo a

decisiones clínicas, que permita satisfacer sus requisitos arquitecturales

significativos, restricciones de negocio y escenarios de calidad previamente

definidos.

• Seleccionar y aplicar la(s) técnica(s) de evaluación de los componentes de la

arquitectura de software del sistema de apoyo a decisiones clínicas, según los

atributos de calidad previamente definidos.

23

1.6. Proceso Metodológico

Para alcanzar los objetivos específicos del proyecto, se propuso la metodología

representada en la Figura 1-3. Esta metodología consistió en abordar cada objetivo

específico a través de cuatro fases: Exploración, Desarrollo, Validación y Divulgación.

Estas fases son descritas a continuación.

Figura 1-3. Metodología propuesta para el proyecto de Investigación Aplicada

• En la Fase de Exploración, se llevaron a cabo actividades de revisión de literatura,

con el fin de apoyar, desde la teoría y prácticas en otros contextos, el desarrollo de

los objetivos. Las principales técnicas aplicadas en esta fase fueron el estudio de

mapeo sistémico [22] y la revisión sistemática de literatura [23]. Esta información

fue consolidada en el Capítulo 2.

• En la Fase de Desarrollo, se construyó la salida o entregable principal de cada

objetivo específico, por medio de la aplicación de las técnicas y metodologías

revisadas y sintetizadas previamente en la fase de exploración. Los resultados

Definir los Requisitos Arquitecturales

Diseñar y Documentar la Arquitectura

Evaluar la Arquitectura

Documentación del Reporte Técnico

Exploración Desarrollo

ValidaciónDivulgación





24

encontrados en esta fase se encuentran distribuidos en el Capítulo 3 -para el primer

objetivo específico-, en el Capítulo 4 -para el segundo objetivo específico-, en el

Capítulo 5 -para el tercer objetivo específico-, y, finalmente, en el Capítulo 6, en el

cual se discuten estos resultados.

• En la Fase de Validación, se validó que el entregable o conjunto de entregables del

objetivo específico estuviesen correctamente discernidos y distribuidos antes de

someterse a divulgación. Esta fase fue considerada como apoyo a la consolidación

y revisión de los resultados generados en la fase anterior y como parte del proceso

de aseguramiento de la calidad de los reportes técnicos y demás medios de

divulgación.

• Finalmente, en la Fase de Divulgación, se trabajó en la preparación de los

resultados para su divulgación, a través de los diferentes medios, como

publicaciones, talleres y el presente reporte técnico.

En la Tabla 1-1, se resumen las actividades que fueron llevadas a cabo en el proyecto, por

cada objetivo específico y fase.

25

Tabla 1-1. Actividades del Proyecto, por objetivo y fase

OBJ-1

Definir los Requisitos Arquitecturales

OBJ-2

Diseñar la Arquitectura de Software

OBJ-3

Validar la Arquitectura de Software

Exploración

• Se aplicó una revisión sistemática de literatura

[24], donde se buscó información pertinente

sobre la implementación de CDSS.

• Se exploraron diferentes técnicas, tecnologías y

herramientas que hacen parte del estado del arte

para la construcción de CDSS, encontrando

tendencias y oportunidades relacionadas con la

ingeniería de software aplicada en el campo de

la salud. Esta información se encuentra

documentada en la sección 2.2.

• Se complementó la revisión sistemática de

literatura realizada en el primer objetivo

[24], por medio de una revisión Ad-hoc,

para identificar los componentes comunes

en el diseño arquitectural de CDSS.

• Se estudiaron las tácticas asociadas a los

atributos de calidad correspondientes a los

drivers de la arquitectura en [25], [26] y se

contrastó esta información con las

propuestas de otros autores consignadas en

la sección 2.2.

• Se aplicó un proceso de revisión

literatura ad-hoc, donde se buscó

información correspondiente a los

métodos existentes para la

evaluación de Arquitecturas de

Software, teniendo en cuenta los

atributos de calidad que dirigieron el

diseño llevado a cabo en el segundo

objetivo.

Desarrollo

• Se identificaron los componentes,

acontecimientos, actores y subprocesos de la

implementación de CDSS, con el fin de

conocer en detalle los escenarios que podían

cubrirse con este tipo de sistemas. Lo anterior

fue realizado por medio de una caracterización

de CDSS (Sección 2.1.2).

• Se identificaron los componentes,

acontecimientos, actores y subprocesos del

Triage en diferentes contextos, basados en la

revisión de literatura (sección 2.1.1), la

normatividad colombiana para los servicios de

urgencias (sección 2.4) y la observación directa

de las prácticas llevadas a cabo en algunos

centros hospitalarios de la región, para ubicar

el proyecto en un contexto específico (Sección

2.3.4).

• Se definieron las métricas, metodologías,

técnicas y herramientas para realizar la

validación de los requisitos y escenarios de

calidad.

• Se validaron los requisitos y escenarios de

calidad identificados en el primer objetivo

en busca de su completitud para iniciar el

diseño de la arquitectura de software.

• Se llevó a cabo el proceso incremental de

diseño de la Arquitectura de Software -

ADD- (descrito en la sección 2.1.3.2).

• Se seleccionó, combinó y priorizó el

conjunto de vistas que permitieron

documentar el diseño realizado en la

actividad anterior.

• Se seleccionaron los métodos que

permitieron llevar a cabo la

validación de la Arquitectura de

Software.

• Se identificaron las métricas a

aplicar durante la evaluación de la

arquitectura, así como se elaboraron

los planes de ejecución de las

evaluaciones a través de los métodos

definidos.

• Se ejecutó la validación de los

componentes de la arquitectura

mediante los métodos y métricas

definidos previamente. Durante esta

actividad se analizaron, compararon

y documentaron los resultados en los

26

• Basados en [26], [27], los resultados de la

caracterización previa, la aplicación del

método QAW (sección 3.1) y la revisión

bibliográfica de la fase de exploración, se llevó

a cabo la definición, priorización y

documentación de los requisitos

arquitecturales, las restricciones de negocio y

los escenarios de calidad. Se definieron los

drivers de la arquitectura.

• Los resultados del desarrollo de este objetivo

se encuentran en la sección 3.2.

• El método seleccionado (4+1 [28]) para la

documentación de las vistas arquitecturales

se encuentra descrito en la sección 4.1.

• Los resultados del desarrollo de este

objetivo se encuentran en la sección 4.2.

formatos propuestos por cada

método, confirmando así el

entregable principal del objetivo.

• Los resultados del desarrollo de este

objetivo se encuentran en la sección

5.2.

Validación

• Se llevaron a cabo las asesorías del tutor, que

fueron orientadas a evaluar la pertinencia y

completitud de las fuentes consultadas, así

como la publicación de un artículo relacionado

con la definición de los requisitos

arquitecturales.

• En la validación también fueron incluidos los

resultados obtenidos en esta fase y las

conclusiones obtenidas durante el desarrollo del

objetivo.

• Se llevaron a cabo las asesorías del tutor,

para validar el aporte generado en esta fase,

con el fin de preparar sus resultados para la

publicación de un segundo artículo.

• En la validación también fueron incluidos

los resultados obtenidos en esta fase y las

conclusiones obtenidas durante el desarrollo

del objetivo.

• Se llevaron a cabo las asesorías del

tutor, para validar la completitud de

la evaluación de la arquitectura y la

documentación del reporte técnico y

análisis de resultados.

Divulgación

• Se desarrolló un artículo basado en la revisión

sistemática llevada a cabo en la fase de

exploración. Posteriormente, éste fue publicado

y presentado en CHASE 2016 [29],

conferencia “Cloud Connected Health” (CCH).

• Se desarrolló un artículo donde fueron

consignadas las decisiones arquitecturales

tomadas para los drivers, teniendo en cuenta

el contexto definido. Posteriormente, éste

fue publicado en el Congreso Colombiano

de Computación versión 12 (CCC 2017)

[30], sección “Ingeniería de Software y

Arquitecturas TI”.

• Se preparó el reporte técnico final.

27

Capítulo 2. Referentes Teóricos y Contextuales

2.1. Marco Teórico

2.2. Estado del Arte

2.3. Marco Contextual

2.4. Marco Legal

28

2.1. Marco Teórico

2.1.1. Clasificación de Urgencias Hospitalarias

La clasificación hospitalaria, también conocida como Triage (en adelante) o Triaje, del

verbo triar en francés -que significa separar, clasificar, tamizar o seleccionar-, surge a partir

de las exigencias de la Guerra y se comienza a utilizar informalmente en el Siglo XVIII [1].

Posteriormente, se utilizó en la Segunda Guerra mundial con un mayor grado de formalidad

y se comenzó a practicar en civiles, en el contexto de la atención hospitalaria, para lo que se

definieron y estandarizaron diferentes tipos y escalas de clasificación de pacientes [1], [2].

El presente trabajo se encuentra enfocado en el Triage de Urgencias Hospitalarias. Según

[1], el Triage Hospitalario es el proceso de determinar la prioridad de tratamiento de

pacientes, basados en la severidad de su condición, permitiendo manejar eficientemente los

recursos asociados a dicho tratamiento, principalmente cuando estos son limitados. Lo

anterior, aplicado al contexto de urgencias médicas, se trata de la clasificación de los

pacientes que acuden a un servicio hospitalario de urgencias. En este escenario, una

urgencia se constituye como una situación que se debe solucionar con rapidez y suele tener

un alto nivel de importancia o prioridad. La clasificación de urgencias corresponde

específicamente a una valoración clínica preliminar que prioriza a los pacientes según su

grado de urgencia antes de una valoración diagnóstica más compleja, de tal forma que en

una congestión del servicio de atención o ante la reducción de recursos médicos, los

pacientes más urgentes puedan ser tratados con prioridad, mientras que el resto puedan ser

controlados y reevaluados continuamente hasta que puedan ser atendidos o nuevamente

priorizados [1], [2].

Es importante aclarar que este proceso no corresponde a un diagnóstico, sino únicamente a

la priorización o clasificación de pacientes. Sin embargo, durante esta clasificación pueden

llevarse a cabo pruebas diagnósticas y búsqueda de información adicional, las cuales

pueden ser útiles como entradas al proceso, aumentando su sensibilidad. Sobre esta

aclaración, existe discrepancia entre diferentes autores ya que algunos afirman que el

Triage de Hospitalario no requiere -o no debiera incluir- otro tipo de información adicional

29

a los signos y síntomas de los pacientes, mientras que otros piensan lo contrario y atribuyen

los errores cometidos en este proceso justo a la ausencia de entradas importantes como el

diagnóstico clínico [1], [2], siendo esta última la postura adoptada por los autores del

presente proyecto. En [31] se estudia ampliamente la sensibilidad del Triage Hospitalario,

abordando la discusión generada alrededor del uso de información adicional a la

convencional como entrada al proceso.

En la Tabla 2-1 se resumen las principales características del proceso de Triage

Hospitalario.

Tabla 2-1. Resumen de características del Triage. Adaptado de [1], [2] y [21]

Característica Resumen

Funciones Principales

• Identificar rápidamente a los pacientes en situación de riesgo vital

mediante una clasificación

• Asegurar la priorización en función de la clasificación

• Asegurar la reevaluación de los pacientes no urgentes

• Determinar el área más adecuada de tratamiento de un paciente

• Proporcionar exploraciones diagnósticas preliminares

• Suministrar información del paciente a los acompañantes

• Disminuir la congestión del servicio

• Suministrar información que ayude a mejorar el servicio

Tipos

• Adultos (Simple y Avanzado)

• Pediátrico (Simple y Avanzado)

Modelos

• Tradicional

• Estructurado

Sistemas para el Modelo

Estructurado

• La Australian Triage Scale (ATS)

• La Canadian Emergency Department Triage and Acuity Scale (CTAS)

• El Emergency Severit Index (ESI)

• El Manchester Triage System (MTS)

• El Model Andorrá de Triatge (MAT)

• El Sistema Español de Triage (SET) que, originalmente, deriva del

MAT

Personal involucrado

• Personal Sanitario (En su mayoría, personal de enfermería)

• Personal con formación en Triage

• Personal con formación en pediatría (para Triage Pediátrico)

30

2.1.2. Sistema de Apoyo a Decisiones Clínicas

Los CDSS comenzaron a ser estudiados en la década de los 90’s, provenientes de la

Inteligencia Artificial y su aplicación en la medicina, la cual se encaminó hacia el apoyo del

diagnóstico de pacientes, prescripción de medicamentos, análisis de laboratorios clínicos y

entornos educativos, vigilancia clínica y en áreas ricas en datos como los cuidados

intensivos.

Los CDSS se definen en [13] como aquellos que proporcionan, a los médicos, el personal,

los pacientes y otras personas, el conocimiento e información específica de un paciente,

filtrada inteligentemente y presentada en el momento oportuno, con el objetivo de mejorar

la atención sanitaria. En [32] se afirma que los CDSS enlazan las observaciones médicas

con el conocimiento para influenciar las decisiones tomadas por los médicos para mejorar

la atención sanitaria. Finalmente, en [33] se definen como sistemas activos de conocimiento

que utilizan dos o más elementos de datos de un paciente para generar un asesoramiento

para un caso específico. De acuerdo con estas definiciones, se puede afirmar entonces que

el propósito general de los CDSS es asistir al personal clínico en el punto de atención

sanitaria desde diferentes perspectivas, a saber, la administrativa, la clínica y la operacional.

En la Tabla 2-2 se presenta un resumen las principales características de los CDSS, basados

en las definiciones anteriores.

Tabla 2-2. Resumen de características de los CDSS. Adaptado de [15] y [14]


Funciones Principales

• Gestión Administrativa: Documentación, Autorización de

Procedimientos, Facturación.

• Gestión Clínica: Protocolos de investigación, seguimiento de pedidos,

atención preventiva.

• Control de Costos: Monitoreo de órdenes de medicamentos, evitar test

duplicados o innecesarios.

• Apoyo a Decisiones: Diagnóstico, Tratamientos, mejores prácticas.

Clasificaciones

• Basados en Conocimiento (Knowledge Based): Buscan la simulación

del experto, por medio de una Base de Conocimiento, un Motor de

Reglas de Inferencia y un Mecanismo de Comunicación.

• No Basados en Conocimiento (Non Knowledge-Based): No utilizan

31


una base de conocimiento preestablecida. Se basan en una forma de AI

conocida como “Machine Learning”, la cual aprende de experiencias

pasadas para encontrar patrones en los datos clínicos, implementando

técnicas como las Redes Neuronales Artificiales y los Algoritmos

Genéticos.

Tipos

• Alertas y recordatorios: Sistemas expertos que generan alertas sobre la

condición de un paciente o en otro tipo de situaciones clínicas. Por lo

general, en tiempo real.

• Apoyo a diagnóstico: Comparación de la información de un paciente

con una base de conocimiento para entregar posibles diagnósticos. Útil

para médicos inexpertos o casos muy complejos. También conocidos

como Sistemas de Apoyo a Decisiones de Diagnóstico (DDSS, por sus

siglas en inglés).

• Crítica y planeación de tratamientos: Búsqueda de inconsistencias,

errores y omisiones cometidas en un plan de tratamiento. Formulación

de tratamientos basado en las condiciones de un paciente y los

protocolos y líneas guía de tratamientos.

• Apoyo a decisiones de prescripción: Validación de las interacciones

entre medicamentos, errores de dosis y contraindicaciones relacionadas,

tales como alergias de pacientes. También conocidos como Sistemas de

Apoyo a Decisiones de Prescripción. Es uno de los más aceptados y

utilizados mundialmente.

• Recuperación de Información: Ubicación y recuperación de

información clínica apropiada y precisa utilizada para diagnósticos y

tratamientos.

• Reconocimiento de Imágenes e Interpretación: Interpretación de

imágenes clínicas desde simples rayos-x hasta escaneos de MRI o CT

para la detección de posibles anomalías en pacientes.

Principales Beneficios

• Aumento de la calidad de la atención y mejora en los resultados de

salud

• Evita errores y eventos adversos

• Mejora de la eficiencia, relación costo-beneficio, y satisfacción de

pacientes y proveedores

Barreras de

Implementación

• Relacionadas con la evidencia: Evidencia no disponible, inconsistente

y/o inaccesible.

• Relacionadas con los médicos: Mal uso, no aceptación de las

recomendaciones.

• Relacionadas con los sistemas: Convergencia de múltiples requisitos

para lograr diagnósticos precisos, necesidad de utilizar información

externa, inadecuada usabilidad o integración con el flujo de trabajo del

practicante.

Principales Retos

• Marco de Trabajo: Alcance del proceso de atención, formas de entrega

de CDSS, toma de decisiones centrada en el paciente y compartida.

32


• Fuentes de conocimiento: Desarrollo, formalización e incorporación

del conocimiento de CDS, difusión de mejores prácticas.

• Uso: Herramientas y recursos de gestión del conocimiento, datos de la

población, interoperabilidad y uso generalizado, usabilidad y eficacia,

seguridad, calidad, regulación y responsabilidad.

2.1.3. Arquitectura de Software

En [26] se define la Arquitectura de Software (AS, en adelante), como el conjunto de

estructuras necesarias para dar un entendimiento sobre un sistema, las cuales comprenden

elementos de software, las relaciones entre ellos y sus propiedades. Existen tres categorías

de estructuras, las cuales juegan un papel fundamental en el rol de diseñar, documentar y

analizar arquitecturas de software:

• Estructura de descomposición en módulos (Module)

• Estructuras de componentes y conectores (C&C)

• Estructuras de asignación (Allocation)

Cabe mencionar que, aunque un software está compuesto por una gran variedad de

estructuras, no todas son arquitecturales. Por ejemplo, el código fuente como tal no es

arquitectural ya que este, por sí mismo, no permite llevar cabo un entendimiento del

sistema. Por lo anterior, se puede afirmar que la AS es una abstracción de un sistema, que

selecciona ciertos detalles para entender el mismo y que omite otros que no son relevantes

para dicho entendimiento, en el contexto arquitectural. Según [25], el proceso de diseño de

una arquitectura de software consta de tres pasos principales, los cuales se representan en la

Figura 2-1 y se describen a continuación.

33

Figura 2-1. Proceso de Diseño de una Arquitectura de Software. Tomado de [25]

2.1.3.1. Determinar los Requisitos Arquitecturales

La AS se relaciona con tres tipos de requisitos: 1) Funcionales, que describen lo que el

sistema debe hacer y cómo debe comportarse ante algún estímulo; 2) Atributos de Calidad,

que son cualificaciones de los requisitos funcionales como, por ejemplo, qué tan rápido

debe ser ejecutada una funcionalidad; 3) Restricciones, que son decisiones que ya fueron

tomadas y no pueden ser cambiadas. Entre estos tres tipos de requisitos, la satisfacción de

los atributos de calidad es el principal objetivo de la arquitectura de software, haciendo que

las decisiones arquitecturales que se tomen dependan de estos. Existen métodos, como el

Quality Attribute Workshop (QAW) [34], que permiten definir y priorizar estos requisitos.

El método QAW, según [34] es un método de intervención temprana utilizado para generar,

priorizar y refinar atributos de calidad antes de que la arquitectura de software sea diseñada.

Este método es de gran relevancia ya que se enfoca en preocupaciones tempranas basadas

en los escenarios de uso del sistema, específicamente en el rol que el software

desempeñará. El factor clave de éxito del QAW radica en la participación de los interesados

del proyecto, los cuales son individuos sobre los cuales el sistema tiene un impacto

significativo, por lo que normalmente se realiza con usuarios finales, instaladores,

administradores, capacitadores, arquitectos, clientes, ingenieros de software, entre otros,

quienes pueden organizarse en grupos entre 5 y 30 personas (dependiendo del tamaño del

34

sistema) y deben estar previamente preparados en temas relacionados con atributos y

escenarios de calidad.

El QAW comprende 8 pasos secuenciales, como se ilustra en la Figura 2-2, cuyo objetivo

principal es conducir el taller hacia la generación de escenarios de calidad priorizados,

refinados y representados de forma estructurada por medio de un árbol de utilidad, el cual,

según [26], es un repositorio donde son almacenados los ASR, el cual permite que éstos

puedan ser almacenados, revisados, referenciados, utilizados para tomar decisiones y

revisitados en caso de que el sistema exponga cambios mayores (control de versiones). El

QAW constituye una guía que contiene algunos protocolos mínimos a cumplirse y describe

las salidas que se debe generar en cada paso. Sin embargo, no se define exactamente la

forma como debe llevarse a cabo.

Figura 2-2. Pasos del método QAW

2.1.3.2. Diseñar la Arquitectura

Consiste básicamente en definir la estructura y las responsabilidades de los componentes en

el sistema. En este punto es donde se toman todas las decisiones arquitecturales en

cumplimiento de los escenarios de calidad resultantes del paso anterior. Para diseñar

adecuadamente una AS, lo cual es una tarea bastante compleja y con muchos retos

asociados, los diseñadores constantemente han buscado la forma de capturar y reutilizar el

conocimiento aplicado en arquitecturas exitosas. Para esto se utilizan los patrones y tácticas

de diseño, que se definen como un conjunto de decisiones de diseño exitosas, repetibles,

35

puestas en práctica frecuentemente, con propiedades que permiten su reutilización y que

describen una clase de arquitectura para la construcción de un sistema de software. En la

Tabla 2-3 se pueden observar algunos ejemplos de los patrones de diseño descritos

ampliamente en [26].

Tabla 2-3. Patrones de diseño. Tomado de [26]

Patrón de

Diseño Ejemplo

Layered

Pattern

(Module)

Broker

Pattern

(C&C)

36

MVC Pattern

(C&C)

Pipe-and-

Filter Pattern

(C&C)

Client-Server

Pattern

(C&C)

37

Peer-to-Peer

Pattern

(C&C)

Service-

Oriented

Architecture

Pattern

(C&C)

38

Publish-

Subscribe

Pattern

(C&C)

Shared-Data

Pattern

(C&C)

39

Map-Reduce

Pattern

(Allocation)

Multi-tier

Pattern

(C&C,

Allocation)

Uno de los métodos más utilizados para diseñar AS es el Attribute-Driven Design (ADD,

en adelante). Este método agrupa tres estrategias, a saber, descomposition, diseñar para los

ASR y generate-and-test [26]. Por medio de la estrategia descomposition se busca

comenzar con el sistema como un todo e irlo descomponiendo en subsistemas,

denominados elementos. De esta forma, los atributos de calidad también deben ser

descompuestos y asignados a los elementos. La descomposición finaliza cuando el diseño

generado para cada elemento cumple las restricciones y objetivos de negocio del sistema.

40

Diseñar para los ASR básicamente se trata de dirigir el diseño arquitectural a través de los

atributos de calidad identificados a través de los ASR, los cuales, tienen un profundo efecto

en la arquitectura y, por lo tanto, se debe trabajar para satisfacerlos. Finalmente, la

estrategia generate-and-test busca diseñar la arquitectura por medio de hipótesis y sus

correspondientes pruebas dirigidas a cada elemento del sistema. En este caso, una hipótesis

es una solución que satisface un requerimiento, una prueba es el proceso de determinar si la

hipótesis es correcta. Mediante esta estrategia, si una hipótesis es correcta, se continúa con

el siguiente elemento; de lo contrario, se genera una nueva hipótesis para el mismo

elemento. Existen varias técnicas para crear una hipótesis. Algunas de las más conocidas y

utilizadas en el presente diseño son:

• Por medio de analogías sobre cómo otras implementaciones similares resolvieron

los requerimientos, restricciones y objetivos de negocio

• Los Frameworks pueden aportar soluciones comunes independientes de dominio

• Las tácticas y patrones son soluciones conocidas a problemas comunes en contextos

específicos

• Descomposición de un dominio en subdominios

• A menudo se usan listas de chequeo comunes para los atributos de calidad

ADD, según [25], [26], [35] es un método iterativo, en el cual, por cada iteración, (1) Se

selecciona una parte (elemento) del sistema a diseñar, por medio de la estrategia

descomposition; (2) Se revisan y ordenan los ASR a satisfacer para dicho elemento; y (3)

Se crea y prueba un diseño arquitectural para dicho elemento, por medio de la estrategia

generate-and-test. Estas tres macro-actividades se ejecutan de forma sistemática, por medio

de los cinco pasos representados en la Figura 2-3.

41

Figura 2-3. Pasos del método ADD según [26]

Por otro lado, un paso intrínseco del diseño de la arquitectura es su documentación. Según

[36], [26] y [25], una arquitectura de software muy bien diseñada puede fallar en su

implementación si no se encuentra bien documentada. Esto significa que la arquitectura

puede no ser comprendida o, peor aún, comprendida incorrectamente. Todo el esfuerzo

dedicado durante la etapa de diseño puede perderse por errores en la documentación. La

documentación de una arquitectura es vista como un medio de comunicación entre el

arquitecto y el resto de los interesados (implementadores, clientes, patrocinadores, otros

arquitectos, entre otros).

En [36] se afirma que, en la mayoría de los casos, los procesos de documentación de

arquitectura de software son llevados a cabo como esfuerzos cuyo objetivo es cumplir

únicamente con un entregable definido por algún interesado, comprometiendo así la calidad

de la documentación y, por ende, la implementación consecuente. Sólo en algunos casos -

que son los que evidencian a los mejores arquitectos-, el proceso de documentación es un

proceso continuo durante el diseño arquitectural y no se produce por cumplir un requisito

sino porque resulta ser esencial dentro de dicho proceso y su posterior implementación.

El método Views and Beyond [36] es una práctica creada por el SEI que describe la forma

cómo debe documentarse una arquitectura de software. Ésta práctica sugiere centrarse en

un concepto denominado vista, el cual consiste en la representación de un conjunto de

Step 1: Choose an element of the system to design

Step 2: Identify the ASRs for the chosen element

Step 3: Generate a design solution for the chosen element

Step 4: Verify and Refine Requirements and Generate Input for the Next Iteration S

tep

5:

Rep

eat

unti

l sa

tisf

yin

g a

ll

the

AS

R

42

elementos y sus relaciones desde diferentes dimensiones. Sin embargo, sugiere dar gran

importancia a la documentación, refinamiento y notación que acompañan a la vista, con el

fin de evitar ambigüedades a la hora de su implementación.

Para la selección, combinación, priorización y documentación de vistas del diseño

arquitectural presentado en este documento, se utilizó el modelo de vistas 4 + 1 de Philippe

Kruchten [28], el cual, como es mostrado en la Figura 2-4, consiste en representar la

arquitectura de software a través de cinco vistas principales, a saber, Vista Lógica, Vista de

Procesos, Vista Física y Vista de Escenarios o Uso. La forma como fue llevado a la práctica

este modelo no dista del propuesto por Philippe Kruchten. Sin embargo, fueron utilizadas

las notaciones, representaciones (módulos, componentes y conectores, despliegue) y

documentación para cada vista, tal como se describe en [36].

Figura 2-4. Modelo de Vistas 4 + 1 de Philippe Kruchten [28]

2.1.3.3. Evaluar la Arquitectura

Debido a que las arquitecturas brindan una importante contribución al éxito de los

proyectos de ingeniería y sistemas software, se hace necesario tomar conciencia y llevar a

cabo las actividades que sean necesarias para asegurarse que la arquitectura diseñada sea

43

capaz de proveer todo lo que se espera de ella. Para esto, existen métodos de evaluación de

AS, los cuales determinan si éstas son aptas para el propósito que fueron diseñadas. Los

métodos de evaluación de AS comúnmente utilizados son descritos a continuación.

Evaluación durante el diseño: Es realizada por el diseñador de la arquitectura, a través del

sub-paso test, del paso generate-and-test, del método ADD y es llevado a cabo durante el

proceso de diseño, por cada iteración o elemento del sistema. En este sub-paso se analizan

las decisiones clave que fueron tomadas para cada ASR, por medio de los siguientes

criterios:

• Costo versus beneficio: Se trata de balancear las decisiones al punto de evitar

refinamientos extremos con altos costos asociados, por un lado, mientras que, por

el otro, cubrir los escenarios de calidad propuestos a un beneficio razonable.

• Importancia de la decisión: Se trata de priorizar las decisiones basados en el

valor e impacto para el negocio y la arquitectura que tienen los escenarios de

calidad cubiertos por dichas decisiones.

• Número de alternativas posibles: Este criterio apunta a reducir la cantidad de

alternativas que tiene una decisión arquitectural para hacer más viable la

evaluación. Este criterio entonces apunta a descartar rápidamente alternativas

mientras se evalúa el diseño.

Método ATAM: El “Architecture Tradeoff Analysis Method” [26], [25] o ATAM por sus

siglas en inglés, es un método de evaluación de arquitectura de software externo, lo cual

implica que no se aplica intrínsecamente en la etapa de diseño, si no como una etapa

posterior. Lo anterior no quiere decir que la evaluación de la arquitectura a través de

ATAM sólo puede hacerse al finalizar el diseño. Por el contrario, se considera riesgoso y se

recomienda realizar esta evaluación por iteraciones similares a las iteraciones de la etapa de

diseño. La diferencia realmente radica en el enfoque de la evaluación y sus participantes.

Para la aplicación de ATAM, los evaluadores deben estar familiarizados con la arquitectura

o sus objetivos de negocio y no se requiere tener el sistema construido, aunque requiere de

44

tiempo y disponibilidad por parte del equipo. Este método se basa en la técnica conocida

como juicio de expertos, donde se verifica el cubrimiento de los escenarios de calidad, a

través de las decisiones arquitecturales planteadas y reflejadas en el diseño, al mismo

tiempo que se verifica si estas decisiones se relacionan con otros escenarios, lo cual se

conoce como los Tradeoff de la arquitectura. ATAM es un método acertado siempre y

cuando se aplique correctamente.

El proceso de aplicación de este método se encuentra dividido en 4 fases principales

(Figura 2-5), las cuales se encuentran divididas a su vez en diferentes pasos. Su entrada

principal es el elemento o porción de la arquitectura a evaluar, que puede ser incluso todo el

diseño arquitectural. Sus principales salidas son presentadas y divulgadas comúnmente por

medio de un reporte técnico y son descritas a continuación:

• Conjunto de preocupaciones y análisis sobre la arquitectura, escritos en forma de

riesgos y no riesgos, donde un riesgo es una decisión arquitectural que puede

generar consecuencias indeseables, mientras que un no riesgo es una decisión

arquitectural considerada segura. Estos riesgos y no riesgos normalmente son

categorizados en temas específicos para mejorar su interpretación y análisis

posterior.

• Informe de cubrimiento de escenarios de calidad por medio de las decisiones

arquitecturales, escrito en forma de análisis o razonamiento de cómo las decisiones

se encuentran satisfaciendo el escenario.

• Conjunto de puntos de sensibilidad y tradeoff, que consiste en el efecto que una

decisión arquitectural tiene sobre otros atributos de calidad para los que no fue

pensada la decisión.

Evaluación mediante Prototipo: La construcción de un prototipo es una técnica bastante

útil para evaluar escenarios complejos con un nivel de detalle y exactitud altos [26].

Además de que puede utilizarse para verificar la satisfacción de un escenario de calidad, su

uso también está orientado a determinar la viabilidad de implementación del sistema. Un

prototipo normalmente es realizado para una porción del sistema, por lo que comúnmente

toma el nombre de prueba de concepto.

45

Figura 2-5. Fases del método ATAM

Los tipos de pruebas no funcionales que pueden abordarse por medio de un prototipo o una

prueba de concepto se encuentran descritas en [37]. Sin embargo, los tipos utilizados en el

presente proyecto se describen a continuación.

• Prueba de Carga: Consiste en simular demanda sobre una aplicación de software y

medir el resultado. Estas pruebas se realizan bajo demanda esperada y también en

condiciones de sobrecarga (picos en la demanda).

• Prueba de Estrés: Corresponde a aplicar una prueba de carga con parámetros por

encima de los parámetros esperados.

• Prueba de Desempeño/Rendimiento: Realizada para asegurar que el sistema o

módulo cumpla con los niveles de rendimiento y los tiempos de respuesta acordados

en los escenarios de calidad. Este tipo de prueba se usa para determinar si el

rendimiento cumple con los requisitos bajo la demanda esperada y en condiciones

de sobrecarga.

• Prueba de Recuperación: Consiste en verificar qué tan rápido y qué tan bien se

recupera una aplicación luego de experimentar un falló de hardware o software. Por

lo tanto, para realizar pruebas de recuperación se requiere forzar la falla y luego

verificar si la recuperación ocurre adecuadamente.

46

2.2. Estado del Arte

A través de un estudio de mapeo sistemático [38], se encontró que los CDSS se encuentran

dentro de las principales tendencias del sector salud, con un 40% de incidencia en sus áreas

de aplicación, mientras que las Historias Clínicas Electrónicas (HCE, en adelante) se

encuentran dentro de las principales entradas o fuentes de datos principales de los CDSS,

con un 30% de participación. También se encontró que de los CDSS son utilizados como

apoyo al proceso de Triage por su capacidad para generar información relevante que puede

ser utilizada durante el proceso. Algunos de estos hallazgos se describen a continuación.

En [39] se propone el diseño de un CDSS de Triage para pacientes en emergencia en la fase

pre-hospital, sin requerir conocimiento especial relacionado con el sistema de clasificación

por parte de los paramédicos. Esta propuesta plantea como objetivo que, sin adicionar

tiempo para evaluar al paciente y usando los formatos preestablecidos de las ambulancias,

la condición del paciente pueda ser estimada con la información recogida por los

paramédicos y, de esta forma, se pueda llevar a cabo una clasificación en función de dicha

condición. Otro aspecto importante que se propone es la transformación de los formatos de

la Escala de Triage de Manchester (MTS) a los utilizados en el sistema de ambulancias, en

el dominio particular. El principal resultado de este estudio tiene qué ver con la alta

sensibilidad de Triage que logró obtener el sistema, con una tendencia hacia la sobre

estimación de la condición de los pacientes, quedando pendiente aumentar su efectividad

con el fin de masificar su uso. Sin embargo, en este estudio no se presenta el diseño de la

arquitectura del sistema y no se incluye la HCE como complemento a la base de

conocimiento que sirve como apoyo a la toma de decisiones.

En [5] se propone el uso de tecnología basada en agentes como plataforma para modelar,

diseñar e implementar un sistema de apoyo a decisiones de Triage (llamado Triage DSS),

con el fin de soportar las tareas realizadas por el departamento de emergencias médicas,

como el registro de los pacientes entrantes, la etapa de clasificación (Triage), programación

de tratamientos y el monitoreo de los turnos de los pacientes en espera. La propuesta apunta

a que las decisiones sean construidas a partir de una base de conocimiento estructurado.

Según los autores de esta propuesta, las características de la tecnología de agentes

47

(Autonomía, Reactividad, Proactividad, Habilidad Social, Modularidad, Eficiencia,

Flexibilidad, Manejo de Eventos) hacen que ésta sea adecuada para su aplicación en el

Triage, debido a que permite modelar, diseñar y construir sistemas complejos. Sin embargo,

como su nombre lo indica, solo se trata de una conceptualización preliminar de un posible

sistema, dentro de la cual se mencionan posibles tecnologías a utilizar, así como

herramientas y metodologías propuestas para implementar el CDSS, lo que se encuentra

lejos de ser un diseño arquitectónico formal. No se plantea una propuesta de validación de

la propuesta.

En [40] se propone la arquitectura de un sistema multi-agente y un repositorio de

conocimiento basado en reglas para la implementación de un CDSS que soporte: 1)

Construcción y presentación del CCDSS, dirigida por el conocimiento; 2) Estructuración y

formalización del conocimiento. Sin embargo, esta propuesta presenta un modelo muy

simple de la arquitectura y no entra en detalles de su diseño y validación. Esta propuesta es

general y no se enfoca en un dominio particular, específicamente, el Triage y tampoco

plantea el uso de la HCE como apoyo a la toma de decisiones.

En [4] se propone la implementación de una plataforma de Triage en línea (Tele-Triage)

escalable y de costo razonable o efectivo, utilizando un sistema experto y técnicas de

Machine Learning y Procesamiento de Lenguaje Natural. Esta plataforma, básicamente

corresponde a un CDSS de tipo recomendación que sigue un protocolo estándar de Triage

definido y validado por el personal médico. Esta propuesta constituyó el Spin-off de la

compañía Keona Health [41] y fue validada en la Universidad de Carolina del Norte,

arrojando buenos resultados comparados con el proceso presencial, tales como, la

reducción de los tiempos del Triage realizado por el personal de enfermería (de 12 minutos

a 8), el incremento de la seguridad de los pacientes, el aumento de la demanda de pacientes

y el control de los costos. Sin embargo, las limitaciones con las que cuenta esta plataforma

es que fue validada sobre estudiantes que ya tienen conocimiento sobre el uso de

aplicaciones web y no tiene en cuenta una población diferente a la de la Universidad foco

de la evaluación desarrollada. Por otro lado, la propuesta no se enfoca en los detalles

arquitecturales del sistema y tampoco se habla de la adaptación de alguna arquitectura de

referencia que pueda ser utilizada en otros escenarios.

48

En [42] se propone una arquitectura abierta y distribuida para la implementación de CDSS.

Esta propuesta está acompañada de un Framework para la administración del conocimiento

en sistemas clínicos distribuidos y utiliza la HCE de los pacientes, técnicas de minería de

datos, bases de datos clínicas, bases de conocimiento de expertos y las tecnologías y

estándares disponibles para proveer a los profesionales de la salud el soporte a las

decisiones clínicas. Para resolver aspectos de interoperabilidad se propone una arquitectura

orientada a servicios (SOA), partiendo de que ya existe la conectividad a una arquitectura

de gestión de HCE. La principal limitación de esta propuesta es que es de propósito general

y, por ende, no aborda detalles arquitecturales para un dominio en particular,

específicamente el Triage.

En estudios como [43], [31] y [44] se afirma que los CDSS mejoran la sensibilidad o

precisión del Triage, lo que puede significar que la calidad de la salud y seguridad de los

pacientes mejore igualmente. Estudios como [45] plantean que, a pesar de que el uso de

CDSS ha incrementado, el verdadero reto se encuentra en la interacción entre el personal de

clasificación y el CDSS, para lo que se requiere contar con unas habilidades mínimas por

parte del personal y hacer énfasis en la usabilidad de estos sistemas. Según los autores de

[45], mientras esta brecha no se rompa, los esfuerzos por la construcción de sistemas de

apoyo a la etapa de clasificación hospitalaria no se verán reflejados en la calidad de la

salud. Otros estudios, como [2], proponen mayor énfasis en la estructuración del proceso de

clasificación, como factor clave del éxito en cualquier implementación.

Con respecto a la caracterización de los CDSS orientados a apoyar el Triage, en varios

estudios como [46], [47], [48], [49], [50] y [51] se afirma que los departamentos de

urgencias (ED, por sus siglas en inglés) son uno de los mayores focos de implementación

de CDSS, dada su gran pertinencia para incrementar indicadores relacionados con la

oportunidad de atención de los pacientes. Sin embargo, se encontró que estudios como [46],

[52], [49], [50], [53], [54], [55], [51] y [56] se inclinan por el nicho de la Salud en Casa o

Home Healthcare (Figura 2-6). Las implementaciones más comunes para este tipo de

sistemas son 1) Alertas y Recomendaciones, como se muestra en [52], [53] y [55]; y 2)

Servicios de Conocimiento, como se muestra en [46], [48], [49] and [50] (Figura 2-7).

Según [57], [58] y [59], las fuentes de información más utilizadas durante la

49

implementación de CDSS son las EHR y los sistemas de información de los hospitales

(Figura 2-8).

Figura 2-6. Principales Áreas de Aplicación de los CDSS según [24]

Figura 2-7. Principales Tipos de CDSS implementados según [36]

50

Figura 2-8. Principales Fuentes de Información de los CDSS según [36]

Con respecto a la arquitectura de software de los CDSS, se encontró que la mayoría de

estos (i.e. [46]-[50]), presentan un enfoque arquitectural basado en tres componentes: 1)

Una Base de Conocimiento, la cual modela el conocimiento médico según el dominio; 2)

Un Motor de Inferencia, el cual puede estar basado en conocimiento (i.e. Reglas) o en

técnicas de Inteligencia Artificial (i.e. Machine Learning); y 3) Una Interface, para

permitir, al usuario final u otros actores, realizar consultas o simplemente exponer los

servicios del CDSS. En la Figura 2-9 puede observarse un ejemplo de un diseño

arquitectural basado en este enfoque.

Con respecto al estilo arquitectural más utilizado, propuestas como [46], [49], [52], [60] y

[61] presentan una Arquitectura Orientada a Servicios (SOA, por sus siglas en inglés);

estudios como [53] proponen una Arquitectura Orientada a Recursos (ROA, por sus siglas

en inglés); y propuestas como [47] y [54] presentan una Arquitectura Cliente-Servidor. Las

principales limitaciones en la mayoría de estas propuestas tienen qué ver con altos costos de

implementación, la fragmentación de las tecnologías de información para la salud (HIT, por

sus siglas en inglés), dificultades para el intercambio de los datos de los pacientes, falta de

regulaciones para la protección de las EHR, falta de estándares para la interoperabilidad y

51

la falta de arquitecturas de referencia que faciliten el diseño.

Figura 2-9. Ejemplo de Diseño Arquitectural de un Cloud CDSS. Tomado de [46]

Finalmente, como se indica en la Figura 2-10, la mayoría de los estudios mostraron

Security, Performance, Compatibility y Reliability como atributos de calidad que dirigieron

los diseños arquitecturales.

Figura 2-10. Principales Drivers Arquitecturales de los CDSS según [36]

52

2.3. Marco Contextual

La salud es un factor decisivo para el bienestar de las personas, las familias y las

comunidades, a la vez que es un requisito para el desarrollo humano con equidad [62]. La

sociedad en su conjunto debe garantizar que ningún individuo quede excluido del acceso a

los servicios de salud y que estos proporcionen una atención de calidad para todos los

usuarios. Para alcanzar el desarrollo humano sostenible, se han venido identificando los

rezagos y brechas sociales en cuanto a condiciones de salud, proponiendo medidas para

superarlos, las cuales se consideran estratégicamente como un componente de esencial de la

acción pública integral [63]. Para este propósito fueron incluidos varios objetivos

relacionados con la salud dentro de los objetivos de desarrollo del milenio [64], dentro de

los cuales se enmarcan, reducir la mortalidad en niños menores de cinco años, reducir la

mortalidad materna y aumentar la prestación de servicios de salud. Posteriormente, en

2015, estos objetivos fueron extendidos y pasaron a ser objetivos de desarrollo sostenible

[65], donde la salud es el tercero de los 17 objetivos creados.

Según las carteras de salud y de tecnología y comunicaciones en Colombia, los gobiernos

deben estar atentos y prepararse mejor para afrontar las problemáticas actuales y poder

suplir la demanda de servicios médicos de manera más eficiente y efectiva. Esto conlleva a

implementar iniciativas, en forma de proyectos y programas, cuyo foco principal se

encuentre enmarcado en principios orientadores para las políticas de salud, tales como la

mejora en la capacidad de respuesta de los sistemas de salud. A continuación, se presenta

una breve radiografía del sector salud, destacando las iniciativas y avances en América,

España y Colombia, con el fin de contextualizar el impacto indirecto que generan

propuestas como la presente.

2.3.1. Las TICs en el sector salud en Iberoamérica

En el año 2011 fue creada y aprobada la Estrategia y Plan de acción de eSalud 2012-2017

de la Organización Panamericana de la salud [66], que tiene como objetivo apoyar el

desarrollo sostenible de los sistemas de salud y prioriza el desarrollo e inclusión de políticas

53

nacionales de eSalud en la región. Más adelante, en 2015 ésta es alineada con la nueva

definición de los objetivos de desarrollo sostenible en lo que respecta a la salud. Dentro de

este marco, se destacan algunas iniciativas de desarrollo de TICs en la materia, las cuales se

resumen en la Tabla 2-4.

Tabla 2-4. Avances en eSalud - Américas y España. Tomado de [62]

País Avances

Argentina

Telemedicina:

• Servicios de Interconsultas por email por más de 12 años

• Educación Médica a Distancia.

• Programa de comunicación a distancia para apoyar a los centros de salud

del interior del país por medio de consultas de alta complejidad.

• Registro Médico Electrónico en el Ministerio de Salud en Buenos Aires.

Reúne 43 hospitales que están conectados en red. Cuenta con una Historia

Clínica Electrónica para la atención primaria y un sistema de referencia y

contra referencia.

Proyectos en desarrollo:

• Registros Médicos Electrónicos.

• Principales desafíos: Estandarización y la Interoperabilidad.

• Portales de Salud.

• Optimizar las computadoras por medio de pantalla táctil, lápiz óptico o

reconocimiento de voz.

• Desarrollar software y hardware que permitan que las facturaciones y

trámites administrativos se realicen en forma automática.

• Información en línea.

• Evaluar automáticamente la información sobre tratamientos y fármacos

administrados para evitar reacciones adversas y secundarias.

• Mejorar la infraestructura comunicacional asociada a la disminución de

costos de los servicios que permitan el desarrollo e implementación de

redes de salud.

• Mejorar el acceso a la información para que los servicios médicos se

orienten más específicamente a la prevención.

• Capacitar a los profesionales en el uso de TIC.

• Desarrollar sistemas de vigilancia epidemiológica y monitoreo de

enfermedades que permitan un cuidadoso control de toda la población.

• Aplicaciones Móviles para realizar un mejor control y seguimiento de

pacientes con patologías crónicas, como diabetes o hipertensión, así como

pacientes de la tercera edad.

Brasil

Telemedicina:

• Red Universitaria de Telemedicina (RUTE) 2006.

• RUTE www.rute.rnp.br y Telesalud de Brasil www.telessaudebrasil.org.br

los dos pertenecientes al Ministerio de Ciencia y Tecnología y al Ministerio

de Salud, respectivamente.

• Programa Nacional de Telesalud de Atención Primaria (Telesalud de

Brasil)

• RUTE: En la actualidad suman 158 instituciones de salud. La red conecta

54

36 núcleos de telesalud en 36 hospitales clínicos y 31 núcleos embrionarios

completamente operativos.

• Diariamente el RUTE lleva a cabo sesiones de conferencias vía web o

video relativas a radiología, oncología, y urología pediátrica, salud de niños

y adolescentes, dermatología, cardiología, oftalmología, etc.

Chile

Proyectos actuales:

• Libro Azul: Establecer una red de comunicaciones a lo largo de todo el

país, una red sectorial y dotar de equipamiento computacional a todos los

establecimientos.

Proyectos habilitantes:

• Plan centralizado de contratación de equipos computacionales en

modalidad de arriendo esta modalidad incorporó los servicios de

mantenimiento, mesa de ayuda, licencia de Windows, Office, antivirus y

actualización permanente de estas herramientas y la renovación de todo el

equipamiento al vencer el contrato y con esto se resuelve el problema de

obsolescencia tecnológica y costos favorables por economías de escala.

• Red de comunicaciones para todos los establecimientos y servicios de

transmisión de voz, datos e imágenes con un estándar de

telecomunicaciones y una mayor eficiencia en el uso de los recursos

financieros.

• 60.000 puntos de conexión de voz, anexos telefónicos y 40.000 nodos de

datos y más de 100.000 puntos de conexión.

• Internet a todos los establecimientos del país.

• Portales Web.

• Correo Electrónico con más de 28.000 casillas habilitadas y puede

ampliarse hasta 40.000.

Proyectos aplicaciones:

• 8 servicios de salud de un total de 29 se han iniciado la implementación en

todas sus redes asistenciales (2009).

• Agendamiento de citas.

• Referencia y Contrarreferencia.

• Urgencia.

• Farmacia.

• Registro de Población en control (actividades asociadas a pacientes

crónicos).

• Once trámites en los Sistemas de Trámites en Línea.

• Oficina de Informaciones Reclamos y Sugerencias (OIRS).

Telemedicina:

• 100 equipos en hospitales de baja complejidad para exámenes

osteopulmonares interconectados a la red de comunicaciones. (2008).

Proyectos en desarrollo:

• Implementar las otras 21 aplicaciones de servicios de salud.

• Implementación de soluciones para la gestión de pabellones, gestión de

camas, banco de sangre, abastecimiento y recaudación, entre otras.

• SEREMI. Sistema de información para las secretarías regionales

ministeriales de salud.

• Aplicaciones en las redes asistenciales y ampliar los trámites en línea

actuales.

• Lograr que todos los establecimientos asistenciales que disponen de

55

equipos osteopulmonares implementen esta aplicación de telemedicina.

Costa Rica

Proyectos actuales:

• Sistemas de Educación y Bibliotecas Virtuales.

• Sistemas de Información en la Web para atención primaria y hospitales.

• Cursos de Alfabetización digital orientados a vencer la resistencia de

profesionales y técnicos del área.

Telemedicina:

• Teleconsulta.

• Intercambio científico entre médicos.

• Teleconferencias en salud (1994).

• Consejo Técnico de Telemedicina (1996).

• Red Nacional de Telesalud (1998 / 2001).

• Teledermatología (2004).

Aplicaciones eSalud:

• Educación a distancia.

• Temas como pie diabético, problemas endocrinológicos e hipertensión.

• Videoconferencias.

• Hospital Virtual uso de equipos móviles mediante el uso de tecnología

inalámbrica.

• Expediente Electrónico en algunos hospitales y clínicas y EBAIS.

Ecuador

Proyectos actuales:

• Agenda Nacional de Conectividad (ANC) 2001.

• Libro Blanco de la Sociedad de la Información Ecuatoriana (2006).

• Telesalud Rural.

• Teletrauma de la Fuerza Aérea.

• Red de Telemedicina para zonas aisladas.

• FUNDETEL (2005).

• Primer Simposio Internacional de Telemedicina y eSalud (2006).

• Red académica avanzada del Ecuador CEDIA (2002).

• Plan Nacional de Telemedicina y Telesalud (2006).

• Marco Normativo: El plan Nacional para el Buen Vivir 2009-2013 la ley

Orgánica del Sistema Nacional de Salud y los códigos, declaraciones,

acuerdos y resoluciones internacionales de telemedicina.

Estrategias del plan nacional:

• Promover programas de formación y evaluación de las técnicas de

telemedicina.

• Ampliación de la Red de telemedicina para establecer centros de referencia

clínica y tecnológica.

• Desplegar nuevos sistemas terminales e incorporar soluciones móviles.

• Incorporación en RED de las Unidades sanitarias.

• Capacitación continua para profesionales de la salud

• Diseño e implementación de normas, protocolos y estándares requeridos

por la telemedicina

• Teleasistencia.

México

Proyectos actuales:

56

• Centro Nacional de Información y Documentación en Salud (CENIDS)

permitió la consulta remota del sistema Medical Literature Analysis and

Retrieval System (MEDLARS) de la National Library of Medicine (NLM)

en Bethesda, Maryland, Estados Unidos. (1970).

• Educación en Salud por Televisión del Hospital Infantil de México

Federico Gómez (1985) CEMESATEL.

• CEMESATEL incorporó servicios digitales (2006).

• Sistema Estatal de Información Básica (SEIB) centralizado y abarca los 32

estados.

• Automatiza la operación del SEIB y del programa de Vacunación Universal

y las primeras redes locales e las entidades federativas (1992).

• Centro Nacional de Información Y2K (2000).

• Sistema Nacional de Vigilancia Epidemiológica (SINAVE) (1995).

• Sistema Único de Información para la Vigilancia epidemiológica (SUIVE).

• Sistema Único Automatizado de Vigilancia Epidemiológica (SUAVE).

• Red Hospitalaria para la Vigilancia Epidemiológica (RHOVE).

• Sistema Epidemiológico y Estadístico de Defunciones (SEED).

• 22 sistemas especiales de vigilancia epidemiológica.

• Desarrollo del Sistema de Administración Hospitalaria (SAHO) 2000 /

2006.

• La Secretaría de Salud (SSA) inició el desarrollo de la Noma Mexicana del

Expediente Clínico Electrónico y se planteó los componentes del modelo de

interoperabilidad (2007 / 2012).

Panamá

Proyectos actuales:

• Centro de Documentación e Información Médica (CDIM) (1999)

Telemedicina. Teleneurofisiología.

• Proyecto Nacional de Telemedicina (2000).

• Regulación de la Telemedicina (2002).

• Programa Nacional de Telemedicina y Telesalud (2005).

• Programas de telemedicina Rural, asistencia de teleobstetricia el Programa

de Teleradiología y el Programa de Telemedicina a población penitenciaria.

Perú

Proyectos actuales:

• Uno de los cinco países en el mundo que sobresalen en el uso de tecnología

m-Health.

• Cell-PREVEN. Sistema de Vigilancia en tiempo real para eventos adversos

usando celulares e Internet. Relacionados con la administración de

metronidazol como tratamiento de vaginosis bacteriana entre trabajadoras

sexuales.

• Colecta-PALM. Dirigido a personas viviendo con VIH /SIDA que reciben

terapia antiretroviral. Incluye archivos de audio y textos con imágenes de

avatars sencillas y sexo seguro.

• Cell-POS. Celulares e Internet que envía recordatorios vía SMS a celulares

de personas con VIH/SIDA. Estos mensajes resaltan la importancia para

que estos pacientes se tomen las medicinas indicadas por los médicos y

citas médicas.

• WAWARED. Elevar los niveles de acceso a los sistemas de salud de las

mujeres de escasos recursos que están embarazadas mejorando los

mecanismos de información materno-infantil por medio de mensajes de

texto.

• CareNET. Móvil e Internet para el soporte de Pacientes con diabetes.

57

• EHAS. Utilizó móviles y ofreció cursos de formación en salud a distancia.

• PROMETEO. 1er sistema computarizado e integrado de información de

salud rural.

• PDA-PREVEN. Recolección de datos sobre conductas sexuales.

• Vía-Net. Internet para llegar a la comunidad más afectada por la epidemia

VIH.

• Plan Nacional de Telesalud (2004).

• e-Gobierno. NETLAB. Sistema de información para el acceso a los

resultados de CD4 y carga viral por parte de los pacientes viviendo con

VIH (2007).

• Educación y entrenamiento en informática en salud. AMAUTA programa

en informática biomédica. QUIPU proyecto para la promoción de

investigación y formación de profesionales en informática biomédica y

salud global.

• Ley de Aseguramiento Universal en Salud. Políticas específicas sobre

Salud electrónica.

Uruguay

Proyectos actuales:

• Sistema Nacional Integrado de Salud (SNIS) (2005)

• En el Plan Director de Informática del MSP para el período 2005-2009 se

priorizaron algunas líneas estratégicas: 1.) Construir sistemas de

información en salud. 2.) Utilizar sistemas gerenciales. 3.) Promover la

historia clínica electrónica (HCE) única para cada persona de acuerdo con

el Decreto 396/03. 4.) Definición de estándares de contenido y de

interoperabilidad. 5.) Optimizar y transparentar la comunicación del MSP

con la población a través del uso eficiente del Portal. 6.) Participar en los

proyectos de desarrollo e implantación de sistemas de información con

otros organismos del Estado a través de ámbitos de coordinación

permanente.

• De los emprendimientos derivados del Plan Director en este quinquenio,

cabe destacar el proyecto del Sistema de estadísticas vitales, control de

embarazo y del niño (SEVEN) que comprende el certificado de nacido vivo

electrónico (CNV-e), el certificado de defunción electrónico (CD-e), el

Sistema de información perinatal (SIP) y el Programa Aduana (seguimiento

del crecimiento y desarrollo del niño hasta los dos años). Quizás éste sea el

de mayor envergadura y proyección entre los que está desarrollando el

MSP, pues conjuga varios aspectos incluidos en las líneas estratégicas.

• Agencia para el Desarrollo del Gobierno de Gestión Electrónica y la

Sociedad del Conocimiento (AGESIC) (2005).

• Centro Nacional de Respuesta a Incidentes de Seguridad Informática

(CERTuy).

• REDuy. Red de alta velocidad que interconecta a todo el Estado Uruguayo.

Para que corran los componentes de Plataforma de Gobierno Electrónico y

Expediente Electrónico.

• Desarrollo de Normas Técnicas y Estándares. HL7 Uruguay.

Venezuela

Proyectos actuales:

• SINAPSIS. Sistema Nacional Público de Salud para la Inclusión Social.

Historia Clínica Estandarizada en formato papel para luego convertirlo a

electrónico.

• Centro Nacional de Innovación Tecnológica (CENIT) (2005) Su función es

la de transferir tecnología desde el sector académico y de investigación

hacia las comunidades.

58

• Medicarro. Brindan acceso inalámbrico para acceder a los servidores del

sistema además maneja videoconferencia en tiempo real y diferido e

incluso tiene la capacidad de operar equipos médicos a distancia.

• Negatoscopio. Para el área de teleradiología y para radiología

intrahospitalaria y también funciona como un pizarrón que permite

consultar con otros colegas o explicarle el caso al paciente.

• Quirófanos Inteligentes. Con capacidad de adquisición de vídeo y signos

vitales usados tanto para asesorar el acto quirúrgico a distancia como, al ser

ubicados en hospitales de IV nivel, servir de centros d educación a distancia

de salud.

• Robots Quirúrgicos. Tiene una cabina de mando que reúne al cirujano y el

robot en la misma sala pero conectados a distancia.

• Telemedicina (1988) Sistema de navegación neuroquirúrgica llamado

Neuropanacea.

• Red REACCIUN, integra todas las universidades públicas del país,

incluidos sus hospitales universitarios y están realizando proyectos de

teleradiología.

• Programa SOS telemedicina para Venezuela de la facultad de Medicina de

la Universidad Central de Venezuela (UCV), implementa una red de

telemedicina donde equipa y conecta centros remotos de atención primaria

e salud con médicos especialistas de la UCV, para mejorar la capacidad

resolutiva, educar a distancia, transferir tecnologías a las regiones,

desarrollar capacidades y evaluar los beneficios de la telemedicina con una

fuerte alianza con HP, CISCO, Microsoft y Digetel.

España

Proyectos actuales:

• El 90% de los médicos de atención primaria utilizan la Historia Clínica

Electrónica con éxito.

• Receta Electrónica

• Imagen Médica: RIS y PACS

• Tarjeta Sanitaria. Plan de Calidad del Sistema Nacional de Salud.

• Solicitud de pruebas e integración de resultados de laboratorio.

• Sistemas de ayuda a la prescripción

• Central de llamadas para cita previa masiva y también se realiza por

Internet

• Proyectos piloto de Telemedicina. Teledermatología, Telepatología,

Transferencia de Imágenes, teleictus, etc.

• 1era Fase de Interoperabilidad. Historia Clínica Digital del Sistema

Nacional de Salud (HCDSNS)

• PROYECTO EUROPEO DE HISTORIA CLÍNICA DIGITAL (EPSOS)

Interoperabilidad: Participan 12 estados de la Unión Europea con distintos

idiomas y tecnologías que se proponen el acceso a la historia clínica

resumida y la receta electrónica. La idea es que en los 12 países

comprometidos se pueda acceder al resumen de la historia clínica de

cualquiera de sus habitantes cuando precisen atención médica.

Adicionalmente, se espera que una prescripción electrónica realizada en

alguno de los 12 países sirva para la dispensación en las otras naciones.

59

2.3.2. El sector salud en Colombia

El modelo sobre el cual se encuentra basado el sistema general de seguridad social en

Colombia parte del supuesto del equilibrio que debe existir entre los volúmenes de atención

y los niveles de complejidad asistencial. De esta forma, la mayoría de los eventos deben ser

atendidos en los niveles inferiores o de baja complejidad, mientras que solo un bajo

porcentaje de éstos debe ser remitido a los niveles de complejidad superiores. Este modelo

fue adoptado mediante la Ley 100 de 1993 [67] y se encuentra basado en los principios de

eficiencia, universalidad, solidaridad, integralidad, unidad y participación, con el objetivo

de garantizar acceso a la asistencia sanitaria oportuna, de calidad y segura.

A pesar de que este modelo ha tenido importantes avances, aún sigue siendo insuficiente,

puesto que tiene ya más de 20 años de operación a la fecha evidenciándose no solo la falta

de equilibrio entre la demanda y los niveles de complejidad descritos arriba, sino que, por

el contrario, ha ocurrido lo contrario: la mayor parte de las atenciones en salud están siendo

realizadas en los niveles intermedios y superiores, debido a la baja capacidad de resolución

con la que cuentan los niveles inferiores, generando así un colapso en los niveles

superiores. Este desequilibrio se debe principalmente a que las inversiones se han

concentrado en los establecimientos de segundo y tercer nivel, dejando a los de primer

nivel rezagados en inversión pese a que éstos son el eje fundamental del modelo. Este

proyecto es independiente del nivel de atención, por lo que puede ser aplicado en

instituciones hospitalarias de cualquier nivel.

Respecto a las Tecnologías de la Información y las Comunicaciones (TICs), según los más

recientes informes, tener información médica disponible de los pacientes en forma

electrónica en las unidades de atención, ayuda a mejorar la calidad en la atención, a reducir

errores médicos y a hacer más eficientes los procesos médicos y administrativos. Lo

anterior apunta a todos los niveles, de atención, incluyendo el enfoque principal de esta

propuesta: el servicio de urgencias hospitalarias. Según estos mismos informes, los

sistemas de información en salud contribuyen a este fin, de la siguiente forma:

60

• Son el componente fundamental para el modelo de Servicios de Salud integrados.

Esto permite la estructuración de algunos servicios, específicamente el Triage

hospitalario.

• Habilitan la comunicación directa e indirecta entre prestadores de una misma

unidad, de diferentes unidades, de diversas instituciones, departamentos o regiones.

Esto permite la centralización de la historia clínica electrónica de los pacientes.

• Permiten la generación, almacenamiento, procesamiento y envío oportuno y seguro

de información en forma de datos y de imágenes médicas. Esto permite acceder a

información específica de los pacientes, de forma oportuna y precisa.

Dado lo anterior, en el contexto del Plan Vive Digital 2014-2018, el ministerio de las TICs

ha venido implementando una iniciativa para apoyar -con las TIC- la renovación del sector

Salud. En conjunto con el Ministerio de Salud y Protección Social, el Ministerio TIC a

través de esta iniciativa, trabaja en la definición e implementación de un Plan de TIC para

este sector. Este plan incluye iniciativas que llevarán a la implementación de la historia

clínica digital y a la consolidación de plataformas TIC que contribuyan a la

universalización y el acceso a los servicios de salud. Las metas propuestas por el plan son:

• Historia clínica digital

• Desarrollo de soluciones y aplicaciones para pacientes y afiliados al Sistema de

Seguridad Social en Salud

• TIC para el acceso de la población a los servicios de salud: Tele-salud y

Telemedicina.

También, en el mismo año, se creó una agenda estratégica de innovación para el nodo salud

[62], enmarcado dentro de los nodos de innovación [68], [69], los cuales, en alianza con

Colciencias, buscan generar espacios de concertación y diseño de soluciones a las

necesidades y oportunidades TIC identificadas. El nodo salud, específicamente, busca

fomentar la creación de servicios y soluciones para el sector, con el fin de minimizar la

brecha de las iniquidades en materia de salud, por medio de la apropiación de las TICs,

contando con la estrategia de Gobierno en Línea como base.

61

El esquema busca potenciar el modelo de salud mediante el desarrollo del subsistema de

información en tres aspectos:

• Formulación de un modelo de interoperabilidad de la historia clínica electrónica,

anclada en el desarrollo paralelo de su necesaria normalización y estandarización.

• Desarrollo del Sistema Maestro de Información - Sector Salud, que cobije como

áreas de desempeño fundamentales la financiación, el aseguramiento y la gestión

del riesgo en salud, la prestación de los servicios, la rendición de cuentas, la calidad

de los servicios, la seguridad de los pacientes y la salud pública.

• Fortalecimiento de la capacidad resolutiva del primer nivel de complejidad a través

de la implementación e integración de servicios de telemedicina, con otros

desarrollos en soluciones móviles y atención en casa, buscando robustecer el

concepto de redes integradas de servicios de salud, con aplicaciones TIC salud.

2.3.3. Triage de Urgencias en Colombia

El estado colombiano, en cabeza del ministerio de la protección social y la salud, ha

definido el Triage en los servicios de urgencias como, “(…) un sistema de selección y

clasificación de pacientes, basado en sus necesidades terapéuticas y los recursos

disponibles, que consiste en una valoración clínica breve que determina la prioridad en la

que un paciente será atendido. (…)”. De acuerdo con esta definición, y en el marco de la

normatividad colombiana, el Triage de urgencias tiene los siguientes objetivos:

• Asegurar una valoración rápida y ordenada de todos los pacientes que llegan a los

servicios de urgencias, identificando a aquellos que requieren atención inmediata.

• Seleccionar y clasificar los pacientes para su atención según su prioridad clínica y

los recursos disponibles en la institución,

• Disminuir el riesgo de muerte, complicaciones o discapacidad de los pacientes que

acuden a los servicios de urgencia.

62

• Brindar una comunicación inicial con información completa que lleve al paciente y

a su familia a entender en qué consiste su clasificación de Triage, los tiempos de

atención o de espera que se proponen y así disminuir su ansiedad

Actualmente, en Colombia se aplican dos tipos de Triage, según [70] y [71]:

• Triage Tradicional. Se encuentra contemplado en la mayoría de las instituciones y

aún se encuentra vigente pese a existir esfuerzos para llegar a un modelo más

estructurado. Es realizado por médicos y enfermeras, aunque en la mayoría de los

centros clínicos es llevado a cabo por médicos. En el proceso se incluye, aunque no

en todos los casos, la anamnesis del paciente, el examen físico y el diagnóstico

correspondiente. La clasificación en este caso corresponde, en su mayoría, a un

listado de diagnósticos médicos, excepto por los últimos niveles, los cuales

establecen la consulta externa y/o prioritaria como puntos de valoración para toda

patología en niveles superiores a 3, en la mayoría de los casos. En este tipo de

Triage prima el criterio médico sobre cualquier procedimiento.

• Triage Estructurado. Se encuentra en implementación a nivel nacional y

rápidamente se introduce en la mayoría de las instituciones de mediana y alta

complejidad. El Triage estructurado sistematiza las actividades y criterios de

clasificación de los pacientes que consultan el servicio de urgencias y puede ser

realizado por profesionales en medicina o enfermería en instituciones de mediana y

alta complejidad, mientras que, para instituciones de baja complejidad, puede ser

realizado por auxiliares de enfermería o tecnólogos en atención prehospitalaria, con

supervisión médica. Este proceso abarca las siguientes actividades (las cuales

cambian de institución a institución):

o Valorar y clasificar al paciente según su condición clínica. La valoración

incluye la anamnesis del paciente, estado mental y grado de conciencia,

apariencia general, signos vitales y evaluación de dolor. La clasificación

consiste en la asignación de un nivel según la escala aplicada. En este caso,

no se incluyen exámenes físicos ni diagnósticos a los pacientes, por lo que la

clasificación entra a depender de un proceso sistémico y no del criterio del

63

médico, en la mayoría de los casos. Este proyecto se encuentra centrado en

esta actividad.

o Trasladar al paciente al área de tratamiento e informar a profesionales

médicos y de enfermería responsables.

o Diligenciar el formato de Triage (también realizado durante la valoración y

clasificación).

o Mantener contacto con el paciente y su familia, proporcionando información

relacionada con el proceso de atención y el tiempo de espera.

o Evaluar frecuentemente a los pacientes que se encuentran en espera, después

de ser clasificados y repetir la clasificación de ser necesario.

Teniendo en cuenta lo dispuesto en [71], en Colombia se busca llevar a cabo la

clasificación de pacientes mediante la aplicación de las categorías representadas en la Tabla

2-5. Con esta definición, se busca disminuir el tiempo de atención de pacientes en los

servicios de urgencias hasta en un 30%, así como optimizar el uso de recursos clínicos en

las instituciones.

Tabla 2-5. Categorías del Triage. Tomado de [71]

Nivel Tipo de

Urgencia

Tiempo de

Espera

Descripción

TRIAGE I Reanimación Atención

inmediata

Requiere atención inmediata. La condición

clínica del paciente representa un riesgo vital y

necesita maniobras de reanimación por su

compromiso ventilatorio, respiratorio,

hemodinámico o neurológico, perdida de

miembro u órgano u otras condiciones que por

norma exijan atención inmediata.

TRIAGE II Emergencia Menos de 30

minutos

La condición clínica del paciente puede

evolucionar hacia un rápido deterioro o a su

muerte, o incrementar el riesgo para la pérdida de

un miembro u órgano, por lo tanto, requiere una

atención que no debe superar los treinta (30)

minutos. La presencia de un dolor extremo de

acuerdo con el sistema de clasificación usado

debe ser considerada como un criterio dentro de

esta categoría.

TRIAGE III Urgencia Menos de 2 horas

La condición clínica del paciente requiere de

medidas diagnósticas y terapéuticas en urgencias.

64

Son aquellos pacientes que necesitan un examen

complementario o un tratamiento rápido, dado

que se encuentran estables desde el punto de

vista fisiológico, aunque su situación puede

empeorar si no se actúa.

TRIAGE IV Urgencia menor Menos de 4 horas

El paciente presenta condiciones médicas que no

comprometen su estado general, ni representan

un riesgo evidente para la vida o pérdida de

miembro u órgano. No obstante, existen riesgos

de complicación o secuelas de la enfermedad o

lesión si no recibe la atención correspondiente.

TRIAGE V No urgente Menos de 5 horas

El paciente presenta una condición clínica

relacionada con problemas agudos o crónicos sin

evidencia de deterioro que comprometa el estado

general de paciente y no representa un riesgo

evidente para la vida o la funcionalidad de

miembro u órgano.

2.3.4. Contexto del proyecto

Teniendo en cuenta lo anterior y como es mostrado en la Figura 2-11, este proyecto se

encuentra orientada hacia el proceso de Triage que es suministrado en los servicios o

departamentos de urgencias de los centros hospitalarios del sector salud en Colombia. El

Triage hospitalario se encuentra orientado principalmente a la distribución de los recursos

médicos disponibles en un centro hospitalario que puede ser una clínica, hospital o

cualquier institución prestadora de salud, sujeta al sector. La asignación de estos recursos se

basa principalmente en tres condiciones:

• Disponibilidad de recursos médicos: Éstos son por lo general escasos. En cuanto a

esta condición, se cumplen dos reglas básicas:

o Cuando no se presenta escasez de recursos, el Triage no es necesario

o Cuando se presenta escasez total, el Triage puede llegar a ser inútil

• Condición del paciente: La cual es determinada por medio de una evaluación, cuya

principal entrada es la anamnesis del paciente.

65

• Sistema, plan, guía o conjunto de criterios: Los cuales soportan la determinación de

la prioridad del paciente, de manera sistemática (estructurada) o tradicional.

Figura 2-11. Escenario de Triage seleccionado para el estudio

Después de seleccionado el escenario para contextualizar la propuesta, se tomó una muestra

conformada por cuatro centros hospitalarios de diferentes niveles de atención, ubicados en

el Valle del Cauca (Tabla 2-6).

Tabla 2-6. Centros Hospitalarios tomados como muestra

Nombre Ubicación

Hospital Rubén Cruz Vélez [72] Tuluá, Valle

Clínica San Francisco S.A. [73] Tuluá, Valle

Clínica Mariangel Dumian Medical [74] Tuluá, Valle

Hospital Departamental Tomás Uribe Uribe [75] Tuluá, Valle

66

2.4. Marco Legal

Colombia tiene un marco legal amplio en materia de salud, específicamente en urgencias y

Triage. Casi todo este marco se encuentra alineado con el modelo que se describe en la

sección 2.3.2. Sin embargo, recientemente se han adicionado decretos que apuntan a

extender este marco legal para mejorar la oferta de los servicios de salud, de cara a las

nuevas propuestas e iniciativas llevadas a cabo por el ministerio de salud y otras carteras

como las TIC.

La normatividad de urgencias en Colombia es amplia y detallada en algunos aspectos como

la obligatoriedad de la atención, la prohibición de las barreras de acceso para el servicio y

las determinaciones legales con respecto a autorizaciones, cobros, proceso de referencia y

contra referencia, responsabilidades de los diferentes actores del sistema, entre otros. Pese a

que el Triage fue reglamentado a nivel nacional, los límites entre la urgencia y la no

urgencia continúan siendo, en ocasiones, imprecisos. Sin embargo, el cumplimiento de la

norma ha permitido subsanar varios de los baches que se encontraban en los servicios de

urgencias con respecto al Triage.

Las principales normas que reglamentan la Atención de Urgencias y el Triage que

adquieren importancia para la presente investigación se encuentran fundamentalmente en la

Constitución Política de Colombia, en los artículos 48, 49, 50 y la Ley 100 de 1993, donde

se crea el Sistema de Seguridad Social Integral. Adicionalmente encontramos como marco

normativo los siguientes.

• Ministerio de Salud y Protección Social. Circular 030 del 18 de mayo del 2016,

para secretarios departamentales, distritales y municipales de salud y gerentes de

instituciones prestadoras de salud, por la cual se otorgó un plazo hasta el 24 de junio

de 2016 para ajustar el Triage a los criterios definidos en la resolución 5596 de

2015.

67

• Ministerio de Salud y Protección Social. Resolución 5596 del 24 de diciembre

del 2015, por la cual se definen los criterios técnicos para el Sistema de Selección y

Clasificación de pacientes en los servicios de urgencias "Triage".

• Ministerio de Hacienda y Crédito Público y Departamento de Planeación

Nacional. Ley No. 1753 del 09 de junio de 2015, Por la cual se expide el plan

nacional de desarrollo 2014-2018 “Todos por un nuevo País”, el cual incluye la

implementación de herramientas para la salud, historia clínica electrónica,

arquitectura empresarial, interoperabilidad y servicios de telemedicina y tele-salud.

• Ministerio de las Tecnologías de la Información y las Comunicaciones, Plan

Nacional de Tecnologías de la Información y las Comunicaciones TIC 2014 -

2019, por medio del cual se crea el nodo de innovación en salud y, en convenio con

Colciencias, se abren convocatorias de proyectos orientados a soluciones

innovadoras para este sector.

• Comisión de Regulación en Salud, mediante el Acuerdo 029 del 2 de diciembre

de 2011, en el parágrafo 2 del artículo 19, se incluyó la prestación de los servicios

bajo la modalidad de telemedicina dentro del plan obligatorio de salud, hecho que

elimina una de las barreras identificadas para la prestación bajo esta modalidad e

incentiva la creación de nuevos servicios.

• Ministerio de Hacienda y Crédito Público y Departamento de Planeación

Nacional. Ley No. 1450 del 16 de junio de 2011, “Por la cual se expide el Plan

Nacional de Desarrollo, 2010-2014”, el cual involucra aspectos relacionados con la

salud y el uso de las TICs como catalizador de iniciativas de equidad en oferta y

demanda, así como de la eficiencia para la prestación de los servicios de salud.

• Ministerio de Protección Social y Ministerio de Hacienda y Crédito Público.

Ley No. 1438 del 19 de enero de 2011, por medio de la cual se reforma el sistema

68

general de seguridad social en salud y se dictan otras disposiciones respecto al

desarrollo de la telesalud.

• Ministerio de la Protección Social y el Ministerio de Hacienda y Crédito

Público. Ley 1419 de 2010, por medio de la cual se establecen los lineamientos

para el desarrollo de la Telesalud en Colombia.

• Ministerio de las Tecnologías de la Información y las Comunicaciones. Ley

1341 de 2009, por la cual se definen principios y conceptos sobre la Sociedad de la

Información y la organización de las Tecnologías de la Información y las

Comunicaciones TIC.

• Ministerio de la Protección Social. Decreto 4747 de diciembre 7 de 2007, por el

cual se regulan algunos aspectos de las relaciones entre los prestadores de servicios

de salud y las entidades responsables del pago de los servicios de salud de la

población a su cargo, y se dictan otras disposiciones.

• Ministerio de la Protección Social. Circular 076 de noviembre 27 de 2007, sobre

modificación y adopción de formularios de inscripción en el registro especial de

prestadores de servicios de salud para los que inicien la prestación de servicios y de

reporte de novedades al sistema único de calidad del Sistema Obligatorio de

Garantía de Calidad.

• Ministerio de la Protección Social. Resolución 3763 de 2007, por la cual se

modifican parcialmente las Resoluciones 1043 y 1448 de 2006 y la Resolución

2680 de 2007.


Público. Ley 1164 de 2007, por la cual se dictan disposiciones en materia del

Talento Humano en Salud, sobre pertinencia y competencia del talento humano.

69


Público. Ley 1122 de 2007, parágrafo 2° artículo 26, parágrafo 4° artículo 27.

Promueve los servicios de telemedicina en territorios de difícil acceso.

• Ministerio de la Protección Social. Resolución 1448 de 2006, por la cual se

definen las condiciones de habilitación para las instituciones que prestan servicios

de salud bajo la modalidad de telemedicina.

• Presidencia de la Republica y el Ministerio de Protección Social. Decreto 1011

de 2006, por el cual se establece el Sistema Obligatorio de Garantía de Calidad de la

atención de salud del Sistema General de Seguridad Social en Salud.

Como se puede observar, el marco legal colombiano para el sector salud, que inicia con la

constitución política es bastante amplio, pero ha carecido de equidad, dejando este sector en

desventaja durante varios años. A partir del año 2011 se han visto cambios positivos en la

norma, permitiendo estar más alineados con otros países y apostando por objetivos globales

como los objetivos de desarrollo del milenio, con vigencia a 2015 y los objetivos de

desarrollo sostenible, con vigencia a 2030. Específicamente para el proceso de Triage, hasta

el año 2015, Colombia carecía de reglamentación o algún criterio para definir este proceso.

Con la resolución No. 5596 del ministerio de protección social y salud de diciembre de

2015 y la circular enviada a las entidades públicas y privadas para su cumplimiento, la

aplicación de un modelo único de Triage es una realidad. Esta resolución proporcionó, con

mayor claridad, el marco conceptual, contextual y normativo para el abordaje del presente

trabajo.

70

Capítulo 3. Elicitación de los Requisitos Arquitecturales

3.1. Métodos

3.2. Resultados

71

3.1. Métodos

Para la generación de los ASR fueron utilizados los métodos relacionados con entrevistas a

stakeholders, consolidación de objetivos de negocio y revisión de literatura. La

combinación de estos tres métodos tuvo como resultado la generación del árbol de utilidad

descrito en la sección 3.2.1. Para las entrevistas realizadas a stakeholders y la consolidación

de los objetivos de negocio fueron utilizados los métodos QAW (principal) y PALM

(secundario) de manera conjunta, mientras que para la revisión bibliográfica fue realizada

una revisión sistemática de literatura en conjunto con una revisión ad-hoc sobre el Triage

de urgencias en Colombia, contexto y marco legal (secciones 2.3 y 2.4).

El método QAW fue llevado a cabo mediante un taller con las siguientes características:

• No. de participantes: 10

o 5 usuarios finales:

▪ 1 director de Servicio de Urgencias

▪ 2 encargados del área de Triage

▪ 2 enfermeras de Triage

o 2 arquitectos de software

o 3 ingenieros de software

• Duración del taller: 8 horas todos los participantes con 6 horas adicionales solo

para los arquitectos

• Cantidad de sesiones: 4 para todos los participantes con 1 adicional solo para los

arquitectos

La agenda del taller fue desarrollada utilizando algunas técnicas provenientes de Design

Thinking [76], [77], [78] y Lean UX [79], [80], [81], adaptadas para la búsqueda de ASR.

Estas técnicas permitieron lograr mayor empatía con los participantes, facilitando la

ejecución del taller, dada su gran carga técnica. El desarrollo del taller se describe en la

Tabla 3-1.

72

El resultado principal de este taller es un listado de escenarios priorizados, refinados y

documentados en un árbol de utilidad. Según [26], un árbol de utilidad es un repositorio

donde son almacenados los ASR, el cual permite que éstos puedan ser almacenados,

revisados, referenciados, utilizados para tomar decisiones y revisitados en caso de que el

sistema exponga cambios mayores (control de versiones). El árbol de utilidad construido

para la presente propuesta se describe en la sección 3.2.1, mientras que los escenarios

refinados para la evaluación de la arquitectura de software se describen en la sección 3.2.2.

Posteriormente, se realizó una Revisión Sistemática de Literatura, cuyo objetivo principal

se basó en encontrar la mayor evidencia posible en cuánto al diseño arquitectural de un

CDSS, sus drivers arquitecturales principales y los escenarios de calidad que constituyen

los mayores retos y preocupaciones consignados en la literatura, en otros contextos donde

éstos fueron implementados. Este ejercicio académico tomó alta relevancia ya que permitió

contrastar los resultados del QAW con otros contextos y así lograr un mayor refinamiento,

además de su validación temprana. Durante la aplicación de esta técnica, se siguió el

protocolo propuesto por Kitchenham [23], el cual es considerado como uno de los

instrumentos principales durante la práctica de la ingeniería de software basada en

evidencias (EBSE). Este protocolo fue aplicado como se muestra en la Tabla 3-2.

73

Tabla 3-1. Desarrollo del QAW para la propuesta de diseño arquitectural

Paso Duración Técnicas y Herramientas Desarrollo

1. Introducción y

presentación 1 hora

• Elevator Pitch [82]

• Presentación por

diapositivas

Los coordinadores describieron la motivación del QAW, iniciando por la

motivación de la propuesta como tal. En este caso, los arquitectos prepararon un

“Elevator Pitch” estructurado de tal forma que los participantes comprendieran el

problema planteado, su hipótesis y finalmente su rol en el taller.

Para explicar los pasos del taller, se utilizó una presentación por diapositivas

bastante simple, donde se explicó el objetivo de cada paso, las expectativas en

cuanto a resultados y lo que se obtendría al final.

Finalmente, cada participante se presentó ante el grupo, enfatizando en su

background, rol en la organización a la que pertenece y posible rol en el taller

desde su entendimiento y la relación que su rol tiene con respecto al sistema,

basado en la hipótesis previamente explicada.

2. Presentación del negocio 2 horas

• Lean UX & Design

Thinking – Empathy

Map [83]

• PALM [26]

Esta sesión fue ejecutada principalmente por los representantes de los usuarios

finales, pero guiados a través de los coordinadores. Los participantes presentaron

el contexto de sus negocios, utilizando como punto de partida sus declaraciones

misionales.

En este paso se utilizaron principalmente dos técnicas:

1. Mapa de Empatía [83]: Los coordinadores escucharon atentamente la

presentación de algunos requisitos de alto nivel, mientras los participantes

presentaron sus contextos. El mapa de empatía intenta ponerse en el lugar

de los representantes del negocio y hacerse preguntas relacionadas con

los “Pain points” del usuario. Algunas de estas preguntas son: ¿Qué

puede estar pensando el usuario?, ¿Qué siente?, ¿Qué partes del contexto

generaron ciertas emociones? Esto permitió conocer algunas necesidades

y revelaciones clave respecto a las principales preocupaciones de los

usuarios.

2. PALM [26]: Este método fue embebido en el paso 2 del QAW,

específicamente para expresar objetivos de negocio como escenarios y

enlazarlos con algunas categorías preestablecidas. Este método permitió a

74

su vez enlazar, tempranamente, algunos objetivos de negocio y

restricciones con escenarios de calidad.

Los coordinadores documentaron los hallazgos, comenzaron a escribir algunos

escenarios de calidad encontrados, permitiendo trabajar inmediatamente en el plan

arquitectural, para dar continuidad al taller.

3. Presentación del plan

arquitectural 0.5 horas

• Focus group


diapositivas

Por medio de un “Focus Group”, los arquitectos presentaron los planes de la

arquitectura, en términos de:

• Posibles decisiones y estrategias para satisfacer los requisitos del negocio

provenientes del paso 2.

• Requisitos y restricciones clave que podrán afectar la arquitectura y

conducirán las futuras decisiones.

• Diagramas de contexto y escenario principal de la arquitectura de

software, mostrando el rol del software a construir en el sistema.

Este paso fue realizado con todos los participantes, lo que generó retos desde el

punto de vista de audiencia. La sesión fue realizada con un enfoque hacia los

usuarios finales, como un medio de validación de los objetivos de negocio. Se

recogió la retroalimentación generada para su posterior análisis.

4. Identificación de drivers 0.5 horas

• Focus group


diapositivas

Por medio de un “Focus Group”, los arquitectos presentaron los drivers

arquitecturales, representados como atributos de calidad. Estos drivers fueron

generados a partir de la información recopilada y la revisión de literatura que se

llevó a cabo en paralelo. Se solicitaron aclaraciones y opiniones para el

refinamiento de los drivers. Los drivers presentados fueron:

• Security

• Performance

• Compatibility

• Availability

Las mayores preocupaciones de los representantes del usuario final se presentaron

con respecto a performance y availability, mientras que, desde el punto de vista

75

técnico, security y compability tomaron relevancia.

5. Lluvia de ideas de

escenarios 2 horas • Brainstorming

Los coordinadores iniciaron una lluvia de ideas en conjunto con los participantes,

utilizando la técnica “Brainstorming”, orientada a que los participantes generaran

los escenarios de calidad. Antes de este taller, los coordinadores explicaron, en

términos generales, las características básicas de un escenario (fuente, estímulo,

respuesta, medida, ambiente). En la medida que la sesión fue desarrollada, los

coordinadores se aseguraron de la correcta construcción de escenarios y

proporcionaron guía sin afectar el objetivo de la dinámica.

El desarrollo de la sesión de lluvia de ideas de escenarios fue realizado en forma

de Round-Robin, en el cual, cada participante a la vez proponía un escenario o las

preocupaciones que el software debía resolver. En cada intervención, cada

coordinador simplemente se aseguró de la completitud del escenario, más no de su

pertinencia, prioridad y si era correcto o no. En lo que se hizo énfasis fue en

garantizar al menos un escenario por driver, por lo que, al finalizar cada ronda, se

suministró orientación para llegar a este objetivo.

Terminado el ejercicio, el resultado principal fue un listado de 34 escenarios

(llamados escenarios crudos), construido directamente por los participantes y

guiado/moderado por los coordinadores.

6. Consolidación de

escenarios 2 horas

• Focus group

• Vetting

• Design Thinking -

Mind Map [84]

• Design Thinking –

The 5 Whys [85]

Finalizado el paso anterior, se formó una nueva sesión del taller orientada a la

consolidación de escenarios. La consolidación de escenarios básicamente buscó:

• Eliminar escenarios duplicados

• Unir dos o más escenarios en uno solo

• Remover algunos escenarios innecesarios, por consenso

Para esta sesión se utilizaron las técnicas Focus Group, Vetting, Mind Map y los 5

por qué. Durante el focus group, combinado con mapas mentales y los 5 por qué,

se comenzaron a identificar escenarios propensos a consolidar o agrupar, dadas

algunas características de similitud. Se trabajó en consenso y se lograron acuerdos

para evitar que algunos stakeholders pensaran que sus escenarios fueron

simplemente diluidos.

76

El paso siguiente en la sesión fue hacer un proceso de vetado de algunos

escenarios para su posterior remoción. Fueron muy pocos los escenarios que

pasaron por este proceso.

El resultado de esta sesión fue un listado de 26 escenarios crudos sin duplicados y

seleccionados para su priorización.

7. Priorización de escenarios 2 horas

• Focus Group

• Voting

• Árbol de utilidad

Esta sesión se hizo por medio de 2 rondas de votos. Los coordinadores asignaron a

cada stakeholder el 30% del total de escenarios en votos, redondeando al siguiente

número par. En este caso, como fueron 26 escenarios crudos resultantes del paso

anterior, cada stakeholder tuvo 8 votos (26*0,3=7,8).

Las rondas se hicieron por medio de Round-Robin y en cada ronda, cada

stakeholder podía poner 4 votos en total. A esta priorización, se le conoce como

prioridad según el valor de negocio. Los arquitectos y stakeholders técnicos

asignaron la prioridad conocida como prioridad según el impacto arquitectural.

Finalmente, se combinaron ambas para definir la prioridad de cada escenario.

El resultado de este ejercicio fue el listado de los 26 escenarios priorizados por la

combinación de valor para el negocio e impacto arquitectural. La documentación

de los escenarios de calidad priorizados consistió en representarlos a través de un

árbol de utilidad como repositorio principal (sección 3.2.1).

8. Refinamiento de escenarios 4 horas • ATAM

Finalmente, los coordinadores refinaron y documentaron los escenarios más

relevantes, por medio de un árbol de utilidad. El refinamiento consistió en:

• Proporcionar una clara y detallada descripción del escenario en términos

de:

o Estímulo

o Respuesta

o Fuente del Estímulo

o Ambiente

o Artefacto estimulado

o Medida de la respuesta

• Proporcionar una descripción de los objetivos/metas del negocio o su

77

misión, afectados por el escenario

• Listar los atributos de calidad relevantes, asociados con el escenario

• Preocupaciones y preguntas que pueden surgir de los stakeholders, con

respecto al escenario

• Criterios de evaluación (valor para el negocio e impacto arquitectural). La

escala utilizada para el valor del negocio fue:

o High (H): El requerimiento debe hacerse

o Medium (M): Es importante, pero si es omitido, el proyecto no

fracasa

o Low (L): Sería bueno tenerlo, pero no vale la pena mucho

esfuerzo

La escala utilizada para el impacto arquitectural fue:

o High (H): Incluir este ASR afectará en gran medida la

arquitectura

o Medium (M): Afectará en cierta medida la arquitectura

o Low (L): Afectará poco la arquitectura

La documentación de los escenarios de calidad refinados (sección 3.2.2) consistió

en representarlos a través del método ATAM, quedando definidos para su

correspondiente evaluación.

78

Tabla 3-2. Desarrollo de la revisión sistemática de literatura, adaptado de [24]

Fase Paso Desarrollo

Planeación

Identificación de la necesidad de la

revisión

Se estableció el objetivo principal de la revisión como “Encontrar evidencia

disponible sobre enfoques arquitecturales basados en cloud para la implementación de

CDSS” [24]. Dentro de estos enfoques arquitecturales, la idea era identificar los

principales escenarios, atributos de calidad, restricciones, retos y preocupaciones que,

generalmente, dirigen este tipo de implementaciones. A partir de este objetivo, se

plantearon las preguntas de la revisión, las cuales se enumeran a continuación, tal

como fueron planteadas:

“RQ1. What evidence is there about implementing CDSS in the cloud since 2010?

What are the major architectural approaches, contributions, limitations and concerns

about implementing cloud-based CDSS?

RQ2. Among which areas of health, which have more CDSS implementations?

RQ3. What types of CDSS are being built?

RQ4. What are the quality attributes that are typically driven in CDSS architectural

designs?

RQ5. What are the main data sources used in cloud-based CDSS?

RQ6. What evidence is there that cloud computing is an adequate approach for

implementing CDSS?”

Especificación de preguntas de

investigación

Desarrollo del protocolo

Teniendo las preguntas planteadas, se procedió a desarrollar el protocolo de la

revisión sistemática de literatura. Se siguieron las líneas guía propuestas en [23], sin

ningún tipo de modificación.

Evaluación del protocolo

Ejecución Estrategia de búsqueda

La cadena de búsqueda usada en las fuentes principales fue construida por medio de la siguiente estrategia:

79

• Las preguntas fueron descompuestas en facetas usando la técnica PICO

(Population, Intervention, Context and Outcome) como se describe a

continuación:

o “Population: Clinical Decision Support Systems”

o “Intervention: Cloud Computing, Software as a Service”

o “Context: Health Care”

o “Outcome: Quality Attributes and Scenarios, Software Engineering

measures”

• Se utilizaron conectores AND para unir las facetas.

• Se identificaron alternativas de escritura, sinónimos y abreviaciones.

• Se utilzaron conectores OR para las alternativas, sinónimos y abreviaciones.

Finalmente, la cadena de búsqueda utilizada fue:

(clinical OR medical OR "health care" OR healthcare OR health-care OR

"point of care" OR point-of-care OR care OR ehealth OR e-health OR

health) AND (cdss OR dss OR "decision support" OR decision-support OR

"decision making" OR decision-making OR alert OR reminder OR assist)

AND (system OR software OR service OR program OR application OR

architecture OR design OR implementation OR approach) AND (cloud OR

"cloud computing" OR cloud-computing OR "cloud based" OR cloud-based OR

"cloud enabled" OR cloud-enabled OR saas OR "software as a service" OR

software-as-a-service OR haas OR "health as a service" OR "ehealth as a

sevice" OR "e-health as a service" OR health-as-a-service OR ehealth-

as-a-sevice OR e-health-as-a-service)

Selección de fuentes primarias de

búsqueda

El proceso de búsqueda fue conducido sobre bases de datos electrónicas, usando y

ajustando la cadena de búsqueda, según las especificaciones de cada fuente. Las bases

de datos electrónicas utilizadas fueron:

o Compendex [86]

o Scopus [87]

o PubMed [88]

o IEEE Xplore [89]

o ACM [90]

80

Evaluación de calidad de los estudios

Para la evaluación de calidad y priorización de los estudios, se plantearon 5 preguntas para cada estudio, con el fin de calificarlos con un puntaje, de acuerdo con el peso de cada pregunta. Las preguntas se describen a continuación, tal como fueron planteadas: “AQ1. Was the method process described and appropriate? (12.5%)

AQ2. Were the results clearly described? (12.5%)

AQ3. Was the architectural approach described? (25%)

AQ4. It is possible to identify key quality attributes and/or scenarios that drive the design? (25%)

AQ5. The article helps or guides a future architectural design to conduce a CDSS implementation? (25%)”

La calificación posible planteada para cada pregunta fue N (0) si el estudio falla o no

contesta la pregunta, P (0.5) si el estudio cumple o contesta positivamente la pregunta

de forma parcial, o Y (1) si el estudio cumple o contesta positivamente la pregunta de

forma total. De acuerdo con lo anterior, los estudios seleccionados fueron calificados

con un puntaje entre 0 y 1, lo cual permitió su priorización para la revisión detallada

(extracción y síntesis de datos).

Extracción de datos

La extracción de información para los estudios evaluados se llevó a cabo por medio de la consolidación de dos tipos de información:

o Información general: Se extrajo información demográfica del estudio. La información extraída por cada artículo en este caso fue: data extractor, extraction date, data checker, checking date, study identifier, title, authors, year of publication, full reference, name of database, type of source, name of source and quality assessment score. Esta información fue tabulada en una table donde cada studio o artículo representa una fila.

o Información referente a cada Pregunta de Investigación: Se extrajo información relacionada con cada pregunta, con el fin de facilitar la síntesis de los datos, orientada a resolver cada objetivo secundario (preguntas). La información extraída por cada artículo en este caso fue: summary of the

81

proposed architectural approach, contributions of cloud computing on CDSS, gaps on intervention of cloud computing on CDSS, challenges of computing on CDSS, application area within the domain of health, types of proposed clinical decision support systems, list of quality attributes addressed, data sources proposed for the implementation of the CDSS. Esta información fue consignada en una ficha por estudio o artículo.

Con respecto a la estrategia de extracción de información, se generaron dos perfiles para los investigadores:

o Extractor: Encargado de conducir la extracción de datos sobre los estudios seleccionados y evaluados previamente.

o Validador: Encargado de validar cada extracción, con el objetivo de remover el sesgo del extractor.

Dado que la revisión de literatura fue realizada entre dos personas, ambos hicieron las veces de extractor y validador, cada uno con la mitad de los estudios en cada rol.

Síntesis de datos

Por cada artículo se elaboraron tabulaciones con la siguiente información:

o Enfoque arquitectural propuesto, contribuciones principales, brechas y retos (resolviendo la pregunta RQ1)

o Número de estudios por resultado sobre la intervención de cloud computing en la implementación de CDSS (resolviendo la pregunta RQ6)

o Número de estudios por área de aplicación (resolviendo la pregunta RQ2) o Número de estudios por tipo de CDSS (resolviendo la pregunta RQ3) o Número de estudios por atributo de calidad (resolviendo la pregunta RQ4) o Número de estudios por fuente de datos (resolviendo la pregunta RQ5)

Documentación

(Reporte Técnico)

Especificación de mecanismos de

diseminación

Se definió generar un Reporte Técnico, en el cual se explicó todo el protocolo

utilizado (para efectos de replicación por parte de otros autores) y los resultados

principales, así como la discusión final. Este reporte fue escrito en forma de artículo

[24], siguiendo los lineamientos de IEEE y fue sometido a publicación en el evento

CHASE 2016 [29], conferencia Cloud Connected Health (CCH), donde fue evaluado,

aprobado, publicado y posteriormente presentado por uno de los autores.

Escritura del Reporte Técnico

Evaluación del Reporte Técnico

82

3.2. Resultados

3.2.1. Árbol de Utilidad

La Tabla 3-3 muestra los ASR definidos y priorizados utilizando los métodos descritos en

la sección anterior.

Tabla 3-3. Árbol de Utilidad

ID Atributo de

Calidad Refinamiento ASR

Valor e

Impacto

ASR-01 Performance Throughput

Durante un pico de carga, el sistema debe estar en la

capacidad de procesar dos mil (2.000) solicitudes de

Triage por segundo.

(A, A)

ASR-02 Availability No downtime

El sistema debe estar disponible 24/7 (99.9%)

(A, A)


Si una instancia del clasificador falla, se debe

notificar al administrador, el sistema debe continuar

recibiendo solicitudes, por lo que otra instancia del

clasificador debe ser creada y los datos de todas las

solicitudes recibidas deben quedar consistentes.

(A, M)

ASR-04 Security Privacy

El 100% de la información del paciente proveniente

del Sistema de Historias Clínicas debe estar

encriptada a nivel de datos en cualquier modo de

operación.

(A, A)

ASR-05 Security Confidentiality Ningún cliente o usuario puede utilizar el Sistema sin

ser autorizado (A, A)


Si uno de los componentes principales del

clasificador falla, se debe retirar el componente y

operar en modo contingencia y reportar en un lapso

no mayor a 5 minutos.

(A, M)

ASR-07 Performance Transaction

response time

Durante un pico de carga del sistema, un usuario

ingresa una solicitud de Triage y ésta debe

completarse en menos de 30 segundos.

(A, M)

ASR-08 Performance Transaction

response time

Durante un pico de carga doble del sistema, un (A, M)

83

usuario ingresa una solicitud de Triage y ésta debe

completarse en menos de 2 minutos.

ASR-09 Security Confidentiality

En el 100% de los casos, los datos de las solicitudes

de Triage enviados al sistema no deben ser vistos por

terceros no autorizados.

(A, M)

ASR-10 Security Integrity

En el 100% de los casos, los datos de las solicitudes

de Triage enviados al sistema no deben ser alterados

por terceros no autorizados.

(A, M)

ASR-11 Security Integrity

En el 100% de los casos, los datos de los pacientes

consultados en sistemas terceros deben ser de sólo

lectura.

(A, M)

ASR-12 Security

Confidentiality

Integrity

Availability

El sistema resiste intrusiones no autorizadas y en

caso de presentarse un intento de intrusión, lo reporta

a los encargados de seguridad en un lapso no mayor a

90 segundos.

(A, M)

ASR-13 Interoperability Integration

Durante la consulta de la Historia Clínica Electrónica

(EHR y EMR) del paciente, el sistema de Triage debe

utilizar el estándar HL7 para comunicarse con el

sistema de Historias Clínicas Electrónicas.

(A, M)

ASR-14 Interoperability Integration

Durante la consulta de los registros médicos

personales (PHR), el sistema de Triage debe utilizar

el estándar HL7 para comunicarse con los Sistemas

de Información de los Hospitales.

(A, M)


Si algún componente del sistema falla, se deberá

reportar al equipo de monitoreo y alertas en un lapso

menor a 5 minutos.

(A, M)

ASR-16 Performance Throughput

Durante un pico de carga doble, el sistema debe estar

en la capacidad de procesar mil (1.000) solicitudes de

Triage por segundo.

(M, A)

ASR-17 Security Non-repudiation

Todas las comunicaciones dentro del sistema (100%)

deben estar encriptadas a nivel de protocolo en

cualquier modo de operación.

(M, M)

ASR-18 Configurability User-defined

changes

Se requiere configurar una escala de clasificación

existente. El equipo de configuración debe poder

ejecutar dicha tarea en 1 día sin necesidad de realizar

modificaciones al código fuente del sistema.

(M, M)

84

ASR-19 Configurability User-defined

changes

Se requiere configurar una base de datos nueva para

el sistema. El equipo de configuración debe poder

ejecutar dicha tarea en 2 días sin necesidad de

realizar modificaciones al código fuente del sistema.

(M, M)

ASR-20 Modificability Developer

changes

Se requiere implementar una nueva escala de

clasificación. Un implementador debe poder realizar

el cambio en menos de 160 horas hombre.

(M, M)

ASR-21 Modificability

Proficiency

Developer

changes

Un implementador de lado cliente con experiencia

mayor a 2 años en desarrollo de software es

proficiente en la integración del sistema con el

sistema cliente en menos de 80 horas hombre.

(M, L)

ASR-22 Extensibility Adding new

Components

Un implementador crea una API Web sincronizada

del sistema en menos de 160 horas hombre.

(M, L)


Components

Un implementador crea una API Web asíncrona del

sistema en menos de 160 horas hombre.

(M, L)


Components

Un implementador integra el sistema de clasificación

de urgencias hospitalarias a un sistema de

información de un hospital en menos de 500 horas

hombre.

(M, L)

ASR-25 Security Audit

El sistema debe trazar el 100% de las solicitudes

realizadas, junto con sus correspondientes respuestas.

(L, L)

ASR-26 Availability Testeability

Todos los componentes del sistema deben

proporcionar un servicio por medio del cual puedan

ser monitoreados.

(L, L)

85

3.2.2. Escenarios Refinados

De la Tabla 3-4 a la Tabla 3-13 se muestran los 10 escenarios de calidad principales, los

cuales fueron refinados y seleccionados para el proceso de evaluación de la arquitectura de

software (sección Capítulo 5).

Tabla 3-4. Escenario ASR-01 refinado

Escenario #: ASR-01 Durante un pico de carga, el sistema debe estar en la capacidad

de procesar dos mil (2.000) solicitudes de Triage por segundo.

Atributo de Calidad Performance

Refinamiento del Atributo de Calidad Throughput

Ambiente Pico de Carga transaccional

Estímulo Entrada de 2.000 solicitudes de Triage en 1 segundo

Respuesta

Cada solicitud es atendida en el tiempo normal establecido en

ASR-07. Todas las solicitudes son atendidas. Ninguna solicitud

es atendida por encima del tiempo establecido.


Escenario #: ASR-02 El sistema debe estar disponible 24/7 (99.9%).

Atributo de Calidad Availability

Refinamiento del Atributo de Calidad No downtime

Ambiente Operación normal

Estímulo Usuarios/Clientes intentando acceder

Respuesta 99.9% de disponibilidad del sistema


Escenario #: ASR-03

Si una instancia del clasificador falla, se debe notificar al

administrador, el sistema debe continuar recibiendo solicitudes,

por lo que otra instancia del clasificador debe ser creada y los

datos de todas las solicitudes recibidas deben quedar

consistentes.




Estímulo Una instancia del clasificador falla

Respuesta

Las solicitudes deben continuar siendo atendidas. Las

solicitudes que fueron atendidas antes de la falla deben ser

consistentes y proporcionar una respuesta dentro de los tiempos

establecidos en ASR-07.

86


Escenario #: ASR-04

El 100% de la información del paciente proveniente del

Sistema de Historias Clínicas debe estar encriptada a nivel de

datos.

Atributo de Calidad Security

Refinamiento del Atributo de Calidad Privacy


Estímulo El sistema consulta la información del paciente directamente en

una fuente externa.

Respuesta La información del paciente debe retornar encriptada.


Escenario #: ASR-05 Ningún cliente o usuario puede utilizar el Sistema sin ser

autorizado.


Refinamiento del Atributo de Calidad Confidentiality


Estímulo Un usuario/cliente no autenticado o no autorizado intenta

registrar una solicitud de Triage

Respuesta El sistema rechaza la petición por falta de credenciales o

credenciales de acceso inválidas.


Escenario #: ASR-06

Si uno de los componentes principales del clasificador falla, se

debe retirar el componente, operar en modo contingencia y

reportar en un lapso no mayor a 5 minutos.




Estímulo Un componente principal del clasificador falla

Respuesta

El sistema debe retirar el componente, operar en modo

contingente y notificar al administrador sobre la falla. Se debe

continuar con los tiempos de respuesta establecidos en ASR-

07.


Escenario #: ASR-07

Durante un pico de carga del sistema, un usuario ingresa una

solicitud de Triage y ésta debe completarse en menos de 30

segundos.


Refinamiento del Atributo de Calidad Transaction Response Time

Ambiente Pico de Carga transaccional

Estímulo Una solicitud de Triage es ingresada

Respuesta La respuesta a la solicitud de Triage debe entregarse

completamente en menos de 30 segundos.

87


Escenario #: ASR-08

Durante un pico de carga doble del sistema, un usuario ingresa

una solicitud de Triage y ésta debe completarse en menos de 1

minuto.


Refinamiento del Atributo de Calidad Transaction Response Time

Ambiente Doble Pico de Carga transaccional

Estímulo Una solicitud de Triage es ingresada

Respuesta La respuesta a la solicitud de Triage debe entregarse

completamente en menos de 2 minutos.


Escenario #: ASR-09

En el 100% de los casos, los datos de las solicitudes de Triage

enviados al sistema no deben ser vistos por terceros no

autorizados.



Ambiente Operación Normal

Estímulo Un tercero no autorizado intenta ver una solicitud de Triage

Respuesta El sistema no permite la visualización de los datos y reporta la

anomalía.


Escenario #: ASR-10

En el 100% de los casos, los datos de las solicitudes de Triage

enviados al sistema no deben ser alterados por terceros no

autorizados.


Refinamiento del Atributo de Calidad Integrity


Estímulo Un tercero no autorizado intenta alterar una solicitud de Triage

Respuesta El sistema no permite la actualización de los datos y reporta la

anomalía.

88

Capítulo 4. Diseño de la Arquitectura de Software

4.1. Métodos

4.2. Resultados

89

4.1. Métodos

Para el diseño y documentación de la arquitectura fueron utilizados dos métodos propuestos

por el SEI [16]. Con respecto al diseño, se utilizaron las estrategias descomposition y

generate-and-test, las cuales apuntan a dividir el sistema en elementos principales y, por

cada elemento, generar y probar un diseño arquitectural. Estas estrategias fueron aplicadas

por medio del método “Attribute Driven Design” (ADD, en adelante) [26] [91]. En la

Tabla 4-1, se describen los pasos que fueron aplicados para generar las principales

decisiones arquitecturales. La documentación del diseño arquitectural de los elementos del

sistema fue llevada a cabo utilizando un enfoque semi-formal, por medio del método

“Views and Beyond” (VaB, en adelante) [36] y utilizando el modelo de vistas 4+1

propuesto por Philippe Kruchten [28].

Tabla 4-1. Desarrollo del método ADD. Extendido de [26]

Paso Desarrollo

1. Seleccionar un elemento del

sistema a diseñar

Lo primero que se llevó a cabo fue una propuesta de solución

desarrollada durante la definición de los ASR y validada con los

stakeholders durante el QAW y con otros referentes académicos y de

industria como parte del trabajo futuro en [24]. A esta se le conoció

como la iteración 0, la cual tomó como elemento principal al sistema

como tal.

Seguido de la propuesta de solución, los arquitectos identificaron los

elementos primarios y secundarios del sistema por medio de la

descomposición del dominio o escenario principal en subdominios. Los

elementos primarios identificados fueron:

• Motor de Inferencia para Alertas y Recomendaciones

• Componente de Clasificación por escalas (Triage)

• Componente de Consulta de EHR y EMR de pacientes

Los elementos secundarios identificados fueron:

• Componente de registro (Input In Bound) y coordinación de

peticiones

• Componente de respuesta (Output In Bound)

• Componentes de seguridad

Los elementos excluidos del diseño arquitectural fueron:

90

• Sistemas de EHR y EMR

• Sistemas de Información de Hospitales

• Repositorio de Conocimiento Externo

• Todo lo relacionado con implementaciones de lado cliente o el

usuario final

Se iniciaron las iteraciones con los elementos primarios y luego con los

secundarios. Los elementos primarios fueron iterados más de una vez,

por medio de niveles de descomposición. En algunos elementos se llegó

a 3 iteraciones, mientras que, para la mayoría, se desarrollaron entre 1 y

2 iteraciones.

2. Identificar los ASR para dicho

elemento

Por cada elemento se identificaron los ASR marcados como (H, H), (H,

M) y (M, H) en el árbol de utilidad (Tabla 3-3), los cuales tuvieron

relación directa con el elemento en el cual se estaba iterando. La mayoría

de ASR aplicó a casi todos los elementos. Sólo en algunos casos

relacionados con la seguridad y la recepción de solicitudes se

presentaron ASR exclusivos.

El proceso de diseño arquitectural fue dirigido por los siguientes

atributos de calidad:

• Performance

• Availability

• Security

Sin embargo, en algunos elementos se incluyeron otros atributos de

calidad.

3. Generar una solución de diseño

para el elemento

Durante este paso se utilizaron tácticas, patrones y listas de chequeo

relacionados con los atributos de calidad identificados previamente, los

cuales estaban relacionados con el elemento. Estas tácticas, patrones y

listas de chequeo fueron tomadas de [25] y [26], la revisión de literatura

asociada al contexto de los CDSS [24], algunas revisiones ad-hoc

descritas en la sección 2.2 y la experiencia de los arquitectos en

ingeniería de software.

En la sección 4.2.1 se describen las decisiones arquitecturales tomadas

por cada atributo de calidad y para el sistema en general.

4. Verificar y refinar

requerimientos; Generar entradas

para la siguiente iteración

Dado que las decisiones generadas en el paso anterior generaron

restricciones para las siguientes iteraciones, en este paso se hizo una

revisión del diseño propuesto hasta el momento, en busca de

inconsistencias, restricciones y trade-offs importantes que evitaran el

progreso en el diseño e invitaran a reconsiderar el diseño o los

requerimientos. En el caso de hacer un refinamiento en los ASR, se hizo

directamente sobre el Árbol de Utilidad, guardando su respectivo control

de versiones. En la mayoría de los casos se presentaron refinamientos a

nivel de diseño y no de ASR, dado que los identificados como (H, H),

(H, M) y (M, H) eran inamovibles.

5. Repetir los pasos 1-4 hasta que

91

se satisfagan todos los ASR Esta actividad y la aplicación del método en términos generales, se puede

resumir en los siguientes puntos:

• Se identificaron 6 elementos

• Se realizaron 17 iteraciones (este paso se aplicó 16 veces)

• Los elementos principales fueron iterados más de una vez,

mientras que los secundarios, una sola vez

• Los atributos de calidad que guiaron el diseño fueron

Performance, Availability y Security.

• Durante cada iteración, se construyeron las vistas

arquitecturales, las cuales confirman la documentación de la

arquitectura. Esto se hizo como parte de una estrategia de

entrega continua/temprana de la arquitectura.

4.2. Resultados

4.2.1. Planteamiento de la Solución

4.2.1.1. Arquitectura de alto nivel

Teniendo en cuenta los ASR, la revisión sistemática de literatura, donde se contempla el

estado del arte en cuanto a la implementación de CDSS y la revisión bibliográfica Ad-hoc

realizada para el proceso de Triage en el contexto colombiano, se propuso la arquitectura

que se muestra en la Figura 4-1. Esta arquitectura consiste básicamente en cuatro

componentes principales: Process Coordinator (Coordinator Service), Triage Engine, EHR

Service e Inference Engine; los componentes para la entrada y salida de peticiones:

Register Service, y Response Service, y, finalmente, componentes secundarios con

funciones y responsabilidades específicas tales como gestión de la seguridad, monitoreo y

modelo de entrega de la solución. Cada componente es capaz de recibir una tarea/mensaje,

ejecutar sus funciones según sus responsabilidades y entregar una respuesta que puede ser

útil para otros componentes y para el resto del proceso. Lo anterior es gestionado a través

de un coordinador de procesos y servicios de mensajería para el paso de tareas/mensajes

entre componentes. A continuación, se describen cada componente en orden de importancia

para el sistema.

92

Figura 4-1. Arquitectura propuesta. Diagrama de alto nivel

• Coordinator Service: Este componente es llamado también Process Coordinator

(por el patrón de diseño arquitectural) y es el encargado de tomar las peticiones

registradas por el Register Service y despacharlas a los tres componentes principales

del sistema: Triage Engine, EHR Service e Inference Engine. Sus funciones van

más allá de un despacho simple, abordando tácticas de Availability y Security

descritas más abajo.

• Triage Engine: Es uno de los componentes principales de la arquitectura,

responsable de la aplicación del proceso de Triage a las peticiones enviadas por el

Process Coordinator, a través de un método o algoritmo de clasificación de

urgencias hospitalarias (i.e. MAT, SET, MAT/SET). Este componente está

encargado de enviar los resultados a los componentes encargados de suministrar las

respuestas al cliente o usuario.

• EHR Service: Es uno de los componentes principales de la arquitectura,

responsable de la consulta de la historia clínica de los pacientes (EHR, EMR, PHR),

93

a través de sistemas externos como bases de datos de EHR y PHR, y los sistemas de

información de hospitales para la consulta de EMR. Esta información es consultada

como fuente de datos principal para el motor de inferencias durante el proceso de

generación de alertas y recomendaciones. Este componente está encargado de

enviar los resultados a los componentes encargados de suministrar las respuestas al

cliente o usuario.

• Inference Engine: Es el componente principal de la arquitectura. Está compuesto

por los tres elementos comunes de un CDSS según [24], [92] y lo descrito en la

sección 2.2: Una base de conocimiento interna y/o externa, un motor de inferencia y

una interface. Su responsabilidad principal en esta propuesta es generar alertas y

recomendaciones basadas en la historia clínica y la anamnesis de un paciente,

correlacionando esta información con una base de conocimiento interna alimentada

por bases de conocimiento externas. Este componente está encargado de enviar los

resultados a los componentes encargados de suministrar las respuestas al cliente o

usuario.

• Register Service: Este componente tiene la responsabilidad de recibir las peticiones

que llegan de los usuarios y/o clientes (e.g. Un sistema de información de un

hospital integrado). Dentro de esta función, está encargado de validar la

información de entrada y despacharla al Process Coordinator para su procesamiento.

Este componente responde al usuario cuando asegura que la petición fue registrada,

más no cuando ésta termina, por lo que las transacciones realizadas al sistema son

asíncronas. En las arquitecturas orientadas a servicios, este componente es llamado

“Inbound endpoint” y puede ser implementado de diversas formas, como, por

ejemplo, una petición HTTP, una cola de entrada, un mensaje de correo electrónico,

un trino en Twitter, entre otros.

• Response Service: Este componente tiene la responsabilidad de obtener los

resultados suministrados por el Triage Engine, EHR Service e Inference Engine y

entregarlos a los clientes o usuarios de tal forma que se pueda cerrar el ciclo de las

peticiones realizadas a través del Register Service. Este componente puede ser

94

implementado de diferentes formas, según el enfoque que tome la construcción del

sistema. Por ejemplo, en una arquitectura orientada a servicios, este componente es

un Outbound endpoint que puede ser representado por medio de una cola o tema de

salida, un correo electrónico, una salida HTTP o una notificación push.

• Application Delivery Service: Consiste en un conjunto de servicios con

responsabilidades asociadas al modelo de entrega de las funcionalidades del

sistema, seguridad y monitoreo y gestión del sistema. En cuanto a servicios básicos

de entrega, comprende balanceo de cargas, Gateway y caché de contenido. En

cuanto a seguridad, comprende detección de ataques, control de acceso básico (i.e.

autenticación HTTP), entrega segura de información y validación de integridad por

medio de un protocolo de mensajería. Finalmente, en cuanto a monitoreo y gestión,

comprende log de actividades, rastreo de excepciones, monitoreo y alertas.

• Authentication and Authorization Service: Este componente es responsable de la

gestión de usuarios, roles, listas de control de acceso (ACL), grupos y todos los

elementos involucrados en la autenticación y autorización de usuarios y/o clientes

del servicio.

Por fuera de los límites de la arquitectura de software propuesta, se encuentran los

siguientes componentes, los cuales corresponden a sistemas externos que no hacen parte del

diseño de la arquitectura de software.

• Electronic Health Records System: Se asume como un sistema externo que

permitirá la consulta de EHR y PHR a través de un protocolo de comunicación y

mensajería estándar. También se asume que esta información es de dominio público

o comunitario. Por ejemplo, mediante algún servicio para entidades de salud.

• Hospital Information System: Se asume como un sistema privado perteneciente a

una entidad o red de entidades de salud, el cual puede ser integrado

bidireccionalmente. Puede ser utilizado para consultar EMR de los pacientes, así

95

como para integrarlo al sistema propuesto con un modelo de entrega viable (e.g. a

través de la exposición de servicios basados en HTTP).

• External Knowledge Repository: Se refiere a datos abiertos que contienen

información útil sobre síntomas, enfermedades, medicamentos y prescripciones

médicas. Al igual que el EHR System, se asume como información de domino

público o comunitario.

4.2.1.2. Enfoque Arquitectural

Teniendo en cuenta la arquitectura de alto nivel construida durante la primera iteración del

método ADD, descrita en la sección 4.2.1.1, se determinó que ésta presenta un estilo

principal de Tubos y Filtros (Pipe and Filter) donde el intercambio de mensajes

(Mesagging) constituye el principal patrón de diseño. Este estilo y patrón de diseño

permiten al sistema dividir el procesamiento de una solicitud de Triage en pasos

independientes, asíncronos y conectados a través de colas de mensajería, brindando

características fundamentales como performance, escalabilidad, reutilización y bajo

acoplamiento, necesarios para cumplir con los requisitos arquitecturales. Bajo este enfoque,

los filtros están representados en cada uno de los componentes principales de la

arquitectura encargados del procesamiento especifico de una etapa de la clasificación,

mientras que los tubos están representados en colas que, a través de mensajes, permiten

establecer la relación consumidor-productor entre los diferentes componentes de la

arquitectura.

Dados los escenarios de calidad descritos en 3.2.1 y refinados en 3.2.2 y las siguientes

iteraciones del método ADD, los principales atributos de calidad que debe satisfacer la

arquitectura de software propuesta son performance, availability y security. Esto se debe a

que el Triage de urgencias hospitalarias es un servicio vital que requiere generar respuestas

rápidas y precisas, en un entorno hostil que opera en un esquema 7/24/365, en el cual la

información del paciente es el insumo principal. El sector salud en general se encuentra

fuertemente regulado, por lo que cualquier sistema de información que opere dentro de su

alcance será igualmente regulado y controlado por normas relacionadas, en su mayoría, con

la privacidad de la información de los pacientes y clínicas.

96

A continuación, se describen las principales decisiones arquitecturales, representadas en

forma de tácticas y patrones utilizados por cada driver.

4.2.1.3. Solucionando Performance

De acuerdo con [25], [35], las tácticas utilizadas para performance se dividen en dos

grupos, tal como se muestra en la Figura 4-2: Control de la Demanda de Recursos y

Gestión de Recursos.

Figura 4-2. Tácticas analizadas para performance. Adaptado de [25], [35]

Control de la Demanda de Recursos se refiere al conjunto de tácticas que se pueden

implementar para limitar el número de solicitudes, eventos y/o llamados que el sistema

puede procesar en cierto tiempo, y con los recursos disponibles, para satisfacer los tiempos

de respuesta requeridos y especificados en los ASR. En el escenario de Triage propuesto, la

implementación de tácticas orientadas a controlar la demanda de los recursos no se

considera viable por la criticidad del servicio a la que se enfrenta el CDSS que sea

implementado, al tener que proporcionar resultados que van en consecución de la salud de

un paciente de manera directa o indirecta. De esta forma, limitar el número de solicitudes,

por ejemplo, puede afectar la oportunidad de atención de un paciente, provocando impactos

negativos en su condición de salud y en el servicio de urgencias como tal.

Basados en lo anterior, la arquitectura propuesta considera algunas tácticas provenientes del

segundo grupo (Gestión de Recursos), el cual consiste en gestionar y optimizar el uso de los

recursos computacionales disponibles para atender la mayor cantidad posible de solicitudes,

eventos y/o llamados. Según lo anterior, las decisiones arquitecturales para el diseño

propuesto tuvieron en cuenta las siguientes tácticas y patrones.

97

DA-01. Introducción de Concurrencia: Se refiere al procesamiento de varias actividades

en paralelo para la misma petición, con el objetivo de reducir el tiempo de respuesta. El uso

de esta táctica es posible ya que la aplicación del algoritmo de Triage, la búsqueda de la

historia clínica del paciente y la sugerencia de alertas y recomendaciones, a partir de una

base de conocimiento, son actividades que pueden ser procesadas de forma independiente y

en paralelo, es decir, no existe dependencia entre ellas.

Figura 4-3. Componentes del patrón "Process Coordinator". Tomado de [25]

Para implementar esta táctica se utilizó el patrón de diseño Process Coordinator,

representado en la Figura 4-3. Este patrón encapsula los procesos o actividades que deben

ser ejecutados para atender una petición, reduce el acoplamiento ya que cada proceso o

actividad no es consciente de que existen otras actividades en ejecución, y permite además

implementar su comunicación de forma sincronizada o asíncrona. En el diseño propuesto,

el Process Coordinator es el único componente responsable de despachar una misma

petición hacia tres componentes principales: Triage Engine, Inference Engine y EHR

Service. Estos componentes ejecutan la misma petición en paralelo y generan respuestas

diferentes e independientes, según su especialización. La primera variación realizada a este

patrón se encuentra representada en la Figura 4-4 y consiste en que el Process Coordinator,

en este caso, no espera resultados de los procesos si no que éstos responden de manera

independiente y autónoma, por medio de una cola o tema de salida por cada uno de ellos.

98

Figura 4-4. Primera variación del patrón "Process Coordinator"

La segunda variación realizada a este patrón se encuentra representada en la Figura 4-5 y

consiste en la utilización de colas persistentes para el registro de las peticiones realizadas a

cada componente, incluyendo el Process Coordinator. Esto es una forma de introducir

concurrencia, al permitir que cada componente atienda solicitudes de forma asíncrona, sin

que el componente origen deba esperar una respuesta del componente destino. En este caso

se utilizó el patrón de diseño Task Queue o Messaging, el cual se encuentra basado en el

uso Producers y Consumers suscritos a las colas de tareas.

DA-02. Implementación de múltiples copias de cómputo: Consiste en tener múltiples

instancias de un componente específico, con el fin de procesar múltiples peticiones al

mismo tiempo, sin degradar el tiempo de respuesta. Incluso, se puede pensar en reducir

dicho tiempo mediante la aplicación de esta táctica. En el diseño propuesto, se estableció la

cardinalidad [3, *] para los componentes principales (Register, Process Coordinator, Triage

Engine, Inference Engine, EHR Service y Response Service), tal como se muestra en la

Figura 4-6. En este caso, para la recepción de las peticiones se pueden implementar

balanceadores de carga cuando estas peticiones deban ser sincronizadas (Figura 4-7), o

colas volátiles y/o persistentes cuando estas peticiones puedan ser asíncronas (Figura 4-8).

99

Figura 4-5. Segunda variación del patrón "Process Coordinator"

100

Figura 4-6. Diseño de componentes con cardinalidad específica

Figura 4-7. Uso de un Load Balancer para transacciones sincronizadas

Figura 4-8. Uso de colas persistentes para transacciones asíncronas

Por medio de la implementación de esta táctica, es posible mejorar el throughput del

sistema, permitiendo incrementar el número de peticiones atendidas dentro de un

determinado periodo y, en consecuencia, se podrá incrementar la oportunidad de atención

de un paciente en el servicio de Triage.

101

DA-03. Incrementar Recursos computacionales: Consiste en el escalamiento de los

recursos computacionales disponibles (procesamiento, almacenamiento, memoria, redes de

comunicaciones) durante el procesamiento de una solicitud. La implementación de esta

táctica depende en gran medida del presupuesto establecido para el proyecto. Sin embargo,

tal como se describe en [24], la implementación de un CDSS puede ser soportada por

modelos de entrega basados en computación en la nube, los cuales permiten acceder a una

gran variedad y volumen de recursos computacionales a un bajo costo, si se compara con

modelos tradicionales on-premise. El reto con modelos de entrega basados en la nube se

encuentra en las diferentes restricciones y aspectos de seguridad y privacidad de la

información que deben considerarse. En la propuesta de arquitectura, los componentes

fueron diseñados de tal forma que puedan escalar horizontalmente, independientemente del

modelo de entrega y la infraestructura subyacente. Se estableció una cardinalidad (descrita

en la decisión DA-02) con el fin de limitar el incremento de los recursos.

Otras tácticas aplicadas en el diseño de la arquitectura propuesta son:

• DA-04. Implementación de múltiples copias de la información, por medio del

caché de datos y la replicación de la información en bases de datos de solo-lectura

con el fin de mejorar la capacidad de operación de las mismas.

• DA-05. Calendarización de recursos, por medio del uso de semáforos y accesos

sincronizados a algunos componentes críticos, con el fin de evitar contención de

recursos.

4.2.1.4. Solucionando Availability

Availability hace referencia a la propiedad que tiene el software de estar listo para ejecutar

sus tareas cuando sea requerido y su capacidad de enmascarar y/o reparar fallos. De esta

forma, el periodo fuera de servicio de un sistema no excederá el valor requerido en un

intervalo específico de tiempo. Existen múltiples estilos, patrones y tácticas de arquitectura

para satisfacer este atributo de calidad, las cuales según [25], [35], se pueden clasificar en

tres grupos, tal como se muestra en la Figura 4-9: Detección de Fallos, Recuperación de

Fallos y Prevención de Fallos.

102

Figura 4-9. Tácticas analizadas para availability. Adaptado de [25], [35]

La Detección de Fallos incluye todas aquellas tácticas que permiten detectar posibles fallas

de manera oportuna para mitigar eventos que afecten el funcionamiento normal sistema.

Esto se logra mediante la implementación de herramientas y tácticas orientadas al

monitoreo de los componentes de un sistema. De esta manera se pueden detectar y reparar

fallas antes de que éstas se conviertan en errores visibles a los usuarios. De este grupo, las

decisiones arquitecturales descritas a continuación fueron tenidas en cuenta para la

arquitectura propuesta.

DA-06. Monitoreo del Sistema: Dado que la arquitectura propuesta involucra diversos

componentes orquestados a través de tareas y mensajes, cada uno puede representar un

punto de fallo. La arquitectura propuesta propone el monitoreo de los componentes más

importantes (Auth Service, Register, Process Coordinator, Triage Engine, Inference Engine

y EHR Service) por medio de transacciones sintéticas como el “Self-Check”, “Ping/Echo”

y “Heartbeat”, orquestadas a través de un monitor del sistema basado en reglas para la

generación de alertas y monitoreo, como se ilustra en la Figura 4-10. Uno de los tipos de

monitoreo más utilizados son los APM (Application Performance Monitoring), los cuales

se enfocan en la detección y diagnóstico de problemas complejos en aplicaciones, con el fin

de mantener el nivel de servicio (SLA) esperado. Algunos ejemplos de herramientas que

proveen este servicio son: New Relic [93], DataDog [94] y Grafana [95].

103

Figura 4-10. Uso de un Monitor para los componentes principales

DA-07. Log de Actividades: La implementación de un log de actividades, como se ilustra

en la Figura 4-11, en los componentes principales permitirá detectar eventos anormales.

Esto se logra determinando patrones de eventos considerados como normales para la

aplicación e implementando reglas que detecten si una serie de eventos no cumplen dicho

patrón.

En el log de actividades del sistema propuesto se podrán determinar aspectos como:

• Un componente presenta degradación sistemática en la atención de peticiones, dado

que el tiempo entre peticiones supera los límites de control establecidos.

104

• Un componente no está actuando como fue programado debido a que la trazabilidad

de sus acciones dista del patrón definido.

• Un componente del sistema se encuentra fallando constantemente debido a que

genera mensajes de error frecuentes asociados a la infraestructura.

Se utilizarán servicios de terceras partes para analizar de forma inteligente los logs de

actividades y saber reaccionar oportunamente ante un posible fallo. Algunos ejemplos de

herramientas que proveen este servicio son: LogStash [96], LogEntries [97] y LogMatic

[98].

Figura 4-11. Uso de un Log de Actividades para los componentes principales

105

Figura 4-12. Uso de rastreo de excepciones para los componentes principales

DA-08. Gestión de Excepciones: Las excepciones como tal pueden ser consideradas fallos

en el sistema. Algunas de estas denotan errores críticos o fatales, mientras que otras

simplemente pueden alertar que el sistema se está viendo afectado por algún evento

anormal. La implementación de rastreo de excepciones (Figura 4-12) es una forma de traza

de logs especializada en este tipo de eventos, y puede lograrse por medio de un adecuado

tratamiento a las mismas, según su naturaleza e impacto que pueda generar el evento en el

sistema.

Se propone utilizar un log de actividades con reglas especializadas (patrones relacionados

con manejo de excepciones) y servicios de terceras partes específicamente para gestionar

excepciones. Algunos ejemplos de herramientas que proveen este servicio son: Rollbar

[99], Airbrake [100] y Sentry [101].

106

En Recuperación de Fallos se agrupan las estrategias que permiten que el sistema sea capaz

de recuperarse y de volver a su funcionamiento normal, cuando se presenta una. La

redundancia es una de las tácticas más utilizadas, cuyo objetivo es permitir que, ante la falla

de un componente del sistema, otro componente sea capaz de continuar la atención de las

solicitudes que se encuentren en proceso sin que los usuarios se vean afectados. Otras

tácticas y patrones para este grupo se encuentran asociadas a la gestión de excepciones,

rollback, reintentos y degradación. De este grupo, las decisiones arquitecturales descritas a

continuación fueron tenidas en cuenta para la arquitectura propuesta.

Figura 4-13. Uso de redundancia tipo Cold Spare para el Triage Engine

DA-09. Implementación de redundancia de tipo Cold Spare: Esta táctica es la que exige

menor presupuesto entre las tácticas de tipo redundancia. Su implementación permitirá al

sistema recuperarse del fallo de un componente por medio de la introducción transparente

de otra instancia del mismo componente. En la arquitectura propuesta, esto será logrado

gracias al uso de colas persistentes y el patrón Messaging o Task Queue en los

componentes principales. Lo anterior se puede evidenciar en la Figura 4-13 y su escenario

principal se describe a continuación.

Cuando un componente falla, éste será reportado por medio del monitor del sistema o a

través de una excepción. Inmediatamente, se disparará una acción para la creación de una

107

nueva instancia del componente a nivel de infraestructura (por medio de la técnica de auto-

scaling). Esta nueva instancia retomará el trabajo de la cola ya que esta información fue

persistida y se encontrará disponible para la nueva instancia.

DA-10. Compensación de Transacciones: Esta táctica permite al sistema regresar a un

estado anterior estable ante una falla. El uso de esta táctica es posible gracias al uso de

colas especializadas para cada tipo de componente y la persistencia del estado de las

solicitudes en proceso. Esto permite determinar las solicitudes que se encontraba

atendiendo el componente que falló, para luego compensar las transacciones que fueron

realizadas antes de la falla. Se propone el uso de compensación de transacciones en las

capas de persistencia de la arquitectura.

DA-11. Reintentos y reenvío continuo: Esta táctica permite a un componente hacer un

reintento en caso de un fallo, con el fin de evitar que el usuario del sistema evidencie un

error en caso de alguna latencia o fallo esporádico. Gracias a la implementación de colas

persistentes, los componentes podrán reestablecer las tareas o mensajes en las mismas con

el fin de ejecutar un reintento. El uso del patrón de diseño Process Coordinator permite

implementar el reenvío continuo fácilmente, ya que éste puede reestablecer las peticiones

que van a los tres servicios en caso de algún fallo. De hecho, este componente puede

determinar a qué componentes reenviar una petición.

En Prevención de Fallos se encuentran las tácticas, las cuales, apoyadas en la detección de

fallas, se encargan de prevenir fallas en el sistema antes que estas se presenten. Algunas de

las tácticas de este grupo se enfocan en determinar qué componentes no se encuentran en

normal, para removerlos o degradar sus funcionalidades hasta que se encuentren en

operación normal. Otras tácticas se enfocan en la prevención de fallos conocidos,

robusteciendo las competencias de los componentes. De este grupo fueron tomadas las

siguientes decisiones arquitecturales.

108

DA-12. Remoción del servicio: Aplicar esta táctica en la arquitectura propuesta es posible

a través del Process Coordinator, el cual puede determinar si algunos de los componentes

principales presentan fallos para evitar enviarles peticiones. Se puede verificar el estado de

los componentes directamente o a través del monitor del sistema. Por ejemplo, si en

determinado momento se detecta que el componente EHR Service, encargado de consultar

la historia clínica electrónica del paciente, presenta problemas de contención, éste se puede

remover temporalmente del servicio, como se observa en la Figura 4-14. De esta forma, el

sistema podrá realizar el proceso de Triage con los dos componentes restantes (Triage e

Inference Engine), aportando igualmente información valiosa al proceso.

Figura 4-14. Remoción del componente EHR Service desde el Process Coodinator

DA-13. Incrementar las competencias de los componentes: Esta técnica se basa en que

cada componente asegure su consistencia e integridad por medio de validaciones más

robustas, auto-verificación y otros mecanismos de autodefensa y autocontrol. En el actual

diseño, se propone que cada componente sea independiente y autónomo al momento de

validar entradas y verificar su estado.

109

4.2.1.5. Solucionando Security

Seguridad se refiere a la habilidad que tiene el sistema para proteger sus datos de accesos

no autorizados, así como permitir acceso a servicios y datos únicamente a quienes cuenten

con los privilegios requeridos. La seguridad considera tres características esenciales, a

saber, la confidencialidad, integridad y disponibilidad.

La confidencialidad se refiere a la protección de servicios y datos de accesos no

autorizados. La integridad se refiere a la protección de dichos servicios y datos de

manipulación no autorizada. Disponibilidad se refiere a garantizar que el sistema se

encuentre operando en condiciones normales para su uso legítimo.

El objetivo de las tácticas para seguridad es preservar estas tres características en un

sistema, por medio de la detección, resistencia, reacción o recuperación de ataques, a través

de diferentes técnicas y herramientas. Según [25], [35] y como se muestra en la Figura

4-15, las tácticas para seguridad se pueden dividir en cuatro grupos: Detección de Ataques,

Resistencia a Ataques, Reacción a Ataques y Recuperación de Ataques.

Figura 4-15. Tácticas analizadas para security. Adaptado de [25], [35]

La Detección de Ataques es una forma proactiva de reducir la deuda técnica, por medio de

la identificación de posibles ataques relacionados con el sistema. Una técnica utilizada para

esta identificación de ataques es la inferencia basada en patrones de eventos anormales.

Esta técnica puede implementarse fácilmente a través de un log de actividades y un

110

rastreador de excepciones, las cuales son tácticas descritas anteriormente. De este grupo

fueron tomadas las siguientes decisiones arquitecturales.

DA-14. Implementación de un “Application Delivery Service”: Este componente,

representado en la Figura 4-16, hace parte de la arquitectura propuesta y está encargado de

la detección de ataques de seguridad, entre otros servicios relacionados con el modelo de

entrega de la solución. Este componente puede ser visto como un proxy o un Gateway

expuesto al público, a través del cual serán filtradas todas las peticiones entrantes para

proceder con validaciones de seguridad antes de pasar mensajes a los componentes

principales. Gracias al uso del log de actividades y el rastreo de excepciones, este

componente detectará patrones de mensajes anormales que sean considerados como

posibles ataques como intrusión al sistema (i.e. Inyección SQL, Cross-site scripting),

denegación de servicio (i.e. DoS) y detección de retraso de mensajes. La implementación

de este componente puede lograrse a través de servicios de terceros como NGINX [102], el

cual proporciona servicios de proxy, Gateway y seguridad.

Figura 4-16. Implementación del Application Delivery Service

DA-15. Verificación de la integridad de los mensajes: Es una táctica que consiste en la

verificación de los mensajes entregados a los componentes principales de la arquitectura,

con el fin de detectar posibles ataques de tipo inyección (i.e. Inyección SQL, Cross-site

scripting). Su implementación se puede lograr por medio de la validación de esquema a

nivel de protocolo de mensajería. De acuerdo con [103], la validación de esquema es

111

utilizada para proteger a un Sistema de mensajes malformados maliciosamente. La

validación de mensajes con esquemas puede proteger parámetros y/o atributos en

operación, datos y contratos de mensajes.

La Resistencia a los Ataques es una forma proactiva de proteger el sistema antes de que un

ataque sea exitoso. Las decisiones arquitecturales tenidas en cuenta en este grupo se

describen a continuación.

DA-16. Componente de Autenticación y Autorización “Auth Service”: Este

componente (Figura 4-17) es el encargado del control de acceso al sistema. Su

implementación se propone como un servicio de gestión de identidad y acceso (IAM, por

sus siglas en inglés). Existen servicios de terceros que proporcionan este servicio por medio

del uso de tokens (oAuth, JSON Web Tokens [104]), roles, gestión de permisos y niveles

de acceso, gestión de políticas de autorización, autenticación multi-factor, single sign-on,

entre otros. Algunos ejemplos de proveedores de estos servicios son: NGINX [102], Auth0

[105], Okta [106] y Microsoft Azure Active Directory [107]. En la Figura 4-18 se

representa el flujo que utilizará el Sistema para autenticación de usuarios del sistema,

mientras que la Figura 4-19 muestra el flujo para la autorización de peticiones. Estos flujos

se encuentran basados en oAuth 2.0 [108].

Figura 4-17. Componente de Autenticación y Autorización “Auth Service”

112

Figura 4-18. Flujo de Autenticación basado en oAuth 2.0 [108]

Figura 4-19. Flujo de Autorización basado en oAuth 2.0 [108]

DA-17. Limitar el acceso y la exposición: Básicamente, se propone la creación de zonas

de seguridad, divididas en dos grandes grupos: Zonas militarizadas, las cuales no

proporcionarán acceso a ningún componente que no se encuentre dentro de su zona de

seguridad; y Zonas desmilitarizadas, las cuales proporcionarán acceso parcial o total a

componentes que se encuentran en otras zonas de seguridad. Las reglas de firewall son

implementadas en la infraestructura subyacente. Tal como se muestra en la Figura 4-20, el

componente “Application Delivery Service” estará ubicado en una zona desmilitarizada

para actuar como proxy, separando el acceso público del acceso privado. Los componentes

principales de la arquitectura, donde se encuentran las actividades principales e información

sensible no serán expuestos para su acceso público o acceso desde interfaces no

autorizadas.

Para la limitación de la exposición, todos los componentes se comunican entre sí a través de

interfaces bien definidas. Ningún componente podrá comunicarse con otro por medios

diferentes a estas interfaces. Las interfaces permiten definir los contratos de comunicación,

donde puede definirse el nivel de exposición o encapsulamiento de los servicios de los

componentes. Por ejemplo, el único componente expuesto a los clientes finales es el

Application Delivery Service y los balanceadores de carga que se implementen antes de

113

éste. Los componentes principales sólo son accesibles a otros componentes a través de sus

interfaces.

DA-18. Cifrado de datos: Consiste en mitigar un ataque no detectado, al no permitir que

un intruso entienda la información que ha sido vulnerada. Esta técnica será implementada

de la siguiente forma:

• Cifrado a nivel de protocolo y no repudiación, para todos los componentes de la

arquitectura que utilicen protocolos basados en TCP/IP (i.e. HTTP, SMTP).

• Cifrado a nivel de datos para el componente EHR Service, con el objetivo de cifrar

información sensible de los pacientes. La anonimización de datos será un tipo de

cifrado a utilizar.

Para el cifrado a nivel de protocolo y de datos, se hará uso de SSL (Secure Sockets Layer) y

se realizará negociación TLS para la no repudiación de peticiones y mensajes entre

componentes.

Figura 4-20. Limitando acceso a los componentes a través de zonas de seguridad

114

DA-19. Separación de entidades: Se trata de proveer una separación física de los

componentes que manejan datos sensibles, con el objetivo de evitar su vulneración al

presentarse un ataque sobre otros componentes de la arquitectura. Esto será implementado

por medio de la limitación del acceso y la exposición, por medio de la definición de zonas

de seguridad. Para que esto sea posible, se propone un modelo de despliegue a nivel de

infraestructura, que permite dividir el sistema por niveles. Esto es descrito más abajo en la

vista de despliegue del sistema (sección 5.2.2.5).

La Reacción a los Ataques es una forma de proteger el sistema cuando un ataque tuvo éxito

y está siendo llevado a cabo. Lo anterior quiere decir que el ataque no fue detectado y los

mecanismos de resistencia no pudieron evitarlo. En este caso, se proponen dos decisiones

arquitecturales descritas a continuación.

DA-20. Revocación de acceso: Se refiere a la revocación bien sea del acceso a algún

recurso o la limitación de los permisos que tiene un usuario o cliente hacia el mismo. Esta

se da cuando el sistema detecta que se está presentando un ataque. Esta táctica será

implementada usando el patrón Process Coordinator, en su componente principal. Cuando

éste es informado sobre un evento anormal en alguno de los componentes que procesan las

actividades relacionadas con el Triage, removerá el componente del servicio hasta que el

evento sea normalizado (manual o automáticamente).

DA-21: Informe a actores: Se refiere a alertar a los actores relacionados con la seguridad

del sistema que está siendo comprometido durante un ataque. Estos actores pueden ser

administradores de Bases de Datos, administradores de aplicaciones, personal de seguridad,

entre otros. En todos los casos (detección, resistencia y reacción a ataques), dentro de las

acciones llevadas a cabo, se implementará el informe de la situación a los administradores

del sistema, con el fin de facilitar la toma de decisiones. Las alertas propuestas en este caso

pueden tener la prioridad como uno de sus atributos, donde ésta es más alta si el sistema fue

atacado y más baja si existen posibilidades de ser atacado. Los monitores del sistema, log

115

de actividades y rastreador de excepciones serán configurados para suministrar esta

información de manera oportuna.

Finalmente, la Recuperación de Ataques comprende dos tácticas reactivas que consisten en

que el sistema alcance un punto de operación normal o estable después de haber sido

atacado. En este caso, se utilizarán las mismas tácticas y patrones descritos para la categoría

Recuperación de Fallos, del atributo Availability.

4.2.1.6. Solucionando otros Atributos de Calidad

Los escenarios planteados en el árbol de utilidad (Tabla 3-3) no sólo se plantean alrededor

de Performance, Availability y Security. A pesar de que éstos tres atributos de calidad son

los dirvers arquitecturales, existen otros atributos que hacen parte del diseño para los cuales

se plantearon tácticas y patrones. Estas tácticas y patrones se plantean a continuación. Las

decisiones arquitecturales DA-22 a DA-26 solucionan los atributos Modificability,

Configurability y Extensibility, mientras que, las decisiones DA-27 a DA-29 solucionan

Interoperability.

DA-22: División en módulos: La división de un sistema en módulos específicos permite

que las modificaciones que se requieran realizar a estos se puedan efectuar de manera

rápida y efectiva, minimizando el impacto en los demás componentes. En la sección 5 se

puede observar en detalle la utilización de esta táctica en los diferentes niveles de diseño de

la arquitectura.

DA-23: Incremento de la cohesión semántica: La definición de roles y responsabilidades

específicas para cada uno de los componentes de la arquitectura minimiza el impacto que

conlleva una modificación sobre alguna de las funcionalidades. Al tener componentes

altamente cohesionados, las piezas de software a modificar durante un cambio son

fácilmente identificables y se reduce el tiempo de modificación que requiere cada una de

ellas. En el diseño propuesto, cada componente tiene sus propios roles y responsabilidades.

116

Por ejemplo, el componente de Triage solo se encarga de realizar la clasificación de

urgencias, mientras que el motor de inferencias se encarga de las alertas y

recomendaciones. El el diseño no existe un componente que solape las responsabilidades de

otro.

DA-24: Encapsulamiento: S refiere al ocultamiento del estado de un componente, de tal

forma que las funcionalidades del mismo o su comportamiento solo pueda ser afectado a

través de sus propias interfaces o métodos. El encapsulamiento de funcionalidades reduce

la probabilidad de que un cambio en un módulo se propague a los demás módulos del

sistema. En el diseño propuesto se definieron interfaces (API) a cada uno de los

componentes de la arquitectura logrando que la comunicación con el resto del sistema se

realice a través de estas, sin que los demás componentes requieran conocer cómo fue

implementado o cómo el módulo con el que están interactuando procesa una petición.

DA-25: Uso de intermediarios: Esta táctica es usada para evitar la dependencia entre un

módulo A y un módulo B, la cual puede romperse a través del uso de intermediarios. En el

diseño de la arquitectura se optó por la implementación de los patrones Process

Coordinator y Task Queue para eliminar la relación directa entre la mayoría de

componentes del sistema. En las secciones 5.2.2.3 y 5.2.2.4 se puede ver la utilización de

esta táctica en cuanto a componentes y los procesos asociados con los escenarios bajo los

cuales fue propuesta la arquitectura.

DA-26: Restricción de dependencias: Consiste en restringir un módulo en términos de

visibilidad y autorización, con el fin de que la interacción entre módulos se haga a través de

los caminos o mecanismos definidos por el arquitecto. En el diseño propuesto, los

componentes están organizados en un estilo de capas (Layered), el cual restringe que una

capa superior (Interface) solo pueda acceder a la siguiente capa inferior (Business Logic)

reduciendo el acoplamiento entre los módulos del sistema. En la sección 5 se puede

117

observar en detalle la utilización de esta táctica en los diferentes niveles de diseño de la

arquitectura

DA-28 – Localización de Servicios: Consiste en la localización de un servicio a través de

un directorio de servicios conocidos. Esta táctica es propuesta en la arquitectura para los

servicios de EHR, EMR y PHR, permitiendo que el servicio externo con el que se desea

interoperar el sistema pueda ser localizado en tiempo de ejecución.

DA-29 Orquestación de Servicios: Consiste en el uso de un mecanismo de control para

coordinar y gestionar la secuencia de invocación de servicios particulares. Es usada cuando

la utilización de servicios requiere cierto grado de complejidad en términos de interacciones

y/o actividades. Esta táctica es propuesta en la arquitectura para coordinar la invocación de

los servicios externos (EHR System, HIS System), los cuales son utilizados por los

componentes del sistema para consultar información como la Historia Clínica Electrónica

(EHR y EMR) del paciente y registros médicos personales (PHR).

4.2.1.7. Cubrimiento de Requisitos

Durante las iteraciones del método ADD, en la medida que los arquitectos tomaron las

decisiones arquitecturales basadas en las tácticas y patrones descritas en las secciones

anteriores, se verificó el impacto (positivo y negativo) que tienen las mismas frente a los

atributos de calidad. Basados en lo anterior, se construyó iterativamente un árbol de

tácticas, el cual es útil como guía para el refinamiento de las decisiones arquitecturales y la

aplicación de los métodos de evaluación. En la Figura 4-21 se muestra el árbol de tácticas,

el cual fue construido teniendo en cuenta el modelo descrito en [109]. Una vez finalizadas

las iteraciones aplicando el método ADD, se verificaron todas las decisiones arquitecturales

con respecto a los escenarios de calidad, con el fin de garantizar la completitud en el

cubrimiento de los requisitos arquitecturalmente significativos. La Tabla 4-2 muestra el

mapeo entre los escenarios y las decisiones arquitecturales.

118

Figura 4-21. Resultado final del Árbol de Tácticas/Decisiones construido iterativamente

119

Tabla 4-2. Cubrimiento de escenarios a través de las decisiones arquitecturales

ID Atributo de

Calidad ASR Decisiones Arquitecturales

ASR-01 Performance

Durante un pico de carga, el sistema debe estar en la

capacidad de procesar dos mil (2.000) solicitudes de

Triage por segundo.

• DA-01. Introducción de Concurrencia

• DA-02. Implementación de múltiples copias de cómputo

• DA-03. Incrementar recursos computacionales

• DA-04. Implementación de múltiples copias de la

información

• DA-05. Calendarización de recursos

ASR-02 Availability

El sistema debe estar disponible 24/7 (99.9%)

• DA-06. Monitoreo del sistema

• DA-07. Log de actividades

• DA-08. Gestión de Excepciones

• DA-09. Implementación de redundancia tipo cold spare

• DA-10. Compensación de transacciones

• DA-11. Reintentos y reenvío continuo

ASR-03 Availability

Si una instancia del clasificador falla, se debe notificar al

administrador, el sistema debe continuar recibiendo

solicitudes, por lo que otra instancia del clasificador debe

ser creada y los datos de todas las solicitudes recibidas

deben quedar consistentes.




• DA-09. Implementación de redundancia tipo cold spare

• DA-10. Compensación de transacciones

• DA-13. Incrementar las competencias de los componentes

• DA-21. Informe a actores

ASR-04 Security


Sistema de Historias Clínicas debe estar encriptada a nivel

de datos en cualquier modo de operación.

• DA-18. Cifrado de datos

120

ASR-05 Security Ningún cliente o usuario puede utilizar el Sistema sin ser

autorizado

• DA-16. Componente de Autenticación y Autorización “Auth

Service”

• DA-20. Revocación de acceso


ASR-06 Availability

Si uno de los componentes principales del clasificador

falla, se debe retirar el componente y operar en modo

contingencia y reportar en un lapso no mayor a 5 minutos.




• DA-12. Remoción del servicio



ASR-07 Performance

Durante un pico de carga del sistema, un usuario ingresa

una solicitud de Triage y ésta debe completarse en menos

de 30 segundos.





información

ASR-08 Performance

Durante un pico de carga doble del sistema, un usuario

ingresa una solicitud de Triage y ésta debe completarse en

menos de 1 minuto.





información

ASR-09 Security

En el 100% de los casos, los datos de las solicitudes de

Triage enviados al sistema no deben ser vistos por terceros

no autorizados.

• DA-14. Implementación de un Application Delivery Service


Service”

• DA-17. Limitar el acceso y la exposición


• DA-19. Separación de entidades


121

ASR-10 Security


Triage enviados al sistema no deben ser alterados por


• DA-14. Implementación de un Application Delivery Service

• DA-15. Verificación de la integridad de los mensajes


Service”






ASR-11 Security

En el 100% de los casos, los datos de los pacientes

consultados en sistemas terceros deben ser de sólo lectura.


Service”





ASR-12 Security

El sistema resiste intrusiones no autorizadas y en caso de

presentarse un intento de intrusión, lo reporta a los

encargados de seguridad en un lapso no mayor a 90

segundos.




• DA-12. Remoción del servicio


Service”






ASR-13 Interoperability

Durante la consulta de la Historia Clínica Electrónica

(EHR y EMR) del paciente, el sistema de Triage debe

• DA-28. Localización de servicios

• DA-29. Orquestación de servicios

122

utilizar el estándar HL7 para comunicarse con el sistema

de Historias Clínicas Electrónicas.

ASR-14 Interoperability

Durante la consulta de los registros médicos personales

(PHR), el sistema de Triage debe utilizar el estándar HL7

para comunicarse con los Sistemas de Información de los

Hospitales.

• DA-28. Localización de servicios

• DA-29. Orquestación de servicios

ASR-15 Availability

Si algún componente del sistema falla, se deberá reportar

al equipo de monitoreo y alertas en un lapso menor a 5

minutos.





ASR-16 Performance

Durante un pico de carga doble, el sistema debe estar en la

capacidad de procesar mil (1.000) solicitudes de Triage

por segundo.





información

• DA-05. Calendarización de recursos

ASR-17 Security

Todas las comunicaciones dentro del sistema (100%)

deben estar encriptadas a nivel de protocolo en cualquier

modo de operación.


ASR-18 Configurability

Se requiere configurar una escala de clasificación

existente. El equipo de configuración debe poder ejecutar

dicha tarea en 1 día sin necesidad de realizar


• DA-22: División en módulos

• DA-23: Incremento de la cohesión semántica

• DA-24: Encapsulamiento

• DA-25: Uso de intermediarios

• DA-26: Restricción de dependencias

ASR-19 Configurability

Se requiere configurar una base de datos nueva para el


123

sistema. El equipo de configuración debe poder ejecutar

dicha tarea en 2 días sin necesidad de realizar







Se requiere implementar una nueva escala de clasificación.

Un implementador debe poder realizar el cambio en menos

de 160 horas hombre.







Un implementador de lado cliente con experiencia mayor a

2 años en desarrollo de software es proficiente en la

integración del sistema con el sistema cliente en menos de

80 horas hombre.



ASR-22 Extensibility

Un implementador crea una API Web sincronizada del








Un implementador crea una API Web asíncrona del








Un implementador integra el sistema de clasificación de

urgencias hospitalarias a un sistema de información de un

hospital en menos de 500 horas hombre.




124



ASR-25 Security

El sistema debe trazar el 100% de las solicitudes

realizadas, junto con sus correspondientes respuestas.



ASR-26 Availability

Todos los componentes del sistema deben proporcionar un

servicio por medio del cual puedan ser monitoreados.




125

4.2.2. Vistas Arquitecturales

5.2.2.1. Vista de Escenarios

Descripción de la Vista

Esta vista representa el uso del sistema desde el punto de vista de la arquitectura de

software. Su representación ha sido construida mediante diagramas de casos de uso de

UML, con el objetivo de mostrar el escenario principal que se cubre con la propuesta.

VP-01. Escenario principal

Representación de la Vista

La Figura 4-22 representa el caso de uso principal del sistema, el cual se resume a

continuación: Un usuario cliente del sistema realiza una petición de Triage o Clasificación

de Urgencia Hospitalaria.

Figura 4-22. Presentación del escenario principal de la solución propuesta

Este caso de uso incluye la aplicación del método o algoritmo de Triage y la generación de

alertas y recomendaciones, que a su vez incluye la consulta de la historia clínica del

paciente en fuentes externas y la inferencia a través de un motor que consulta en una base

126

de conocimiento interna, generada a partir de una base de conocimiento externa. Los

resultados se van notificando al usuario o cliente en la medida que son obtenidos.

Catálogo de Elementos

La Tabla 4-3 muestra los elementos presentes en esta vista, mientras que la Tabla 4-4

muestra las relaciones entre estos elementos.

Tabla 4-3. Elementos del escenario principal

Elemento Nombre Descripción

Actor User

Cliente o usuario del sistema. En esta vista no se

detalla la especialización de este actor.

Caso de Uso Hospital Emergency

Classification

Caso de uso principal que representa el proceso de

Triage o clasificación de urgencia hospitalaria para

un paciente.

Caso de Uso Apply Classification Method

Consiste en la aplicación del método o algoritmo de

Triage según la anamnesis del paciente.

Caso de Uso Generate Alerts and

Reminders

Consiste en la generación de alertas y

recomendaciones basadas en los datos del paciente y

una base de conocimiento.

Caso de Uso Search Health Records

Consiste en la búsqueda de los EHR, PHR y EMR

de los pacientes, por medio de la integración con

sistemas externos.

Caso de Uso Search Knowledge Repository

Consiste en la búsqueda de datos en una base de

conocimiento, con el fin de permitir la inferencia de

alertas y recomendaciones. Esta base de

conocimiento es interna y es alimentada por una

base de conocimientos externa.

Caso de Uso Notify HEC Result

Consiste en suministrar al usuario o cliente el

resultado de aplicar el método de Triage y el proceso

de inferencia de alertas y recomendaciones.

Actor Electronic Health Record

(EHR) System

Sistema abierto utilizado para consultar EHR y PHR

de pacientes. Puede ser visto como un sistema de

acceso público o comunitario, el cual puede ser

utilizado por la solución propuesta.

127

Actor Hospital Information System

(HIS)

Sistema privado correspondiente a una entidad con

la que puede ser integrada la solución propuesta en

algún caso particular. Puede ser utilizado para

consultar los EMR de los pacientes.

Actor External Knowledge

Repository

Base de conocimiento externa, la cual puede ser

consultada para generar conocimiento propio en la

solución propuesta. Puede ser visto como un sistema

de acceso público o comunitario con información de

síntomas, enfermedades, medicamentos,

prescripciones médicas comunes, etc.

Tabla 4-4. Relaciones entre los elementos del escenario principal

Elemento Relacionado con Tipo de relación

User Hospital Emergency Classification Asociación

User Notify HEC Result Asociación

Hospital Emergency Classification Apply Classification Method Inclusión

Hospital Emergency Classification Generate Alerts and Reminders Inclusión

Hospital Emergency Classification Notify HEC Result Inclusión

Generate Alerts and Reminders Search Electronic Health Records Inclusión

Generate Alerts and Reminders Search Knowledge Repository Inclusión

Search Electronic Health Records Electronic Health Record (EHR)

System Asociación

Search Electronic Health Records Hospital Information System (HIS) Asociación

Search Knowledge Repository External Knowledge Repository Asociación

5.2.2.2. Vista Lógica


Esta vista representa la descomposición y uso de los módulos del sistema, así como la

relación entre ellos y otros sistemas. Su representación ha sido construida mediante

diagramas de paquetes de UML, con el objetivo de mostrar la descomposición y el uso

fácilmente.

128

VP-02. Vista general de módulos


La Figura 4-23 presenta la primera iteración o nivel de descomposición del sistema. En esta

vista se puede observar el módulo principal de la arquitectura (Hospital Emergency

Classifier o HEC) y su relación con los sistemas externos: Electronic Health Record (EHR)

System, Hospital Information System (HIS) y External Knowledge Base.

Figura 4-23. Vista general de módulos de la solución propuesta




Tabla 4-5. Elementos de la vista general de módulos


Paquete o Módulo Triage CDSS

Frontera o límites del sistema.

Paquete o Módulo Hospital Emergency Classifier

(HEC)

Módulo principal del sistema, el cual consiste en el

clasificador de urgencias hospitalarias, basado en un

método de Triage y alertas y recomendaciones.

129

Paquete o Módulo Electronic Health Record

(EHR) System





Paquete o Módulo Hospital Information System

(HIS)





Paquete o Módulo External Knowledge

Repository







Tabla 4-6. Relaciones entre los elementos de la vista general de módulos


Hospital Emergency Classifier (HEC) Electronic Health Record (EHR)

System Uso

Hospital Emergency Classifier (HEC) Hospital Information System (HIS) Uso

Hospital Emergency Classifier (HEC) External Knowledge Repository Uso

VP-03. Vista de módulos – Hospital Emergency Classifier


La Figura 4-24 presenta la segunda iteración o nivel de descomposición del sistema. En

esta vista se observan los módulos internos de la solución propuesta y cuáles y cómo

interactúan con los sistemas externos. También se pueden observar dos módulos internos al

sistema, pero vistos como apoyo para la clasificación. Estos son: Auth Service y

Transactional Service.

130

Figura 4-24. Vista de módulos Hospital Emergency Classifier




Tabla 4-7. Elementos de la vista de módulos del Hospital Emergency Classifier


Paquete o Módulo Hospital Emergency Classifier

(HEC)

Módulo principal del sistema, el cual consiste en el

clasificador de urgencias hospitalarias, basado en un

método de Triage y alertas y recomendaciones.

Paquete o Módulo Register Service

Módulo que registra todas las peticiones realizadas

por el usuario o cliente.

Paquete o Módulo Coordinator Service

Process Coodinator, descrito en el planteamiento de

la solución, el cual, básicamente está encargado de

tomar las peticiones registradas y despacharlas de

manera inteligente hacia los tres componentes que

generan el resultado esperado.

Paquete o Módulo Triage Service

131

Módulo que aplica el método o algoritmo de Triage

a la petición realizada, según la anamnesis del

paciente.

Paquete o Módulo EHR Service

Módulo que consulta las EHR, PHR y EMR de los

pacientes por medio de su integración con sistemas

externos.

Paquete o Módulo Inference Engine

Módulo principal del CDSS (motor de inferencia).

Paquete o Módulo Response Service

Módulo encargado de consultar las respuestas

generadas por el Triage Service, EHR Service e

Inference Engine, para luego generar las salidas

correspondientes para los usuarios o clientes.

Paquete o Módulo Auth Service

Módulo encargado de la autenticación y autorización

de usuarios y/o clientes del sistema.

Paquete o Módulo Transactional Service

Módulo encargado de la persistencia del sistema.


(EHR) System






(HIS)






Repository







Tabla 4-8. Relaciones entre los elementos de la vista de módulos del HEC


Coordinator Service Register Service Uso

Triage Service Coordinator Service Uso

EHR Service Coordinator Service Uso

132

Inference Engine Coordinator Service Uso

Response Service Triage Service Uso

Response Service Inference Engine Uso

Hospital Emergency Classifier (HEC) Auth Service Uso

Hospital Emergency Classifier (HEC) Transactional Service Uso

EHR Service Electronic Health Record (EHR)

System Uso

EHR Service Hospital Information System (HIS) Uso

Inference Engine External Knowledge Repository Uso

VP-04. Vista de módulos – Coordinator Service


La Figura 4-25 presenta la tercera iteración o nivel de descomposición del módulo

“Coordinator Service”. En esta vista se observa cómo el módulo será implementado

internamente.

Figura 4-25. Vista de módulos Coordinator Service

133




Tabla 4-9. Elementos de la vista de módulos del Coordinator Service


Paquete o Módulo Coordinator Service

Process Coodinator, descrito en el planteamiento de

la solución, el cual, básicamente está encargado de

tomar las peticiones registradas y despacharlas de

manera inteligente hacia los tres componentes que

generan el resultado esperado.

Capa Interface

Capa donde se exponen las interfaces o servicios que

puede suministrar el Coordinator Service.

Paquete o Módulo Coordinator Interface Services

Módulo que expone las interfaces o servicios del

Coordinator Service.

Paquete o Módulo Coordinator Interface DTO

Módulo que define los objetos de transferencia de

datos en el Coordinator Service.

Capa Business Logic

Capa donde se implementan los elementos que

resuelven la lógica de negocios del Coordinator

Service. Ejemplo: Despacho de solicitudes a los

diferentes componentes.

Paquete o Módulo Coordinator Business Services

Módulo que maneja la lógica de negocios del

Coordinator Service.

Paquete o Módulo Coordinator Business Objects

Módulo que define los objetos de negocio utilizados

por el Coordinator Service.

Capa Integration

Capa donde es realizada la integración con otros

servicios a través de sus interfaces. Ejemplo: Interfaz

con el Transactional Service para realizar

persistencia de solicitudes.

Paquete o Módulo Coordinator Integration

Services

Módulo que realiza las integraciones del Coordinator

Service con otros módulos o sistemas, a través de

interfaces.

Paquete o Módulo Coordinator Integration

134

Objects Módulo que define los objetos de integración de

datos utilizados por el Coordinator Service para

comunicarse con otros módulos o sistemas.




paciente.




externos.





Tabla 4-10. Relaciones entre los elementos de la vista de módulos del Coordinator


Triage Service Coordinator Service Uso

EHR Service Coordinator Service Uso

Inference Engine Coordinator Service Uso

Coordinator Interface Services Coordinator Interface DTO Uso

Interface Business Logic Permitido para Uso

Coordinator Business Logic Coordinator Business Objects Uso

Business Logic Integration Permitido para Uso

Coordinator Integration Services Coordinator Integration Objects Uso

Coordinator Integration Services Transactional Service Uso

VP-05. Vista de módulos – Triage Service


La Figura 4-26 presenta la tercera iteración o nivel de descomposición del módulo “Triage

Service”. En esta vista se observa cómo el módulo será implementado internamente.

135

Figura 4-26. Vista de módulos Triage Service




Tabla 4-11. Elementos de la vista de módulos del Triage Service





paciente.

Capa Interface


puede suministrar el Triage Service.

Paquete o Módulo Triage Interface Services


Triage Service.

Paquete o Módulo Triage Interface DTO


datos en el Triage Service.

136

Capa Business Logic


resuelven la lógica de negocios del Triage Service.

Ejemplo: Aplicación del algortimo de Triage.

Paquete o Módulo Triage Business Services

Módulo que maneja la lógica de negocios del Triage

Service.

Paquete o Módulo Triage Business Objects


por el Triage Service.

Capa Integration



con el Transactional Service para realizar

persistencia de resultados del Triage.

Paquete o Módulo Triage Integration Services

Módulo que realiza las integraciones del Triage

Service con otros módulos o sistemas, a través de

interfaces.

Paquete o Módulo Triage Integration Objects

Módulo que define los objetos de integración de

datos utilizados por el Triage Service para






generadas por el Triage Service, para luego generar

las salidas correspondientes para los usuarios o

clientes.

Tabla 4-12. Relaciones entre los elementos de la vista de módulos del Triage Service


Response Service Triage Service Uso

Triage Interface Services Triage Interface DTO Uso


Triage Business Logic Triage Business Objects Uso


Triage Integration Services Triage Integration Objects Uso

Triage Integration Services Transactional Service Uso

137

VP-06. Vista de módulos – EHR Service


La Figura 4-27 presenta la tercera iteración o nivel de descomposición del módulo “EHR

Service”. En esta vista se observa cómo el módulo será implementado internamente.

Figura 4-27. Vista de módulos EHR Service




Tabla 4-13. Elementos de la vista de módulos del EHR Service





externos.

138

Capa Interface


puede suministrar el EHR Service.

Paquete o Módulo EHR Interface Services


EHR Service.

Paquete o Módulo EHR Interface DTO


datos en el EHR Service.

Capa Business Logic


resuelven la lógica de negocios del EHR Service.

Ejemplo: Transformación de datos.

Paquete o Módulo EHR Business Services

Módulo que maneja la lógica de negocios del EHR

Service.

Paquete o Módulo EHR Business Objects


por el EHR Service.

Capa Integration



con el Electronic Health Records (EHR) System.

Paquete o Módulo EHR Integration Services

Módulo que realiza las integraciones con otros

módulos o sistemas, a través de interfaces. En este

caso, este módulo implementará un delegado de

negocios o una fachada para la integración con

sistemas externos, por lo que cada tipo de

integración será realizada en módulos diferentes, con

implementaciones diferentes, dependiendo del

sistema externo.

Paquete o Módulo EHR Integration

Módulo que realiza las integraciones con los

Electronic Health Records (EHR) Systems, a través

del delegado de negocios o fachada.

Paquete o Módulo HIS Integration

Módulo que realiza las integraciones con los

Hospital Information Systems (HIS) Systems, a

través del delegado de negocios o fachada.

Paquete o Módulo EHR Integration Objects


datos utilizados por el EHR Service para


139




(EHR) System






(HIS)







generadas por el EHR Service, para luego generar

las salidas correspondientes para los usuarios o

clientes.

Tabla 4-14. Relaciones entre los elementos de la vista de módulos del EHR Service


Response Service EHR Service Uso

EHR Interface Services EHR Interface DTO Uso


EHR Business Logic EHR Business Objects Uso


EHR Integration Services EHR Integration Uso

EHR Integration Services HIS Integration Uso

EHR Integration Electronic Health Record (EHR)

System Uso

HIS Integration Hospital Information System (HIS) Uso

EHR Integration Services EHR Integration Objects Uso

EHR Integration EHR Integration Objects Uso

HIS Integration EHR Integration Objects Uso


140

VP-07. Vista de módulos – Inference Engine


La Figura 4-28 muestra la tercera iteración o nivel de descomposición del módulo

“Inference Engine”. En esta vista se observa cómo el módulo será implementado

internamente.

Figura 4-28. Vista de módulos Inference Engine

Cabe destacar que en esta vista ya pueden identificarse los componentes principales del

CDSS propuesto:

• Interface: Mapeado en el módulo “Inference Interface Services”

• Motor de Inferencia: Mapeado en el “Interface Business Service”

• Base de Conocimiento: Mapeado en los módulos “Inference Repository Rules

Base”, “Inference Repository Fact Base” y el “Inference Repository External Base”,

que usa a su vez al “External Knowledge Repository”.

141




Tabla 4-15. Elementos de la vista de módulos del Inference Engine




Capa Interface


puede suministrar el Inference Engine.

Paquete o Módulo Inference Interface Services


Inference Engine.

Paquete o Módulo Inference Interface DTO


datos en el Inference Engine.

Capa Business Logic


resuelven la lógica de negocios del Inference

Engine, la cual básicamente consiste en realizar las

inferencias de alertas y recomendaciones.

Paquete o Módulo Inference Business Services

Módulo que maneja la lógica de negocios del

Inference Engine.

Paquete o Módulo Inference Business Objects


por el Inference Engine.

Capa Integration



con el External Knowledge Repository.

Paquete o Módulo EHR Integration Services

Módulo que realiza las integraciones con otros

módulos o sistemas, a través de interfaces. En este

caso, este módulo implementará un delegado de

negocios o una fachada para la integración con

sistemas internos (motor de reglas, base de hechos

interna) y externos (base de conocimientos externa).

Paquete o Módulo Inference Repository Rules

Base

Módulo que realiza las integraciones con un motor

de reglas implementado internamente, a través del

142

delegado de negocios o fachada.

Paquete o Módulo Inference Repository Fact

Base

Módulo que realiza las integraciones con una base

de hechos implementada internamente, a través del

delegado de negocios o fachada.

Paquete o Módulo Inference Repository External

Base

Módulo que realiza las integraciones con la base de

conocimientos externa, a través del delegado de

negocios o fachada.

Paquete o Módulo Inference Integration Objects


datos utilizados por el Inference Engine para





Repository









generadas por el Inference Engine, para luego

generar las salidas correspondientes para los

usuarios o clientes.

Tabla 4-16. Relaciones entre los elementos de la vista de módulos del Inference Engine


Response Service Inference Engine Uso

Inference Interface Services Inference Interface DTO Uso


Inference Business Logic Inference Business Objects Uso


Inference Integration Services Inference Repository Rules Base Uso

Inference Integration Services Inference Repository Fact Base Uso

Inference Integration Services Inference Repository External Base Uso

Inference Repository External Base External Knowledge Repository Uso

Inference Integration Services Inference Integration Objects Uso

143

Inference Repository Rules Base Inference Integration Objects Uso

Inference Repository Fact Base Inference Integration Objects Uso

Inference Repository External Base Inference Integration Objects Uso


5.2.2.3. Vista de Desarrollo


En esta vista se muestra el sistema desde la perspectiva del desarrollador y se ocupa de la

gestión del software. Básicamente, en esta vista se busca mostrar la forma como el sistema

se encuentra conformado por diferentes componentes con roles definidos, sus dependencias

y los tipos de conectores que existen entre cada componente. Para representar esta vista, se

ha optado por construir un Diagrama de Componentes de UML, con un estilo de

componentes y conectores.

VP-08. Vista general de Componentes y Conectores (C&C)


Figura 4-29. Vista general de C&C de la solución propuesta

144

La Figura 4-29 muestra la primera iteración o nivel de descomposición del sistema. En esta

vista se puede observar la interacción, a través de interfaces, entre el componente principal

de la arquitectura, el Hospital Emergency Classifier (HEC), y los sistemas externos, a

saber: Electronic Health Record (EHR) System, Hospital Information System (HIS) y

External Knowledge Base.




Tabla 4-17. Elementos de la vista general de C&C


Componente Hospital Emergency Classifier

(HEC)

Componente principal del sistema, el cual consiste

en el clasificador de urgencias hospitalarias, basado

en un método de Triage y alertas y

recomendaciones.

Componente Electronic Health Record

(EHR) System





Componente Hospital Information System

(HIS)





Componente External Knowledge

Repository







Interface HEClassifierService

Interface principal del sistema, a través de la cual se

recibirán solicitudes de los clientes o usuarios.

También llamado “Inbound endpoint” del sistema.

Interface EHRService

Interface entre el componente clasificador y el

servicio de consulta de historias clínicas (Electronic

Health Records System).

145

Interface HISService

Interface entre el componente clasificador y un

sistema de información hospitalaria de una entidad

(HIS).

Interface ExtKnowledgeService

Interface entre el componente clasificador y una base

de conocimiento externa.

Interface ResponseServices

Interface utilizada por el sistema para suministrar

respuestas a los clientes y/o usuarios. También

llamado “Outbound endpoint” del sistema.

Tabla 4-18. Relaciones entre los elementos de la vista general de C&C


Hospital Emergency Classifier

(HEC)

Electronic Health Record (EHR)

System

Conector Call



(HEC) Hospital Information System (HIS)

Conector Call



(HEC) External Knowledge Repository

Conector Call


VP-09. Vista de C&C – Hospital Emergency Classifier


La Figura 4-30 muestra la segunda iteración o nivel de la vista de componentes y

conectores, en la cual se detalla el componente principal “Hospital Emergency Classifier

(HEC)”. En esta vista se pueden observar los componentes internos de la solución

propuesta, así como el uso de la mayoría de tácticas y patrones de diseño arquitectural.

146

Figura 4-30. Vista de C&C Hospital Emergency Classifier

147




Tabla 4-19. Elementos de la vista de C&C del HEC


Componente Hospital Emergency Classifier

(HEC)

Componente principal del sistema, el cual consiste

en el clasificador de urgencias hospitalarias, basado

en un método de Triage y alertas y

recomendaciones.

Componente AppDeliveryService

Componente encargado del modelo de entrega del

servicio, balanceo de cargas, proxy y firewall. Ver

sección 4.2.1.1.

Componente RegisterService

Componente encargado del registro de las peticiones

a ser procesadas por el Process Coordinator. Ver

sección 4.2.1.1.

Componente AuthService

Componente encargado de Autenticación y

Autorización de usuarios y/o clientes del sistema.

Ver sección 4.2.1.1.

Componente CoordinatorQueue

Cola persistente a la cual se encuentra suscrito el

Process Coordinator para la atención de solicitudes.

Componente CoordinatorService

Componente encargado de tomar las peticiones

registradas y despacharlas a través de las diferentes

actividades del proceso de Triage propuesto. Ver

sección 4.2.1.1.

Componente TriageQueue


TriageService para la aplicación del método de

Triage.

Componente TriageService


despachadas por el Process Coordinator y aplicar el

método o algoritmo de Triage. Ver sección 4.2.1.1.

Componente InferenceQueue


motor de inferencias (InferenceEngine) para la

aplicación de la lógica de alertas y recomendaciones.

148

Componente InferenceEngine


despachadas por el process Coordinatori y aplicar

alertas y recomendaciones, a partir de una base de

conocimiento, a partir de reglas. Ver sección 4.2.1.1.

Componente KnowledgeDB

Componente que representa la base de conocimiento

utilizada por el InferenceEngine. Se trata de una

base de hechos.

Componente EHRQueue


servicio de consulta de historias clínicas de

pacientes.

Componente EHRService


despachadas por el Process Coordinator y lanzar la

consulta de EHR, PHR y EMR a los sistemas

externos. Ver sección 4.2.1.1.

Componente TransactionalService

Componente encargado de la persistencia

transaccional del sistema. Ver sección 4.2.1.1.

Componente TransactionalDB

Componente que representa la persistencia

transaccional del sistema.

Componente ResponseQueue

Cola persistente donde son producidos los resultados

de los procesos asociados al Triage y a la cual se

encuentra suscrito el componente ResponseService

para la generación de resultados a usuarios y/o

cliente.

Componente ResponseService

Componente encargado de tomar los resultados

producidos por cada componente asociado al

proceso de Triage y elaborar respuestas dirigidas a

los usuarios y/o clientes.

Componente Electronic Health Record

(EHR) System





Componente Hospital Information System

(HIS)





149

Componente External Knowledge

Repository







Interface HEClassifierService

Interface principal del sistema, a través de la cual se

recibirán solicitudes de los clientes o usuarios.

También llamado “Inbound endpoint” del sistema.


Interface entre el componente clasificador y el

servicio de consulta de historias clínicas (Electronic

Health Records System).


Interface entre el componente clasificador y un

sistema de información hospitalaria de una entidad

(HIS).


Interface entre el componente clasificador y una base

de conocimiento externa.

Interface AuthServices

Interface entre el componente de registro de

peticiones y los servicios de autenticación y

autorización.

Interface CoordinatorQueueWriteService

Interface utilizada para escribir en la cola

CoordinatorQueue.

Interface CoordinatorQueueReadService

Interface utilizada para leer de la cola

CoordinatorQueue.

Interface TriageQueueWriteService


TriageQueue.

Interface TriageQueueReadService

Interface utilizada para leer de la cola TriageQueue.

Interface InferenceQueueWriteService


InferenceQueue.

Interface InferenceQueueReadService


InferenceQueue.

150

Interface EHRQueueWriteService


EHRQueue.

Interface EHRQueueReadService

Interface utilizada para leer de la cola EHRQueue.

Interface ResponseQueueWriteService


ResponseQueue.

Interface ResponseQueueReadService


ResponseQueue.

Interface TransactionalServices

Interface utilizada por los componentes para persistir

datos transaccionales a través del componente

TransactionalService.

Interface ResponseServices

Interface utilizada por el sistema para suministrar

respuestas a los clientes y/o usuarios. También

llamado “Outbound endpoint” del sistema.

Tabla 4-20. Relaciones entre los elementos de la vista de C&C del HEC


AppDeliveryService RegisterService

Enrutamiento (Balanceo de Cargas, Proxy y

Gateway)

RegisterService CoordinatorQueue

Conector Write

Interface CoordinatorQueueWriteService

CoordinatorService CoordinatorQueue

Conector Read

Interface CoordinatorQueueReadService

CoordinatorService TriageQueue

Conector Write


CoordinatorService InferenceQueue

Conector Write


CoordinatorService EHRQueue

Conector Write


TriageService TriageQueue

151

Conector Read

Interface TriageQueueReadService

InferenceEngine InferenceQueue

Conector Read

Interface InferenceQueueReadService

EHRService EHRQueue

Conector Read

Interface EHRQueueReadService

InferenceEngine KnowledgeDB

Asociación

TriageService ResponseQueue

Conector Write


InferenceEngine ResponseQueue

Conector Write


EHRService ResponseQueue

Conector Write


RegisterService TransactionalService

Conector Call


CoordinatorService TransactionalService

Conector Call


TriageService TransactionalService

Conector Call


InferenceEngine TransactionalService

Conector Call


EHRService TransactionalService

Conector Call


TransactionalService TransactionalDB

Asociación

ResponseService ResponseQueue

Conector Read

Interface ResponseQueueReadService

152

Hospital Emergency

Classifier (HEC)

Electronic Health Record

(EHR) System

Conector Call


Hospital Emergency

Classifier (HEC)

Hospital Information

System (HIS)

Conector Call


Hospital Emergency

Classifier (HEC)

External Knowledge

Repository

Conector Call


5.2.2.4. Vista de Procesos


En esta vista se muestra el sistema desde la perspectiva de la interacción o comportamiento

que tienen los diferentes componentes, durante su ejecución. Básicamente, en esta vista se

busca mostrar la secuencia con la cual fluyen los mensajes que son enviados entre

componentes, representando un momento de la ejecución de un proceso. Para representar

esta vista, se ha optado por construir un Diagrama de Secuencia de UML dado que se

requiere explicar los 6 procesos o transacciones principales del sistema:

• VP-10. Vista de procesos– Registro de una petición

• VP-11. Vista de procesos – Despacho de una petición

• VP-12. Vista de procesos – Aplicación de Triage

• VP-13. Vista de procesos – Consulta de EHR

• VP-14. Vista de procesos – Generación de Inferencias

• VP-15. Vista de procesos – Notificación de Resultados

Estos procesos corresponden, respectivamente, al escenario principal del diseño propuesto,

desde que una petición es registrada, hasta que su resultad es notificado. A continuación, se

detalla cada vista.

153

VP-10. Vista de procesos – Registro de una petición


La Figura 4-37 ilustra la forma cómo las peticiones son ingresadas al “Process Corrdinator”

a través del componente “Register Service”. Se puede observar que la petición es asíncrona

ya que finaliza con la escritura de la petición en la cola del coordinador.




Tabla 4-21. Elementos de la vista de procesos – Registro de una petición


Actor User

Cliente o usuario del sistema. En esta vista no se

detalla la especialización de este actor.

Línea de Vida RegisterInterfaceService

Componente que expone las interfaces o servicios

del RegisterService.

Línea de Vida RegisterBusinessService

Componente donde se implementan los elementos

que resuelven la lógica de negocios del

RegisterService. Ejemplo: Persistir la petición.

Línea de Vida RegisterIntegrationService

Componente que realiza las integraciones del

RegisterService con otros módulos o sistemas, a

través de interfaces.

Línea de Vida TransactionalInterfaceService


del TransactionalService para efectos de persistencia

de las peticiones.

Linea de Vida QueueWriter

Componente que escribe en la cola de entrada del

CoordinatorService.

Línea de Vida CoordinatorQueue

Cola de entrada de peticiones del

CoordinatorService.

154

Tabla 4-22. Relaciones entre los elementos – Registro de una petición


User RegisterInterfaceService

Mensaje Sincronizado:

1: registerHECRequest

RegisterInterfaceService RegisterBusinessService


1.1: createHECRequest

RegisterBusinessService RegisterIntegrationService


1.1.1: saveHECRequest

RegisterIntegrationService TransactionalInterfaceService


1.1.1.1: insertHECRequest

RegisterBusinessService QueueWriter


1.1.1.2: writeQueue

RegisterBusinessService CoordinatorQueue


1.1.1.2.1: write

155

Figura 4-31. Vista de procesos – Registro de una petición

156

VP-11. Vista de procesos – Despacho de una petición


La Figura 4-32 muestra la forma cómo las peticiones son despachadas desde el “Process

Coordinator” a cada uno de los componentes principales de la arquitectura, de forma

paralela. Se puede observar que la petición es asíncrona ya que finaliza con la escritura de

la petición en la cola de cada componente.




Tabla 4-23. Elementos de la vista de procesos – Despacho de una petición


Línea de Vida CoordinatorQueue

Cola de entrada de peticiones del

CoordinatorService.

Linea de Vida CoordinatorQueueReader

Componente que lee los mensajes de la cola de

entrada del CoordinatorService. Actúa como un

consumidor en el patrón de diseño TaskQueue.

Línea de Vida CoordinatorInterfaceService


del CoordinatorService. Es el punto de entrada del

componente principal.

Línea de Vida CoordinatorBusinessService



CoordinatorService. Ejemplo: Despachar las

peticiones según disponibilidad de los componentes.

Línea de Vida CoordinatorIntegrationService


CoordinatorService con otros módulos o sistemas, a





de las peticiones.

157


Componente que escribe mensajes en una cola. En

este caso, escribe mensajes en las colas de los

componentes principales.

Línea de Vida TriageQueue

Cola de entrada de peticiones del TriageService.

Línea de Vida EHRQueue

Cola de entrada de peticiones del EHRService.

Línea de Vida InferenceQueue

Cola de entrada de peticiones del InferenceEngine.

Tabla 4-24. Relaciones entre los elementos – Despacho de una petición


CoordinatorQueueReader CoordinatorQueue


1: read

CoordinatorQueueReader CoordinatorInterfaceService


2: processHECRequest

CoordinatorInterfaceService CoordinatorBusinessService


2.1: routeHECRequest

CoordinatorBusinessService CoordinatorBusinessService


2.1.1: setRoutingMap

CoordinatorBusinessService CoordinatorIntegrationService


2.1.2: createTriageRequest

CoordinatorIntegrationService TransactionalInterfaceService


2.1.2.1: insertTriageRequest



2.1.3: dispatchTriageRequest

CoordinatorIntegrationService QueueWriter


2.1.3.1: writeQueue

158

QueueWriter TriageQueue


2.1.3.1.1: write



2.1.4: createEHRRequest



2.1.4.1: insertEHRRequest



2.1.5: dispatchEHRRequest



2.1.5.1: writeQueue

QueueWriter EHRQueue


2.1.5.1.1: write



2.1.6: createInferenceRequest



2.1.6.1: insertInferenceRequest



2.1.7: dispatchInferenceRequest



2.1.7.1: writeQueue

QueueWriter InferenceQueue


2.1.7.1.1: write



2.1.8: updateHECRequest



2.1.8.1: updateHECRequest

159

Figura 4-32. Vista de procesos – Despacho de una petición

160

VP-12. Vista de procesos – Aplicación de Triage


La Figura 4-33 ilustra la forma cómo las peticiones de aplicación del método de Triage

despachadas desde el “Process Coordinator” son atendidas por el componente

“TriageService”.




Tabla 4-25. Elementos de la vista de procesos – Aplicación de Triage


Línea de Vida TriageQueue

Cola de entrada de peticiones del TriageService.

Linea de Vida TriageQueueReader


entrada del TriageService. Actúa como un


Línea de Vida TriageInterfaceService


del TriageService. Es el punto de entrada del

componente.

Línea de Vida TriageBusinessService



TriageService. Ejemplo: Aplicar el algoritmo de

Triage.

Línea de Vida TriageIntegrationService


TriageService con otros módulos o sistemas, a través

de interfaces.




de las peticiones.


Componente que escribe mensajes en la cola de

entrada de datos del componente

“ResponseService”.

161

Línea de Vida ResponseQueue

Cola de entrada de datos del ResponseService, en la

cual se escribe el mensaje correspondiente a la

respuesta generada.

Tabla 4-26. Relaciones entre los elementos – Despacho de una petición


TriageQueueReader TriageQueue


1: read

TriageQueueReader TriageInterfaceService


2: processRequest

TriageInterfaceService TriageBusinessService


2.1: triageProcess

TriageBusinessService TriageBusinessService


2.1.1: triageEvaluation

TriageBusinessService TriageIntegrationService


2.1.2: registerTriageEvaluation

TriageIntegrationService TransactionalInterfaceService


2.1.2.1: insertTriageEvaluation



2.1.3: notifyTriageEvaluation

TriageIntegrationService QueueWriter


2.1.3.1: writeQueue

QueueWriter ResponseQueue


2.1.3.1.1: write



2.1.4: updateTriageRequest

TriageIntegrationService TransactionalInterfaceService


2.1.4.1: updateTriageRequest

162

Figura 4-33. Vista de procesos – Aplicación de Triage

163

VP-13. Vista de procesos – Consulta de EHR


La Figura 4-34 muestra la forma cómo las peticiones de consulta de historia clínica

electrónica, despachadas desde el “Process Coordinator”, son atendidas por el componente

“EHRService”. Se puede observar que la petición es asíncrona ya que finaliza con la

escritura de la petición en la cola de salida. Esto implica que esta petición no depende de

los resultados proporcionados por otros componentes.




Tabla 4-27. Elementos de la vista de procesos – Consulta de EHR


Línea de Vida EHRQueue

Cola de entrada de peticiones del EHRService.

Linea de Vida EHRQueueReader


entrada del EHRService. Actúa como un consumidor

en el patrón de diseño TaskQueue.

Línea de Vida EHRInterfaceService


del EHRService. Es el punto de entrada del

componente.

Línea de Vida EHRBusinessService


que resuelven la lógica de negocios del EHRService.

Ejemplo: Procesar la EHR del paciente.

Línea de Vida EHRIntegrationService


EHRService con otros módulos o sistemas, a través

de interfaces.




de las peticiones.



164






respuesta generada.

Línea de Vida Electronic Health Record

(EHR) System





Línea de Vida Hospital Information System

(HIS)





Tabla 4-28. Relaciones entre los elementos – Consulta de EHR


EHRQueueReader EHRQueue


1: read

EHRQueueReader EHRInterfaceService


2: processRequest

EHRInterfaceService EHRBusinessService


2.1: processEHR

EHRBusinessService EHRIntegrationService


2.1.1: getPatientEHR

EHRIntegrationService Electronic Health Record (EHR)

System


2.1.1.1: getPatientEHR

EHRIntegrationService Hospital Information System (HIS)


2.1.1.2: getPatientEHR

EHRBusinessService EHRBusinessService


2.1.2: processPatientEHR



165

2.1.3: registerEHRResult

EHRIntegrationService TransactionalInterfaceService


2.1.3.1: insertEHRResult



2.1.4: notifyEHRResult

EHRIntegrationService QueueWriter


2.1.4.1: writeQueue



2.1.4.1.1: write



2.1.5: updateEHRRequest

EHRIntegrationService TransactionalInterfaceService


2.1.4.1: updateEHRRequest

166

Figura 4-34. Vista de procesos – Consulta de EHR

167

VP-14. Vista de procesos – Generación de Inferencias


La Figura 4-35 muestra la forma cómo las peticiones de generación de inferencias basadas

en bases de conocimiento, despachadas desde el “Process Coordinator”, son atendidas por

el componente “InferenceEngine”. Se puede observar que la petición es asíncrona ya que

finaliza con la escritura de la petición en la cola de salida. Esto implica que esta petición no

depende de los resultados proporcionados por otros componentes.




Tabla 4-29. Elementos de la vista de procesos – Generación de Inferencias


Línea de Vida InferenceQueue

Cola de entrada de peticiones del InferenceEngine.

Linea de Vida InferenceQueueReader


entrada del InferenceEngine. Actúa como un


Línea de Vida InferenceInterfaceService


del InferenceEngine. Es el punto de entrada del

componente.

Línea de Vida InferenceBusinessService



InferenceEngine. Ejemplo: Obtener conocimiento

externo, mapear con conocimiento interno y aplicar

reglas de inferencia para la generación de alertas y

recomendaciones para el paciente.

Línea de Vida InferenceIntegrationService


InferenceEngine con otros módulos o sistemas, a


Línea de Vida KnowledgeDB

Base de conocimiento interna del motor de

inferencias (i.e. repositorio de reglas en un motor

basado en reglas).

168




de las peticiones.








respuesta generada.

Línea de Vida External Knowledge

Repository






prescripciones médicas comunes, entre otros.

Tabla 4-30. Relaciones entre los elementos – Generación de Inferencias


InferenceQueueReader InferenceQueue


1: read

InferenceQueueReader InferenceInterfaceService


2: processRequest

InferenceInterfaceService InferenceBusinessService


2.1: processInference

InferenceBusinessService InferenceIntegrationService


2.1.1: getKnowledge

InferenceIntegrationService KnowledgeDB


2.1.1.1: getKnowledge

InferenceIntegrationService External Knowledge Repository


2.1.1.2: getKnowledge

InferenceBusinessService InferenceBusinessService


2.1.2: applyInferenceRules

169



2.1.3: registerInferenceResult

InferenceIntegrationService TransactionalInterfaceService


2.1.3.1: insertInferenceResult



2.1.4: notifyInferenceResult

InferenceIntegrationService QueueWriter


2.1.4.1: writeQueue



2.1.4.1.1: write



2.1.5: updateInferenceRequest

InferenceIntegrationService TransactionalInterfaceService


2.1.4.1: updateInferenceRequest

170

Figura 4-35. Vista de procesos – Generación de Inferencias

171

VP-15. Vista de procesos – Notificación de Resultados


La Figura 4-36 muestra la forma cómo las respuestas que llegan a la cola de salida son

procesadas. En este caso puntual, se propuso establecer una interface de salida (output

endpoint) por cada cliente, de tal modo que cada cliente se pudiese suscribir a esta interface

para recibir los resultados que se generan de forma asíncrona. Este enfoque es comúnmente

utilizado por medio de tecnologías de Web Sockets y los sistemas basados en notificaciones

(e.g. push, email, entre otros).




Tabla 4-31. Elementos de la vista de procesos – Notificación de Resultados



Cola principal de salida de resultados donde los

componentes principales escriben sus resultados.

Linea de Vida ResponseQueueReader

Componente que lee los mensajes de la cola

principal de salida. Actúa como un consumidor en el

patrón de diseño TaskQueue.

Línea de Vida ResponseInterfaceService


del ResponseService. Es el punto de entrada del

componente.

Línea de Vida ResponseBusinessService



ResponseService. Ejemplo: Transformar la respuesta

en un formato legible para un cliente, a través de un

protocolo de mensajería especificado.

Línea de Vida ResponseIntegrationService


ResponseService con otros módulos o sistemas, a




172


de las peticiones.


Componente que escribe mensajes en las colas de

salida configuradas para cada cliente.

Línea de Vida ClientNotificationQueue

Cola de salida (Output endpoint) configurada para

cada cliente.

Tabla 4-32. Relaciones entre los elementos – Notificación de Resultados


ResponseQueueReader ResponseQueue


1: read

ResponseQueueReader ResponseInterfaceService


2: processRequest

ResponseInterfaceService ResponseBusinessService


2.1: notifyResult

ResponseBusinessService ResponseIntegrationService


2.1.1: getResult

ResponseIntegrationService TransactionalInterfaceService


2.1.1.1: getResult

ResponseBusinessService ResponseBusinessService


2.1.2: processResult

ResponseBusinessService ResponseIntegrationService


2.1.3: notifyResult

ResponseIntegrationService QueueWriter


2.1.3.1: writeQueue

QueueWriter ClientNotificationQueue


2.1.3.1.1: write

173

Figura 4-36. Vista de procesos – Notificación de Resultados

174

5.2.2.5. Vista Física


En esta vista se muestra el sistema desde la perspectiva física, con el objetivo de evidenciar

la forma como el sistema será desplegado. Para representar esta vista, se ha optado por

construir un Diagrama de Despliegue de UML, el cual muestra las conexiones y nodos

creados y habilitados al momento del aprovisionamiento de la infraestructura.

VP-15. Vista general de Despliegue


La Figura 4-37 representa la forma como se plantea el despliegue del sistema, en lo

correspondiente al aprovisionamiento de infraestructura.

175

Figura 4-37. Vista general de Despliegue HEC

176

Capítulo 5. Evaluación de la Arquitectura de Software

5.1. Métodos

5.2. Resultados

177

5.1. Métodos

Para la evaluación de la arquitectura de software fueron utilizados tres métodos propuestos

por el SEI [16]. La evaluación de la arquitectura fue realizada sobre los escenarios

refinados (Tabla 3-4 a Tabla 3-13), los cuales constituyen los drivers principales del diseño

propuesto. La evaluación de la arquitectura fue desarrollada de tal forma que se cubrieran

todos los requisitos arquitecturales, a través de los diferentes métodos. El criterio para

determinar los requisitos arquitecturales a ser evaluados por cada método se basó en la

viabilidad, tiempo y costo-beneficio de la evaluación.

El primer método tiene que ver con la evaluación interna realizada durante la etapa de

diseño arquitectural, en la ejecución del método ADD, al finalizar el tercer paso de cada

iteración (generate-and-test). En este caso, las decisiones fueron revisadas por pares,

similar a lo que se conoce como “Code Review” en las etapas de implementación

(codificación). Por cada elemento del sistema, uno de los pares (rol diseñador) proporcionó

y explicó los bosquejos de las vistas y decisiones arquitecturales, basadas en tácticas y

patrones, para resolver un conjunto de escenarios de calidad involucrados en la iteración. El

otro par (rol evaluador) aplicó los criterios de evaluación mencionados en la sección 2.1.3.3

para decidir si la hipótesis generada se cumple y así continuar con más elementos de la

arquitectura o generar una nueva hipótesis para el mismo elemento. Los resultados de esta

evaluación se encuentran intrínsecos en el diseño y documentación de la arquitectura de

software. Mediante este método fueron cubiertas todas las decisiones arquitecturales, por

ende, todos los requisitos arquitecturales.

El segundo método utilizado fue el ATAM [26] [91]. En la presente propuesta, el método

ATAM fue aplicado según la guía del SEI. En la Tabla 5-1, se describen los pasos que

fueron aplicados en cada fase para la evaluación de la arquitectura de software planteada.

Cabe destacar que la evaluación fue realizada por iteraciones, en línea con el diseño

arquitectural, producto de la aplicación del método ADD. Mediante este método fueron

cubiertos los requisitos arquitecturales ASR-04, ASR-05, ASR-09 y ASR-10, los cuales

corresponden al driver “Security”.

178

Tabla 5-1. Desarrollo del método ATAM. Extendido de [26], [25]

Fase Paso Desarrollo

FASE 0.

Colaboración y

Preparación

N/A

Los arquitectos prepararon el ejercicio de evaluación por

medio de la construcción de material útil como

presentaciones sobre el sistema, escenarios a validar,

vistas construidas y decisiones arquitecturales (views &

beyond).

En esta preparación, se acordó un cronograma y recursos

necesarios por cada ejercicio de evaluación, el cual

osciló entre 1 y 4 días por iteración, dependiendo del

tamaño de la iteración. Dada la complejidad en esfuerzo

y tiempo que demanda este método, se seleccionaron 4

de los 10 escenarios refinados para esta evaluación

(ASR-04, ASR-05, ASR-09 y ASR-10). De igual forma,

en algunos ejercicios, se esperó a que se finalizara más

de una iteración de la fase de diseño.

La principal salida de esta fase fue la realización de un

kick-off del ejercicio de evaluación, en el cual se explicó

la forma como éste iba a ser abordado, con el objetivo

de que los participantes lo tuvieran claro.

FASE 1. Evaluación

1. Presentación del

ATAM

En este paso simplemente se explicó el proceso del

método ATAM, se aclararon dudas propuestas por los

participantes y se establecieron las expectativas en

términos de resultados esperados. Se utilizó el material

construido en la fase 0.

2. Presentación de los

drivers de negocio

En este paso se utilizó el material construido en la fase 0

para proporcionar explicación sobre el sistema, en

términos de:

• Funciones más importantes.

• Restricciones de negocio.

• Objetivos de negocio. En este punto se explicó el

problema de investigación y la hipótesis.

• Contexto del proyecto. En este punto se explicó el

contexto de la salud en Colombia, específicamente

en términos del Triage y su reglamentación

actualizada.

• ASRs principales.

3. Presentación de la

Arquitectura de Software

En este paso se utilizó el material construido en la fase 0

para proporcionar explicación sobre la arquitectura de

software, en términos de:

• Grado de avance o nivel de diseño realizado hasta

el momento, incluyendo documentación.

179

• Restricciones técnicas.

• Principales decisiones arquitecturales que fueron

tomadas para satisfacer los escenarios de calidad

contemplados en la iteración.

En esta fase se utilizaron las vistas de alto nivel y nivel 1

con el objetivo de proporcionar explicaciones completas

sin entrar aún en detalles. Esto facilitó el entendimiento

general del estilo arquitectural y patrones de diseño

utilizados.

4. Identificación de las

aproximaciones

arquitecturales

En este paso simplemente se realizó un mapeo del

cubrimiento de escenarios por medio de las decisiones

arquitecturales tomadas. Se identificaron las tácticas y

patrones relacionados para su posterior análisis. Este

paso fue completado durante la etapa de diseño ya que el

cubrimiento de escenarios siempre fue realizado al

finalizar cada iteración del método ADD.

5. Generación del Árbol

de Utilidad

Este paso no fue realizado durante la evaluación, ya que,

al finalizar la construcción de los escenarios de calidad,

éstos fueron refinados y representados por medio de un

árbol de utilidad. Esto fue realizado durante la

aplicación del QAW.

6. Análisis de

aproximaciones

arquitecturales

Este paso fue realizado escenario por escenario y se basó

en analizar cómo cada decisión arquitectural que cubre

cada escenario lo satisfizo. En este paso se identificaron

los riesgos, no riesgos, puntos de sensibilidad y tradeoff

generados por las decisiones arquitecturales. En la

evaluación propuesta, se realizaron discusiones sobre

cómo se manejaron las tácticas y patrones en términos

de su adaptación al contexto y escenarios propuestos,

teniendo en cuenta sus debilidades y relación con otros

atributos de calidad. Este análisis fue documentado

siguiendo las recomendaciones del SEI.

El resultado de este paso constituye la salida más

importante del método ATAM y puede ser visto en la

sección 5.2.1.

FASE 2.

Continuación de la

evaluación

7. Priorización de

escenarios

Este paso no fue realizado durante la evaluación dado

que fue cubierto en la aplicación del QAW (priorización

de escenarios).

8. Análisis de

aproximaciones

arquitecturales

En este paso se aplicaron las mismas técnicas del paso 6.

La diferencia radica en que en este paso se trabaja con

escenarios priorizados por los interesados. En este caso

no fue realizado según la propuesta ya que la

priorización fue establecida desde el principio.

180

9. Presentación de

Resultados

Este paso fue realizado por medio de la construcción de

la sección 5.2.1 del presente documento. En esta sección

se presenta básicamente la evaluación de cada escenario,

en la cual se encuentra la siguiente información:

• Información sobre el escenario

• Decisiones arquitecturales

• Impacto para el negocio y la arquitectura

• Riesgos descubiertos

• No riesgos documentados

• Hallazgos en términos de puntos de sensibilidad y

tradeoffs

• Categorías de riesgos y razonamiento sobre su

afectación al negocio

FASE 3.

Seguimiento N/A

Al finalizar cada iteración de la evaluación de la

arquitectura, se compartieron los resultados para su

posterior revisión y divulgación.

Finalmente, el tercer método se basó en la construcción de un prototipo para evaluar

algunos de los escenarios de calidad construidos, a través de la interacción con datos

pseudo-aleatorios en un entorno controlado. En el presente trabajo se construyó un

prototipo para evaluar algunos de los escenarios de calidad y analizar la viabilidad de

implementar la arquitectura tal como fue propuesta sin mayores impactos en términos de

costos y otras restricciones de negocio. La Figura 5-1 muestra el escenario cubiertos por el

prototipo, el cual consiste en que el cliente solicita la clasificación de una urgencia

hospitalaria, el sistema aplica el algoritmo de clasificación y genera una respuesta a partir

de su resultado. Mediante este método fueron cubiertos los requisitos arquitecturales ASR-

01, ASR-02, ASR-03, ASR-06, ASR-07 y ASR-08, los cuales corresponden a los drivers

“Performance” y “Availability”.

181

Figura 5-1. Escenario principal cubierto por el prototipo

5.2. Resultados

5.2.1. Evaluación mediante ATAM

A continuación, se describen los resultados de la aplicación de ATAM, con sus

correspondientes análisis.

Tabla 5-2. Evaluación escenario ASR-04 por medio de ATAM

Escenario #: ASR-04


Sistema de Historias Clínicas debe estar encriptada a nivel de

datos.


Refinamiento del Atributo de Calidad Privacy


Estímulo El sistema consulta la información del paciente directamente

en una fuente externa.

Respuesta La información del paciente debe retornar encriptada.

Decisiones Arquitecturales Sensibilidad Tradeoff Riesgo No Riesgo

DA-15. Verificación de la integridad de

los mensajes T1 NR1

DA-18. Cifrado de datos S1 T2 NR2

Razonamiento

182

• T1. Todo lo relacionado con análisis de mensajes disminuye el performance.

• NR1. El uso de validación de esquemas como XSD mitiga los impactos que pueden generarse a

nivel de desempeño. Además, no se analizará la totalidad de los mensajes, si no aquellos que se

encuentran de cara al usuario final y sistemas externos.

• S1. La complejidad del cifrado de datos en términos de recurso computacional requerido para su

procesamiento dependerá del nivel de seguridad que se quiere implementar. Las variaciones a los

algoritmos de cifrado afectarán directamente el performance.

• T2. El cifrado de datos añade un “over-head” al sistema, dado que se deben cifrar y descifrar

mensajes en todo momento. Esto disminuye el performance general de la aplicación en términos

de tiempos de respuesta y throughput.

• NR2. Los servidores web cada vez están más preparados en términos de seguridad a nivel de

protocolo.

Diagrama arquitectural

Estas decisiones arquitecturales no se encuentran

representadas en las vistas elaboradas durante la fase de

diseño. Sin embargo, fueron descritas en la sección 4.2.1.5.

Análisis de Resultados

Al utilizar estas decisiones arquitecturales únicamente sobre

los componentes que consultan la EHR del paciente, se

considera que la arquitectura propuesta satisface

completamente el escenario, sin generar mayores impactos

en performance.


Escenario #: ASR-05 Ningún cliente o usuario puede utilizar el Sistema sin ser

autorizado.




Estímulo Un usuario/cliente no autenticado o no autorizado intenta

registrar una solicitud de Triage

Respuesta El sistema rechaza la petición por falta de credenciales o

credenciales de acceso inválidas.


DA-16. Componente de Autenticación y

Autorización “Auth Service” S2 T3, T4 R1 NR3, NR4

DA-20. Revocación de acceso S3 T5 R2

DA-21. Informe a actores S4 NR5

Razonamiento

• R1. El uso de un servicio de terceros hace que la arquitectura dependa de los ANS de dicho

servicio.

• NR3. Los servicios de terceros a utilizar en fase de implementación presentan ANS acordes a los

escenarios de calidad planteados.

• S2. Los servicios de terceros pueden realizar cambios que obliguen a cambiar la implementación

(conocido como lock-in).

• NR4. El encapsulamiento de las funciones de autenticación y autorización aumenta la cohesión y

reduce el acoplamiento.

• T3. Se disminuye el performance al incluir autenticación/autorización de peticiones (T1). Sin

183

embargo, el uso de oAuth2.0 y JSON Web Tokens disminuyen la cantidad de peticiones que son

realizadas a sistemas terceros.

• T4. Se afecta la disponibilidad por las razones explicada en R1. Sin embargo, como se explica en

NR3, este tipo de servicios por lo general presentan ANS que garantizan la satisfacción de los

escenarios de availability propuestos en la arquitectura.

• S3. Dependiendo del tiempo que pueda tardarse un cliente en restaurar su acceso normal, se podrá

generar el riesgo R2.

• T5. La revocación de acceso afecta la disponibilidad del sistema.

• R2. En caso de presentarse un ataque y se revoque el acceso a una entidad o un cliente, el sistema

no operaría para dicha entidad hasta que se tomen acciones. Esto puede poner el riesgo los ANS

del sistema.

• S4. El uso de sistemas de terceros para la generación de alertas o informar sobre algún suceso

genera dependencia con dicho tercero (lock-in).

• NR5. El uso de protocolos de comunicación y mensajería estándar mitiga cualquier riesgo

inherente a la dependencia con terceros. Además, genera bajo acoplamiento.


En la Figura 4-30 se puede observar cómo las peticiones del

cliente pasan siempre por el componente “AuthService”.


A pesar de que se pueden presentar impactos en performance

y availability, se debe satisfacer este escenario por el

dominio en el que la arquitectura se propone. Existen

diferentes mecanismos -como los expuestos en el

razonamiento- para mitigar dicho impacto. Por lo anterior, se

considera que las decisiones arquitecturales satisfacen

completamente el escenario de calidad, generando algunos

impactos fácilmente mitigables.


Escenario #: ASR-09


Triage enviados al sistema no deben ser vistos por terceros

no autorizados.




Estímulo Un tercero no autorizado intenta ver una solicitud de Triage

Respuesta El sistema no permite la visualización de los datos y reporta

la anomalía.


DA-14. Implementación de un Application

Delivery Service T6 NR6


los mensajes T1 NR1



DA-17. Limitar el acceso y la exposición S5 R3 NR6, NR7


DA-19. Separación de entidades S6 T6 R4 NR8


184

Razonamiento

• T6. Incluir un componente adicional en el flujo de una petición disminuye el performance.

• NR6. El componente “Application Delivery Service” utilizará tecnologías especialmente

diseñadas para alto tráfico y aplicaciones de alto desempeño.






servicio.













• R3. Limitar el acceso y la exposición podría eventualmente limitar opciones que el negocio

requiera para otros sistemas diferentes al que se está implementando (i.e. una variación del

sistema para utilizar el motor de inferencia con otros propósitos o en otro dominio).

• NR6. La arquitectura propuesta no contempla un enfoque de línea de productos, por lo que no se

debe contemplar variaciones con respecto al uso de los servicios.

• S5. Configuraciones no centralizadas pueden hacer que el sistema sea muy complejo de mantener

en términos de acceso y exposición.

• NR7. Las plataformas IaaS permiten configurar fácilmente reglas de acceso y exposición de

servicios, de forma centralizada.








protocolo.








protocolo.

• S6. La separación excesiva de responsabilidades impactará negativamente el performance y la

disponibilidad de la aplicación.

• T6. La separación de entidades disminuye el performance y la disponibilidad, aunque aumenta la

cohesión y disminuye el acoplamiento.

• R4. Si la separación es física, en redes de comunicaciones o segmentos diferentes, con ancho de

banda limitado, los escenarios de performance no podrán ser satisfechos por la arquitectura.

185

• NR8. Por medio de la virtualización, se pueden mitigar los riesgos asociados a las

comunicaciones.






• En la Figura 4-29 se puede observar el uso de los

componentes “Application Delivery Service” y

“Auth Service” como parte del flujo principal.

• En la Figura 4-37 se puede ver la separación de

entidades propuesta.

• En la Figura 4-20 se puede ver el uso de zonas

militarizadas y desmilitarizadas.






razonamiento- para mitigar dicho impacto. Además, algunas

de las tácticas serán utilizadas únicamente en aquellos

componentes que requieren uso de sistemas externos y se

encuentran de cara al usuario. Esto hace que el impacto en

performance sobre todo pueda mitigarse en lo que se conoce

como la zona desmilitarizada. Por lo anterior, se considera

que las decisiones arquitecturales satisfacen completamente

el escenario de calidad, generando algunos impactos

fácilmente mitigables.


Escenario #: ASR-10


Triage enviados al sistema no deben ser alterados por



Refinamiento del Atributo de Calidad Integrity


Estímulo Un tercero no autorizado intenta alterar una solicitud de

Triage

Respuesta El sistema no permite la actualización de los datos y reporta

la anomalía.


DA-14. Implementación de un Application

Delivery Service T6 NR6


los mensajes T1 NR1



DA-17. Limitar el acceso y la exposición S5 R3 NR6, NR7


DA-19. Separación de entidades S6 T6 R4 NR8

186

DA-20. Revocación de acceso S3 T5 R2


Razonamiento

• T6. Incluir un componente adicional en el flujo de una petición disminuye el performance.

• NR6. El componente “Application Delivery Service” utilizará tecnologías especialmente

diseñadas para alto tráfico y aplicaciones de alto desempeño.






servicio.













• R3. Limitar el acceso y la exposición podría eventualmente limitar opciones que el negocio

requiera para otros sistemas diferentes al que se está implementando (i.e. una variación del

sistema para utilizar el motor de inferencia con otros propósitos o en otro dominio).

• NR6. La arquitectura propuesta no contempla un enfoque de línea de productos, por lo que no se

debe contemplar variaciones con respecto al uso de los servicios.

• S5. Configuraciones no centralizadas pueden hacer que el sistema sea muy complejo de mantener

en términos de acceso y exposición.

• NR7. Las plataformas IaaS permiten configurar fácilmente reglas de acceso y exposición de

servicios, de forma centralizada.








protocolo.








protocolo.

• S6. La separación excesiva de responsabilidades impactará negativamente el performance y la

disponibilidad de la aplicación.

• T6. La separación de entidades disminuye el performance y la disponibilidad, aunque aumenta la

cohesión y disminuye el acoplamiento.

187

• R4. Si la separación es física, en redes de comunicaciones o segmentos diferentes, con ancho de

banda limitado, los escenarios de performance no podrán ser satisfechos por la arquitectura.

• NR8. Por medio de la virtualización, se pueden mitigar los riesgos asociados a las

comunicaciones.

• S3. Dependiendo del tiempo que pueda tardarse un cliente en restaurar su acceso normal, se podrá

generar el riesgo R2.

• T5. La revocación de acceso afecta la disponibilidad del sistema.

• R2. En caso de presentarse un ataque y se revoque el acceso a una entidad o un cliente, el sistema

no operaría para dicha entidad hasta que se tomen acciones. Esto puede poner el riesgo los ANS

del sistema.






• En la Figura 4-29 se puede observar el uso de los

componentes “Application Delivery Service” y

“Auth Service” como parte del flujo principal.

• En la Figura 4-37 se puede ver la separación de

entidades propuesta.

• En la Figura 4-20 se puede ver el uso de zonas

militarizadas y desmilitarizadas.






razonamiento- para mitigar dicho impacto. Además, algunas

de las tácticas serán utilizadas únicamente en aquellos

componentes que requieren uso de sistemas externos y se

encuentran de cara al usuario. Esto hace que el impacto en

performance sobre todo pueda mitigarse en lo que se conoce

como la zona desmilitarizada. Por otro lado, la relación

costo-beneficio de proteger al sistema ante una intrusión, es

buena. Por lo anterior, se considera que las decisiones

arquitecturales satisfacen completamente el escenario de

calidad, generando algunos impactos fácilmente mitigables y

con una relación costo-beneficio razonable.

5.2.2. Evaluación mediante Prototipo

Teniendo en cuenta el escenario implementado por medio del prototipo (Figura 5-1), a

continuación, se describe el proceso o flujo que el prototipo sigue:

188

• El proceso cual comienza con el registro de la solicitud de clasificación (ver

secuencia en la Figura 5-2). Esta solicitud es ingresada a la cola del “Coordinator

Service” para ser atendida de forma asíncrona.

• En paralelo, el “Coordinator Service” atiende la petición (ver secuencia en la Figura

5-3). Esta atención en el prototipo consiste en verificar, por medio de una

información registrada en base de datos, la disponibilidad del componente “Triage

Service”. En caso de estar disponible, despacha la solicitud a éste, de forma

asíncrona y a través de su cola de entrada.

• El proceso de Triage atiende la solicitud enviada aplicando el algoritmo de Triage y

escribe la respuesta generada en la cola de respuesta general del sistema (Figura

5-4).

• Finalmente, el componente “Response Service” toma la respuesta de la cola de

respuestas general del sistema y genera una salida para el cliente que generó la

petición (Figura 5-5), el cual se encuentra suscrito a una cola de salida creada para

el mismo.

Como se puede observar, todas las peticiones son asíncronas, siguiendo las

especificaciones del diseño arquitectural propuesto.

En la Figura 5-6 se pueden ver los componentes implementados para cubrir el escenario

y los procesos descritos anteriormente, mientras que en la Figura 5-7 se muestra la

forma como fue desplegado el prototipo utilizando el proveedor de infraestructura como

servicios (IaaS, por sus siglas en inglés) Amazon Web Services (AWS). Cabe destacar

que el uso de AWS se debe a la posibilidad de ejecutar la cardinalidad propuesta para

los componentes, a un bajo costo y con relativa facilidad, en términos de

implementación. También fue propuesto este proveedor con el objetivo de comprobar la

viabilidad de implementación de un CDSS en un modelo de entrega en la nube, a nivel

de una prueba de concepto. Sin embargo, el prototipo diseñado no implementa las

características propias de una solución “cloud-enabled”, las cuales se encuentran

ampliamente descritas en [24].

189

Figura 5-2. Proceso implementado en el prototipo – Registro de una petición

190

Figura 5-3. Proceso implementado en el prototipo – Despacho de una petición

191

Figura 5-4. Proceso implementado en el prototipo – Aplicación de Triage

192

Figura 5-5. Proceso implementado en el prototipo – Notificación de Resultados

193

Figura 5-6. Componentes y conectores implementados en el prototipo

194

Figura 5-7. Despliegue del prototipo en Amazon Web Services

195

A continuación, se describen los detalles de implementación del prototipo:

• Toda la implementación fue realizada utilizando una VPC (Virtual Private Network)

o nube privada, en la cual se creó la infraestructura alrededor del prototipo.

• Se crearon 7 grupos de seguridad. 6 de estos grupos corresponden a los

componentes implementados, incluyendo la base de datos. El grupo restante se

utilizó para la máquina desde donde se realizaron pruebas. Para cada grupo de

seguridad se configuraron reglas de firewall de acuerdo con la decisión arquitectural

DA-17.

• Se crearon 6 imágenes de las configuraciones de las instancias o AMIs, en AWS. 5

de estas corresponden a la configuración base de cada componente de la

implementación, mientras que la restante fue la imagen a partir de la cual se

generaron las otras. Esta fue llamada, la imagen base. De forma general, la

configuración de las instancias fue la siguiente:

o Tipo de instancia: t2.micro [110]

o Sistema Operativo: Linux, distribución Ubuntu Server 16.04 LTS

o Tipo de virtualización: HVM

o Tipo de almacenamiento: AWS Elastic Block Storage (EBS), SSD de

propósito general.

o Software instalado: JDK 1.8, Play Framework v2.5

• A partir de estas AMIs, se crearon 5 configuraciones de lanzamiento de instancias,

para luego ser configuradas en los grupos de Auto-Scaling. Seguido de esto, se

crearon los 5 grupos de Auto-Scaling correspondientes, donde se configuró la

cardinalidad deseada y algunas reglas para el incremento o reducción de la cantidad

de instancias. Una vez configurada la cardinalidad mínima, inicia el proceso de

creación y encendido de las máquinas necesarias para mantener las cantidades

mínimas.

• Para cada grupo de Auto-Scaling correspondientes a los componentes “Register

Service” y “Transactional Service” se implementó 1 balanceador de cargas, dado

que las peticiones a estos componentes son sincronizadas, es decir, se hacen

directamente al componente utilizando el protocolo HTTP.

196

• Se creó una instancia de Amazon RDS [111] para la base de datos relacional. Por

tratarse de un prototipo, no se habilitó la opción de multi-zona. La configuración de

esta instancia fue la siguiente:

o Tipo de instancia: db.t2.micro [112]

o Motor: PostgreSQL

o Caso de Uso: Desarrollo / Pruebas

o Tipo de Almacenamiento: SSD de propósito general

o Capacidad de Almacenamiento: 30GB

• En cuanto a las tecnologías utilizadas para la construcción del prototipo, fueron

seleccionadas las mismas para todos los componentes, variando algunas de ellas

dependiendo de las capacidades desarrolladas en el componente. Por ejemplo,

aquellos componentes con acceso a base de datos implementaron persistencia,

mientras que otros implementaron la ejecución de un motor de reglas básico. Cabe

destacar que el diseño arquitectural permite la selección de tecnologías diferentes

para todos los componentes, dependiendo de las capacidades deseadas en cada uno.

Sin embargo, por tratarse de una prueba de concepto, este análisis no fue realizado.

En la Figura 5-8 se muestran las tecnologías utilizadas para la implementación del

prototipo.

• El algoritmo de Triage aplicado en el prototipo se encuentra basado en la escala de

clasificación Manchester (MTS) [113], el cual fue implementado por medio de un

motor de reglas basadas en los síntomas del paciente. Las escalas de clasificación

del sistema MTS se encuentran descritas en la Tabla 5-6. Los síntomas y reglas

aplicadas a éstos fueron generados a partir de datos pseudo-aleatorios, pues el

objetivo del prototipo no fue evaluar la funcionalidad y efectividad del método de

Triage, sino los escenarios asociados a desempeño y disponibilidad del sistema, por

medio de la arquitectura de software diseñada.

197

Figura 5-8. Tecnologías utilizadas para la implementación del prototipo

198

Tabla 5-6. Sistema de Escalas de Clasificación MTS. Tomado de [113]

Número Nombre Color Tiempo de Atención

1 INMEDIATO ROJO 0 MIN

2 MUY URGENTE NARANJA 10 MIN

3 URGENTE AMARILLO 60 MIN

4 NORMAL VERDE 120 MIN

5 NO URGENTE AZUL 240 MIN

Para evaluar los escenarios de calidad, se construyó una suite de pruebas automatizadas.

Dentro de la suite, se definió un conjunto de pruebas por cada escenario. Cada conjunto de

pruebas fue implementado y ejecutado utilizando Apache Jmeter [114] para el caso de los

escenarios asociados a Performance, mientras que se realizaron pruebas manuales para el

escenario asociado a Availability. A continuación, se describen y analizan los resultados

obtenidos.

5.2.2.1. Evaluación del escenario ASR-01

Este escenario se encuentra descrito en la Tabla 3-4. Para este escenario se ejecutó una

prueba de carga [37]. Básicamente, se trata de generar un ambiente equivalente a un pico

de carga transaccional para el sistema, el cual debe registrar un Throughput de 2.000

transacciones por segundo, en promedio. Para ejecutar este escenario en el prototipo, se

implementaron 6 casos de prueba utilizando Jmeter, los cuales se encuentran descritos en la

Tabla 5-7.

Tabla 5-7. Casos de Prueba implementados para ASR-01

No. de

Caso Descripción No. Hilos

Tiempo de

Distribución

(seg.)

No. Peticiones

por Hilo

CASO 1

100 clientes diferentes envían 1 petición

al mismo tiempo.

100 0 1

CASO 2

100 clientes diferentes envían 10

peticiones al mismo tiempo.

100 0 10

CASO 3

1.000 clientes diferentes envían 1 1.000 0 1

199

petición al mismo tiempo.

CASO 4

30 clientes diferentes envían 1.000

peticiones distribuidas en un lapso de 10

segundos. Se espera enviar

aproximadamente 3.000 peticiones por

segundo.

30 10 1.000

Estos casos de prueba fueron ejecutados de forma secuencial, en una máquina ubicada en la

misma zona de disponibilidad del sistema en Amazon Web Services, con el fin de evitar la

latencia natural generada por la conexión a internet. Los resultados obtenidos se describen a

continuación.

El APDEX (Application Performance Index, por sus siglas en inglés), el cual corresponde a

una valoración general del sistema suministrada por APDEX Alliance [115], es de 0.987,

en una escala de 0 a 1, donde 0 es el performance más bajo y 1 el más alto. El APDEX más

bajo fue obtenido en el CASO 4, en el cual el sistema recibe 1.000 peticiones por segundo,

distribuidas en 30 clientes concurrentes, generando un total de 30.000 llamados. La Figura

5-9 muestra el APDEX generado para cada caso de prueba.

Figura 5-9. APDEX (Application Performance Index) generado por Jmeter

El mayor Throughput logrado por el sistema es de 518,13 (CASO 2), seguido del CASO 3,

con un Throuhput de 477,78. Lo anterior indica que el Throughput promedio para estos dos

casos se ubica en 500 transacciones por segundo. La Figura 5-10 muestra el resumen de

ejecución de todos los casos de prueba. En la última columna se puede observar el

Throughput, mientras que las columnas “Average”, “Min”, “Max” representan tiempos de

200

respuesta. También se puede observar que, en la ejecución de todos los casos de prueba, no

se generó ningún error, lo cual prueba la confiabilidad del sistema (Figura 5-11).

Figura 5-10. Estadísticas ejecución de escenario ASR-01

Figura 5-11. Errores generados en la ejecución del escenario ASR-01

En la Figura 5-12 se puede observar que el sistema alcanzó un pico de peticiones por

segundo (859 peticiones), que indica el máximo pico transaccional logrado por la prueba.

La Figura 5-13 muestra la cantidad de respuestas suministradas por el sistema, cuyo pico se

encuentra en 523 respuestas por segundo. La Figura 5-14 muestra que el CASO 2 generó el

Throughput más alto del sistema, logrando la atención de las 523 respuestas en 1 segundo,

mientras que en el CASO 4, las peticiones fueron distribuidas a lo largo de 3 minutos,

logrando un pico de 260 transacciones por segundo.

201

Figura 5-12. Gráfico de peticiones por segundo que llegaron al sistema

Figura 5-13. Gráfico de respuestas por segundo suministradas por el sistema

Figura 5-14. Gráfico de transacciones por segundo que fueron atendidas por el sistema

202

Figura 5-15. Gráfico de correlación de Tiempos de Respuesta vs Peticiones

Cabe destacar que los tiempos de respuesta en promedio se ubicaron entre los 150 y 250

ms, para una cantidad entre 100 y 250 peticiones por segundo (Figura 5-15), con una

dispersión cercana a cero, lo que indica que el sistema no sufrió ninguna degradación en sus

ASL y la mayoría de las peticiones (31.392) se ubicaron en tiempos de respuesta menores o

iguales a los 500 ms (Figura 5-16). También, es interesante observar el comportamiento del

sistema en la medida que creció la cantidad de clientes concurrentes, pues mejoró sus

tiempos de respuesta con dicho incremento (Figura 5-17). Esto obedece a la

implementación de la técnica de “Auto-Scaling” implementada por medio de Amazon Web

Services, en la cual se llegó a un límite de crecimiento de 4 máquinas de tipo “t2.micro”

[110] por servicio o componente.

Figura 5-16. Gráfico de Cantidad de respuestas vs rangos de Tiempos de Respuesta

203

Figura 5-17. Gráfico de Tiempos de Respuesta promedio vs Clientes concurrentes

Como resultado final de la ejecución de este escenario, se puede concluir que el ASR-01

puede ser cumplido con la implementación correcta. Por medio de la implementación del

prototipo, que tiene el alcance de ser una prueba concepto, se llegó a un máximo de 523

transacciones por segundo, alcanzadas con una infraestructura pequeña que consistió en 4

instancias de bajo rendimiento, comúnmente utilizadas para entornos de desarrollo o

pruebas (t2.micro), con una única instancia RDS para la Base de Datos. Incrementando la

infraestructura a instancias de cómputo y base de datos de producción, y aumentando los

límites de los grupos de Auto-Scaling, aunado a la selección de un framework más ligero

que el utilizado en el prototipo (i.e. Node.JS [116]), fácilmente se puede cumplir el ASR. El

patrón de diseño Process Coordinator ajustado permitió al sistema incrementar su

confiabilidad, ya que todas las peticiones fueron atendidas de forma asíncrona, logrando

unos tiempos de respuesta por encima de la media, según el APDEX. De esta forma, se

puede concluir que las decisiones arquitecturales tomadas satisfacen el ASR.

5.2.2.2. Evaluación de los escenarios ASR-02 y ASR-03

El escenario ASR-02 se encuentra descrito en la Tabla 3-5 y se trata de que el sistema se

encuentre disponible en operación normal las 24 horas del día, 7 días de la semana y 365

días del año. Por otro lado, el escenario ASR-03 se encuentra descrito en la Tabla 3-6. Para

este escenario se ejecutó una prueba de recuperación [37], la cual consistió en verificar que

el sistema continúe atendiendo peticiones en operación normal aún y cuando una de las

204

instancias del clasificador (Coordinator Service) falla. La satisfacción de estos escenarios

pudo lograrse fácilmente con la arquitectura propuesta desde las siguientes perspectivas:

Desde la infraestructura, se logró probar que la arquitectura puede ser implementada en un

entorno de computación en la nube, por medio de Amazon Web Services, el cual tiene un

ANS de hasta 99.99% para instancias EC2 [117] y hasta 99.95% para instancias RDS

[118], las cuales son los servicios principales utilizados y se encuentran por encima del

escenario propuesto. Por otro lado, por medio de este proveedor de infraestructura, se

pudieron aplicar tácticas de monitoreo, balanceo de cargas y auto-scaling de la

infraestructura de una forma relativamente simple.

Por medio de la inclusión de las tácticas arquitecturales propuestas en el prototipo, se pudo

comprobar la satisfacción de los escenarios, de igual forma. El patrón de diseño utilizado y

la mensajería totalmente asíncrona hace que el sistema sea a prueba de fallos y los puntos

de contención sean mínimos. Con respecto a la implementación de la redundancia de tipo

Cold-Spare, se pudo evidenciar que, ante la falla de alguna instancia de un componente, el

sistema reacciona rápidamente activando una nueva instancia. En el prototipo se pudo

probar esta táctica fácilmente, a través del siguiente flujo:

• Se configuraron los grupos de auto-scaling a un mínimo deseado de 3 instancias por

componente.

• Se ejecutaron los casos de prueba utilizados para el escenario ASR-01 (sección 5).

• Durante la ejecución, se comenzaron a apagar instancias aleatoriamente, incluyendo

instancias del componente “Coordinator Service”.

• Se observó cómo inmediatamente el sistema comenzó a crear nuevas instancias para

los componentes afectados. El tiempo promedio de creación de nuevas instancias

fue de 20 segundos.

• Se revisaron los tiempos de respuesta y Throughput del sistema, encontrando cero

afectaciones en los mismos.

Mediante la prueba de estos escenarios se concluyó que el sistema es capaz de mantener sus

ANS (99.9%) en una implementación formal y puede recuperarse rápidamente de fallos.

Por lo tanto, se satisface completamente el escenario de calidad.

205


Este escenario se encuentra descrito en la Tabla 3-9. Para este escenario se ejecutó una

prueba de recuperación [37]. Básicamente, se trata de generar una falla en alguno de los

componentes principales utilizados para la clasificación: “Triage Service”, “EHR Service”

o “Inference Engine”. Este escenario fue probado en todas las ejecuciones del prototipo ya

que su alcance sólo estaba basado en incluir el componente de Triage. Sin embargo, fueron

añadidas las colas de entrada para los otros dos componentes, con el objetivo de evaluar el

comportamiento del “Coordinator Service” cuando se reporta que un componente no es

operativo. La forma como se decidió reportar un componente en estado no operativo en la

implementación del prototipo fue a través de un indicador de estado en a base de datos que

usa el clasificador para consultar los endpoints de los componentes principales. El

escenario completo incluiría monitoreo e informe de la situación de forma automática (ver

decisiones arquitecturales en la sección 4.2.1.4). Sin embargo, fue suficiente con registrar el

estado de forma manual.

Mediante la prueba de este escenario se concluyó que el “Coordinator Service” es capaz de

evitar peticiones a componentes reportados como no operativos y, por lo tanto, se satisface

completamente el escenario de calidad.


Este escenario se encuentra descrito en la Tabla 3-10. Para este escenario se combinó la

ejecución de una prueba de carga con una prueba de rendimiento [37]. Básicamente, se

trata de generar un ambiente equivalente a un pico de carga transaccional para el sistema

construido, el cual, en el prototipo evaluado, corresponde a una carga comprendida entre

300 y 500 transacciones por segundo. En este caso, los tiempos de respuesta globales, es

decir, incluyendo la ejecución del proceso de Triage deben ser menores a 30 segundos. Para

ejecutar este escenario en el prototipo, se implementaron 3 casos de prueba utilizando

Jmeter, los cuales se encuentran descritos en la Tabla 5-8.

206


No. de


Tiempo de

Distribución

(seg.)

No. Peticiones

por Hilo

CASO 1



100 0 10

CASO 2

1.000 clientes diferentes envían 1


1.000 0 1

CASO 3





segundo.

30 10 1.000

De igual forma que el escenario ASR-01, estos casos de prueba fueron ejecutados de forma

secuencial y en una máquina ubicada en Amazon Web Services. Los resultados obtenidos

se describen a continuación. A pesar de que los escenarios fueron lanzados desde Jmeter,

sus resultados no fueron consolidados desde la herramienta, ya que los tiempos de respuesta

que se muestran en este caso corresponden a la respuesta del componente “Register

Service”.

Por tratarse de un sistema totalmente asíncrono, se implementó otra forma de obtener los

tiempos de respuesta, la cual consistió en leer el timestamp de las transacciones en la base

de datos. En este caso, el tiempo respuesta corresponde a la diferencia del timestamp de

registro en la cola del cliente (output endpoint) y el timestamp de registro en la cola de

entrada al sistema (input endpoint).

En una primera implementación del prototipo, se obtuvieron los resultados mostrados en la

Tabla 5-9.

207

Tabla 5-9. Primeros resultados ejecución de casos de prueba para ASR-07

No. de Caso No. de

Peticiones

Throughput

deseado Min (s) Max (s) Promedio (s)

CASO 1 1.000 518,7 0,201 20,966 7,948

CASO 2 1.000 477,78 0,358 20,468 10,349

CASO 3 30.000 164,93 0,211 123,951 58,585

Como se puede ver en la Figura 5-18, dado el resultado del caso 3, se percibió una

degradación del sistema en relación con el aumento de la cantidad de peticiones, sin ser

necesariamente proporcional al Throughput. Se encontró un punto de contención en las

interfaces de los componentes que tienen la labor de consumir la información de las colas

de entrada. En el caso del prototipo, las colas de los componentes “Coordinator Service”,

“Triage Service” y “Response Service”. La contención encontrada se trataba de una

limitación en la cantidad de lecturas por segundo que se podían realizar a las colas

implementadas a través del servicio AWS SQS [119], la cual entregaba un máximo de 10

mensajes por segundo, por nodo, lo cual es una configuración muy baja.

Figura 5-18. Tiempo de respuesta vs cantidad de peticiones

208

Después de una optimización a estas interfaces, se lograron los resultados mostrados en la

Tabla 5-10, donde se evidencia la ausencia de la contención, normalizándose de esta forma

la relación entre los tiempos de respuesta y la cantidad de peticiones, como se puede

observar en la Figura 5-19. Se destaca esta apreciación ya que una buena arquitectura con

una implementación inadecuada puede generar anti-patrones, en los cuales los resultados

pueden ser catastróficos. El arquitecto debe asegurarse de que la implementación sea

evaluada apropiadamente.

Tabla 5-10. Resultados definitivos ejecución de casos de prueba para ASR-07.

No. de Caso No. de

Peticiones

Throughput


CASO 1 1.000 518,7 0,254 1,159 0,397

CASO 2 1.000 477,78 0,226 2,525 1,229

CASO 3 30.000 164,93 0,186 2,769 1,418

Figura 5-19. Tiempo de respuesta vs peticiones después de optimización

Como resultado final de la ejecución de este escenario, se puede concluir que el ASR-07

puede ser cumplido con la implementación adecuada. Sin embargo, el prototipo sólo

contempló el algoritmo de Triage en la ejecución del proceso, es decir, los componentes de

209

inferencia de alertas y recomendaciones, y consulta de EHR no fueron contemplados. Entre

estos componentes, el que podría generar mayor contención es el de consulta de EHR dado

que se ha contemplado como un sistema externo y ya se debería entrar en detalles de los

ANS que provea el servicio seleccionado en una eventual implementación.

Con respecto al motor de inferencia, dado que el enfoque apunta a utilizar una base de

conocimiento interna alimentada de forma asíncrona por una base de conocimiento externa,

el sistema mantendrá tiempos de respuesta similares a los del algoritmo de Triage para

implementaciones basadas en reglas. Para otras implementaciones (i.e. basadas en

inteligencia artificial, como machine learning) no se prevén mayores impactos en los

tiempos, por lo que se puede considerar que la arquitectura satisface el ASR en lo que tiene

qué ver con el algoritmo de Triage y el motor de inferencias. Otro punto a considerar es que

la infraestructura de los componentes implementados estuvo limitada a 3 instancias

t2.micro por cada componente.


Este escenario se encuentra descrito en la Tabla 3-10. Para este escenario se combinó la

ejecución de una prueba de estrés con una prueba de rendimiento [37]. Básicamente, se

trata de generar un ambiente equivalente a un doble pico de carga transaccional para el

sistema construido, el cual, en el prototipo evaluado, corresponde a una carga comprendida

entre 600 y 1.00 transacciones por segundo. En este caso, los tiempos de respuesta globales,

es decir, incluyendo la ejecución del proceso de Triage deben ser menores a 1 minuto. Para

ejecutar este escenario en el prototipo, se implementaron 3 casos de prueba utilizando

Jmeter, los cuales se encuentran descritos en la Tabla 5-11.

210


No. de


Tiempo de

Distribución

(seg.)

No. Peticiones

por Hilo

CASO 1



100 0 20

CASO 2

2.000 clientes diferentes envían 1


2.000 0 1

CASO 3





segundo.

40 20 1.500

De igual forma que los escenarios ASR-01 y ASR-07, estos casos de prueba fueron

ejecutados de forma secuencial y en una máquina ubicada en Amazon Web Services. Los

resultados obtenidos se describen a continuación en la Tabla 5-12, mientras que la relación

entre los tiempos de respuesta y el Throughput se representa en la Figura 5-20.

Tabla 5-12. Resultados ejecución de casos de prueba para ASR-08.

No. de Caso No. de

Peticiones

Throughput


CASO 1 2.000 710 0,267 1,214 0,819

CASO 2 2.000 824 0,342 4,673 2,236

CASO 3 60.000 523 0,208 4,981 2,415

Como resultado final de la ejecución de este escenario, se puede concluir que el ASR-08 se

puede satisfacer de forma holgada, por lo menos en lo que corresponde a los componentes

internos (Algoritmo de Triage y motor de inferencia), por las razones descritas en la

sección 5.2.2.4. Lo anterior quiere decir que, en un doble pico de carga, el sistema continúa

respondiendo normalmente sin presentarse degradación del servicio. Este tipo de resultados

es muy común en arquitecturas de tubos y filtros, especialmente, cuándo se utilizan colas

optimizadas durante el procesamiento de la información. Por lo anterior, se puede decir que

211

el sistema puede estar preparado para comportarse como un servicio de alto desempeño,

con la implementación e infraestructura adecuadas.

Figura 5-20. Tiempo de respuesta vs cantidad de peticiones

212

Capítulo 6. Análisis de Resultados

6.1. Discusión de resultados y conclusiones

6.2. Recomendaciones y Trabajo Futuro

213

6.1. Discusión de resultados y conclusiones

6.1.1. Sector Salud

En la literatura se ha encontrado una amplia evidencia sobre el uso de CDSS en la industria

de la salud. Por medio de estos sistemas, se ha logrado mejorar los resultados relacionados

con la oportunidad de atención de pacientes. Cada vez más, las instituciones de esta

industria están utilizando esta solución en conjunto con modelos de entrega como la

computación en la nube, con el fin de obtener una mejor relación costo-beneficio, integrar e

intercambiar registros médicos entre diferentes plataformas y organizaciones, y compartir

conocimiento para la mejora de las prescripciones, tratamientos y diagnósticos. Dentro de

las implementaciones de CDSS, se encontró que las Alertas y Recomendaciones

constituyen la implementación más común y de mayor aporte al dominio del Triage y de la

salud en general, siendo los EMR, EHR y PHR, los insumos principalmente utilizados por

estos sistemas. Lo anterior, constituye una gran oportunidad para el proceso de Triage y se

logra demostrar la pertinencia de los CDSS para mejorar las entradas y, por ende,

resultados de dicho proceso.

Se destacan los desafíos que se presentan actualmente en el dominio de la salud. En

Colombia existe un marco legal amplio que permite al sistema operar bajo la normatividad

vigente. Sin embargo, se evidencia una brecha amplia con respecto al uso de la tecnología,

comparado con otros sectores como el financiero y logístico, o inclusive, si se compara con

el mismo sector en otros países y contextos. Lo anterior hace que el impacto de este

proyecto sea positivo para el sector en Colombia ya que se encuentra en línea con esfuerzos

como los que se evidencian en la cartera de las tecnologías de la información y las

telecomunicaciones, demostrando que este sector resulta ser una fuerte motivación para el

inicio de proyectos como el actual.

El proceso de determinación de requisitos arquitecturales en este dominio puede ser

abordado con relativa facilidad si se sigue un proceso riguroso, puesto la información de

este sector, en la actualidad, no es completamente accesible y se encuentra bastante

dispersa. Se puede afirmar, desde el punto de vista del abordaje de este trabajo, que la

214

entrevista directa y la adherencia a un marco legal y contextual funcionan bien en el sector

y permiten una correcta lectura de las necesidades en términos de escenarios y restricciones

de negocio. Esto pudo ser corroborado por medio del método QAW elaborado, en el cual,

se pudieron confirmar y contrastar los drivers arquitecturales que se habían encontrado y

analizado en el estado del arte, revisiones de literatura ad-hoc y el marco legal. Este método

permitió generar los escenarios y restricciones de negocio directamente con un grupo de

interesados que comprende el sector, específicamente el funcionamiento del proceso de

Triage. También se puede afirmar que adaptar y extender prácticas que han tenido buenos

resultados en otros contextos es clave para este tipo de proyectos. En el caso particular, el

diseño arquitectural fue guiado por una amplia revisión sistemática de literatura ajustada al

dominio particular, donde se encontró que otros países han utilizado los CDSS para mejorar

los resultados de la industria de la salud.

6.1.2. Ingeniería de Software

El proyecto se enfocó en satisfacer los escenarios de calidad por medio de un diseño

arquitectural dirigido por los drivers performance, availability y security a través de un

adecuado balance entre la rigurosidad de los procesos de diseño, los estándares que rigen la

industria en la actualidad, el contexto del proyecto y el marco legal. Como se menciona en

la sección 6.1.1, la determinación de los ASRs en el sector es un desafío que puede

abordarse desde la rigurosidad de los métodos de la ingeniería de software. En este

proyecto se lograron los resultados esperados ya que no sólo se aplicaron estos métodos si

no que se combinaron con la ingeniería de software basada en evidencias, la cual permitió

llegar a conclusiones similares en términos de los drivers arquitecturales.

En las revisiones bibliográficas realizadas se encontró una falta de formalismo y

rigurosidad en la aplicación de los métodos y la elaboración de los reportes técnicos con sus

correspondientes resultados. Por ejemplo, algunos autores no fueron rigurosos en mostrar la

evaluación de sus modelos arquitecturales, otros no especificaron la forma como llegaron a

los drivers que dirigieron el diseño de la arquitectura de software, mientras que otros no

detallaron los métodos usados para el diseño y documentación de la arquitectura. Esta falta

215

de formalismo y rigurosidad inspiró la elaboración de un proceso de diseño arquitectural

cuidadoso y formal, utilizando los procesos de diseño propuestos por el SEI, los cuales

pueden ser replicados por otros arquitectos e implementadores. Lo anterior corresponde a

uno de los mayores aportes del presente proyecto.

La aplicación del método ADD permitió iterar rápidamente sobre los diferentes niveles de

diseño arquitectural, permitiendo una evaluación gradual de las hipótesis generadas en cada

iteración. Uno de los aportes principales de este trabajo fue que el diseño estuvo basado en

la adaptación de una arquitectura o modelo estándar de CDSS, la cual consiste en tres

componentes principales, a saber, un motor de inferencia, una base de conocimiento y una

interfaz para consultar las Alertas y Recomendaciones del sistema. Sin embargo, otros

componentes, como el Triage y la consulta de Historias Clínicas Electrónicas de los

pacientes durante el proceso de clasificación, permitieron enriquecer el diseño y posteriores

implementaciones, satisfaciendo de esta forma las necesidades puntuales de los interesados

del proyecto. La forma como se propuso la orquestación de estos componentes, siguiendo

un patrón de tubos y filtros, con mensajería asíncrona, multi-capa y multi-nivel, hace

posible satisfacer los ASR definidos fácilmente y proporciona resultados muy interesantes,

los cuales pueden ser un punto de partida para proponer una posible arquitectura de

referencia.

Con respecto a la evaluación de la arquitectura, fueron utilizados tres de los métodos más

utilizados por los arquitectos de software en la industria, a saber, Evaluación durante el

diseño, ATAM y prototipado. Se concluyó que ATAM es uno de los métodos más

completos que existe para analizar las decisiones arquitecturales. Sin embargo, puede llegar

a ser un método complejo si no se aplica de forma iterativa. Por otro lado, a pesar de que se

utilizó ATAM, los autores consideraron pertinente elaborar una prueba de concepto o

prototipo con el fin de dar más fuerza a la evaluación de la arquitectura, a través de

experimentos que permitieron evaluar las decisiones arquitecturales con mayor precisión.

Esta decisión fue tomada a raíz de la experiencia de los arquitectos, con el antecedente de

que existen decisiones arquitecturales que pueden ser evaluadas satisfactoriamente

mediante juicio de expertos, pero, en la práctica, existen variaciones que pueden hacer que

los resultados sean diferentes. En efecto, como resultado de la prueba de concepto, se

216

encontró que una implementación deficiente de la arquitectura puede generar anti-patrones

con resultados catastróficos para el sistema, por lo que deja abierto el debate del vacío que

puede generarse entre el diseño arquitectural y la implementación de un software. Lo

anterior demuestra que las pruebas de concepto o prototipos resultan ser de suma

importancia cuando el arquitecto de software puede presentar inquietudes a la hora de

validar una hipótesis. Es por lo anterior que se puede concluir que la complementariedad de

las dos evaluaciones generó resultados más confiables, sin entrar en detalles del nivel de

fidelidad de las evaluaciones realizadas.

Finalmente, desde la ingeniería de software, se plantea el interrogante sobre el uso de

métodos ágiles (o basados en el desarrollo ágil) para diseño de arquitectura de software y

de sistemas, puesto que la aplicación de estos métodos de forma rigurosa representó

grandes esfuerzos para el proyecto. Los autores del SEI presentan la postura de que todos

los métodos recomendados son perfectamente adaptables a entornos ágiles. Sin embargo,

para los autores del presente proyecto, el debate continúa abierto, sin entrar en detalles

puesto que esto no correspondía al alcance del proyecto.

6.1.3. Ejercicio académico

Con respecto al ejercicio académico llevado a cabo en el proyecto, de destaca la aplicación

de la ingeniería de software basada en evidencias, a través de estudios de mapeo sistémico,

revisión sistemática de literatura y revisión ad-hoc de literatura. Estos métodos combinados

y utilizados en los momentos adecuados (según el progreso del proyecto) fueron

determinantes a la hora de encontrar evidencia sobre la construcción de CDSS para el

proceso de Triage en otros contextos y países. De hecho, los estudios de mapeo sistemático

permitieron a los autores postular la hipótesis.

Se destaca también el fortalecimiento de la escritura técnica en inglés y los aportes que los

autores realizan al mundo a través de dos publicaciones, a saber, una internacional y una

nacional, referenciadas en el presente reporte. La divulgación científica es un proceso que

proporcionó un plus al proyecto, dado que en el proceso metodológico se plantearon los

procesos de validación y divulgación, como partes esenciales.

217

Finalmente, el presente proyecto puede ser replicado por practicantes e implementadores,

dada la rigurosidad con la que fueron abordados los métodos de la ingeniería de software y

la forma como el proceso completo fue documentado.

6.2. Recomendaciones y Trabajo Futuro

Como recomendación principal para los practicantes e implementadores de un CDSS para

el proceso de Triage, se puede decir que se debe poner especial atención en el paso del

diseño de la arquitectura de software a la implementación del sistema como tal. Durante las

pruebas de concepto, realizadas por medio del prototipo, se logró evidenciar que un equipo

de implementación puede generar resultados indeseables pese a que el diseño arquitectural

se encuentre correcto y supere las validaciones pertinentes. En este tipo de

implementaciones, se requieren tácticas que ya se encuentran más del lado del proceso de

desarrollo de software y ciencias de la computación, con el objetivo de optimizar los

componentes desarrollados.

También es importante moverse adecuadamente en el contexto del proyecto que se esté

implementando para dar una lectura acertada de los procesos para el desarrollo de software

que se están utilizando. No es lo mismo proponer un diseño arquitectural para un proyecto

que se encuentra siendo ejecutado desde el desarrollo ágil, que para uno que siga un modelo

tradicional (i.e. cascada). Los métodos y mejores prácticas propuestas por el SEI pueden ser

adaptados, con relativa facilidad, para lograr enmarcar el proceso de diseño arquitectural en

cualquier escenario, Sin embargo, existe un debate amplio sobre esta aseveración, donde,

incluso, se han creado otros marcos de trabajo para el proceso de diseño de arquitecturas de

software.

Lo anterior les proporciona a los autores una nueva motivación de trabajo futuro que

consiste en profundizar sobre el proceso de diseño arquitectural desde otros enfoques, como

el desarrollo ágil, con el objetivo de contrastar los métodos existentes y estudiar la

posibilidad de adaptarlos o extenderlos para cumplir con los desafíos que imponen estos

enfoques. Por supuesto, la implementación de un CDSS siguiendo el diseño propuesto es

218

un trabajo que puede plantearse desde la implementación, siguiendo los lineamientos de la

ingeniería de software, con el fin de evaluar por completo el diseño y analizar las barreras

que se obtienen al pasar del diseño arquitectural a la implementación.

Finalmente, la profundización en las ciencias de la computación, en relación con la

implementación de un CDSS es un trabajo futuro por plantearse para resolver problemas

ubicados en dominios de la salud específicos, como, por ejemplo, alertas y

recomendaciones para pacientes con prescripciones médicas, enfermedades crónicas, entre

otros. Esto, combinado con el proceso de Triage y la fase de implementación del sistema

propuesto, podría entregar resultados muy precisos, para conducir a la propuesta de una

posible arquitectura de referencia. Sin embargo, por el concepto de arquitectura de

referencia, es necesario llevar a cabo varias iteraciones correctamente evaluadas, antes de

que ésta se pueda proponer.

219

Referencias

[1] K. V Iserson and J. C. Moskop, “Triage in Medicine, Part I: Concept, History, and

Types,” Ann. Emerg. Med., vol. 49, no. 3, pp. 275–281, Jun. 2015.

[2] J. Gomez, “Clasificación de pacientes en los servicios de urgencias y emergencias:

Hacia un modelo de triaje estructurado de urgencias y emergencias,” Emergencias,

vol. 15, pp. 165–174, 2003.

[3] D. Aronsky et al., “An integrated computerized triage system in the emergency

department.,” AMIA Annu. Symp. Proc., pp. 16–20, 2008.

[4] O. Oakkar, “Online triage for patients: Implementing a scalable and cost-effective

triage platform using expert system, machine learning and natural language

processing techniques,” University of North Carolina, 2013.

[5] S. Halim, M. Annamalai, M. S. Ahmad, and R. Ahmad, “A conceptualisation of an

agent-oriented triage decision support system,” Commun. Comput. Inf. Sci., vol. 295

CCIS, pp. 272–282, 2012.

[6] K. J. Farion, W. Michalowski, S. Rubin, S. Wilk, R. Correll, and I. Gaboury,

“Prospective evaluation of the MET-AP system providing triage plans for acute

pediatric abdominal pain,” vol. 7, pp. 208–218, 2007.

[7] V. C. Georgopoulos and C. D. Stylios, “Introducing Fuzzy Cognitive Maps for

developing Decision Support System for Triage at Emergency Room Admissions for

the Elderly,” IFAC Proc. Vol., 2012.

[8] V. C. Georgopoulos and C. D. Stylios, “Supervisory Fuzzy Cognitive Map Structure

for Triage Assessment and Decision Support in the Emergency,” in Simulation and

Modeling Methodologies, Technologies and Applications, 2014, pp. 255–269.

220

[9] O. H. Salman, M. F. a Rasid, M. I. Saripan, and S. K. Subramaniam, “Multi-sources

data fusion framework for remote triage prioritization in telehealth.,” J. Med. Syst.,

vol. 38, no. 9, p. 103, 2014.

[10] Y. Tian, T. Zhou, Y. Wang, and M. Zhang, “Design and Development of A Mobile-

based System for Supporting Emergency Triage Decision Making,” 2014.

[11] A. Abelha et al., “Improving Quality of Services in Maternity Care Triage System,”

Int. J. E-Health Med. Commun., vol. 6, no. 2, pp. 10–26, Apr. 2015.

[12] A. Abelha, E. Pereira, A. Brandão, F. Portela, M. Santos, and J. Machado,

“Simulating a multi-level priority triage system for maternity emergency,” in

Modelling and Simulation 2014 - European Simulation and Modelling Conference,

ESM 2014, 2014, pp. 278–282.

[13] E. Berner, “Clinical decision support systems: state of the art,” in Agency for

Healthcare Research and Quality, 2009, no. 9.

[14] E. Coiera, “Clinical Decision Support Systems,” Guid. to Heal. Informatics, pp. 1–

12, 2005.

[15] G. Goertzel, “Clinical decision support system.,” Ann. N. Y. Acad. Sci., vol. 161, no.

2, pp. 689–693, 1969.

[16] “Software Engineering Institute.” [Online]. Available: https://www.sei.cmu.edu/.

[Accessed: 22-Jan-2017].

[17] C. Becker et al., “The Karlskrona manifesto for sustainability design,” Oct. 2014.

[18] C. Marcela, “Análisis de Situación de Salud Colombia, 2014,” Bogotá, 2014.

[19] “Las TIC al servicio de la salud serán prioridad en el Plan Vive Digital II:

Viceministra TI,” 2014. [Online]. Available:

http://www.mintic.gov.co/portal/604/w3-article-7346.html. [Accessed: 12-Jun-

2015].

[20] “Convocatorias Abiertas en Colciencias.” [Online]. Available:

http://www.colciencias.gov.co/convocatorias. [Accessed: 12-Jun-2015].

[21] “Sitio Web MinSalud Colombia.” [Online]. Available:

221

http://www.minsalud.gov.co/Paginas/default.aspx. [Accessed: 12-Jun-2015].

[22] K. Petersen, R. Feldt, S. Mujtaba, and M. Mattsson, “Systematic mapping studies in

software engineering,” in EASE’08 Proceedings of the 12th international conference

on Evaluation and Assessment in Software Engineering, 2008, pp. 68–77.

[23] B. Kitchenham and S. Charters, “Guidelines for performing Systematic Literature

Reviews in Software Engineering,” Engineering, vol. 2, p. 1051, 2007.

[24] L. Tabares, J. Hernandez, and I. Cabezas, “Architectural approaches for

implementing Clinical Decision Support Systems in Cloud : A Systematic Review,”

in Cloud Connected Health (CCH), 2016, pp. 1–6.

[25] I. Gorton, Essential software architecture, First Edit. Berlin, Germany: Springer

Berlin Heidelberg, 2006.

[26] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice Third

Edition. 2012.

[27] I. Gorton, Essential software architecture. 2006.

[28] P. Kruchten, “Architectural Blueprints — The ‘ 4 + 1 ’ View Model of Software

Architecture,” IEEE Softw. 12, vol. 12, no. November, pp. 42–50, 1995.

[29] “CHASE 2016.” [Online]. Available: http://conferences.computer.org/chase/.

[Accessed: 03-Dec-2017].

[30] “12th Colombian Conference on Computing.” [Online]. Available:

http://www.uao.edu.co/12ccc/en/. [Accessed: 03-Dec-2017].

[31] G. Mendoza Camargo and E. Elguero Pineda, “Sensibilidad del triage clínico en el

Servicio de Urgencias Adultos del HRLALM del ISSSTE,” Arch. Med. Urgenc.

México, vol. 3, no. 3, pp. 93–98, 2011.

[32] “Centre for Health Evidence,” 2016. [Online]. Available: http://www.cche.net/.


[33] J. Wyatt and D. Spiegelhalter, “Field trials of medical decision-aids: potential

problems and solutions.,” Proc. Annu. Symp. Comput. Appl. Med. Care, vol. 5479,

pp. 3–7, 1991.

222

[34] M. R. Barbacci, R. Ellison, A. J. Lattanze, J. a. Stafford, C. B. Weinstock, and W. G.

Wood, “Quality Attribute Workshops, Third Edition,” Quality, no. August, p. 38,

2003.

[35] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Thrid Edit.

San Francisco, CA, United states: Addison-Wesley Longman Publishing Co., Inc.,

2012.

[36] P. Clements et al., Documenting Software Architecture Views and Beyond, Second.

Boston, MA, United states: Addison-Wesley Longman Publishing Co., Inc., 2011.

[37] “Certifying Software Testers Worldwide - ISTQB® International Software Testing

Qualifications Board.” [Online]. Available: https://www.istqb.org/. [Accessed: 14-

Mar-2018].

[38] L. F. Tabares and J. F. Hernández, “Descubrimiento de Conocimiento en Big Data :

Estudio de Mapeo Sistémico by,” 2015.

[39] H. H. Dong et al., “Computerized triage system for paramedics in the pre-hospital

emergency medical service phase,” Proc. IEEE/EMBS Reg. 8 Int. Conf. Inf. Technol.

Appl. Biomed. ITAB, vol. 0, pp. 327–330, 2008.

[40] L. Xiao, G. Cousins, T. Fahey, B. D. Dimitrov, and L. Hederman, “Developing a

rule-driven clinical decision support system with an extensive and adaptative

architecture,” 2012 IEEE 14th Int. Conf. e-Health Networking, Appl. Serv. Heal.

2012, pp. 250–254, 2012.

[41] “Keona Health.” [Online]. Available: http://keonahealth.com/. [Accessed: 15-Sep-

2015].

[42] S. H. El-Sappagh and S. El-Masri, “A distributed clinical decision support system

architecture,” J. King Saud Univ. - Comput. Inf. Sci., vol. 26, no. 1, pp. 69–78, 2014.

[43] F. North et al., “Clinical decision support improves quality of telephone triage

documentation--an analysis of triage documentation before and after computerized

clinical decision support.,” BMC Med. Inform. Decis. Mak., vol. 14, no. 1, p. 20, Jan.

2014.

[44] J. Carnicero Giménez de Azcárate, A. Fernández Cellier, and D. Rojas de la

223

Escalera, “Manual de salud electrónica para directivos de servicios y sistemas de

salud: aplicaciones de las TIC a la atención primaria de salud,” vol. 2, p. 331p.,

2014.

[45] J. . Murdoch, R. . Barnes, J. . Pooler, V. . Lattimer, E. . Fletcher, and J. L. .

Campbell, “The impact of using computer decision-support software in primary care

nurse-led telephone triage: Interactional dilemmas and conversational

consequences,” Soc. Sci. Med., vol. 126, pp. 36–47, 2015.

[46] S. Oh et al., “Architecture Design of Healthcare Software-as-a-Service Platform for

Cloud-Based Clinical Decision Support Service.,” Healthc. Inform. Res., vol. 21, no.

2, pp. 102–10, Apr. 2015.

[47] R. A. Nimbalkar and R. A. Fadnavis, “Domain specific search of nearest hospital

and Healthcare Management System,” in 2014 Recent Advances in Engineering and

Computational Sciences (RAECS), 2014, pp. 1–5.

[48] V. Koufi, F. Malamateniou, G. Vassilacopoulos, and A. Prentza, “An Android-

Enabled Mobile Framework for Ubiquitous Access to Cloud Emergency Medical

Services,” in 2012 Second Symposium on Network Cloud Computing and

Applications, 2012, pp. 95–101.

[49] R. K. Lomotey and R. Deters, “Mobile-Based Medical Data Accessibility in

mHealth,” in 2014 2nd IEEE International Conference on Mobile Cloud Computing,

Services, and Engineering, 2014, pp. 91–100.

[50] S. Ahmed, “Knowledge based systems for ubiquitous e-healthcare,” 2014 Int. Conf.

Web Open Access to Learn. ICWOAL 2014, 2015.

[51] A. P. Ciprés, H. M. Fardoun, D. M. Alghazzawi, and M. Oadah, “KAU e-Health

Mobile System,” 2012.

[52] M. Hussain et al., “Cloud-based Smart CDSS for chronic diseases,” Health Technol.

(Berl)., vol. 3, no. 2, pp. 153–175, Mar. 2013.

[53] I. Chouvarda et al., “WELCOME – innovative integrated care platform using

wearable sensing and smart cloud computing for COPD patients with

comorbidities.,” Conf. Proc. ... Annu. Int. Conf. IEEE Eng. Med. Biol. Soc. IEEE

224

Eng. Med. Biol. Soc. Annu. Conf., vol. 2014, pp. 3180–3, Jan. 2014.

[54] J. Wang, H. Abid, S. Lee, L. Shu, and F. Xia, “A secured health care application

architecture for cyber-physical systems,” Control Eng. Appl. Informatics, vol. 13, no.

3, pp. 101–108, 2011.

[55] D. Callegari et al., “EpiCare - A home care platform based on mobile cloud

computing to assist epilepsy diagnosis,” in Proceedings of the 2014 4th International

Conference on Wireless Mobile Communication and Healthcare - “Transforming

Healthcare Through Innovations in Mobile and Wireless Technologies”,

MOBIHEALTH 2014, 2015, pp. 148–151.

[56] R. Afwani and S. H. Supangkat, “Mobile cloud design of reminder system for

Tuberculosis treatment in Indonesia,” in 2012 International Conference on Cloud

Computing and Social Networking (ICCCSN), 2012, pp. 1–4.

[57] T. Sahama, L. Simpson, and B. Lane, “Security and Privacy in eHealth: Is it

possible?,” 2013 IEEE 15th Int. Conf. e-Health Networking, Appl. Serv. Heal. 2013,

no. Healthcom, pp. 249–253, 2013.

[58] “EMR vs EHR vs PHR | ed-informatics.org.” [Online]. Available: http://ed-

informatics.org/healthcare-it-in-a-nutshell-2/emr-vs-ehr-vs-phr/. [Accessed: 06-Mar-

2016].

[59] A. Bakker and E. Pluyter-Wenting, “Hospital information systems.,” Stud. Health

Technol. Inform., vol. 65, pp. 208–230, 2002.

[60] B. E. Dixon et al., “A pilot study of distributed knowledge management and clinical

decision support in the cloud.,” Artif. Intell. Med., vol. 59, no. 1, pp. 45–53, Sep.

2013.

[61] J. Hsieh and M.-W. Hsu, “A cloud computing based 12-lead ECG telemedicine

service,” BMC Med. Inform. Decis. Mak., vol. 12, no. 1, p. 77, 2012.

[62] C. Ministerio de las Tecnologías de información y comunicaciones, “AGENDA

ESTRATÉGICA DE INNOVACIÓN - NODO SALUD,” Bogotá, 2014.

[63] United Nations, “Objetivos de desarrollo del milenio: una mirada desde américa

latina y el caribe,” Santiago, Chile, 2005.

225

[64] United Nations, “Objetivos de Desarrollo del Milenio,” New York, NY, United

states, 2011.

[65] N. Unidas, “Objetivos de Desarrollo Sostenible ( ODS ),” Bogotá, 2015.

[66] “OPS eSalud.” [Online]. Available: http://www.paho.org/ict4health/. [Accessed: 15-

Jun-2017].

[67] S. de la R. de Colombia, Ley 100 de 1993, vol. 1, no. 41. Colombia, 1993, p. 80.

[68] C. Ministerio de las Tecnologías de información y comunicaciones, “Documento de

planeación estratégica del subsistema de innovación para el uso y apropiacion de tic

en el gobierno,” Bogotá, 2011.

[69] C. Ministerio de las Tecnologías de información y comunicaciones, “Estructura de

los Nodos de Innovación (NDI),” Bogotá, 2012.

[70] M. of H. Colombia, Guías para manejo de urgencias 3a Edición. 2009.

[71] R. Colomoia, Ministerio de salud y proteccion social,resolucion 5596 del 2015, vol.

2015. 2015, p. 5.

[72] “Hospital Municipal Rubén Cruz Vélez | Inicio.” [Online]. Available:

https://hospitalrubencruzvelez.gov.co/es/. [Accessed: 07-Dec-2017].

[73] “Clínica San Francisco | Inicio.” [Online]. Available:

http://www.clinicasanfrancisco.com.co/. [Accessed: 07-Dec-2017].

[74] “Bienvenidos a la Clinica Mariangel | Dumian Medical.” [Online]. Available:

http://www.dumianmedical.net/site_dumian/mariangel/bienvenidos-la-clinica-

mariangel. [Accessed: 07-Dec-2017].

[75] “Hospital – Hospital Tomas Uribe Uribe.” [Online]. Available:

http://www.hospitaltomasuribe.gov.co/web/. [Accessed: 07-Dec-2017].

[76] T. Brown, “Design thinking,” Harv. Bus. Rev., vol. 86, no. 6, 2008.

[77] P. J. Denning, “Design thinking,” Commun. ACM, vol. 56, no. 12, pp. 29–31, 2013.

[78] A. Wolbling, K. Kramer, C. N. Buss, K. Dribbisch, P. Lobue, and A. Taherivand,

“Design Thinking: An Innovative Concept for Developing User-Centered Software,”

in Software for People, 2012, pp. 121–136.

226

[79] J. Gothelf and J. Seiden, Lean UX. 2013.

[80] L. A. Liikkanen, H. Kilpiö, L. Svan, and M. Hiltunen, “Lean UX: the next

generation of user-centered agile development?,” 8th Nord. Conf., pp. 1095–1100,

2014.

[81] M. Cyrillo, “Lean UX: Rethink Development,” Inf. Week, Nov. 14, pp. 8–11, 2011.

[82] S. Portigal and J. Norvaisas, “Elevator pitch,” Interactions, vol. 18. p. 14, 2011.

[83] “The Guide to Empathy Maps: Creating 10-Minute User Persona.” [Online].

Available: https://www.uxpin.com/studio/blog/the-practical-guide-to-empathy-maps-

creating-a-10-minute-persona/. [Accessed: 03-Dec-2017].

[84] “How to Use Mind Mapping for Better Thinking.” [Online]. Available:

http://www.designorate.com/how-to-use-mind-mapping/. [Accessed: 03-Dec-2017].

[85] “5 Whys - Problem-Solving Skills From MindTools.com.” [Online]. Available:

https://www.mindtools.com/pages/article/newTMC_5W.htm. [Accessed: 03-Dec-

2017].

[86] “Engineering Village - First choice for serious engineering research.” [Online].

Available: https://www.engineeringvillage.com/. [Accessed: 13-May-2016].

[87] “Scopus - Welcome to Scopus.” [Online]. Available: https://www.scopus.com/.

[Accessed: 13-May-2016].

[88] “Home - PubMed - NCBI.” [Online]. Available:

http://www.ncbi.nlm.nih.gov/pubmed. [Accessed: 13-May-2016].

[89] “IEEE Xplore Digital Library.” [Online]. Available:

http://ieeexplore.ieee.org/Xplore/home.jsp. [Accessed: 13-May-2016].

[90] “ACM Digital Library.” [Online]. Available: http://dl.acm.org/. [Accessed: 13-May-

2016].

[91] L. Villa, I. Cabezas, M. Lopez, and O. Casas, “Towards a Sustainable Architectural

Design by an Adaptation of the Architectural Driven Design Method,” in

Computational Science and Its Applications -- ICCSA 2016: 16th International

Conference, Beijing, China, July 4-7, 2016, Proceedings, Part II, O. Gervasi, B.

227

Murgante, S. Misra, A. M. A. C. Rocha, C. M. Torre, D. Taniar, B. O. Apduhan, E.

Stankova, and S. Wang, Eds. Cham: Springer International Publishing, 2016, pp. 71–

86.

[92] L. Tabares, J. Hernandez, and I. Cabezas, “Architectural Design of a Clinical

Decision Support System for Clinical Triage in Emergency Departments Analysis of

Performance , Availability and Security,” in The 17th International Conference on

Computational Science and Its Applications (ICCSA 2017), 2017, p. 16.

[93] “New Relic. The Software Analytics Company | New Relic.” [Online]. Available:

http://newrelic.com. [Accessed: 01-Dec-2015].

[94] “DataDog - Modern monitoring & analytics.” [Online]. Available:

https://www.datadoghq.com/. [Accessed: 09-Nov-2017].

[95] “Grafana - The open platform for analytics and monitoring.” [Online]. Available:

https://grafana.com/. [Accessed: 09-Nov-2017].

[96] “Logstash - Centralize, Transform & Stash your data.” [Online]. Available:

https://www.elastic.co/products/logstash. [Accessed: 09-Nov-2017].

[97] “Log Management & Analysis Software Made Easy | Logentries.” [Online].

Available: https://logentries.com/. [Accessed: 01-Dec-2015].

[98] “Logmatic.io | Technology Intelligence - Your logs and metrics like you have never

seen before.” [Online]. Available: https://logmatic.io/. [Accessed: 09-Nov-2017].

[99] “Rollbar - Error Tracking Software for Ruby, Python, JavaScript, more.” [Online].

Available: https://rollbar.com/. [Accessed: 01-Dec-2015].

[100] “Error Monitoring and Detection Software | Airbrake.” [Online]. Available:

https://airbrake.io/. [Accessed: 09-Nov-2017].

[101] “Sentry | Error Tracking Software — JavaScript, Python, PHP, Ruby, more.”

[Online]. Available: https://sentry.io/welcome/. [Accessed: 09-Nov-2017].

[102] “Application Security - NGINX.” [Online]. Available:

https://www.nginx.com/solutions/application-security/. [Accessed: 10-Nov-2017].

[103] Microsoft, “Message Validation.” [Online]. Available:

228

https://msdn.microsoft.com/en-us/library/ff650173.aspx. [Accessed: 24-Jan-2017].

[104] E. Peyrott, “The JWT Handbook,” Seattle, WA, United states, 2016.

[105] “Single Sign On & Token Based Authentication - Auth0.” [Online]. Available:

https://auth0.com/. [Accessed: 10-Nov-2017].

[106] “Okta | Always On.” [Online]. Available: https://www.okta.com/. [Accessed: 10-

Nov-2017].

[107] “Active Directory - Access & identity - IDaaS | Microsoft Azure.” [Online].

Available: https://azure.microsoft.com/en-us/services/active-directory/. [Accessed:

10-Nov-2017].

[108] “End User Authentication with OAuth 2.0 — OAuth.” [Online]. Available:

https://oauth.net/articles/authentication/. [Accessed: 10-Nov-2017].

[109] N. B. Harrison and P. Avgeriou, “How do architecture patterns and tactics interact?

A model and annotation,” J. Syst. Softw., vol. 83, no. 10, pp. 1735–1758, 2010.

[110] “Amazon EC2 Instance Types – Amazon Web Services (AWS).” [Online].

Available: https://aws.amazon.com/ec2/instance-types/?nc1=h_ls. [Accessed: 27-

Nov-2017].

[111] “Amazon Relational Database Service (RDS) – AWS.” [Online]. Available:

https://aws.amazon.com/rds/. [Accessed: 29-Nov-2017].

[112] “Amazon RDS Instance Types – Amazon Web Services (AWS).” [Online].

Available: https://aws.amazon.com/rds/instance-types/. [Accessed: 29-Nov-2017].

[113] K. Mackway-Jones, Emergency triage, Second. Manchester, 2006.

[114] “Apache JMeter - Apache JMeterTM.” [Online]. Available: http://jmeter.apache.org/.

[Accessed: 24-Nov-2017].

[115] A. Alliance, “Application Performance Index – Apdex Technical Specification,”

2007.

[116] “Node.js.” [Online]. Available: https://nodejs.org/en/. [Accessed: 19-Mar-2016].

[117] “Amazon EC2 SLA.” [Online]. Available: https://aws.amazon.com/ec2/sla/.


229

[118] “Amazon RDS SLA.” [Online]. Available: https://aws.amazon.com/rds/sla/.


[119] “Amazon Simple Queue Service (SQS) | Message Queuing for Messaging

Applications | AWS.” [Online]. Available: https://aws.amazon.com/sqs. [Accessed:

28-Nov-2017].

Diseño de la Arquitectura de un Sistema de Apoyo a ...

Documents

Transcript of Diseño de la Arquitectura de un Sistema de Apoyo a ...