Diseño de la Arquitectura de un Sistema de Apoyo a ...
Transcript of 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
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-5. Escenario ASR-02 refinado................................................................................. 85
Tabla 3-6. Escenario ASR-03 refinado................................................................................. 85
Tabla 3-7. Escenario ASR-04 refinado................................................................................. 86
Tabla 3-8. Escenario ASR-05 refinado................................................................................. 86
Tabla 3-9. Escenario ASR-06 refinado................................................................................. 86
Tabla 3-10. Escenario ASR-07 refinado............................................................................... 86
Tabla 3-11. Escenario ASR-08 refinado............................................................................... 87
Tabla 3-12. Escenario ASR-09 refinado............................................................................... 87
Tabla 3-13. Escenario ASR-10 refinado............................................................................... 87
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-3. Evaluación escenario ASR-05 por medio de ATAM ........................................ 182
Tabla 5-4. Evaluación escenario ASR-09 por medio de ATAM ........................................ 183
Tabla 5-5. Evaluación escenario ASR-10 por medio de ATAM ........................................ 185
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
Exploración Desarrollo
ValidaciónDivulgación
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]
Característica Resumen
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
Característica Resumen
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
Característica Resumen
• 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.
• Ministerio de la Protección Social y el Ministerio de Hacienda y Crédito
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
• Ministerio de la Protección Social y el Ministerio de Hacienda y Crédito
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
• Presentación por
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
• Presentación por
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)
ASR-03 Availability No downtime
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)
ASR-06 Availability No downtime
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)
ASR-15 Availability No downtime
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)
ASR-23 Extensibility Adding new
Components
Un implementador crea una API Web asíncrona del
sistema en menos de 160 horas hombre.
(M, L)
ASR-24 Extensibility Adding new
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.
Tabla 3-5. Escenario ASR-02 refinado
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
Tabla 3-6. Escenario ASR-03 refinado
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.
Atributo de Calidad Availability
Refinamiento del Atributo de Calidad No downtime
Ambiente Operación normal
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
Tabla 3-7. Escenario ASR-04 refinado
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
Ambiente Operación normal
Estímulo El sistema consulta la información del paciente directamente en
una fuente externa.
Respuesta La información del paciente debe retornar encriptada.
Tabla 3-8. Escenario ASR-05 refinado
Escenario #: ASR-05 Ningún cliente o usuario puede utilizar el Sistema sin ser
autorizado.
Atributo de Calidad Security
Refinamiento del Atributo de Calidad Confidentiality
Ambiente Operación normal
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.
Tabla 3-9. Escenario ASR-06 refinado
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.
Atributo de Calidad Availability
Refinamiento del Atributo de Calidad No downtime
Ambiente Operación normal
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.
Tabla 3-10. Escenario ASR-07 refinado
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.
Atributo de Calidad Performance
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
Tabla 3-11. Escenario ASR-08 refinado
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.
Atributo de Calidad Performance
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.
Tabla 3-12. Escenario ASR-09 refinado
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.
Atributo de Calidad Security
Refinamiento del Atributo de Calidad Confidentiality
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.
Tabla 3-13. Escenario ASR-10 refinado
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.
Atributo de Calidad Security
Refinamiento del Atributo de Calidad Integrity
Ambiente Operación Normal
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-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-13. Incrementar las competencias de los componentes
• DA-21. Informe a actores
ASR-04 Security
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.
• 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
• DA-21. Informe a actores
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-06. Monitoreo del sistema
• DA-07. Log de actividades
• DA-08. Gestión de Excepciones
• DA-12. Remoción del servicio
• DA-20. Revocación de acceso
• DA-21. Informe a actores
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.
• 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
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.
• 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
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
• DA-16. Componente de Autenticación y Autorización “Auth
Service”
• DA-17. Limitar el acceso y la exposición
• DA-18. Cifrado de datos
• DA-19. Separación de entidades
• DA-21. Informe a actores
121
ASR-10 Security
En el 100% de los casos, los datos de las solicitudes de
Triage enviados al sistema no deben ser alterados por
terceros no autorizados.
• DA-14. Implementación de un Application Delivery Service
• DA-15. Verificación de la integridad de los mensajes
• DA-16. Componente de Autenticación y Autorización “Auth
Service”
• DA-17. Limitar el acceso y la exposición
• DA-18. Cifrado de datos
• DA-19. Separación de entidades
• DA-20. Revocación de acceso
• DA-21. Informe a actores
ASR-11 Security
En el 100% de los casos, los datos de los pacientes
consultados en sistemas terceros deben ser de sólo lectura.
• DA-16. Componente de Autenticación y Autorización “Auth
Service”
• DA-17. Limitar el acceso y la exposición
• DA-19. Separación de entidades
• DA-20. Revocación de acceso
• DA-21. Informe a actores
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-06. Monitoreo del sistema
• DA-07. Log de actividades
• DA-08. Gestión de Excepciones
• DA-12. Remoción del servicio
• DA-16. Componente de Autenticación y Autorización “Auth
Service”
• DA-17. Limitar el acceso y la exposición
• DA-18. Cifrado de datos
• DA-19. Separación de entidades
• DA-20. Revocación de acceso
• DA-21. Informe a actores
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.
• DA-06. Monitoreo del sistema
• DA-07. Log de actividades
• DA-08. Gestión de Excepciones
• DA-21. Informe a actores
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.
• 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-17 Security
Todas las comunicaciones dentro del sistema (100%)
deben estar encriptadas a nivel de protocolo en cualquier
modo de operación.
• DA-18. Cifrado de datos
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
modificaciones al código fuente del sistema.
• 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
• DA-22: División en módulos
123
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.
• DA-23: Incremento de la cohesión semántica
• DA-24: Encapsulamiento
• DA-25: Uso de intermediarios
• DA-26: Restricción de dependencias
ASR-20 Modificability
Se requiere implementar una nueva escala de clasificación.
Un implementador debe poder realizar el cambio en menos
de 160 horas hombre.
• 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-21 Modificability
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.
• DA-24: Encapsulamiento
• DA-25: Uso de intermediarios
ASR-22 Extensibility
Un implementador crea una API Web sincronizada del
sistema en menos de 160 horas hombre.
• 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-23 Extensibility
Un implementador crea una API Web asíncrona del
sistema en menos de 160 horas hombre.
• 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-24 Extensibility
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.
• DA-22: División en módulos
• DA-23: Incremento de la cohesión semántica
• DA-24: Encapsulamiento
124
• DA-25: Uso de intermediarios
• DA-26: Restricción de dependencias
ASR-25 Security
El sistema debe trazar el 100% de las solicitudes
realizadas, junto con sus correspondientes respuestas.
• DA-07. Log de actividades
• DA-08. Gestión de Excepciones
ASR-26 Availability
Todos los componentes del sistema deben proporcionar un
servicio por medio del cual puedan ser monitoreados.
• DA-06. Monitoreo del sistema
• DA-07. Log de actividades
• DA-08. Gestión de Excepciones
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
Descripción de la Vista
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
Representación de la Vista
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
Catálogo de Elementos
La Tabla 4-5 muestra los elementos presentes en esta vista, mientras que la Tabla 4-6
muestra las relaciones entre estos elementos.
Tabla 4-5. Elementos de la vista general de módulos
Elemento Nombre Descripción
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
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.
Paquete o Módulo 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.
Paquete o Módulo 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-6. Relaciones entre los elementos de la vista general de módulos
Elemento Relacionado con Tipo de relación
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
Representación de la Vista
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
Catálogo de Elementos
La Tabla 4-7 muestra los elementos presentes en esta vista, mientras que la Tabla 4-8
muestra las relaciones entre estos elementos.
Tabla 4-7. Elementos de la vista de módulos del Hospital Emergency Classifier
Elemento Nombre Descripción
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.
Paquete o Módulo 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.
Paquete o Módulo 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.
Paquete o Módulo 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-8. Relaciones entre los elementos de la vista de módulos del HEC
Elemento Relacionado con Tipo de relación
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
Representación de la Vista
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
Catálogo de Elementos
La Tabla 4-9 muestra los elementos presentes en esta vista, mientras que la Tabla 4-10
muestra las relaciones entre estos elementos.
Tabla 4-9. Elementos de la vista de módulos del Coordinator Service
Elemento Nombre Descripción
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.
Paquete o Módulo Triage Service
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 Transactional Service
Módulo encargado de la persistencia del sistema.
Tabla 4-10. Relaciones entre los elementos de la vista de módulos del Coordinator
Elemento Relacionado con Tipo de relación
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
Representación de la Vista
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
Catálogo de Elementos
La Tabla 4-11 muestra los elementos presentes en esta vista, mientras que la Tabla 4-12
muestra las relaciones entre estos elementos.
Tabla 4-11. Elementos de la vista de módulos del Triage Service
Elemento Nombre Descripción
Paquete o Módulo Triage Service
Módulo que aplica el método o algoritmo de Triage
a la petición realizada, según la anamnesis del
paciente.
Capa Interface
Capa donde se exponen las interfaces o servicios que
puede suministrar el Triage Service.
Paquete o Módulo Triage Interface Services
Módulo que expone las interfaces o servicios del
Triage Service.
Paquete o Módulo Triage Interface DTO
Módulo que define los objetos de transferencia de
datos en el Triage Service.
136
Capa Business Logic
Capa donde se implementan los elementos que
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
Módulo que define los objetos de negocio utilizados
por el Triage 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 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
comunicarse con otros módulos o sistemas.
Paquete o Módulo Transactional Service
Módulo encargado de la persistencia del sistema.
Paquete o Módulo Response Service
Módulo encargado de consultar las respuestas
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
Elemento Relacionado con Tipo de relación
Response Service Triage Service Uso
Triage Interface Services Triage Interface DTO Uso
Interface Business Logic Permitido para Uso
Triage Business Logic Triage Business Objects Uso
Business Logic Integration Permitido para Uso
Triage Integration Services Triage Integration Objects Uso
Triage Integration Services Transactional Service Uso
137
VP-06. Vista de módulos – EHR Service
Representación de la Vista
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
Catálogo de Elementos
La Tabla 4-13 muestra los elementos presentes en esta vista, mientras que la Tabla 4-14
muestra las relaciones entre estos elementos.
Tabla 4-13. Elementos de la vista de módulos del EHR Service
Elemento Nombre Descripción
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.
138
Capa Interface
Capa donde se exponen las interfaces o servicios que
puede suministrar el EHR Service.
Paquete o Módulo EHR Interface Services
Módulo que expone las interfaces o servicios del
EHR Service.
Paquete o Módulo EHR Interface DTO
Módulo que define los objetos de transferencia de
datos en el EHR Service.
Capa Business Logic
Capa donde se implementan los elementos que
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
Módulo que define los objetos de negocio utilizados
por el EHR Service.
Capa Integration
Capa donde es realizada la integración con otros
servicios a través de sus interfaces. Ejemplo: Interfaz
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
Módulo que define los objetos de integración de
datos utilizados por el EHR Service para
comunicarse con otros módulos o sistemas.
139
Paquete o Módulo Transactional Service
Módulo encargado de la persistencia del sistema.
Paquete o Módulo 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.
Paquete o Módulo 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.
Paquete o Módulo Response Service
Módulo encargado de consultar las respuestas
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
Elemento Relacionado con Tipo de relación
Response Service EHR Service Uso
EHR Interface Services EHR Interface DTO Uso
Interface Business Logic Permitido para Uso
EHR Business Logic EHR Business Objects Uso
Business Logic Integration Permitido para 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
Triage Integration Services Transactional Service Uso
140
VP-07. Vista de módulos – Inference Engine
Representación de la Vista
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
Catálogo de Elementos
La Tabla 4-15 muestra los elementos presentes en esta vista, mientras que la Tabla 4-16
muestra las relaciones entre estos elementos.
Tabla 4-15. Elementos de la vista de módulos del Inference Engine
Elemento Nombre Descripción
Paquete o Módulo Inference Engine
Módulo principal del CDSS (motor de inferencia).
Capa Interface
Capa donde se exponen las interfaces o servicios que
puede suministrar el Inference Engine.
Paquete o Módulo Inference Interface Services
Módulo que expone las interfaces o servicios del
Inference Engine.
Paquete o Módulo Inference Interface DTO
Módulo que define los objetos de transferencia de
datos en el Inference Engine.
Capa Business Logic
Capa donde se implementan los elementos que
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
Módulo que define los objetos de negocio utilizados
por el Inference Engine.
Capa Integration
Capa donde es realizada la integración con otros
servicios a través de sus interfaces. Ejemplo: Interfaz
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
Módulo que define los objetos de integración de
datos utilizados por el Inference Engine para
comunicarse con otros módulos o sistemas.
Paquete o Módulo Transactional Service
Módulo encargado de la persistencia del sistema.
Paquete o Módulo 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.
Paquete o Módulo Response Service
Módulo encargado de consultar las respuestas
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
Elemento Relacionado con Tipo de relación
Response Service Inference Engine Uso
Inference Interface Services Inference Interface DTO Uso
Interface Business Logic Permitido para Uso
Inference Business Logic Inference Business Objects Uso
Business Logic Integration Permitido para 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
Triage Integration Services Transactional Service Uso
5.2.2.3. Vista de Desarrollo
Descripción de la Vista
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)
Representación de la Vista
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.
Catálogo de Elementos
La Tabla 4-17 muestra los elementos presentes en esta vista, mientras que la Tabla 4-18
muestra las relaciones entre estos elementos.
Tabla 4-17. Elementos de la vista general de C&C
Elemento Nombre Descripción
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
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.
Componente 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.
Componente 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.
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
Elemento Relacionado con Tipo de relación
Hospital Emergency Classifier
(HEC)
Electronic Health Record (EHR)
System
Conector Call
Interface EHRService
Hospital Emergency Classifier
(HEC) Hospital Information System (HIS)
Conector Call
Interface HISService
Hospital Emergency Classifier
(HEC) External Knowledge Repository
Conector Call
Interface ExtKnowledgeService
VP-09. Vista de C&C – Hospital Emergency Classifier
Representación de la Vista
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
Catálogo de Elementos
La Tabla 4-19 muestra los elementos presentes en esta vista, mientras que la Tabla 4-20
muestra las relaciones entre estos elementos.
Tabla 4-19. Elementos de la vista de C&C del HEC
Elemento Nombre Descripción
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
Cola persistente a la cual se encuentra suscrito el
TriageService para la aplicación del método de
Triage.
Componente TriageService
Componente encargado de tomar las peticiones
despachadas por el Process Coordinator y aplicar el
método o algoritmo de Triage. Ver sección 4.2.1.1.
Componente InferenceQueue
Cola persistente a la cual se encuentra suscrito el
motor de inferencias (InferenceEngine) para la
aplicación de la lógica de alertas y recomendaciones.
148
Componente InferenceEngine
Componente encargado de tomar las peticiones
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
Cola persistente a la cual se encuentra suscrito el
servicio de consulta de historias clínicas de
pacientes.
Componente EHRService
Componente encargado de tomar las peticiones
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
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.
Componente 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.
149
Componente 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.
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).
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 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
Interface utilizada para escribir en la cola
TriageQueue.
Interface TriageQueueReadService
Interface utilizada para leer de la cola TriageQueue.
Interface InferenceQueueWriteService
Interface utilizada para escribir en la cola
InferenceQueue.
Interface InferenceQueueReadService
Interface utilizada para leer de la cola
InferenceQueue.
150
Interface EHRQueueWriteService
Interface utilizada para escribir en la cola
EHRQueue.
Interface EHRQueueReadService
Interface utilizada para leer de la cola EHRQueue.
Interface ResponseQueueWriteService
Interface utilizada para escribir en la cola
ResponseQueue.
Interface ResponseQueueReadService
Interface utilizada para leer de la cola
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
Elemento Relacionado con Tipo de relación
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
Interface TriageQueueWriteService
CoordinatorService InferenceQueue
Conector Write
Interface TriageQueueWriteService
CoordinatorService EHRQueue
Conector Write
Interface TriageQueueWriteService
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
Interface ResponseQueueWriteService
InferenceEngine ResponseQueue
Conector Write
Interface ResponseQueueWriteService
EHRService ResponseQueue
Conector Write
Interface ResponseQueueWriteService
RegisterService TransactionalService
Conector Call
Interface TransactionalServices
CoordinatorService TransactionalService
Conector Call
Interface TransactionalServices
TriageService TransactionalService
Conector Call
Interface TransactionalServices
InferenceEngine TransactionalService
Conector Call
Interface TransactionalServices
EHRService TransactionalService
Conector Call
Interface TransactionalServices
TransactionalService TransactionalDB
Asociación
ResponseService ResponseQueue
Conector Read
Interface ResponseQueueReadService
152
Hospital Emergency
Classifier (HEC)
Electronic Health Record
(EHR) System
Conector Call
Interface EHRService
Hospital Emergency
Classifier (HEC)
Hospital Information
System (HIS)
Conector Call
Interface HISService
Hospital Emergency
Classifier (HEC)
External Knowledge
Repository
Conector Call
Interface ExtKnowledgeService
5.2.2.4. Vista de Procesos
Descripción de la Vista
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
Representación de la Vista
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.
Catálogo de Elementos
La Tabla 4-21 muestra los elementos presentes en esta vista, mientras que la Tabla 4-22
muestra las relaciones entre estos elementos.
Tabla 4-21. Elementos de la vista de procesos – Registro de una petición
Elemento Nombre Descripció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
Componente que expone las interfaces o servicios
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
Elemento Relacionado con Tipo de relación
User RegisterInterfaceService
Mensaje Sincronizado:
1: registerHECRequest
RegisterInterfaceService RegisterBusinessService
Mensaje Sincronizado:
1.1: createHECRequest
RegisterBusinessService RegisterIntegrationService
Mensaje Sincronizado:
1.1.1: saveHECRequest
RegisterIntegrationService TransactionalInterfaceService
Mensaje Sincronizado:
1.1.1.1: insertHECRequest
RegisterBusinessService QueueWriter
Mensaje Sincronizado:
1.1.1.2: writeQueue
RegisterBusinessService CoordinatorQueue
Mensaje Sincronizado:
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
Representación de la Vista
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.
Catálogo de Elementos
La Tabla 4-23 muestra los elementos presentes en esta vista, mientras que la Tabla 4-24
muestra las relaciones entre estos elementos.
Tabla 4-23. Elementos de la vista de procesos – Despacho de una petición
Elemento Nombre Descripció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
Componente que expone las interfaces o servicios
del CoordinatorService. Es el punto de entrada del
componente principal.
Línea de Vida CoordinatorBusinessService
Componente donde se implementan los elementos
que resuelven la lógica de negocios del
CoordinatorService. Ejemplo: Despachar las
peticiones según disponibilidad de los componentes.
Línea de Vida CoordinatorIntegrationService
Componente que realiza las integraciones del
CoordinatorService con otros módulos o sistemas, a
través de interfaces.
Línea de Vida TransactionalInterfaceService
Componente que expone las interfaces o servicios
del TransactionalService para efectos de persistencia
de las peticiones.
157
Linea de Vida QueueWriter
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
Elemento Relacionado con Tipo de relación
CoordinatorQueueReader CoordinatorQueue
Mensaje Sincronizado:
1: read
CoordinatorQueueReader CoordinatorInterfaceService
Mensaje Sincronizado:
2: processHECRequest
CoordinatorInterfaceService CoordinatorBusinessService
Mensaje Sincronizado:
2.1: routeHECRequest
CoordinatorBusinessService CoordinatorBusinessService
Mensaje Sincronizado:
2.1.1: setRoutingMap
CoordinatorBusinessService CoordinatorIntegrationService
Mensaje Sincronizado:
2.1.2: createTriageRequest
CoordinatorIntegrationService TransactionalInterfaceService
Mensaje Sincronizado:
2.1.2.1: insertTriageRequest
CoordinatorBusinessService CoordinatorIntegrationService
Mensaje Sincronizado:
2.1.3: dispatchTriageRequest
CoordinatorIntegrationService QueueWriter
Mensaje Sincronizado:
2.1.3.1: writeQueue
158
QueueWriter TriageQueue
Mensaje Sincronizado:
2.1.3.1.1: write
CoordinatorBusinessService CoordinatorIntegrationService
Mensaje Sincronizado:
2.1.4: createEHRRequest
CoordinatorIntegrationService TransactionalInterfaceService
Mensaje Sincronizado:
2.1.4.1: insertEHRRequest
CoordinatorBusinessService CoordinatorIntegrationService
Mensaje Sincronizado:
2.1.5: dispatchEHRRequest
CoordinatorIntegrationService QueueWriter
Mensaje Sincronizado:
2.1.5.1: writeQueue
QueueWriter EHRQueue
Mensaje Sincronizado:
2.1.5.1.1: write
CoordinatorBusinessService CoordinatorIntegrationService
Mensaje Sincronizado:
2.1.6: createInferenceRequest
CoordinatorIntegrationService TransactionalInterfaceService
Mensaje Sincronizado:
2.1.6.1: insertInferenceRequest
CoordinatorBusinessService CoordinatorIntegrationService
Mensaje Sincronizado:
2.1.7: dispatchInferenceRequest
CoordinatorIntegrationService QueueWriter
Mensaje Sincronizado:
2.1.7.1: writeQueue
QueueWriter InferenceQueue
Mensaje Sincronizado:
2.1.7.1.1: write
CoordinatorBusinessService CoordinatorIntegrationService
Mensaje Sincronizado:
2.1.8: updateHECRequest
CoordinatorIntegrationService TransactionalInterfaceService
Mensaje Sincronizado:
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
Representación de la Vista
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”.
Catálogo de Elementos
La Tabla 4-25 muestra los elementos presentes en esta vista, mientras que la Tabla 4-26
muestra las relaciones entre estos elementos.
Tabla 4-25. Elementos de la vista de procesos – Aplicación de Triage
Elemento Nombre Descripción
Línea de Vida TriageQueue
Cola de entrada de peticiones del TriageService.
Linea de Vida TriageQueueReader
Componente que lee los mensajes de la cola de
entrada del TriageService. Actúa como un
consumidor en el patrón de diseño TaskQueue.
Línea de Vida TriageInterfaceService
Componente que expone las interfaces o servicios
del TriageService. Es el punto de entrada del
componente.
Línea de Vida TriageBusinessService
Componente donde se implementan los elementos
que resuelven la lógica de negocios del
TriageService. Ejemplo: Aplicar el algoritmo de
Triage.
Línea de Vida TriageIntegrationService
Componente que realiza las integraciones del
TriageService con otros módulos o sistemas, a través
de interfaces.
Línea de Vida TransactionalInterfaceService
Componente que expone las interfaces o servicios
del TransactionalService para efectos de persistencia
de las peticiones.
Linea de Vida QueueWriter
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
Elemento Relacionado con Tipo de relación
TriageQueueReader TriageQueue
Mensaje Sincronizado:
1: read
TriageQueueReader TriageInterfaceService
Mensaje Sincronizado:
2: processRequest
TriageInterfaceService TriageBusinessService
Mensaje Sincronizado:
2.1: triageProcess
TriageBusinessService TriageBusinessService
Mensaje Sincronizado:
2.1.1: triageEvaluation
TriageBusinessService TriageIntegrationService
Mensaje Sincronizado:
2.1.2: registerTriageEvaluation
TriageIntegrationService TransactionalInterfaceService
Mensaje Sincronizado:
2.1.2.1: insertTriageEvaluation
TriageBusinessService TriageIntegrationService
Mensaje Sincronizado:
2.1.3: notifyTriageEvaluation
TriageIntegrationService QueueWriter
Mensaje Sincronizado:
2.1.3.1: writeQueue
QueueWriter ResponseQueue
Mensaje Sincronizado:
2.1.3.1.1: write
TriageBusinessService TriageIntegrationService
Mensaje Sincronizado:
2.1.4: updateTriageRequest
TriageIntegrationService TransactionalInterfaceService
Mensaje Sincronizado:
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
Representación de la Vista
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.
Catálogo de Elementos
La Tabla 4-27 muestra los elementos presentes en esta vista, mientras que la Tabla 4-28
muestra las relaciones entre estos elementos.
Tabla 4-27. Elementos de la vista de procesos – Consulta de EHR
Elemento Nombre Descripción
Línea de Vida EHRQueue
Cola de entrada de peticiones del EHRService.
Linea de Vida EHRQueueReader
Componente que lee los mensajes de la cola de
entrada del EHRService. Actúa como un consumidor
en el patrón de diseño TaskQueue.
Línea de Vida EHRInterfaceService
Componente que expone las interfaces o servicios
del EHRService. Es el punto de entrada del
componente.
Línea de Vida EHRBusinessService
Componente donde se implementan los elementos
que resuelven la lógica de negocios del EHRService.
Ejemplo: Procesar la EHR del paciente.
Línea de Vida EHRIntegrationService
Componente que realiza las integraciones del
EHRService con otros módulos o sistemas, a través
de interfaces.
Línea de Vida TransactionalInterfaceService
Componente que expone las interfaces o servicios
del TransactionalService para efectos de persistencia
de las peticiones.
Linea de Vida QueueWriter
Componente que escribe mensajes en la cola de
164
entrada de datos del componente
“ResponseService”.
Línea de Vida ResponseQueue
Cola de entrada de datos del ResponseService, en la
cual se escribe el mensaje correspondiente a la
respuesta generada.
Línea de Vida 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.
Línea de Vida 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.
Tabla 4-28. Relaciones entre los elementos – Consulta de EHR
Elemento Relacionado con Tipo de relación
EHRQueueReader EHRQueue
Mensaje Sincronizado:
1: read
EHRQueueReader EHRInterfaceService
Mensaje Sincronizado:
2: processRequest
EHRInterfaceService EHRBusinessService
Mensaje Sincronizado:
2.1: processEHR
EHRBusinessService EHRIntegrationService
Mensaje Sincronizado:
2.1.1: getPatientEHR
EHRIntegrationService Electronic Health Record (EHR)
System
Mensaje Sincronizado:
2.1.1.1: getPatientEHR
EHRIntegrationService Hospital Information System (HIS)
Mensaje Sincronizado:
2.1.1.2: getPatientEHR
EHRBusinessService EHRBusinessService
Mensaje Sincronizado:
2.1.2: processPatientEHR
EHRBusinessService EHRIntegrationService
Mensaje Sincronizado:
165
2.1.3: registerEHRResult
EHRIntegrationService TransactionalInterfaceService
Mensaje Sincronizado:
2.1.3.1: insertEHRResult
EHRBusinessService EHRIntegrationService
Mensaje Sincronizado:
2.1.4: notifyEHRResult
EHRIntegrationService QueueWriter
Mensaje Sincronizado:
2.1.4.1: writeQueue
QueueWriter ResponseQueue
Mensaje Sincronizado:
2.1.4.1.1: write
EHRBusinessService EHRIntegrationService
Mensaje Sincronizado:
2.1.5: updateEHRRequest
EHRIntegrationService TransactionalInterfaceService
Mensaje Sincronizado:
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
Representación de la Vista
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.
Catálogo de Elementos
La Tabla 4-29 muestra los elementos presentes en esta vista, mientras que la Tabla 4-30
muestra las relaciones entre estos elementos.
Tabla 4-29. Elementos de la vista de procesos – Generación de Inferencias
Elemento Nombre Descripción
Línea de Vida InferenceQueue
Cola de entrada de peticiones del InferenceEngine.
Linea de Vida InferenceQueueReader
Componente que lee los mensajes de la cola de
entrada del InferenceEngine. Actúa como un
consumidor en el patrón de diseño TaskQueue.
Línea de Vida InferenceInterfaceService
Componente que expone las interfaces o servicios
del InferenceEngine. Es el punto de entrada del
componente.
Línea de Vida InferenceBusinessService
Componente donde se implementan los elementos
que resuelven la lógica de negocios del
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
Componente que realiza las integraciones del
InferenceEngine con otros módulos o sistemas, a
través de interfaces.
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
Línea de Vida TransactionalInterfaceService
Componente que expone las interfaces o servicios
del TransactionalService para efectos de persistencia
de las peticiones.
Linea de Vida QueueWriter
Componente que escribe mensajes en la cola de
entrada de datos del componente
“ResponseService”.
Línea de Vida ResponseQueue
Cola de entrada de datos del ResponseService, en la
cual se escribe el mensaje correspondiente a la
respuesta generada.
Línea de Vida 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, entre otros.
Tabla 4-30. Relaciones entre los elementos – Generación de Inferencias
Elemento Relacionado con Tipo de relación
InferenceQueueReader InferenceQueue
Mensaje Sincronizado:
1: read
InferenceQueueReader InferenceInterfaceService
Mensaje Sincronizado:
2: processRequest
InferenceInterfaceService InferenceBusinessService
Mensaje Sincronizado:
2.1: processInference
InferenceBusinessService InferenceIntegrationService
Mensaje Sincronizado:
2.1.1: getKnowledge
InferenceIntegrationService KnowledgeDB
Mensaje Sincronizado:
2.1.1.1: getKnowledge
InferenceIntegrationService External Knowledge Repository
Mensaje Sincronizado:
2.1.1.2: getKnowledge
InferenceBusinessService InferenceBusinessService
Mensaje Sincronizado:
2.1.2: applyInferenceRules
169
InferenceBusinessService InferenceIntegrationService
Mensaje Sincronizado:
2.1.3: registerInferenceResult
InferenceIntegrationService TransactionalInterfaceService
Mensaje Sincronizado:
2.1.3.1: insertInferenceResult
InferenceBusinessService InferenceIntegrationService
Mensaje Sincronizado:
2.1.4: notifyInferenceResult
InferenceIntegrationService QueueWriter
Mensaje Sincronizado:
2.1.4.1: writeQueue
QueueWriter ResponseQueue
Mensaje Sincronizado:
2.1.4.1.1: write
InferenceBusinessService InferenceIntegrationService
Mensaje Sincronizado:
2.1.5: updateInferenceRequest
InferenceIntegrationService TransactionalInterfaceService
Mensaje Sincronizado:
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
Representación de la Vista
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).
Catálogo de Elementos
La Tabla 4-31 muestra los elementos presentes en esta vista, mientras que la Tabla 4-32
muestra las relaciones entre estos elementos.
Tabla 4-31. Elementos de la vista de procesos – Notificación de Resultados
Elemento Nombre Descripción
Línea de Vida ResponseQueue
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
Componente que expone las interfaces o servicios
del ResponseService. Es el punto de entrada del
componente.
Línea de Vida ResponseBusinessService
Componente donde se implementan los elementos
que resuelven la lógica de negocios del
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
Componente que realiza las integraciones del
ResponseService con otros módulos o sistemas, a
través de interfaces.
Línea de Vida TransactionalInterfaceService
Componente que expone las interfaces o servicios
172
del TransactionalService para efectos de persistencia
de las peticiones.
Linea de Vida QueueWriter
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
Elemento Relacionado con Tipo de relación
ResponseQueueReader ResponseQueue
Mensaje Sincronizado:
1: read
ResponseQueueReader ResponseInterfaceService
Mensaje Sincronizado:
2: processRequest
ResponseInterfaceService ResponseBusinessService
Mensaje Sincronizado:
2.1: notifyResult
ResponseBusinessService ResponseIntegrationService
Mensaje Sincronizado:
2.1.1: getResult
ResponseIntegrationService TransactionalInterfaceService
Mensaje Sincronizado:
2.1.1.1: getResult
ResponseBusinessService ResponseBusinessService
Mensaje Sincronizado:
2.1.2: processResult
ResponseBusinessService ResponseIntegrationService
Mensaje Sincronizado:
2.1.3: notifyResult
ResponseIntegrationService QueueWriter
Mensaje Sincronizado:
2.1.3.1: writeQueue
QueueWriter ClientNotificationQueue
Mensaje Sincronizado:
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
Descripción de la Vista
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
Representación de la Vista
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
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
Ambiente Operación normal
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.
Tabla 5-3. Evaluación escenario ASR-05 por medio de ATAM
Escenario #: ASR-05 Ningún cliente o usuario puede utilizar el Sistema sin ser
autorizado.
Atributo de Calidad Security
Refinamiento del Atributo de Calidad Confidentiality
Ambiente Operación normal
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.
Decisiones Arquitecturales Sensibilidad Tradeoff Riesgo No Riesgo
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.
Diagrama arquitectural
En la Figura 4-30 se puede observar cómo las peticiones del
cliente pasan siempre por el componente “AuthService”.
Análisis de Resultados
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.
Tabla 5-4. Evaluación escenario ASR-09 por medio de ATAM
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.
Atributo de Calidad Security
Refinamiento del Atributo de Calidad Confidentiality
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.
Decisiones Arquitecturales Sensibilidad Tradeoff Riesgo No Riesgo
DA-14. Implementación de un Application
Delivery Service T6 NR6
DA-15. Verificación de la integridad de
los mensajes T1 NR1
DA-16. Componente de Autenticación y
Autorización “Auth Service” S2 T3, T4 R1 NR3, NR4
DA-17. Limitar el acceso y la exposición S5 R3 NR6, NR7
DA-18. Cifrado de datos S1 T2 NR2
DA-19. Separación de entidades S6 T6 R4 NR8
DA-21. Informe a actores S4 NR5
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.
• 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.
• 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
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.
• 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.
• 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.
• T4. 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.
• S5. 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.
• NR6. Los servidores web cada vez están más preparados en términos de seguridad a nivel de
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.
• 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.
Diagrama arquitectural
• 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.
Análisis de Resultados
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. 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.
Tabla 5-5. Evaluación escenario ASR-10 por medio de ATAM
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.
Atributo de Calidad Security
Refinamiento del Atributo de Calidad Integrity
Ambiente Operación Normal
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.
Decisiones Arquitecturales Sensibilidad Tradeoff Riesgo No Riesgo
DA-14. Implementación de un Application
Delivery Service T6 NR6
DA-15. Verificación de la integridad de
los mensajes T1 NR1
DA-16. Componente de Autenticación y
Autorización “Auth Service” S2 T3, T4 R1 NR3, NR4
DA-17. Limitar el acceso y la exposición S5 R3 NR6, NR7
DA-18. Cifrado de datos S1 T2 NR2
DA-19. Separación de entidades S6 T6 R4 NR8
186
DA-20. Revocación de acceso S3 T5 R2
DA-21. Informe a actores S4 NR5
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.
• 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.
• 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
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.
• 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.
• 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.
• T4. 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.
• S5. 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.
• NR6. Los servidores web cada vez están más preparados en términos de seguridad a nivel de
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.
• 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.
Diagrama arquitectural
• 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.
Análisis de Resultados
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. 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
5.2.2.3. Evaluación del escenario ASR-06
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.
5.2.2.4. Evaluación del escenario ASR-07
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
Tabla 5-8. Casos de Prueba implementados para ASR-07
No. de
Caso Descripción No. Hilos
Tiempo de
Distribución
(seg.)
No. Peticiones
por Hilo
CASO 1
100 clientes diferentes envían 10
peticiones al mismo tiempo.
100 0 10
CASO 2
1.000 clientes diferentes envían 1
petición al mismo tiempo.
1.000 0 1
CASO 3
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
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
deseado Min (s) Max (s) Promedio (s)
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.
5.2.2.5. Evaluación del escenario ASR-08
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
Tabla 5-11. Casos de Prueba implementados para ASR-08
No. de
Caso Descripción No. Hilos
Tiempo de
Distribución
(seg.)
No. Peticiones
por Hilo
CASO 1
100 clientes diferentes envían 20
peticiones al mismo tiempo.
100 0 20
CASO 2
2.000 clientes diferentes envían 1
petición al mismo tiempo.
2.000 0 1
CASO 3
40 clientes diferentes envían 1.500
peticiones distribuidas en un lapso de 20
segundos. Se espera enviar
aproximadamente 3.000 peticiones por
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
deseado Min (s) Max (s) Promedio (s)
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/.
[Accessed: 15-Dec-2016].
[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/.
[Accessed: 03-Dec-2017].
229
[118] “Amazon RDS SLA.” [Online]. Available: https://aws.amazon.com/rds/sla/.
[Accessed: 03-Dec-2017].
[119] “Amazon Simple Queue Service (SQS) | Message Queuing for Messaging
Applications | AWS.” [Online]. Available: https://aws.amazon.com/sqs. [Accessed:
28-Nov-2017].