asesor: iván mauricio cabezas troyano, doctor (phd) en...
TRANSCRIPT
1
Diseño de una arquitectura que soporte la interoperabilidad de la historia clínica
electrónica de pacientes en situaciones de emergencia
Luis Bernardo Villa Benavides, [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
2017
2
Citar/How to cite (Villa, Luis, 2017)
Referencia/Reference
Estilo/Style: APA 6th ed. (2010)
Villa, L. (2017). Diseño de una arquitectura que soporte la interopera-
bilidad de la historia clínica electrónica de pacientes en situa-
ciones de emergencia. (Tesis Maestría en Ingeniería de Soft-
ware). Universidad de San Buenaventura Colombia, Facultad
de Ingeniería, Cali.
Maestría en Ingeniería de Software, Cohorte III.
Plantilla adaptada de Bibliotecas Universidad de San Buenaventura
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
3
Dedicatoria
A las personas que más amo:
Mi hijo, mi esposa, mi madre y mi abuelita.
Agradecimientos
Al Profesor Iván Mauricio Cabezas por compartir su experiencia y conocimiento,
guiar, motivar y acompañar mi proyecto de investigación de la maestría.
Al equipo de profesores de la Universidad de San Buenaventura – Cali, por las
recomendaciones y sugerencias realizadas con el fin de mejorar mi proyecto de
investigación.
A la empresa SIO S.A. por facilitar las condiciones para poder adelantar mis estu-
dios de maestría en Ingeniería de Software.
4
TABLA DE CONTENIDO
1. INTRODUCCIÓN ...................................................................................................................... 9
1.1. PLANTEAMIENTO DEL PROBLEMA .............................................................................. 10
1.2. PROPUESTA DE SOLUCIÓN ............................................................................................ 11
1.3. OBJETIVOS ......................................................................................................................... 12
1.3.1. Objetivo General ............................................................................................................... 12
1.3.2. Objetivos Específicos ........................................................................................................ 12
1.4. ALCANCE Y PRODUCTOS ............................................................................................... 12
1.4.1. Productos de nuevo conocimiento ..................................................................................... 12
1.4.2. Resultados y Productos de Divulgación ............................................................................ 13
1.4.3. Impactos esperados ........................................................................................................... 13
2. MARCO TEÓRICO .................................................................................................................. 15
2.1. ARQUITECTURA DE SISTEMAS ..................................................................................... 16
2.2. HISTORIA CLÍNICA ........................................................................................................... 18
2.2.1. Antecedentes ..................................................................................................................... 18
2.2.2. Historia Clínica Electrónica .............................................................................................. 19
2.3. TECNOLOGÍA ASOCIADA A LA SALUD ....................................................................... 20
2.4. INTEROPERABILIDAD DE LOS SISTEMAS DE INFORMACIÓN EN SALUD .......... 23
2.5. ESTÁNDARES DE INTEROPERABILIDAD EN SALUD ................................................ 25
2.6. ARQUITECTURA DE INFORMACIÓN DE LA HISTORIA CLÍNICA PARA LA
ATENCIÓN DE EMERGENCIAS ................................................................................................... 27
2.7. MARCO LEGAL .................................................................................................................. 29
2.7.1. Marco Nacional ................................................................................................................. 29
2.7.2. Marco Internacional .......................................................................................................... 31
2.7.2.1. Ley de Portabilidad ....................................................................................................... 31
2.7.2.2. Directiva 95/46/EC ........................................................................................................ 32
2.7.2.3. Cybersecurity Framework ............................................................................................. 33
2.8. SOSTENIBILIDAD Y EL MANIFIESTO KARLSKRONA ............................................... 33
2.9. DISEÑO CENTRADO EN EL USUARIO DE LA EHR ..................................................... 35
2.9.1. Principios de gestión de la calidad de la Historia Clínica ................................................. 37
2.9.1.1. Eventos de seguridad del paciente................................................................................. 37
2.9.1.2. Diseño centrado en el usuario ....................................................................................... 37
2.10. TRABAJOS RELACIONADOS ....................................................................................... 38
5
3. APORTES DEL PROYECTO Y PROCESO DE INGENIERÍA ............................................. 39
3.1. CONTEXTO DEL PROYECTO .......................................................................................... 40
3.2. CONJUNTO DE MÉTODOS APLICADOS ........................................................................ 41
3.3. DEFINICIÓN DE REQUISITOS DE LA ARQUITECTURA ............................................. 42
3.3.1. Elicitación de requisitos .................................................................................................... 42
3.3.1.1. Requisitos identificados en la literatura ........................................................................ 43
3.3.1.2. Requisitos identificados en la normatividad ................................................................. 44
3.3.1.3. Requisitos identificados a través de entrevistas ............................................................ 44
3.3.2. Drivers de la arquitectura .................................................................................................. 46
3.4. DISEÑO DE LA ARQUITECTURA ................................................................................... 48
3.4.1. Iteración 1 - Health Catalogue Repository Federado ........................................................ 48
3.4.2. Iteración 2 - HCR Sostenible ............................................................................................ 51
3.4.2.1. Método de diseño de arquitectura sostenible................................................................. 51
3.4.2.2. Análisis de la sostenibilidad del HCR Distribuido ........................................................ 55
3.4.2.3. Análisis de la sostenibilidad del HCR Centralizado ...................................................... 56
3.4.3. Iteración 3 - HCR basado en microservicios ..................................................................... 58
3.4.3.1. Análisis de la sostenibilidad del HCR Microservicios .................................................. 62
3.5. VISTAS DE LA ARQUITECTURA .................................................................................... 64
3.5.1. VISTA DE DESPLIEGUE ................................................................................................ 64
3.5.1.1. Presentación Principal ................................................................................................... 64
3.5.1.2. Catálogo de elementos .................................................................................................. 65
3.5.1.3. Guía de variabilidad ...................................................................................................... 66
3.5.2. VISTA LÓGICA ............................................................................................................... 67
3.5.2.1. Presentación Principal ................................................................................................... 67
3.5.2.2. Catálogo de Elementos .................................................................................................. 68
3.5.2.3. Guía de variabilidad ...................................................................................................... 68
3.5.3. VISTA DE PROCESOS.................................................................................................... 68
3.5.3.1. Diagrama de Actividades .............................................................................................. 68
3.5.3.1.1. Catálogo de Elementos .................................................................................................. 69
3.5.3.2. Diagrama de estados - Circuit Breaker .......................................................................... 70
3.5.3.2.1. Presentación Principal ................................................................................................... 71
3.5.3.2.2. Catálogo de Elementos .................................................................................................. 71
3.5.4. Diagrama de secuencia - Circuit Breaker .......................................................................... 72
6
3.5.4.1.1. Catálogo de Elementos .................................................................................................. 73
3.6. VALIDACIÓN DE LA ARQUITECTURA ......................................................................... 74
3.6.1. RESULTADOS DE LA VALIDACIÓN .......................................................................... 74
3.6.2. ANÁLISIS DE LAS DECISIONES DE ARQUITECTURA ........................................... 80
3.6.2.1. Compatibilidad .............................................................................................................. 80
3.6.2.2. Mantenibilidad .............................................................................................................. 81
3.6.2.3. Confiabilidad ................................................................................................................. 82
3.6.2.4. Desempeño .................................................................................................................... 84
3.6.2.5. Seguridad ....................................................................................................................... 86
3.6.2.6. Adaptabilidad ................................................................................................................ 87
3.6.2.7. Usabilidad...................................................................................................................... 88
4. OBSERVACIONES FINALES, CONCLUSIONES Y TRABAJOS FUTUROS .................... 91
4.1. CUMPLIMIENTO DE OBJETIVOS .................................................................................... 92
4.2. CONCLUSIONES ................................................................................................................ 94
4.3. TRABAJOS FUTUROS ....................................................................................................... 95
7
Resumen
En este trabajo se aborda el diseño de una arquitectura de sistema para la interoperabili-
dad de la historia clínica electrónica de pacientes en situaciones de emergencia, en el
contexto del sistema de salud colombiano. Se incorporan los conceptos de banco de re-
gistros de salud, salud como servicio en la nube, microservicios, sostenibilidad e historia
clínica personal. El repositorio del catálogo de salud propuesto, regula el acceso, gestio-
na, almacena y brinda los mecanismos de seguridad para proteger la confidencialidad de
la historia clínica personal regulada. El proceso de diseño logró componentes sostenibles
mediante una adaptación propuesta al método Attribute Driven Design. La validación de la
sostenibilidad se realiza mediante el análisis de los resultados obtenidos con la elabora-
ción de la Matriz de Impactos y Oportunidades. Esta matriz permite al arquitecto analizar
la sostenibilidad de la arquitectura desde cinco dimensiones: ambiental, técnica, social,
individual y económica, así como considerar los impactos y oportunidades a corto, me-
diano y largo plazo. Se analizan y discuten los resultados de la validación de la arquitectu-
ra basado en los escenarios de calidad para establecer el cumplimiento de los requisitos.
Finalmente, se presentan las conclusiones y beneficios esperados con la implementación
de servicios basados en la arquitectura propuesta.
Palabras clave: Historia Clínica Electrónica, Historia Clínica Personal, Arquitectura de
Microservicios, Sostenibilidad, Computación en la nube, eHealth, eHaaS.
Abstract
This project focuses on the design of a system architecture for the interoperability of the
electronic medical records of patients in emergency situations, in the context of the Co-
lombian health system. The architecture incorporates concepts as health record bank,
health as a service, microservices, sustainability and Personal Health Record (PHR).The
health catalog repository is proposed for regulating access, managing, storing and provid-
ing security mechanisms to protect the confidentiality of a regulated PHR. The health cata-
log repository design process achieved sustainable components through an adaptation to
the Attribute Driven Design method. The sustainability validation was done by analyzing
the results obtained by the Impacts and Opportunities Sustainability Matrix. This matrix
allows the architect to analyze the sustainability of the architecture from five dimensions:
environmental, technical, social, individual and economic, as well as contemplate the im-
pacts and opportunities in the short, medium and long term. In this project, validation re-
sults of the architecture are based on the quality scenarios in order to establish the fulfill-
ment of the requirements. Some of the services offered by the health catalog repository
are described and discussed. Finally, the conclusions and expected benefits by the im-
plementation of services for the interoperability of electronic medical records based on the
proposed architecture are presented.
Keywords: Electronic Health Record, Personal Health Record, Microservices Architec-
ture, Sustainability, Cloud Computing, e-Health, eHaaS.
8
GLOSARIO
API: Application Programming Interface - Interfaz Programada de Aplicación.
ARQUETIPOS: Patrones de comportamiento de un sistema.
CDA: Clinical Document Architecture - Arquitectura de Documentos Clínicos.
EPS: Entidades promotoras de salud.
ESB: Enterprise Service Bus - Bus de Servicios Empresariales.
FTP: File Transfer Protocol - Protocolo de Transferencia de Archivos.
HCE: Historia Clínica Electrónica o EHR por sus siglas en inglés.
HIS: Health Information System - Sistemas de Información Hospitalarios.
HL7: Health Level Seven.
HTTP: Hypertext Transfer Protocol - Protocolo de Transferencia de Hipertexto.
IPS: Institución prestadora de Salud.
ISO: International Organization for Standardization - Organización Internacional
para la Estandarización.
RIM: Reference Information Model - Modelo de Referencia de Información.
SOA: Service Oriented Architecture - Arquitectura Orientada a Servicios.
SOAP: Simple Object Access Protocol - Protocolo Simple de Acceso a Objetos.
SGSSC: Sistema General de Salud Social de Colombia.
TI: Tecnologías de la Información.
UML: Unified Modeling Language - Lenguaje Unificado de Modelado.
WS: Web Services - Servicios Web.
XML: eXtensible Markup Language - Lenguaje de Marcas Extensible.
9
1. INTRODUCCIÓN
De acuerdo a lo establecido en la legislación del sistema de seguridad social en
salud de Colombia, los servicios de salud son prestados en distintas Instituciones
Prestadoras de Servicios en Salud (IPS), tales como clínicas, hospitales, laborato-
rios y centros de procedimientos diagnósticos y terapéuticos (MinSalud, 1993).
Para la mayoría de los sistemas, como el bancario o el sistema de salud, la infor-
mación es uno de los bienes más preciados. En la historia clínica se registran los
eventos de la atención de los pacientes. Una historia clínica debe cumplir con las
siguientes características esenciales: disponibilidad, integridad y oportunidad
(MinSalud, 1995).
Disponibilidad: hace referencia a la posibilidad de acceder a los registros
médicos de las personas.
Integridad: hace alusión a poder disponer tanto de la información de la
atención clínica, como de los datos relacionados con aspectos sociales y
psicológicos de los pacientes, que son requeridos para la atención médica,
el diagnóstico y tratamiento de las enfermedades.
Oportunidad: es la facilidad de acceso a la información clínica de las perso-
nas en el momento preciso en que esta se requiera.
Alcanzar estas características implica un desafío por la complejidad y sensibilidad
de los datos, los riesgos de seguridad y la fragilidad del derecho a la privacidad,
en casos de pacientes con diagnóstico de VIH, cáncer u otra enfermedad terminal,
los casos relacionados con alguna condición de salud mental, las pruebas de pa-
ternidad o las interrupciones del embarazo.
10
1.1. PLANTEAMIENTO DEL PROBLEMA
Es común que un mismo paciente sea atendido por diferentes IPS, ocasionando
que la historia clínica de los pacientes quede fragmentada. El fraccionamiento va
en contravía con las características que debe cumplir la historia clínica, dado que
no permite asegurar la integralidad, ni la secuencialidad de la información, de
acuerdo a los eventos registrados en las atenciones médicas realizadas al pacien-
te en cada IPS. El fraccionamiento también atenta contra la claridad de la informa-
ción que debe brindar la Historia Clínica para el diagnóstico de las patologías o
para la definición de las conductas en la atención médica.
Más aún, el incumplimiento de estas características se torna más grave, cuando el
paciente se encuentra en situaciones de emergencia, donde, por ejemplo, la opor-
tunidad adquiere más relevancia dado que las condiciones de infraestructura,
tiempo y espacio para la prestación de los servicios son limitadas y requieren de
soluciones eficaces que permitan acceder a la información médica relevante y vital
para la toma de decisiones en la atención.
El problema que se aborda en el presente trabajo es la carencia de mecanismos
de interoperabilidad que permitan un acceso oportuno a la historia clínica electró-
nica de los pacientes atendidos en situaciones de emergencia. Entonces la pre-
gunta a resolver es ¿Cómo lograr que la historia clínica electrónica esté disponible
cuando los pacientes son atendidos en situaciones de emergencia? El plantea-
miento del problema se describe gráficamente en la Figura 1.
Figura 1. Planteamiento del problema
11
1.2. PROPUESTA DE SOLUCIÓN
Para enfrentar los problemas de disponibilidad, fraccionamiento y oportunidad en
el acceso a la información de la historia clínica de los pacientes, es necesaria la
implementación de una arquitectura de sistemas que permitan la interoperabilidad
de la información entre las IPS que componen el sistema general de seguridad
social en salud. Actualmente entre el 30 y el 40 % de los hospitales y clínicas del
país tienen sistematizadas sus historias clínicas. En respuesta a esta necesidad,
el gobierno de Colombia ha impulsado iniciativas orientadas a definir un sistema
de información de salud ajustado a las características y necesidades propias del
país. Para tratar de solucionar los problemas de conectividad en pequeños muni-
cipios y zonas apartadas del territorio Colombiano y también, incentivar la cultura
digital en los profesionales de la salud, para que estén dispuestos a adecuarse a
un mundo digital (MINTIC, 2014)
Un sistema de salud integral interoperable requiere de una arquitectura compuesta
por elementos abiertos, reutilizables y basados en estándares. Además, debe
ofrecer niveles adecuados de seguridad en el acceso a la información, ser escala-
ble y compatible con la infraestructura y los sistemas de información que disponen
las instituciones que conforman el sistema de salud (de Toledo Heras et al., 2005).
La arquitectura debe contemplar escenarios donde se prestan servicios de salud
en condiciones diferentes a las existentes en un ambiente de atención hospitalaria
y existen restricciones en la captura, transmisión y almacenamiento de la informa-
ción inherentes a los equipos electrónicos y medios de comunicación usados en
estos escenarios, tales como la atención de emergencias en transportes medicali-
zados que sirven de ambulancias, la prestación de servicios extramurales y las
campañas rurales para la promoción y prevención de la salud. En el caso de aten-
ción de emergencias, convergen factores externos y condiciones particulares que
ocasionan la falta de disponibilidad y oportunidad de acceso a la información clíni-
ca de los pacientes, en un momento crítico de atención del paciente. En el presen-
te proyecto se define una arquitectura de sistema que permita la interoperabilidad
de la información clínica de las personas, a través de una historia clínica personal
regulada, abordada en el contexto de la atención médica de los pacientes en si-
tuaciones de emergencia.
12
1.3. OBJETIVOS
A continuación se detallan los objetivos propuestos para el proyecto de arquitectu-
ra para la interoperabilidad de la historia clínica de los pacientes en situaciones de
emergencia.
1.3.1. Objetivo General
Diseñar una arquitectura de sistema que soporte la interoperabilidad, entre dife-
rentes centros hospitalarios, de la historia clínica electrónica de pacientes en si-
tuaciones de emergencia, ajustada a las condiciones del Sistema de Salud de Co-
lombia.
1.3.2. Objetivos Específicos
Definir los componentes de la arquitectura del sistema.
Definir una historia clínica electrónica que sea adecuada para la atención de pa-
cientes en situaciones de emergencia.
Validar la arquitectura del sistema.
1.4. ALCANCE Y PRODUCTOS
Al finalizar el proyecto de diseño de la arquitectura se obtuvieron resultados, que
serán de gran importancia para proyectos futuros de implementación basados en
la arquitectura, los cuales se detallan a continuación.
1.4.1. Productos de nuevo conocimiento
Propuesta de arquitectura para la interoperabilidad de la EHR ajustada al marco
de referencia de emergencias médicas.
13
1.4.2. Resultados y Productos de Divulgación
Simposio de Maestrías y Doctorados en el IX Congreso Colombiano de
Computación realizado en la ciudad de Pereira en el año 2014: Se presentó
el proyecto titulado ―Diseño de una Arquitectura que Soporte la Interopera-
bilidad de la Historia Clínica Electrónica de Pacientes en Situaciones de
Emergencia‖.
IEEE HealthCom 2014, realizado en la ciudad de Natal, Brasil: Se publicó el
artículo titulado ―A Review on Usability Features for Designing Electronic
Health Records‖
o DOI: 10.1109/HealthCom.2014.7001812.
Décimo Congreso Colombiano de Computación realizado en la ciudad de
Bogotá, Colombia en el año 2015: Se publicó el artículo titulado ―Electronic
health record as an eHaaS‖
o ISBN:978-1-4673-9463-5
o DOI:10.1109/ColumbianCC.2015.7333471
16th International Conference Computational Science and Its Applications
ICCSA 2016 realizado en Beijing, China: Se publicó el capítulo del libro titu-
lado ―Towards A Sustainable Architectural Design by an Adaptation of the
Architectural Driven Design Method‖, en la serie Lecture Notes in Computer
Science en la edición 9787
o ISBN 978-3-319-42108-7
o DOI: 10.1007/978-3-319-42108-7_6
1.4.3. Impactos esperados
La interoperabilidad permite acceder a la información clínica de los pacientes que
son atendidos en situaciones de emergencia. Al implementar mecanismos de in-
teroperabilidad entre Sistemas de Información en Salud basados en la arquitectura
propuesta en el presente trabajo, se espera impactar sobre diferentes actores del
sistema de salud (los profesionales de la salud, los proveedores de sistemas de
información en salud, las empresas que conforman el sistema, las entidades del
gobierno y a los pacientes).
14
Los impactos más relevantes que se esperan lograr son:
Disponer de la información clínica de los usuarios de manera oportuna en
situaciones de emergencia, permitiendo brindar una atención adecuada.
Contribuir en la selección de marcos de referencia para los sistemas de
EHR.
Dejar abierta la posibilidad de trabajos futuros aplicables.
15
2. MARCO TEÓRICO
En esta sección se describen los conceptos tecnológicos, técnicos y teóricos re-
queridos para la definición de la arquitectura de sistemas de una historia clínica
electrónica que permita la integración e interoperabilidad de los registros médicos
de los pacientes que son atendidos en situaciones de emergencia. Además se
analizan otros proyectos para la interoperabilidad de la EHR, que han sido abor-
dados desde otras perspectivas o aplicados a otros contextos diferentes a la aten-
ción médica de pacientes en situaciones de emergencia.
16
2.1. ARQUITECTURA DE SISTEMAS
La arquitectura de un sistema se define como la estructura o estructuras de los
elementos que componen el sistema, las propiedades e interacciones entre los
componentes y con el medio que lo rodea. Incluye aspectos como la estructura,
los protocolos de comunicación, la sincronización y acceso a datos, la asignación
de funciones para diseñar elementos, la distribución física, y la composición de los
elementos de diseño. Define las reglas de diseño contemplando atributos de cali-
dad y considerando cómo puede cambiar el sistema (Gorton, 2006). Las activida-
des del diseño de una arquitectura, se presentan en la Figura 2.
Figura 2. Actividades del diseño de arquitectura de sistemas. Adaptado de (Gorton, 2006).
Varios autores han propuesto métodos para la definición de requisitos, el diseño y
la evaluación de arquitecturas. Algunas mayormente reconocidas son: (i) Software
Architecture Analysis Method (SAAM) (Kazman, Abowd, Bass, & Clements, 1996),
(ii) Architecture Tradeoff Analysis Method (ATAM) (Kazman, Klein, & Clements,
2000), Architecture-Level Modifiability Analysis (ALMA) (Bengtsson, Lassing,
Bosch, & Van Vliet, 2004) y otros métodos y herramientas propuestos por el SEI
(SEI, 2013). Sin embargo, algunos fueron pensados originalmente para el diseño
de arquitecturas, para evaluar atributos de calidad muy específicos o para arqui-
tecturas a niveles de detalle muy alto.
Para el presente proyecto, se tomará como referencia el método Architecture Dri-
ven Design (ADD) propuesto por el SEI (Wojcik, 2006).En el método ADD los re-
quisitos y atributos de calidad son priorizados por los interesados (stakeholders)
de acuerdo a las necesidades específicas del sistema y se aplican tácticas arqui-
tecturales y patrones para satisfacer los drivers establecidos. Los pasos del ADD
se ilustran en la Figura 3.
17
Figura 3. Método ADD. Adaptado de (Wojcik, 2006).
Para la validación de la arquitectura, se puede realizar mediante pruebas manua-
les, las cuales hacen uso de escenarios para verificar el cumplimiento de los atri-
butos de calidad de la arquitectura. Los escenarios permiten identificar debilidades
del diseño de la arquitectura para que sean solucionadas antes de la fase imple-
mentación (Kazman et al., 1996). El método ATAM permite que un grupo de ex-
pertos evalúen el comportamiento de ciertos atributos en condiciones particulares
planteadas en los escenarios. Esto con el fin de lograr el balance (tradeoff) entre
los atributos (drivers) definidos y priorizados por los interesados (stakeholders).Los
pasos para validar una arquitectura se describen en la Tabla 1.
NO. PASO DESCRIPCIÓN
1 Presentar el ATAM El líder del equipo de evaluación, realiza una descripción del método a los partici-pantes, establece las expectativas y resuelve dudas
2 Presentar los objetivos del Negocio
Se describen las metas del negocio, especialmente las relacionadas con atributos de calidad, que se convertirán en pautas primordiales para la arquitectura
3 Presentar la arquitectura El arquitecto describe la arquitectura enfocándose principalmente en cómo se da cumplimiento a los objetivos del negocio
4 Identificar las propuestas arquitectónicas
El arquitecto identifica las propuestas arquitectónicas pero no son analizadas
5 Generar el árbol de calidad de los atributos de calidad
Los atributos de calidad que comprometen la utilidad del sistema, son obtenidas, especificados y priorizados en escenarios
6 Analizar las propuestas arqui-tectónicas
Basados en los escenarios de mayor prioridad identificados en el paso 5, las pro-puestas que cumplen con estos escenarios, son obtenidas y analizadas
7 Revisión del árbol de utilidad y priorización de escenarios
El conjunto de escenarios obtenido con los interesados debe ser priorizado
8 Analizar las propuestas arqui-tectónicas
Se realizan nuevamente las actividades del paso 6, tomando la priorización del paso 7. El análisis puede llegar a cubrir nuevas propuestas arquitectónicas, ries-gos, no riesgos, puntos de sensibilidad y el tradeoff entre los atributos de calidad.
9 Presentar los resultado El equipo de ATAM documenta y presenta los resultados a los interesados
Tabla 1. Pasos del método ATAM. Adaptado de (Kazman et al., 2000)
18
Como alternativa para el presente proyecto se considera la opción de realizar revi-
siones de diseño por pares siguiendo el método de evaluación de arquitectura
ATAM, propuesto por (Bachmann, 2011). Para las revisiones se toman los escena-
rios que fueron priorizados en la fase de elicitación de requisitos. Los escenarios
permiten validar que el diseño esté alineado con los objetivos de negocio y los in-
tereses de los interesados identificados en el diseño de la arquitectura.
Los pasos para las revisiones del diseño por pares al estilo ATAM son:
PASO 1: Seleccionar el escenario a analizar
PASO 2: Obtener los enfoques de la arquitectura
PASO 3: Analizar los enfoques de la arquitectura
PASO 4: Revisar los resultados
Las revisiones del diseño permiten una retroalimentación temprana de los riesgos
y tomar las decisiones para mitigarlos en tiempo de diseño de la arquitectura.
Además, a medida que se realizan las revisiones del diseño, se generan la docu-
mentación de la arquitectura, quedando listos para una validación al final del dise-
ño de la arquitectura.
2.2. HISTORIA CLÍNICA
2.2.1. Antecedentes
La historia clínica es una herramienta vital para el quehacer de cualquier profesio-
nal de la salud, tanto a nivel asistencial, docente, investigativo o de gestión. Desde
su origen, el estilo hipocrático se basaba en el registro de las vivencias de los en-
fermos. El médico registraba las observaciones de los síntomas de los pacientes.
Posteriormente, en los registros médicos se registraba lo que los pacientes podían
percibir a través de sus sentidos. Luego, con el descubrimiento de nuevos instru-
mentos de exploración y la aparición de los exámenes complementarios (exáme-
nes de laboratorio, diagnóstico por imágenes u otros) se generó una diversidad de
fuentes de información para la historia clínica, entonces el enfoque cambió a las
observaciones del médico.
A finales de 1960 que se ideó una nueva manera de estructurar la información clí-
nica por medio de la creación de una lista de problemas, que originalmente fue
concebida para posibilitar la sistematización de los registros médicos. La sistema-
tización de la historia clínica considera todas las fuentes que generan información,
tales como notas de evolución, exámenes complementarios, indicaciones médicas
19
o lista de problemas. Además la sistematización permite un ordenamiento crono-
lógico para cada fuente de información (Carnicero, 2012).
El formato tradicional de la historia clínica hasta hace unos años atrás fue en pa-
pel. Generando problemas de disponibilidad, accesibilidad y contenido. La versión
en papel también ocasiona duplicidad de los datos y dificultad para garantizar la
confidencialidad de la información. Otros problemas asociados a la historia clínica
en papel son: Formatos no estandarizados y poco estructurados, alto consumo de
espacio físico para almacenamiento, alta probabilidad de pérdida de los documen-
tos, archivado parcial o erróneo y alta probabilidad de deterioro.
2.2.2. Historia Clínica Electrónica
La Historia Clínica Electrónica (HCE o EHR por sus siglas en inglés) es una alter-
nativa que presenta potenciales beneficios, más allá de cubrir las falencias del
formato en papel. Desde que la tecnología posibilitó almacenar la información en
medios electrónicos, los registros médicos han migrado a este formato. Inicialmen-
te el desarrollo se realizó como proceso académico y experimental orientado a
procesos administrativos. Con el paso del tiempo, el eje de la EHR se ha centrado
en procesos asistenciales, con el apoyo de estándares para el manejo y la inte-
gración de la información de las áreas clínicas. En la literatura se utilizan diferen-
tes términos para hacer referencia a la historia clínica electrónica. En el presente
proyecto se utilizarán las definiciones dadas en (Alliance, Information, Report,
Coordinator, & Technology, 2008), las cuales se presentan en la Figura 4.
Figura 4. Definiciones asociadas a la Historia Clínica Electrónica
EMR Electronic Medical
Record
Historia médica Electrónica
Gestionado y consultado por los médicos
autorizados y personal dentro de una
organización de atención de salud
PHR Personal Health Record
Historia Clínica Personal
Se puede extraer de múltiples fuentes bajo
estándares de interoperabilidad.
Compartida y controlada por el usuario
EHR Electronic Health
Record
Historia Clínica Electrónica
Ajustada a estándares de interoperabilidad.
Gestionado por más de una organización de
atención médica autorizada
20
2.3. TECNOLOGÍA ASOCIADA A LA SALUD
Los avances de la tecnología han posibilitado la transformación de los modelos de
prestación de servicios de salud tradicionales. Nuevos conceptos innovadores
permiten mejorar la oportunidad y disponibilidad de acceso a la información y a los
servicios de salud. A continuación se relacionan algunos de los principales con-
ceptos tecnológicos que se consideraron para la propuesta del presente proyecto.
e-Health: e-Health es una tendencia tecnológica relacionada con la atención en
salud. A este término se asocian los servicios en salud que estén apoyados en
tecnologías de la información y las comunicaciones (TIC), especialmente con el
uso de recursos de computación en la nube (Cloud Computing), para mejorar la
prevención, diagnóstico, tratamiento, seguimiento y gestión de servicios (World
Health Organization, 2013) . Algunos servicios de e-Health se muestran en la Figu-
ra 5.
Figura 5. Servicios asociados a e-Health
Cloud Computing: El concepto de computación en la nube apunta a ofrecer ser-
vicios por demanda en Internet, donde los usuarios consumen un servicio sin ac-
ceder a un sistema en particular, mejorando la velocidad de despliegue de las
aplicaciones y reduciendo costos. Sobre esta plataforma se ofrecen servicios a
diferentes niveles: SaaS Software como servicio (Software as a Service); PaaS
21
Plataforma como servicio (Platform as a Service); e IaaS Infraestructura como ser-
vicio (Infraestructure as a Service) (Chowdhary, Yadav, & Garg, 2011).
SOA: El modelo de referencia arquitectónica (Services Oriented Architecture -
SOA), generalmente se implementa con soluciones de Bus de Servicios Empresa-
riales (Enterprise Service Bus –ESB) (Castrillón, González, & López, 2012). SOA
favorece la definición de sistemas distribuidos e incorpora elementos críticos del
negocio. Adicionalmente, facilita integrar sistemas donde existen problemas de
acoplamiento, rehúso, granularidad, heterogeneidad y la inclusión de sistemas le-
gados.
Microservicios: El patrón de arquitectura de microservicios está ganando rápida-
mente terreno en la industria como una alternativa viable a las aplicaciones mono-
líticas y arquitecturas orientadas a servicios. Cada componente de servicio en una
arquitectura de microservicios contiene uno o más módulos que representan una
función de un solo propósito o una parte independiente.
Los componentes se diseñan bajo una arquitectura distribuida como unidades se-
paradas, facilitando el despliegue, logrando mayor escalabilidad y un alto grado de
desacoplamiento de sus componentes. Los servicios se pueden clasificar en 3
capas: 1. Servicios Core o de negocio, encargados de la persistencia de datos de
negocio y de aplicar reglas y lógica de negocio. 2. Servicios Compuestos: Pueden
orquestar un número de servicios core para realizar una tarea o agregar informa-
ción de un conjunto de Servicios Core. 3. Servicios API: Exponen las funcionalida-
des permitidas al exterior para ser ejecutadas por los consumidores o terceras par-
tes. El acceso a los componentes se realiza a través de protocolos de acceso re-
moto tales como: JMS, AMQP, REST, SOAP o RMI. Determinar el nivel adecuado
de granularidad del componente de servicio es uno de los mayores desafíos para
una arquitectura de microservicios.
Los microservicios evolucionaron naturalmente a partir de dos fuentes principales.
La primera, desde aplicaciones monolíticas desarrolladas utilizando el patrón de
arquitectura en capas hacia un modelo de entrega continua de componentes de
servicio, y la segunda, desde las aplicaciones distribuidas desarrolladas a través
del patrón de arquitectura orientada a servicios (SOA) hacia un modelo de compo-
nentes de servicio simplificando las nociones de servicio, conectividad y acceso y
eliminando la necesidad de orquestación de los servicios (Richards, 2016).
La oferta de los microservicios se realiza sobre plataformas estándares con proto-
colos y lenguajes que garantizan la neutralidad, portabilidad e interoperabilidad.
Algunas de las ventajas de la arquitectura de microservicios son: 1. La facilidad de
mantenimiento: Si una función falla, es fácil identificar el componente origen del
22
problema y todos los esfuerzos se centran en corregir el microservicio encargado
de esa función. 2. Cada Microservicio puede elegir su propia tecnología: distintos
Microservicios pueden estar escritos en distintos lenguajes de programación. 3.
Fácilmente escalable: a falta de mayor capacidad para ejecutar una función, se
despliega el mismo microservicio todas las veces que sean necesarias. 4. Alta
disponibilidad: Si un Microservicio falla, el resto continúa trabajando, minimizando
las pérdidas de servicio completas.
eHaaS: El concepto de Health as a Service (eHaaS), es el resultado de combinar
conceptos de Computación en la Nube, SOA, e-Health e Historias clínicas Perso-
nales (Black & Sahama, 2014). eHaaS ofrece servicios en la nube alrededor de la
historia clínica personal. En eHaaS se integran y encapsulan los conceptos de
PHR (Personal Health Records), EMR (Electronic Medical Record) y EHR en un
único sistema (Black, Sahama, & Gajanayake, 2014), tal como se ilustra en la Fi-
gura 6.
Figura 6. Composición de la EHR. Adaptado de (Black et al., 2014)
HRB: El Health Record Bank (HRB) es un modelo conceptual para la consolida-
ción de la información clínica. La propuesta se basa en repositorio centralizado
para almacenar las PHR de los usuarios. Las reglas de negocio del HRB son simi-
lares a las transacciones del sistema bancario mediante la definición de servicios
en la nube (Gold & Ball, 2007). El modelo conceptual del HRB se presenta en la
Figura 7.
23
Figura 7. Modelo Conceptual del HRB. Adaptado de (Gold & Ball, 2007)
2.4. INTEROPERABILIDAD DE LOS SISTEMAS DE
INFORMACIÓN EN SALUD
De acuerdo a (Amatayakul, 2004) un sistema de EHR es un concepto que está
asociado a un conjunto de sistemas de información que ejecutan una serie de fun-
ciones que aportan valor, mediante el registro de transacciones asistenciales, ad-
ministrativas y financieras, las cuales se realizan en distintas instituciones presta-
doras de servicios de salud. La EHR actúa como repositorio donde se almacena la
información del Paciente, en ella se registran los eventos realizados en la atención
clínica. También, es la base para el estudio de casos clínicos y el análisis de estu-
24
dios retrospectivos individuales y grupales. En áreas administrativas y financieras
brinda soporte a la facturación de servicios. Además, es de gran utilidad para la
evaluación de la calidad de servicios prestados.
Una arquitectura para la interoperabilidad de la información clínica debe conside-
rar componentes que soporten los procesos actuales del sistema de salud, así
como la posibilidad de adaptar los sistemas existentes a la arquitectura propuesta,
ya que estos sistemas emplean mecanismos heterogéneos para procesar, guardar
y transmitir la información médica de los pacientes, debido a los distintos formatos
de los registros clínicos que podrían ser datos estructurados en archivos planos
como el caso de los registros individuales de prestación de servicios en salud
(RIPS) (Ministerio de Salud, 2000), archivos XML, documentos digitalizados o ar-
chivos multimedia que contengan imágenes, videos, o archivos de sonido, tales
como las imágenes digitales bajo el estándar DICOM (Digital Imaging and Com-
munication in Medicine) (National Electrical Manufactures Association, 2011).
También se contemplan aspectos como la identificación de personas, interoperabi-
lidad, uso de estándares, representación de la información clínica, usabilidad, se-
guridad, privacidad, confidencialidad y manejo del cambio de la información.
(Carnicero, 2012).
En conclusión, para alcanzar la interoperabilidad entre los diferentes sistemas de
información en salud, se deben abordar los siguientes niveles: Sintáctico, Semán-
tico y Organizacional. Estos se presentan en la Figura 8 (Indarte & pazos
gutiérrez, 2012). Adicionalmente, en el diseño de la arquitectura del presente pro-
yecto se contempla el nivel legal, para dar cumplimiento a las normas establecidas
para el manejo de la información que conforma la historia clínica.
Figura 8. Niveles de interoperabilidad. Adaptado de (Indarte & pazos gutiérrez, 2012)
Técnico
Especifica los medios de comunicació
n física
Sintáctico
Define claramente los tipos, campos, tamaños,
formatos que se podrán
utilizar
Semántico
Busca la correcta
interpretación de la
información que se
intercambia
Organizacional
Especifica reglas de negocio,
procesos y actores
Legal
Establece el conjunto de politicas y
normas para el
tratamientoy seguridad de
la información
25
2.5. ESTÁNDARES DE INTEROPERABILIDAD EN SALUD
La necesidad de integrar los sistemas de salud y lograr la interoperabilidad de la
EHR son temas de gran relevancia a nivel mundial. Existen diferentes obstáculos
en la adopción de la EHR asociados a aspectos financieros, técnicos, tiempo, psi-
cológicos, sociales, legales, organizacionales y de adaptación al cambio, que han
dificultado este proceso y no han permitido lograr cumplir con las expectativas de
los usuarios (Carnicero, 2012). Las instituciones disponen de sistemas que han
sido diseñados únicamente para cumplir con las necesidades propias y específi-
cas de cada empresa para la administración de su información. En algunas oca-
siones los sistemas de estas empresas permiten la interacción de la EHR con
otros sistemas al interior de la institución. En raras ocasiones los sistemas de las
instituciones de salud están diseñados para establecer la interacción con sistemas
de otras instituciones, debido a que la arquitectura no lo soporta, debido a que no
hacen uso de estándares para la interoperabilidad de la información en salud. El
uso de estándares no es una prioridad porque generalmente no está alineado a
los objetivos de negocio de las IPS.
Existen a nivel internacional algunos modelos de referencia para la interoperabili-
dad de los sistemas de información en salud, especialmente para la EHR. Los más
reconocidos son:
HL7: Estándar de la organización Health Level 7 Internacional para la arqui-
tectura de documentos clínicos electrónicos (Health Level Seven
International, 2013a).
openEHR: Modelo de referencia de estándar abierto, define un modelo ge-
nérico basado en un proceso de resolución de problemas clínicos, permi-
tiendo modelar cualquier tipo de atención médica mediante el uso de arque-
tipos (openEHR Foundation, 2014).
CEN/ISO EN13606: Estándar que define protocolos de interoperabilidad
semántica para compartir la información clínica mediante el uso de arqueti-
pos, los cuales le permiten representar cualquier documento clínico en
formato XML (EN13606 Association, 2011).
CDA: (Clinical Document Architecture), es un estándar de la ISO (Interna-
tional Standards Organization) para la definición de documentos clínicos
(Health Level Seven International, 2013b).
Aunque estos estándares son reconocidos mundialmente, en la práctica sólo han
sido implementados por algunos países desarrollados, dado que la adopción de un
estándar significa cambios e inversión para las instituciones (Garcia, Tyson, &
Miles, 2012), aún más la adopción del estándar por sí sola, no asegura la interope-
26
rabilidad (Tuomainen & Mykkänen, 2012). Se requiere de políticas de gobierno
que apoyen el proceso para incentivar el uso de estos modelos que permitan el
acceso a la información clínica de los usuarios desde las distintas redes de institu-
ciones donde se prestan los servicios de salud (Indarte & pazos gutiérrez, 2012).
Existe una relación directa entre los diferentes tipos de estándares definidos para
cada tipo de interoperabilidad tal como se presenta en la Tabla 2.
NIVEL TIPO ESTÁNDAR
TÉCNICA Infraestructura en comunicación Comunicación Física Redes de computadores
TCP/IP
SINTÁCTICA
Estándares de sintaxis HTML, XML, EDI, JSON
Protocolos de comunicación generales SOAP, SMTP, FTP, HTTP
Protocolos de comunicación en salud HL7, X12, DICOM, ISO 13606
Especificación de formato XML Schema
Especificación de servicios WSDL
SEMÁNTICA
Terminología y nomenclatura en salud RadLex, UMLS, MeSH, CIE10, Snomed CT, LOINC
Modelos de información HL7 RIM, openEHR
Modelos de conocimiento Arquetipos, Ontologías, RDF
ORGANIZACIONAL Especificación de procesos BPEL, BPMD
Arquitectura de comunicación IHE, IFK
Tabla 2. Estándares Interoperabilidad en salud por niveles
Para la generación de documentos clínicos existen varios modelos. El más reco-
nocido a nivel mundial es HL7. HL7 se presenta como solución a los problemas de
interoperabilidad de la información en salud en cualquier ámbito y con una inver-
sión mínima de tiempo.
Si bien HL7 tiene muchas fortalezas, estas premisas no tan cercanas a la realidad,
sino ya se tendría desde hace varios años funcionando un sistema integrado de
salud que esté basado en HL7. En la Tabla 3 se presentan las ventajas y desven-
tajas de HL7(Pazos, 2011).
VENTAJAS DESVENTAJAS
Permite crear un marco de comunicación a gran escala. Complejidad: un solo modelo, más de 20 dominios, decenas de CMET’s (Common Model Element Types), mensajes e interacciones.
Es un excelente punto de partida para definir cómo se van a comunicar.
No es aplicable directamente, necesita acuerdos previos y la construcción de "guías de implementación".
No hay otro estándar de mensajería tan ampliamente difun-dido e implementado como es el caso de HL7v2.
No garantiza interoperabilidad semántica básica o global: Necesita guías de implementación y no provee mecanismos como lo hacen las ontologías y arquetipos.
El más completo en referencia a los dominios. Especificaciones crípticas, difícil de entender, ambiguas y dependientes de la interpretación.
Capacidad de integrar terminologías estándar tales como CIE, SNOMED y LOINC.
No usa estándares de modelado (UML). Problemas en el modelado de la información (clasificación, ambigüedad).
Esquema de comunicación simple, basado en eventos y mensajes.
Requiere de una organización externa, con especificaciones propias, para implementarse correctamente. (IHE)
HL7 v3 se basa en mensajería XML. Calidad variable, complejidad de evaluación y trabajo en comités.
Tabla 3. Ventajas y desventajas de HL7
27
2.6. ARQUITECTURA DE INFORMACIÓN DE LA HISTORIA
CLÍNICA PARA LA ATENCIÓN DE EMERGENCIAS
El término ―Emergencia‖ es usado para definir una situación de peligro o desastre
que requiere una acción inmediata (Real Academia Española, 2016). En el contex-
to médico una emergencia es la necesidad de ayuda médica frente a una condi-
ción que se presenta sin previo aviso y que amenaza la vida del paciente o su sa-
lud, causando la muerte de no ser atendido (Organización Mundial de la Salud
(OMS), 2015). En el caso de la atención de pacientes en situaciones de emergen-
cia, es vital el apoyo que pueda brindar la historia clínica del paciente en la toma
de decisiones. Debido a las limitantes como tiempo, recursos físicos y tecnológi-
cos en la atención de una emergencia, se hace necesario su optimización.
Por esta razón es relevante identificar los componentes más importantes de un
resumen de historia clínica que apoyen la prestación de la atención médica en una
situación típica de emergencias. Dependiendo de la estructura, organización y eti-
quetado de la información clínica presentada al usuario, se logra que los conteni-
dos sean de fácil acceso y de utilidad para la atención de los pacientes en situa-
ciones de emergencia. Un acceso efectivo a la información clínica se puede lograr
aplicando los conceptos propuestos por la arquitectura de la información para el
diseño de estructuras de organización basadas en registros (Morville, Rosenfeld, &
Rosenfeld, 2007).
Para el presente proyecto se toma como el modelo de historia clínica orientada a
problemas (HCOP), para el registro dinámico de los eventos asociados a la salud
del paciente, la cual es muy usada por instituciones que atienden emergencias. La
estructura de la HCOP está dividida en cuatro partes: la base de datos del pacien-
te, la lista de problemas, las notas de evolución y las hojas de flujo. Las notas de
evolución se registran siguiendo la estructura SOAP (por sus siglas en inglés: Sub-
jective – Objective - Assessement - Plan), que permite un análisis basado en la
evidencia para la toma de decisiones en el plan de tratamiento de los pacientes
(Cantale, 2006). Además, se consideraron los componentes de la historia clínica,
seleccionados en un estudio realizado por la comunidad openEHR (openEHR,
2009) que definió los arquetipos de mayor relevancia para la atención de emer-
gencias, los cuales están alineados con el orden de prioridades del contenido clí-
nico para los registros de salud establecido en el estándar ISO/TR 12773-1 (ISO,
2009). Los componentes seleccionados se detallan en la Tabla 4.
28
No. COMPONENTE
VERSIÓN ARQUETIPO
DESCRIPCIÓN
1 HISTORIA FAMILIAR
(v1) Base para la evaluación de riesgo para el paciente, debido a las condiciones de los miembros de la familia.
2 RESUMEN DE CONSUMO DE SUSTANCIAS
(v1)
Familia de arquetipos que comprenden un arquetipo genérico para registrar el consumo de sustancias genéricas. Arquetipos Proyecto de candidatos también existen como especializaciones para el alcohol y el consumo de tabaco.
3 HISTORIA DE
VIAJE
(v0) Un resumen de los viajes. El uso en este contexto es informar del riesgo de las condiciones de salud basado en un viaje reciente.
4 REACCIÓN ADVERSA
(v1) Base para el control de la interacción o la presentación de informes de even-tos adversos. El uso en este contexto consiste en proporcionar una lista de reacciones adversas / alergias.
5 ALERTAS,
PRECAUCIONES (v1)
Comprenderá la información que puede necesitar consideración o acción especial por un profesional de la salud.
6 GRUPO SANGRE (v1) Arquetipo laboratorio especializado para la presentación de informes del grupo sanguíneo.
7 ADMISIÓN / EPISODIO
(v1)
Una definición genérica para las admisiones o episodios de la atención pres-tada. Se utiliza en este contexto para proporcionar una lista de las admisio-nes recientes / significativas de hospitalización o episodios de atención para una condición dada.
8 GRUPO DE
SIGNOS VITALES (v0)
Comprende la presión arterial, el pulso, la oximetría, la respiración y la tem-peratura. El uso en este contexto es el de proporcionar la base para el apoyo a la decisión potencial.
9 PESO (v1) Capturará peso. El uso en este contexto es el de proporcionar la base para el potencial de dosis ayuda a la decisión por ejemplo, medicación por kg.
10 INFORME
DIAGNÓSTICO
(v1) Un arquetipo genérico para informar el resultado de una prueba radiológica genérico. El uso en este contexto es el de proporcionar algunos resultados recientes o significativos de radiología.
11 INFORME ECG (v0) Para informar de los hallazgos interpretados y conclusiones de ECG. El uso en este contexto para proporcionar una base de comparación para los nue-vos hallazgos del ECG.
12 INFORME DE
LABORATORIO (v0)
Un arquetipo genérico para informar del resultado de una prueba genérica laboratorio. El uso en este contexto es el de proporcionar algunos resultados recientes o significativos de laboratorio.
13 MEDICAMENTOS (v0) Base de órdenes de medicamentos, recetas médicas, y diversas listas de medicamentos. El uso en este contexto, es probable que una lista de medi-camentos actual.
14 PROCEDIMIENTOS (v1) Un arquetipo genérico para incluir información en un procedimiento que se ha realizado. El uso en este contexto es el de proporcionar una lista de algunos de los procedimientos recientes o importantes que se han realizado.
15 REFERENCIA (v1) Base para el ordenamiento y referencias de registro y un resumen de las referencias que han sido ordenados / completado.
16 SINOPSIS CLÍNICA (v1) Base formal para la grabación de un resumen clínico textual.
17 PROBLEMA /
DIAGNÓSTICO (v1)
El diagnóstico es actualmente una especialización del problema; El uso de tanto en este contexto será como la base para una lista de problemas.
18 PLAN DE CUIDADO
(v0) Base para el registro de las directivas en curso centrados en el paciente con respecto a sus opciones para las instrucciones de cuidado por ejemplo re-animación.
19 NOTIFICACIÓN (v0)
Un arquetipo genérico para la documentación / notificación formal. Los ejem-plos específicos incluyen un certificado médico. El uso en este contexto es el de proporcionar una lista de las notificaciones que se han generado para este paciente.
Tabla 4. Componentes de la Historia Clínica para atención de emergencias
29
2.7. MARCO LEGAL
En esta sección se relacionan algunas de las principales normas asociadas a la
EHR del ámbito nacional e internacional, que son consideradas en el diseño de la
arquitectura de la EHR para pacientes en situaciones de emergencia.
2.7.1. Marco Nacional
Dentro de la normatividad relacionada con la salud de la población Colombiana,
existen algunas normas que están orientadas a establecer cierto niveles de inter-
operabilidad de la información clínica. Tal como es la Resolución 3374 de 2000, la
cual reglamenta cuales son los datos básicos que deben reportar las IPS y las
EPS sobre los servicios de salud prestados a los pacientes, mediante el reporte de
archivos planos en formato TXT (Ministerio de Salud, 2000). La información que
tiene los RIPS respecto a los registros médicos es básica y principalmente está
relacionada con los diagnósticos establecidos dentro de la atención. Esto se debe
a que el obejtivo principal de los RIPS es soportar la facturación de los servicios
prestados por las IPS. En ciertos casos donde se realiza análisis de información
basados en RIPS se establece que son insuficientes, por lo tanto es necesario
acudir a otras fuentes de información más específicas tales como las normas para
el reporte de atención de ciertas patologías como la cuenta de alto costo (CAC,
2007).
El gobierno de Colombia desde el año 2010 está gestionando el proyecto de re-
forma al actual sistema de salud. En el año 2011 el Ministerio de la Protección So-
cial expide la ley 1438, en la que se dictan los lineamientos generales de las modi-
ficaciones al sistema de salud (MinSalud, 2011). Esta ley incluye artículos que
contemplan la adopción de sistemas de información para mejorar la prestación del
servicio, mediante la integración de la información. Los artículos de la ley 1438
que se relacionan con el presente proyecto son:
Artículo 22º que trata de la portabilidad nacional, permitiendo que las personas
puedan ser identificadas como usuarios del sistema de salud, sin importar el lugar
donde se les preste la atención.
Artículo 62°. Busca la conformación de redes integradas de servicios de salud, pa-
ra establecer la interacción entre las diferentes entidades que conforman el siste-
ma de salud.
30
Artículo 112°. Busca la Articulación del sistema de información, que permita la
gestión de la información relacionada con la prestación de servicios de salud y su
en PARÁGRAFO TRANSITORIO define que La historia clínica única electrónica
será de obligatoria y tendrá plena validez probatoria.
Artículo 113º. Establece que se debe definir el Sistema de Información Integrado
del Sector Salud, el cual tiene la finalidad de integrar sistemáticamente, los datos,
la información y el conocimiento, que son la base para la toma de decisiones en la
atención de los usuarios, permitiendo la participación de diferentes actores del sis-
tema de salud, incluyendo aspectos clínicos, financieros de costos e ingresos, es-
tableciendo el estado de la salud poblacional.
El decreto 429 de 2016 ordena que el sistema debe asegurar que la información
del conjunto mínimo de datos esté disponible para los integrantes: planificadores,
gerentes en salud, directores y administradores, profesionales, pacientes y ciuda-
danos. Además, añade que en todo caso, se deberá respetar la reserva de los da-
tos (MINSALUD, 2016).
El gobierno colombiano en 2012 emitió la ley estatutaria 1581 que tiene por objeto
desarrollar el derecho constitucional que tienen todas las personas a conocer, ac-
tualizar y rectificar las informaciones que se hayan recogido sobre ellas en bases
de datos o archivos, así como el derecho a la información. En la ley 1581 se apli-
can los principios de legalidad, finalidad, libertad, veracidad, transparencia, acceso
y circulación restringida, seguridad, confidencialidad de la información personal.
En el contexto de esta ley se entiende por datos sensibles aquellos que afectan la
intimidad del Titular o cuyo uso indebido puede generar su discriminación. Se con-
templan como datos sensibles los datos relativos a la salud, a la vida sexual y los
datos biométricos (Congreso de la República de Colombia, 2012).
Aunque existe legislación que establece la necesidad de implementar sistemas
para la interoperabilidad de los sistemas de salud en Colombia, se evidencia la
falta de decisiones en la definición de las políticas que establezcan un panorama
claro que sirva de guía al desarrollo de los sistemas.
Para avanzar en este sentido se requiere definir los lineamientos, restricciones y
estándares a ser utilizados, para estructurar una solución que permita la interope-
rabilidad de acuerdo a los parámetros que establezca el gobierno, lo cual implicará
realizar grandes inversiones para las instituciones involucradas (Indarte & pazos
gutiérrez, 2012).
31
2.7.2. Marco Internacional
La División de Desarrollo Social de la Comisión Económica para América Latina
(CEPAL), en el marco institucional del componente de TIC y salud, tiene estable-
cidos programas de cooperación entre la Unión Europea y América Latina. En
América Latina y el Caribe existe una variedad de factores que limitan el acceso a
una atención médica oportuna y de calidad, debido a la escasez de recursos hu-
manos, infraestructura, equipamiento médico y recursos financieros.
En este escenario, las TIC deben participar en la solución para reducir las limita-
ciones de acceso así como mejorar la eficiencia en el sector. Para superar estas
dificultades no podrán estar ausentes de las políticas nacionales de salud. El
CEPAL busca contribuir al diseño de políticas y estrategias en salud electrónica,
reducir las brechas de acceso y calidad que afecta a las poblaciones más vulnera-
bles y mejorar la efectividad y la eficiencia de la gestión de los sistemas de salud.
El CEPAL es reconocido por la Organización Panamericana de la Salud como
grupo asesor de su área de Comunicación y Gestión del Conocimiento (Indarte &
pazos gutiérrez, 2012).
En otras regiones de mundo, organizaciones como el Departamento de Salud y
Servicios Humanos de los EE.UU. (HHS) o la Unión Europea tienen establecidas
normas regulatorias para la protección de la privacidad y seguridad de la informa-
ción médica de las personas. Las normas de seguridad de la información en salud
buscan que se proteja la intimidad y confidencialidad de la información en el con-
texto del sistema de salud que pretende la interoperabilidad de los registros médi-
cos entre las instituciones de salud para la consolidación de la EHR.
2.7.2.1. Ley de Portabilidad
El departamento de servicios de salud y humanos de los Estados Unidos (Health
and Human Services HHS) emitió la Ley de Portabilidad y Responsabilidad de Se-
guros de Salud (Health Insurance Portability and Accountability Act - HIPAA) don-
de establece que todas las organizaciones de atención a la salud deben cumplir
con reglas estrictas diseñadas para proteger la confidencialidad e integridad de la
información de las personas (CMS, 2003). La norma de seguridad HIPAA especifi-
ca un conjunto de procesos empresariales y requisitos técnicos que los responsa-
bles del manejo de la información en salud deben seguir. HIPAA está orientada a
tres áreas:
32
Seguridad Administrativa: Estas son prácticas diseñadas para controlar las
medidas de seguridad y la conducta del personal que accede, ve, procesa y
distribuye electrónicamente información médica protegida.
Seguridad Física: Estos son procesos que protegen equipo físico y edificios
relacionados, de peligros naturales y medioambientales, así como de intru-
siones físicas.
Seguridad Técnica: Estos son mecanismos técnicos y procesos diseñados
para proteger, controlar y monitorear el acceso a la información. Restringe
el acceso sólo al personal autorizado y promueve el uso de contraseñas pa-
ra controlar el acceso y autenticar al usuario.
Con la implementación de la norma HIPAA se pretende dar mayor control al pa-
ciente sobre su información de salud, establecer restricciones para el uso y trans-
misión de registros médicos, regular que las organizaciones del sistema de salud
tengan mecanismos de seguridad vigentes para enfrentar cualquier amenaza o
peligro respecto de la seguridad, el uso no autorizado o la divulgación de la infor-
mación para ayudar a proteger la intimidad, equilibrar la necesidad de intimidad
del paciente con las necesidades de la salud pública, ofrecer la opción de que los
pacientes gestionen su propia historia clínica, para la consulta, adición o reporte
de inconsistencias en la información para que sean corregidos, y también estable-
ce sanciones por violación de los estándares de confidencialidad del paciente
cuando se evidencie incumplimiento.
2.7.2.2. Directiva 95/46/EC
Las políticas de privacidad están enmarcadas dentro de la Directiva de la Unión
Europea (EU Directive 95/46/EC) que regula la protección de las personas respec-
to al procesamiento de datos personales y al movimiento libre de tales datos
(European Parliament, 1995). Los principios de privacidad más relevantes de la
directiva son:
Los datos deben ser recopilados y almacenados de acuerdo con las leyes.
La información recogida sobre una persona no puede ser divulgada a otras
organizaciones o personas, a menos que sea autorizada por la ley o por
consentimiento expreso del interesado.
Los registros de datos personales deben ser precisos y actualizados.
Las personas tienen derecho a corregir los errores contenidos en sus datos.
Los datos deben ser utilizados sólo para los propósitos con los que fueron
almacenados y se deben utilizar solo por un periodo razonable de tiempo.
33
Las personas tienen derecho a recibir un informe sobre la información que
se tiene sobre ellas.
La transmisión de información personal a lugares donde no se pueda ase-
gurar una protección de datos está prohibida.
2.7.2.3. Cybersecurity Framework
El término Ciberseguridad está asociado a mecanismos diseñados para prevenir,
detectar y responder a los ataques contra los componentes críticos de un sistema
de información. El gobierno de Estados Unidos a través del Instituto Nacional de
Estándares y Tecnología (NIST) propuso un marco para la mejora de la seguridad
cibernética de Infraestructuras críticas (también conocido como el Marco de Segu-
ridad Cibernética) (NIST, 2015). El marco es adaptable, flexible y permite aplicar
los principios y las mejores prácticas de gestión de riesgos independiente del ta-
maño, nivel de riesgo de seguridad o sofisticación de las organizaciones.
La ciberseguridad es una responsabilidad compartida, entre las organizaciones y
los usuarios de los sistemas. Algunos de los aspectos claves que se deben esta-
blecer en ciberseguridad son: establecer una cultura de seguridad, proteger los
dispositivos móviles, mantener buenos hábitos informáticos, utilizar un Firewall,
instalar y mantener actualizado un antivirus, planear lo inesperado, establecer con-
troles de acceso a la información de salud protegida, utilizar contraseñas seguras
y cambiarlas regularmente, limitar el acceso a la red y controlar el acceso físico.
2.8. SOSTENIBILIDAD Y EL MANIFIESTO KARLSKRONA
La sostenibilidad es la capacidad de continuar brindando los beneficios generados
por un proyecto o servicio durante un período prolongado. Esta definición puede
ser ajustada desde la perspectiva desde la cual es analizada. Desde la perspecti-
va de desarrollo, un desarrollo sostenible es aquel que satisface las necesidades
de la generación presente sin comprometer la capacidad de las generaciones futu-
ras para satisfacer sus propias necesidades (WCED, 1987). Desde la perspectiva
social, la sostenibilidad se define como las políticas e instituciones que tienen
efecto en la integración de los diversos grupos y prácticas culturales de una mane-
ra justa y equitativa (Polèse & Stren, 2000). Desde otra perspectiva, la sostenibili-
dad de un sistema pretende lograr la equidad en la distribución y oportunidad en
prestación de los servicios sociales, como la salud y la educación (Harris, 2001).
34
En la actualidad la tecnología se concentra casi exclusivamente a la solución de
problemas técnicos, sin preocupación explícita por los problemas de sostenibili-
dad. Se requiere entonces influir en el desarrollo de productos y servicios sosteni-
bles que impacten en los aspectos sociales. En el ámbito del software se contem-
plan dos tipos de sostenibilidad la relativa y la absoluta. La sostenibilidad relativa
implica que una función se preservará durante un tiempo específico y la sostenibi-
lidad absoluta implica que el software o servicio va a contribuir a preservar el bie-
nestar ambiental y humano (Greenpeace International, 2010).
En (Calero, Moraga, & Bertoa, 2013) se contempla la sostenibilidad como un atri-
buto de calidad desde la perspectiva de la arquitectura de software y establece
sub-características asociadas a los requisitos que los componentes de la arquitec-
tura deben satisfacer, las cuales se muestran en la Figura 9.
Figura 9. Sub-características de sostenibilidad
El consumo de energía, se refiere al grado de consumo de energía necesaria para
que un componente del sistema pueda realizar sus funciones y cumpla con los
requisitos. La optimización de recursos es el grado de cumplimiento de sostenibili-
dad del componente cuando ejecuta sus funciones, en términos de cantidades y
tipos de recursos utilizados, tales como otros productos de software, hardware, y
materiales por ejemplo, papel de impresión o medios de almacenamiento. La per-
durabilidad, es asegurar que el producto de software se conservará y durará a tra-
vés del tiempo. Permite su modificabilidad y adaptación a las nuevas circunstan-
cias sin perder su funcionalidad u otras características relacionadas con la calidad.
Por otra parte, el manifiesto Karlskrona aborda la sostenibilidad como un concepto
multidimensional que tiene como objetivo el desarrollo sostenible (Becker et al.,
2015). Para la sostenibilidad se contemplan cinco dimensiones: la ambiental, la
35
social, la económica, la técnica y la individual (Goodland & Bank, 2002)
(Penzenstadler & Femmer, 2013). Cada dimensión aborda unas temáticas que se
pueden ver afectadas con la implementación de la solución. El detalle de cada una
de las dimensiones de sostenibilidad es presentado en la Tabla 5.
DIMENSIÓN DESCRIPCIÓN INCLUYE
Ambiental Efectos a largo plazo de las actividades humanas sobre los sistemas naturales
Ecosistemas, Materias primas, Cambio climático, Produc-ción de alimentos, Agua, Contaminación y residuos
Social Comunidades sociales y los factores que afectan la confianza en la sociedad
Equidad social, Justicia, Empleo, Democracia y Salud
Económica Activos, el capital y el valor añadido Creación de riqueza, Prosperidad, Rentabilidad, Inversión de capital e Ingresos
Técnica Longevidad de la información, los sistemas y la infraestructura
Mantenimiento, Innovación, Obsolescencia e Integridad de datos
Individual bienestar de los seres humanos como indi-viduos
Bienestar físico y mental, Educación, Autoestima, Habili-dades y Movilidad
Tabla 5. Dimensiones de la sostenibilidad en manifiesto Karlskrona
Para la evaluación de la sostenibilidad de los sistemas de tecnologías de la infor-
mación y las comunicaciones es recomendado considerar tres niveles de impacto,
primarios, secundarios y terciarios (Hilty et al., 2006), los cuales se presentan en la
Tabla 6.
NIVEL TIPO DESCRIPCIÓN
Primer Nivel
Efectos Primarios
Efectos de la existencia física de las tecnologías de la información y las comunicaciones: Im-pactos ambientales de la producción, uso, reciclaje y eliminación de hardware.
Segundo Nivel
Efectos Secundarios
Efectos ambientales indirectos de las tecnologías de la información y las comunicaciones debi-do a su poder para cambiar los procesos, dando lugar a una modificación (disminución o au-mento) de los impactos ambientales.
Tercer Nivel
Efectos Terciarios
Efectos ambientales a mediano o largo plazo por la adaptación a una conducta o estructura económica asociada a los servicios que las tecnologías de la información y las comunicaciones presta.
Tabla 6. Niveles de Sostenibilidad en manifiesto Karlskrona
2.9. DISEÑO CENTRADO EN EL USUARIO DE LA EHR
La usabilidad está definida por la ISO como la efectividad, eficiencia y satisfacción
con la cual los usuarios pueden lograr sus tareas en un contexto previsto de uso
del producto (International Organization For Standardization ISO, 1998). En
(Gans, Kralewski, Hammons, & Dowd, 2005) se señala que uno de los principales
factores para que no se adopten las EHR es la incertidumbre que tiene el personal
médico sobre la facilidad de acceso a los registros médicos consignados. Otro fac-
tor que se debe considerar está relacionado con la caracterización de los usuarios
de la EHR, como lo son las personas de edad avanzada y personas con discapa-
cidades. No tener en cuenta la usabilidad como uno de los atributos de calidad en
los sistemas de EHR impide su crecimiento, desarrollo e implementación en las
instituciones que componen los sistemas de salud y en la aceptación por parte de
los usuarios finales. De este modo, no se logra que la que información clínica sea
36
de fácil acceso para que pueda ser utilizada oportunamente en la atención de los
pacientes. Las implementaciones de EHR deben dar gran importancia a los linea-
mientos básicos de usabilidad, para disminuir la resistencia de los usuarios a
adoptar este tipo de sistemas y reducir los índices de fracaso de las implementa-
ciones de EHR, asociados a problemas de usabilidad (Goldberg et al., 2011). En-
tre los problemas más comunes de usabilidad están: Dificultad en navegación so-
bre la interfaz gráfica, no contar con acceso a funciones secundarias, y la preocu-
pación de los usuarios por la confidencialidad y las pérdidas de información (Gans
et al., 2005). Para dar solución a esta problemática, organizaciones como el Na-
tional Institute of Standars and Technology (NIST), el Office of the National Coor-
dinator for Health Information Technology (ONC) y la Agency for Healthcare Re-
search and Quality (AHRQ), han diseñado unas guías donde se propone un enfo-
que de Diseño Centrado en el Usuario (DCU) y las pautas para evaluar la usabili-
dad de la EHR. Para la elaboración de las guías se tomó como base algunas nor-
mas de la ISO tales como: ISO 9241-11, ISO 9241-210 e ISO/TR 16982. Las ca-
racterísticas asociadas a la usabilidad de la EHR se presentan en la Tabla 7.
Característica Descripción
Facilidad de aprendizaje Grado en que el producto permite a los usuarios aprender su aplicación.
Operatividad Grado en que los usuarios encuentran el producto fácil de utilizar y controlar.
Protección contra errores de usuario Grado en que el sistema protege a los usuarios de cometer errores.
Estética de la interfaz de usuario Grado en que la interfaz de usuario permite interacción agradable y satisfactoria.
Inteligibilidad Grado en que el producto de software permite a los usuarios reconocer si el software es adecuado para sus necesidades.
Accesibilidad Facilidad de uso y seguridad para usuarios con discapacidades específicas.
Tabla 7. Características Usabilidad (International Organization For Standardization, 2011)
El diseño de la EHR incluye componentes relacionados la atención de los pacien-
tes, los cuales se muestran en la Figura 10.
Figura 10. Diseño de la EHR.
37
2.9.1. Principios de gestión de la calidad de la Historia Clínica
El objetivo de la evaluación de la calidad de las historias es lograr historias com-
pletas. La calidad es el grado con el que la historia clínica cumple una serie de re-
quisitos establecidos (Renau & Pérez-Salinas, 2001). Para gestionar la calidad se
debe revisar las historias clínicas, detectar deficiencias y definir planes de correc-
ción. Se pueden realizar 2 tipos de revisiones: La revisión cuantitativa, verifica el
cumplimiento y ordenamiento de los diferentes registros que integran la historia
clínica, y la revisión cualitativa, que analiza el contenido informativo de la historia
clínica. Requiere de la participación de personal médico especializado en auditoría
médica.
2.9.1.1. Eventos de seguridad del paciente
Está asociado a los riesgos del paciente por errores introducidos en el registro
médico, debido a causas como la dificultad de entender ciertos aspectos de la
EHR, ocasionando confusión al personal médico, al no tener la claridad suficiente
de la información que se debe registrar o del significado de los datos que la inter-
faz le presenta en un momento dado de la atención de un paciente. Esta confusión
puede llevar a una mala interpretación de los registros médicos y por lo tanto a
una toma de decisiones equivocada por los médicos que realizan la atención, po-
niendo en riesgo la integridad del paciente.
2.9.1.2. Diseño centrado en el usuario
Los principios fundamentales para la creación de sistemas usables, se basan en la
comprensión sistemática de los usuarios y sus entornos, el diseño del sistema y
las pruebas iterativas de los objetivos de desempeño de los usuarios que se des-
criben en la Tabla 8.
No. Principios de DCU NISTIR 7741
1 Entender las necesidades del usuario, flujos de trabajo y entornos de trabajo
2 Involucrar a los usuarios pronto y con frecuencia
3 Los objetivos de desempeño son establecidos por el usuario
4 El diseño de la interfaz de usuario desde los principios de conducta humana conocidas y modelos de interfaz de usuario que sean familiares al usuario
5 Realizar pruebas de usabilidad para medir qué tan bien la interfaz cumple con las necesidades del usuario
Tabla 8. Principios de diseño centrado en el usuario (Schumacher & Lowry, 2010)
38
2.10. TRABAJOS RELACIONADOS
Algunos países han trabajado en el proceso de construcción de un sistema nacio-
nal de información en salud, ajustado a las necesidades y condiciones propias de
cada región, buscando la integración e interoperabilidad de la información en Sa-
lud, con distintos estilos de arquitecturas, con el fin de lograr la interoperabilidad
de los registros médicos y consolidar una Historia Clínica Electrónica. A continua-
ción en la Tabla 9 se presenta un listado de algunos proyectos y sus característi-
cas más relevantes.
Proyecto País Arquitectura Estándares Características
Health Connect (Australian Government Department
of Health, 2011) Australia SOA
HL7 openEHR SNOMED
Programa nacional para la estrategia de e-Health
My Health Record (Australian Digital Health Agency,
2016) Australia SOA
HL7 openEHR SNOMED
Historia Clínica Personal con reposi-torio único
National Health Information Infrastructure (NHII)
(Kuo, Kushniruk, & Borycki, 2011) Taiwán
Distribuida SOA VPN T.I.
SNOMED LOINC
NHI
Tres dimensiones de la información: Personal, prestadores de servicios y
comunitaria. Tarjetas inteligentes para la identifi-cación y movilización de registros
clínicos personales
My Health Bank (National Health Insurance
Administration of Taiwan, 2015) Taiwán
cloud-based service
SNOMED LOINC
NHI
Historia Clínica Personal con auten-ticación del ―citizen digital certificate" or "password-registered NHI card" para acceso seguro en tiempo real
Infoway - Electronic Health Record Solution (EHRS)
(Canada Health Infoway, 2013) Canadá
SOA ESB
HL7 SNOMED
Programa nacional para la adopción y uso efectivo de la salud digital en
Canadá
Better IT for better health (BIT4health)
(Dietzel & Riepe, 2006) Alemania T.I.
CDA HL7
Utiliza tarjetas electrónicas para el trasporte e interoperabilidad de la
información clínica
National Health Service (NHS) (National Health Service, 2013)
Reino unido
SM WS
SNOMED Clinical
Terms V. 3. Read Codes
V. 2. CDA HL7
Programa para mantener y desarro-llar la infraestructura nacional de TI
del NHS
National Health Information Infrastructure (NHII)
(Safety, Aspden, Corrigan, Wolcott, & Erickson, 2004)
E.E.U.U.
sistema fede-rado
/descentralizado
SOA
HL7 openEHR
SNOMED - LOINC
NDF-RT UMLS DICOM
Utiliza el concepto de tres dimensio-nes: Personal de la salud, Proveedores de la salud y
Población de la salud
Sistema Único de Salud (SUS)
(Indarte & pazos gutiérrez, 2012) Brasil
servicios web SOAP
openEHR HL7 CDA
OASIS WS-Security
Marco de interoperabilidad de in-formación en salud para los niveles
municipal, estadual y federal del SUS
Sharable EHR (Harno & Ruotsalainen, 2006)
Finlandia EHR distribui-
do SOA
HL7 CDA
Información en salud generada, mantenida y preservada por diferen-
tes proveedores de servicios de salud
Tabla 9. Comparativo proyectos de EHR
39
3. APORTES DEL PROYECTO Y PROCESO DE INGENIERÍA
En esta sección se presentan los resultados del proceso de investigación realizado
para el diseño de la arquitectura para la interoperabilidad de la EHR para pacien-
tes en situaciones de emergencia. Algunos de los aportes logrados en el desarro-
llo del proyecto fueron presentados y publicados en diferentes eventos y revistas
de investigación.
40
3.1. CONTEXTO DEL PROYECTO
En el presente proyecto se abordó el problema de falta de acceso oportuno a la
EHR de los pacientes atendidos en situaciones de emergencia. Como solución a
este problema se propuso una arquitectura que posibilita la interoperabilidad de la
EHR y la integración de los diferentes actores del ecosistema de salud. Con la in-
tegración se logra la consolidación de una EHR, mediante la implementación de
un sistema que soporte una PHR regulada como un servicio en la nube, denomi-
nado Health Catalogue Repository (HCR). El contexto que se contempla dentro del
presente proyecto se ilustra en la Figura 11.
Figura 11. Diagrama de contexto del ecosistema de salud
En el HCR, se incluyó el modelo conceptual de PHR regulada (Villa, Cabezas, &
Cruz, 2015) como componente principal para el manejo de la información clínica
de las personas. La PHR regulada toma como base los registros médicos consig-
nados en los EMR de las IPS para lograr la consolidación de la Historia clínica del
paciente. El acceso a la información clínica por parte del personal asistencial, es
autorizado por cada usuario, quienes son propietarios de su información clínica. La
regulación está dada para que el usuario propietario de la información pueda ges-
tionar el acceso y registro de la información clínica, pero que no pueda modificar o
alterar los registros clínicos consignados por el personal asistencial, tal como se
ilustra en la Figura 12. El HCR adopta los conceptos propuestos por el modelo
41
HRB (Gold & Ball, 2007), eHaaS (Black & Sahama, 2014), PHR, EMR y EHR
(Alliance et al., 2008), a la vez que apunta a ser una alternativa de e-Health para
los países en desarrollo que quieren avanzar en la sistematización de forma esca-
lonada, estableciendo componentes de servicio de acuerdo a las necesidades es-
pecíficas del entorno, permitiendo que se generen costos sólo por los recursos
que son usados, y permite la integración de los sistemas de información (HIS) de
las instituciones de salud.
Figura 12. Modelo Conceptual de PHR Regulada
3.2. CONJUNTO DE MÉTODOS APLICADOS
Para el desarrollo del presente trabajo, se tomaron como referencia métodos apli-
cables en cada una de las actividades del diseño arquitectónico para establecer un
procedimiento ordenado y sistemático que permitió alcanzar los objetivos propues-
tos en el diseño de la arquitectura para la interoperabilidad de la EHR. Las tareas
realizadas para cada una de actividades del diseño y los métodos aplicados se
presentan en la Figura 13.
42
Figura 13. Métodos aplicados durante el proyecto
3.3. DEFINICIÓN DE REQUISITOS DE LA ARQUITECTURA
La arquitectura del HCR satisface los requisitos fundamentales para la interopera-
bilidad de la información clínica. El HCR toma en cuenta los requisitos funcionales,
los atributos de calidad y las restricciones detectadas en el proceso de elicitación
de requisitos.
3.3.1. Elicitación de requisitos
Los requisitos de la arquitectura se identificaron mediante la ejecución de activida-
des de:
Entrevistas realizadas a un prestador de servicios en salud que atiende
emergencias
Revisión de la literatura referente a sistemas de historia clínica
Revisión de la normatividad expedida por el gobierno nacional asociada a la
historia clínica y los sistemas de información en salud.
Las fuentes de información del proceso de elicitación de requisitos se presentan
en la Figura 14 y a continuación se relacionan los resultados obtenidos de cada
una de las actividades realizadas.
43
Figura 14. Fuentes de información del proceso de elicitación de requisitos
3.3.1.1. Requisitos identificados en la literatura
Las necesidades prioritarias de interoperabilidad entre los sistemas de información
salud se realizaron con base en una revisión entre diferentes trabajos de investi-
gación de la literatura (Gajanayake, Iannella, & Sahama, 2011), (Sahama,
Simpson, & Lane, 2013), (Hill & Powell, 2009), (Oude Nijeweme - d’Hollosy, van
Velsen, Huygens, & Hermens, 2015), (Michalas, Paladi, & Gehrmann, 2014),
(Fernández-Alemán, Señor, Lozoya, & Toval, 2013), (Bannerman, 2010), donde se
encontraron coincidencias entre los requisitos para soluciones de EHR. Estos se
resumen en la Tabla 10.
REQUISITOS ATRIBUTO DE CALIDAD
Uso de estándares de salud Incluir sistemas Legados Intercambio de la información clínica, administrativa y de afiliación del paciente
Interoperabilidad
Información disponible 7 x 24 x 365 Cumplimiento de los acuerdos de niveles de servicio Acceso a registros médicos, previa validación de privilegios
Disponibilidad
Ajuste de los funcionalidades a los cambios normativos Incluir nuevas funcionalidades sin afectar el sistema
Mantenibilidad
Confidencialidad de información sensible Autenticación de usuarios Proteger la integridad de la historia clínica.
Seguridad
Niveles de respuesta óptimos Consulta oportuna de los registros médicos
Desempeño
Soportar picos de transacciones Adaptarse a diferentes entornos
Adaptabilidad
Facilidad de uso Usabilidad
Sistema auto-sostenible Reducir costos del equipo de TI. Mejorar relación costo/beneficio
Sostenibilidad
Cumplimiento de las leyes nacionales e internacionales Cumplimiento de los acuerdos interinstitucionales
Funcionalidad
Tabla 10. Requisitos de la EHR
44
3.3.1.2. Requisitos identificados en la normatividad
Por otra parte, para el proceso de elicitación de requisitos, se realizó una revisión
de la normatividad que rige el sistema de salud colombiano (MINSALUD, 2016)
donde establecen algunos de los requisitos incorporados en la arquitectura pro-
puesta. El gobierno de Colombia desde el año 2010 está gestionando el proyecto
de reforma al actual sistema de salud. En el año 2011 el Ministerio de la Protec-
ción Social expide la ley 1438, en la que se dictan los lineamientos generales de la
reforma al sistema (MinSalud, 2011). Esta reforma incluye artículos que contem-
plan la adopción de sistemas de información para mejorar la prestación del servi-
cio, mediante la integración de la información. Así pues, existe legislación que es-
tablece la necesidad de implementar sistemas para la interoperabilidad de los sis-
temas de salud en Colombia, pero hace falta que se tomen decisiones en la defini-
ción de las políticas que muestren un panorama claro y que guíe el desarrollo de
los sistemas.
Los requisitos identificados en la normatividad fueron asociados con los atributos
de calidad que la arquitectura soporta desde la perspectiva de los sistemas, tales
como escalabilidad, desempeño, flexibilidad, distribución, cumplimiento de están-
dares, orientación a procesos de negocio, cumplimiento de normativas y servicios
de seguridad. Estos requisitos se presentan en la Tabla 11.
Norma Requisitos Atributos de Calidad
Decreto 2174 de 1996 Sistema de información de oferta de servicios Interoperabilidad
Ley 1995 de 1999 Confidencialidad, seguridad e integridad de la historia clínica Seguridad
Ley 1438 Artículo 12 Herramientas para uso de registros electrónicos de salud Modularidad
Ley 1438 Artículo 60 Redes integradas de servicios de salud Interoperabilidad
Ley 1438 Artículo 63 Mecanismos para la referencia y contra-referencia Funcionalidad
Ley 1438 Artículo 63 Sistema integral único de información de todos los actores de la red Interoperabilidad
Ley 1438 Artículo 64.7 Acceso a la información clínica por equipos básicos de salud Disponibilidad
Ley 1438 Artículo 64.10 Esquemas de comunicación electrónica Interoperabilidad
Ley 1438 Artículo 112 Historia clínica única electrónica obligatoria Funcionalidad
Ley 1438 Artículo 113 Conectividad de las instituciones vinculadas con el sector de salud Interoperabilidad
Ley 1438 Artículo 114 Instituciones del SGSSS: información confiable, oportuna y clara Confiabilidad
Tabla 11. Requisitos asociados a la normatividad colombiana
3.3.1.3. Requisitos identificados a través de entrevistas
Para los requisitos del negocio se realizaron entrevistas al personal de una entidad
que presta el servicio de atención médica a domicilio, atención de urgencias y
emergencias, donde se identificaron las necesidades y expectativas que debería
contemplar la arquitectura de HCR. Los instrumentos de recolección de informa-
ción fueron: una encuesta y un documento de caracterización utilizado durante las
visitas a la institución de salud que atiende pacientes en situaciones de emergen-
45
cia. La encuesta incluyó preguntas estructuradas que evaluaban los componentes
historia clínica, frente a los principios de integralidad, secuencialidad, racionalidad
científica, disponibilidad, oportunidad, seguridad, pertinencia, continuidad, indivi-
dualización y utilidad. La encuesta se diligenció con el fin de conocer los compo-
nentes que se deben considerar en la historia clínica para la evaluación, diagnósti-
co, tratamiento, seguimiento y control en la atención de pacientes en situación de
emergencia, a partir de las experiencias de los profesionales en dicha área.
Los requisitos prioritarios que se identificaron están relacionados con la disponibi-
lidad de la información tomando en cuenta las condiciones de la prestación del
servicio de emergencias médicas, el soporte para la toma de decisiones en la
atención, los tiempos de respuesta que permitan un acceso oportuno a la EHR, la
facilidad en el manejo de la EHR y disponer de mecanismos de seguridad en el
acceso y gestión de la información de la EHR. La consolidación de los requisitos
identificados a través de entrevistas asociados a atributos de calidad, se presentan
en la Tabla 12.
No. REQUISITO ATRIBUTO DE
CALIDAD
ARQ01 El sistema debe comunicarse con sistemas de información de las institucio-nes de salud y dispositivos médicos para integrar los registros médicos a la EHR del paciente
Compatibilidad
ARQ02 El acceso a los datos debe ser de forma segura y con autorización del pa-ciente. Se debe utilizar mecanismos para identificación y autenticación.
Seguridad
ARQ03 El sistema debe permitir incorporar a futuro nuevas funcionalidades o la modificación de las funcionalidades existentes sin afectar el funcionamiento general del sistema
Modificabilidad
ARQ04 El sistema debe permitir almacenar documentos que hacen parte de la EHR en diferentes formatos: XML, PDF, DOC, XLS, TIFF, JPG
Compatibilidad
ARQ05 La disponibilidad del sistema de EHR debe ser continua con un nivel de servicio para los usuarios de 7 días por 24 horas, deberá contar con sistema de alarma cuando el sitio esté fuera de servicio.
Disponibilidad
ARQ06 El sistema de EHR debe ser capaz de manejar al menos 100 usuarios concurrentes en ciertos periodos de tiempo, garantizando que las transac-ciones se realicen sin pérdida de información
Confiabilidad
ARQ07 El sistema debe responder a las solicitudes de servicio del EHR en un tiem-po de 2 segundos en promedio y nunca exceder los 5 segundos.
Desempeño
ARQ08 El sistema debe permitir el intercambio de información a través de diferen-tes estándares de interoperabilidad de información clínica tales como HL7, openEHR, DICOM,
Interoperabilidad
ARQ09 El sistema se debe desarrollar para funcionar en diferentes plataformas y debe permitir el acceso desde diferentes dispositivos
Portabilidad
ARQ10
El sistema deberá tener un registro de logs que contenga todas las transac-ciones realizadas en sistema, los errores y registros de accesos no autori-zados al sistema que permita realizar auditoría y trazabilidad de las opera-ciones realizadas con la EHR de los pacientes.
Confiabilidad
ARQ11 El sistema de EHR para pacientes en situaciones de emergencia debe ser capaz de soportar los picos transaccionales, en el momento que la deman-da de servicios de la EHR así lo requiera
Escalabilidad
ARQ12 El sistema presentará una interfaz de fácil manejo para los usuarios, com-plementada con un buen sistema de ayuda.
Usabilidad
ARQ13 El sistema debe cumplir con la normatividad legal vigente para el acceso, administración y control de la EHR de los pacientes
Funcionalidad
ARQ14 El sistema debe garantizar la consistencia de la información de la EHR en caso de ocurrencia de un fallo , a través de mecanismos de recuperación y sincronización de datos
Confiabilidad
Tabla 12. Requisitos identificados a través de entrevistas
46
Además, como resultado de las entrevistas se logró identificar restricciones pro-
pias de la atención de paciente en situaciones de emergencia, como el tiempo de
la atención, los canales y medios de comunicación, las habilidades tecnológicas
de los usuarios, y la preocupación de los usuarios por la sostenibilidad de la plata-
forma tecnológica que soporte la interoperabilidad de la EHR. La consolidación de
las restricciones identificadas en las entrevistas se presenta en la Tabla 13.
No. RESTRICCIÓN TIPO
ARQ15 El sistema debe proteger la información personal y los registros asociados a la historia clínica.
Información sensible
ARQ16 La arquitectura debe permitir que las implementaciones con múltiples lenguajes, apro-vechando sus fortalezas y optimizando recursos.
Desarrollo
ARQ17 La arquitectura debe garantizar la sostenibilidad del sistema Sostenibilidad
ARQ18 El sistema debe cumplir con la normatividad legal vigente Normatividad
ARQ19 El sistema debe adoptar estándares para la interoperabilidad de la EHR principalmente HL7 y openEHR.
Estándares
ARQ20 Se debe cumplir con los tiempos establecidos por la ley para el establecimiento de mecanismos de interoperabilidad e integración de la EHR
Tiempo
ARQ21 La inversión inicial debe ser la mínima posible que garantice el crecimiento progresivo y la escalabilidad del sistema de EHR
Costo
Tabla 13. Restricciones de la arquitectura para la interoperabilidad de la EHR
3.3.2. Drivers de la arquitectura
Para la definición de los drivers de la arquitectura para la interoperabilidad del
EHR, se realizó un compendio de las inquietudes compartidas por los entrevista-
dos, los requisitos y restricciones identificadas en cada una de las fuentes del pro-
ceso de elicitación de requisitos. Este proceso se realizó con la participación de
los miembros del equipo de investigación LIDIS de la Universidad San Buenaven-
tura y los funcionarios de una entidad prestadora de servicios de atención de
emergencias, siguiendo los lineamientos establecidos por el método QAW
(Barbacci et al., 2003).
En esta fase del proyecto, los requisitos asociados a atributos de calidad, fueron
refinados para establecer los escenarios donde se especifique con más detalle el
alcance del atributo de calidad requerido. Como resultado de este proceso se ob-
tuvieron los siguientes productos:
Drivers de la arquitectura que permita la interoperabilidad de la EHR basa-
dos en terminología de la norma ISO/ICE 25010 (International Organization
For Standardization, 2011), los cuales se presentan en la Tabla 14.
Escenarios asociados a los drivers identificados, los cuales se consolidaron,
priorizaron y refinaron, se presentan en la Tabla 15.
47
DRIVER JUSTIFICACIÓN
Compatibilidad Lograr la interoperabilidad de los registros médicos entre los distintos sistemas de información clínica es el tema prioritario que debe resolver la arquitectura, mediante el uso de estándares que contemple la integración de la información de los sistemas legados existentes en las IPS.
Confiabilidad Es necesario lograr altos niveles de disponibilidad debido al contexto del negocio. La atención de emer-gencias requiere el acceso oportuno a la EHR en cualquier momento y desde cualquier lugar. Los fallos están controlados y la probabilidad de ocurrencia es mínima.
Mantenibilidad
La arquitectura debe soportar las modificaciones y agregar nuevas funcionalidades, con un bajo impacto en el funcionamiento general del sistema, de acuerdo a los cambios normativos relacionados con linea-mientos técnicos para la interoperabilidad de la EHR, establecimiento de estándares de interoperabili-dad y definición de las condiciones para compartir la información clínica de los pacientes.
Seguridad Al compartir la información de la EHR entre diferentes sistemas, existe un alto grado de exposición, por lo cual podría ser consultada o alterada por personas no autorizadas. Considerando que es información confidencial y sensible, se requieren mecanismos que garanticen la seguridad de la información.
Desempeño
Los tiempos de respuesta al igual que la disponibilidad, son claves para cumplir con las expectativas del contexto del negocio. La complejidad de alcanzar altos niveles en el desempeño está impactada por el volumen y tipos de información que maneja la EHR y las operaciones que requieren que se ejecuten de forma secuencial, donde se debe garantizar la integralidad de la información
Adaptabilidad Debido a que existen picos en el número de transacciones hace que la carga incremente, por lo cual se debe permitir escalar el sistema a medida que la demanda de usuarios lo requiera.
Usabilidad La facilidad de uso del sistema permitirá la aceptación y la satisfacción de los usuarios de la EHR.
Funcionalidad La arquitectura debe cumplir con el marco normativo establecido por el gobierno nacional relacionado con el manejo y gestión de la EHR
Tabla 14. Drivers de la arquitectura para la interoperabilidad de la EHR
Atributo de Calidad
Refinamiento del Atributo
Escenario Toleran-
cia Prioridad
Desempeño Throughput
ESC-001. El sistema debe procesar en promedio 20 transacciones por segundo y el tiempo de respuesta espe-rado es de 2 segundos y nunca debe exceder los 5 segun-dos.
+ 3 seg. Alta
Desempeño Escalabilidad
ESC-002. El sistema debe ser capaz de manejar picos transaccionales de 50 usuarios concurrentes en ciertos periodos de tiempo, garantizando que las transacciones se realicen sin pérdida de información
1/100 Alta
Compatibilidad
Interoperabilidad
ESC-003. El sistema debe aceptar y almacenar los datos sin importar su heterogeneidad tecnológica, soportado estándares como HL7, openEHR, DICOM.
Mín. 3 Alta
Confiabilidad Tolerancia
a Fallos
ESC-004. Si al momento de ejecutar una funcionalidad de la EHR se presenta un fallo, el sistema debe controlarlo. No permitir que el error se propague a ningún otro servicio.
Max. 1 Alta
Adaptabilidad Portabilidad ESC-005. El personal asistencial accede a la información de la EHR desde dispositivos móviles, conservando las funcionalidades de la EHR y sin pérdida de rendimiento.
Min. 2 Baja
Seguridad Confidencialidad ESC-006. El sistema de EHR dispone de mecanismos de control acceso que garanticen la seguridad de la informa-ción, impidiendo accesos no autorizados.
1/1000 Alta
Mantenibilidad Cambiabilidad ESC-007. Al modificar un componente de la EHR, el im-pacto no afecta ningún otro componente que no esté rela-cionado con el cambio, ni el funcionamiento general.
Max. 1 Media
Mantenibilidad Modularidad ESC-008. Se desea incorporar una nueva funcionalidad de la EHR. El despliegue de esta funcionalidad no debe afec-tar el funcionamiento de ninguna otra funcionalidad.
Max. 1 Alta
Funcionalidad Idoneidad ESC-009. El sistema responde en todos los casos a las solicitudes de información de la EHR conforme a las nor-mas legales de protección y seguridad de la información.
1/100 Baja
Confiabilidad Recuperabilidad ESC-010. El sistema sufre una falla general. El sistema debe activar los mecanismos de restauración antes de 1 hora, garantizando la integridad de la información.
Max. 15 min. Media
Confiabilidad Disponibilidad
ESC-011. El sistema debe estar habilitado 7X24 para que usuarios autorizados realicen transacciones en la EHR de los pacientes. Se espera la repuesta exitosa en el 99% de los casos.
1% Alta
Usabilidad Operabilidad ESC-012. El sistema dispone de una interfaz que le permi-te al usuario identificar funcionalidades de la EHR apoyado por un sistema de ayuda, previniendo errores.
1/10 Media
Tabla 15. Escenarios del EHR
48
3.4. DISEÑO DE LA ARQUITECTURA
Para establecer la interoperabilidad de la EHR y satisfacer los drivers identificados
como prioritarios, se toma como base arquitecturas de referencia que permitan
cumplir con los requisitos establecidos, adaptarse a las condiciones cambiantes
del negocio y a las exigencias de escalabilidad acorde con el gran volumen de so-
licitudes que el HCR debe soportar. Las solicitudes de servicios contemplan casos
de uso de la atención en salud tales como admisión del paciente, registro de órde-
nes, evoluciones y conductas médicas, registro de resultados de exámenes diag-
nósticos, e incluso la transmisión de datos vitales del paciente en tiempo real,
donde se esperan altos niveles de disponibilidad, flexibilidad y seguridad.
En el marco del desarrollo del proyecto se realizaron varias iteraciones en bús-
queda de los patrones y estilos arquitectónicos que se adaptaran a las condiciones
específicas de este proyecto y que cumplieran los drivers identificados en el pro-
ceso de elicitación de requisitos. A medida que se avanzó en cada una de las ite-
raciones del diseño de la arquitectura, se seleccionaron las tácticas que mejor
respondieran a los drivers identificados. Además, se incluyeron elementos propios
de los sistemas de información en salud, usados como tácticas para dar respuesta
a los drivers y que agregan valor a la arquitectura para lograr la interoperabilidad
de la EHR de pacientes atendidos en situaciones de emergencia. Los resultados y
validaciones de los diseños propuestos se presentan a continuación.
3.4.1. Iteración 1 - Health Catalogue Repository Federado
Como una aproximación inicial, se elaboró una propuesta de arquitectura para la
interoperabilidad de los registros médicos electrónicos bajo un sistema federado
de PHR denominado Health Catalogue Repository (HCR) tomando como base la
arquitectura de referencia SOA (Villa et al., 2015). Los principales componentes
del HCR federado son HRB las EPS, las cuales son fundamentales para la inter-
operabilidad de los registros médicos. En la Figura 15 se presenta el diagrama de
arquitectura de alto nivel del modelo HCR propuesto y sus componentes.
49
Figura 15. Arquitectura de alto nivel del modelo HCR Distribuido
En HCR Federado, los componentes se articulan en una Nube Comunitaria en Sa-
lud (NCS) que permitan gestionar la información en salud, manejar resultados de
exámenes diagnósticos, manejar órdenes médicas y brindar soporte a la toma de
decisiones para el personal que atiende la emergencia. La NCS está conformada
por integración de las nubes de servicios de salud de las EPS, las cuales se en-
cuentran reguladas por la nube central del HCR. La NCS posibilita la integración
gradual de los registros médicos de las entidades de salud en la EHR de los pa-
cientes. La NCS tiene un crecimiento incremental en la medida que las adminis-
tradoras de salud habiliten la infraestructura que soporte los HRB, los usuarios
administren su PHR y las IPS reporten las atenciones de los pacientes mediante el
consumo de servicios en la nube.
La NCS dispone de un Bus de Servicios Empresariales (ESB) que orquesta los
servicios asociados a procesos de prestación de los servicios médicos. El registro
de eventos en el EHR se realiza en diferentes formatos según los estándares de
50
documentos clínicos definidos. El uso de ESB posibilita un bajo acoplamiento, pa-
ra que el HCR no esté asociado directamente a una tecnología específica y pueda
ser implementado en diferentes contextos, por las instituciones que conforman el
sistema de salud de Colombia (tal como se ilustró en la Figura 11).
El HCR ofrece la posibilidad de consolidar una base de referencia para la consulta
de las atenciones médicas realizadas, distribuyendo los costos del almacenamien-
to, infraestructura, seguridad y mantenimiento de la información entre las distintas
entidades de salud que almacenan. Adicionalmente, custodia la EHR de los pa-
cientes. El HCR expone funcionalidades del proceso de atención en salud como
servicios y está basada en SOA como arquitectura de referencia. El HCR cuenta
con mecanismos de replicación de sus nodos centrales y balanceo de carga para
garantizar una alta disponibilidad de los servicios solicitados por los usuarios. El
HCR es responsable de direccionar la información reportada por los usuarios que
consumen los servicios expuestos en el ESB, hacia el HRB de la EPS donde el
paciente se encuentre afiliado. Las EHR´s reposan en los HRB de las EPS que
serán las encargadas de proporcionar la infraestructura para su almacenamiento.
Cada HRB dispone de componentes para la transformación, análisis de calidad,
procesamiento en línea o en lote de la información. El componente Transformador
de la información (Tranforms) es encargado de interpretar y convertir los datos que
son recibidos y solicitados en diferentes formatos, de acuerdo al estándar requeri-
do. El componente de Calidad de Datos (Data Quality) es encargado de validar de
la información contenida en los documentos, con el fin de asegurar el cumplimien-
to de los estándares. El procesamiento de información se realiza en tiempo real
(Streaming) o en lotes (Batch), comparando múltiples flujos de información con
valores referencia o con diccionarios de datos médicos (MDDs). El procesamiento
permite la integración semántica de la información. Además es usada para emitir
alertas cuando se detecte una condición específica en los datos, cuando ocurra un
error o se detecten anomalías de la información reportada.
Al evaluar la propuesta del HCR federado se identifican dos problemas. El primero
relacionado con la dependencia de la participación de las EPS para que se pueda
implementar un sistema basada en esta arquitectura federada. El segundo pro-
blema, relacionado con la dificultad para establecer objetivamente, si el HCR cum-
plía con la restricción de sostenibilidad identificada en la fase de elicitación de re-
quisitos. Por tal razón, se propuso evaluar el diseño de la arquitectura contem-
plando la sostenibilidad como un driver con una prioridad muy alta.
51
3.4.2. Iteración 2 - HCR Sostenible
En una segunda aproximación de la arquitectura para la EHR para pacientes en
situación de emergencia, se propuso el HCR centralizado contemplando la soste-
nibilidad de la EHR como uno de los drivers principales. Sin embargo, en la prácti-
ca, un arquitecto de software puede carecer de las herramientas adecuadas para
evaluar la sostenibilidad de una arquitectura y analizar los problemas asociados a
la sostenibilidad. El objetivo principal de diseñar una arquitectura sostenible para
la EHR es reducir el coste que pudiera generar la deuda técnica. El diseño soste-
nible busca minimizar los riesgos por problemas de actualización, mantenimiento,
errores, deficiente control de versiones, escalabilidad, o integración de nuevas
funcionalidades.
3.4.2.1. Método de diseño de arquitectura sostenible
Para lograr el diseño de una arquitectura sostenible, se propuso el método Sustai-
nable Architecture Driver Design (SADD) (Villa, Cabezas, Lopez, & Casas, 2016).
En la propuesta presentada - SADD - considera ajustes al método ADD, en el con-
texto del diseño arquitectónico sostenible. Los ajustes realizados al método ADD
se ilustran en la Figura 16.
Figura 16. Método SADD
52
SADD es el resultado de combinar los conceptos de la ingeniería de requisitos,
con los principios del manifiesto Karlskrona y el método ADD, como se ilustra en la
Figura 17. SADD se propone como herramienta de apoyo para el arquitecto en
análisis de la sostenibilidad desde sus niveles y dimensiones, que le permita tomar
decisiones alineadas con los requisitos de la arquitectura y la sostenibilidad de la
misma.
Figura 17. Conceptualización del método SADD
La propuesta considera las siguientes adaptaciones en las entradas, el proceso y
las salidas, que se introducen en el método SADD.
En las entradas:
La restricción de sostenibilidad debe ser considerada con la máxima priori-
dad de los drivers.
En el proceso:
En el paso 4 del método ADD "Elija un concepto de diseño que satisfaga a
los drivers de la arquitectura" SADD incluye una modificación, ahora se di-
vide en los cuatro pasos para verificar y refinar los requisitos.
La modificación consiste en analizar y documentar los impactos y oportuni-
dades de sostenibilidad de cada componente arquitectónico en relación con
las cinco dimensiones de sostenibilidad - ambiental, económica, social, téc-
nica e individual - contra los tres niveles considerados por el Manifiesto de
53
Karlskrona - directos, indirectos y a largo plazo. Los 4 pasos son los si-
guientes:
o Paso 4.1. Elija un concepto de diseño.
Elegir un concepto de diseño que satisfaga los drivers.
o Paso 4.2. Construya la matriz de impactos y oportunidades de soste-
nibilidad.
Llene la matriz de impactos para el concepto de diseño para cada
componente. Esta actividad implica identificar impactos y oportuni-
dades del concepto de diseño con respecto a la sostenibilidad, te-
niendo en cuenta las cinco dimensiones y los tres niveles de la sos-
tenibilidad, propuestos en el Manifiesto de Karlskrona. Los impactos
de sostenibilidad son efectos negativos generados por la adopción
del componente seleccionado. Las oportunidades de sostenibilidad
son los efectos positivos del componente incluido en la arquitectura.
Los impactos y oportunidades se definen en términos de recursos fí-
sicos, humanos y ambientales, especificaciones técnicas y atributos
de calidad requeridos por el componente y están relacionados con la
sostenibilidad de la arquitectura en diferentes dimensiones. La planti-
lla para la matriz de impacto de sostenibilidad se ilustra en la Figura
18.
MATRIZ DE IMPACTOS Y OPORTUNIDADES DE SOSTENIBILIDAD <<COMPONENTE>>
<<Componente>> Primer Orden Segundo Orden Tercer Orden
(Diseño y Producción) (Aplicación y Uso) (Uso en el tiempo)
Dimensión Impacto Oportunidad Impacto Oportunidad Impacto Oportunidad
Ambiental <<Impacto>> <<Oportunidad>> <<Impacto>> <<Oportunidad>> <<Impacto>> <<Oportunidad>>
Social <<Impacto>> <<Oportunidad>> <<Impacto>> <<Oportunidad>> <<Impacto>> <<Oportunidad>>
Técnica <<Impacto>> <<Oportunidad>> <<Impacto>> <<Oportunidad>> <<Impacto>> <<Oportunidad>>
Económica <<Impacto>> <<Oportunidad>> <<Impacto>> <<Oportunidad>> <<Impacto>> <<Oportunidad>>
Individual <<Impacto>> <<Oportunidad>> <<Impacto>> <<Oportunidad>> <<Impacto>> <<Oportunidad>>
Figura 18. Plantilla de la matriz de impactos y oportunidades de sostenibilidad
o Paso 4.3. Evaluar la sostenibilidad.
Evaluar el cumplimiento de las restricciones de sostenibilidad y el ni-
vel de adecuación de los conceptos de diseño elegidos. Como he-
rramienta para validar el concepto de diseño elegido, se debe cons-
truir la matriz de impactos y oportunidades de sostenibilidad docu-
mentada en el paso anterior. La selección de un componente que es-
té alineado con la sostenibilidad de la arquitectura es el resultado del
intercambio entre impactos y oportunidades para cada dimensión /
54
nivel. El objetivo de la evaluación es identificar si un componente es-
tá alineado con la sostenibilidad de la arquitectura.
En la propuesta se realiza una evaluación cualitativa para determinar
si se afecta o no afecta la sostenibilidad de la arquitectura. Para de-
terminar el resultado, se analiza si las oportunidades de los compo-
nentes de la matriz (aspectos positivos) son más relevantes que los
impactos (aspectos negativos) por cada una de las dimensiones de
sostenibilidad para cada nivel. Para el análisis cualitativo son más re-
levantes los impactos y oportunidades de tercer nivel (a largo plazo)
que los resultados del segundo nivel y el primer nivel.
Como criterio para decidir sobre la sostenibilidad de la arquitectura al
evaluar varios componentes, los componentes identificados como
principales, deben tener más oportunidades y menos impactos gene-
rados que los otros componentes. No se realiza una evaluación
cuantitativa, dado que estimar una ponderación o un valor de afecta-
ción de la sostenibilidad requiere un análisis multidimensional muy
complejo, lo que implica un gran esfuerzo (Cabezas & Trujillo, 2012),
y no se podría hacer de manera efectiva en un proceso de diseño de
arquitectura.
o Paso 4.4. Repita si es necesario.
Si en la validación de sostenibilidad, el equilibrio entre los impactos
versus las oportunidades está favoreciendo a los impactos, se debe
realizar una nueva iteración seleccionado otro concepto de diseño.
Por lo tanto es necesario regresar al paso 4.1. De lo contrario, conti-
núe con el paso 5.
En las salidas:
Como resultado del análisis de matrices de impactos y oportunidades de
sostenibilidad que se presentaron en la Figura 18, se produce un documen-
to denominado Análisis de sostenibilidad arquitectónica. Este documento es
en esencia, un análisis holístico multidimensional del diseño arquitectónico,
en cuanto a la sostenibilidad. Contiene las justificaciones, así como la com-
pensación inherente, para definir un diseño arquitectónico como sostenible
basado en los resultados de la matriz de sostenibilidad asociada.
55
3.4.2.2. Análisis de la sostenibilidad del HCR Distribuido
Para evaluar la sostenibilidad del HCR, se aplicó el método SADD, el cual fue pro-
puesto en el marco del presente proyecto. En una primera iteración se evaluó la
propuesta del HCR Distribuido, dando como resultado la matriz de impactos y
oportunidades que se presenta en la Tabla 16.
MATRIZ DE IMPACTOS Y OPORTUNIDADES DE SOSTENIBILIDAD DEL HEALTH RECORD BANK DISTRIBUIDO POR EPS
HRB Primer Orden Segundo Orden Tercer Orden
(Diseño y Producción) (Aplicación y Uso) (Uso en el tiempo)
Dimensión Impactos Oportunidades Impactos Oportunidades Impactos Oportunidades
Ambiental Incrementa la generación de
residuos
Incrementa el consumo de
energía en cada nodo de EPS
Incrementa la Huella de car-
bono
Social
Requiere un alto grado de habilidades
del equipo de desarrollo
Requiere leyes que regulen el uso del HRB
Permite acce-der a la infor-mación clínica de los pacien-
tes
Posibilita una
mejor atención en salud
Requiere SLA que contemplen la sostenibilidad de la informa-
ción
Técnica
Involucra diseños com-plejos, difíci-les de admi-nistrar, ges-tionar y man-
tener
Permite el alma-cenamiento distribuido
Implica duplici-dad de informa-ción de salud
Implica obso-lescencia de la plataforma de cada nodo de
EPS
La capacidad del HCR es limitada a la
capacidad de cada nodo del HBR de cada
EPS
Implica distribu-ción de la infor-mación de salud
Perdurabilidad de los docu-mentos de
salud depende de cada nodo
de EPS
Económica
Implica altos costos en los procesos de
diseño
Requiere la inversión de las EPS en licen-
cias de almace-namiento por cada Nodo
Permite la generación de nuevos ingre-sos por servi-
cios incorpora-dos
Requiere de un gran apoyo financiero constante
Permite nuevos modelos de
negocio
Implica una gran inversión de infraestruc-tura de cada
EPS para soportar cada nodo del HRB
Individual
Requiere un diseño cen-trado en el
usuario
Permite conser-var la privaci-dad, confiden-cialidad y pro-tección de la
información del paciente y de los registros
médicos
Requiere de grandes habili-dades tecnoló-
gicas
Ofrece accesi-bilidad en línea a la información
de salud
Implica mayor responsabilidad
en seguridad de la informa-
ción
Tabla 16. Matriz de impactos y oportunidades de sostenibilidad para el HCR Distribuido
56
Como resultado del análisis de la matriz de sostenibilidad del HCR distribuido se
establece que hay impactos relevantes en algunas dimensiones, las cuales se
amplían a continuación:
Ambiental: Establecer una infraestructura en cada EPS para el HBR, impli-
ca un mayor uso de recursos físicos, mayor consumo de energía y por lo
tanto un mayor impacto en términos de la huella de carbono.
Social: Requiere que existan acuerdos de servicio entre las EPS, donde se
establezcan mecanismos de cooperación para garantizar la disponibilidad
de acceso a la información de la EHR contenida en los HBR de cada enti-
dad. En la práctica, este tipo de acuerdos no son fáciles de establecer debi-
do a conflictos de intereses del negocio.
Económica: Establecer una infraestructura en cada EPS para el HBR, im-
plica una gran inversión para cada EPS para adquirir, desplegar y mantener
cada nodo del HRB y las interfaces que permitan la interoperabilidad con el
nodo central del HRB
Técnica: Establecer HBR distribuido implica un mayor esfuerzo para la ges-
tión, el control, el despliegue y mantenimiento del HCR. Las limitaciones de
la arquitectura estarán determinadas en gran parte por la capacidad de los
HRB de cada EPS. La heterogeneidad de los HRB hace que en algunos
casos no sea posible unificar algunos criterios para el tratamiento y alma-
cenamiento de la EHR, lo cual implica establecer mecanismos alternos para
dar cumplimiento a ciertos requisitos de la arquitectura, principalmente rela-
cionados con la seguridad y conservación de la información.
Al evaluar los resultados de la matriz de impactos y oportunidades del HCR distri-
buido se puede establecer que existen impactos que son muy relevantes que afec-
tan considerablemente la sostenibilidad del arquitectura, especialmente en las di-
mensiones ambiental, social, económica y técnica, detalladas anteriormente por lo
cual se debe realizar una nueva iteración con un concepto de diseño diferente.
3.4.2.3. Análisis de la sostenibilidad del HCR Centralizado
Para la segunda iteración se propone una arquitectura del HCR Centralizado,
donde el HRB es un único nodo que almacena toda la información de las EHR de
los pacientes. Concentrar el almacenamiento de la información facilita el control y
acceso a la información, pero requiere de mayores esfuerzos para establecer me-
57
canismos de almacenamiento que ofrezcan un buen desempeño. El resultado de
la matriz de sostenibilidad de la segunda iteración se presenta en la Tabla 17.
MATRIZ DE IMPACTOS Y OPORTUNIDADES DE SOSTENIBILIDAD DEL HEALTH RECORD BANK CENTRALIZADO
HRB Primer Orden Segundo Orden Tercer Orden
(Diseño y Producción) (Aplicación y Uso) (Uso en el tiempo)
Dimensión Impactos Oportunidades Impactos Oportunidades Impactos Oportunidades
Ambiental Disminuye la
generación de residuos
Permite un uso efectivo de los
recursos natura-les
Reduce el im-
pacto a la huella de carbono
Social
Requiere habilidades
para el equipo de desarrollo
Requiere leyes que regulen el uso del HRB Permite acceder
a la información clínica de los
pacientes
Posibilita una
mejor atención en salud
Requiere SLA que contemplen la sostenibilidad de la informa-
ción
Técnica
Implica diseños
complejos
Permite un almacenamiento distribuido, con reutilización de componentes y servicios flexi-bles por de-
manda
Requiere meca-nismos de al-
macenamiento seguro
Permite un acceso opor-
tuno a la infor-mación clínica consolidada
Evita la obso-lescencia de la plataforma en
sitio
Requiere capacidades de desarro-
llo en la nube
Ofrece alta capacidad de
almacenamiento y escalabilidad
Evita duplicar información de
salud
Permite el al-macenamiento perdurable de
documentos de salud
Económica
Implica un costoso
proceso de diseño
Permite una baja inversión inicial en infra-
estructura
Permite la gene-ración de nue-
vos ingresos por servicios incor-
porados Requiere de un apoyo financie-
ro constante
Permite nuevos modelos de
negocio Evita la inver-sión en licencias
para almace-namiento
Individual
Requiere un diseño
centrado en el usuario
Permite privaci-dad, confiden-cialidad y pro-tección de la
información de salud
Requiere de muchas habili-dades tecnoló-
gicas
Ofrece accesibi-lidad en línea a la información
de salud
Requiere ma-yor responsabi-lidad en segu-
ridad de la información
Permite la ubi-cuidad de la información
Tabla 17. Matriz de impactos y oportunidades de sostenibilidad para el HCR Centralizado
Una vez realizado el análisis de la propuesta del HCR centralizado, se determinó
que se había alcanzado una arquitectura sostenible en las dimensiones: ambien-
tal, económica, social e individual, en relación a la primera iteración del HCR dis-
tribuido. Las conclusiones del análisis para estas dimensiones se detallan a conti-
nuación:
Ambiental: Se establece un único HBR que optimiza el uso de recursos,
reduce el consumo energético y disminuye considerablemente el impacto a
la huella de carbono.
58
Social: Se elimina la dependencia de las EPS existente en el modelo dis-
tribuido. Las EPS pasan a ser un actor más de la arquitectura.
Económica: Se logra disminuir la inversión necesaria para la implementa-
ción de una arquitectura centralizada basada en un modelo de servicios,
donde un único HRB se podrá escalonar en la medida que las solicitudes
así lo demanden.
Sin embargo, en el análisis de la dimensión tecnológica se identificaron los si-
guientes impactos:
Tecnológica: Para la dimensión tecnológica se encontraron varios impac-
tos, uno de los más relevantes es el relacionado con la complejidad de la
implementación de un sistema de interoperabilidad de la historia clínica
electrónica bajo la arquitectura del HCR centralizado. A corto plazo, la im-
plementación de un ESB y lograr orquestar una serie de servicios indivi-
duales pero fuertemente cohesionados, resulta una tarea que requiere mu-
chos recursos, lo cual ocasiona a mediano y largo plazo que sea una arqui-
tectura excesivamente costosa de mantener.
En consecuencia, se requiere realizar una tercera iteración dentro del SADD,
para lograr una arquitectura del HCR sostenible, incluyendo la dimensión tec-
nológica, que permita alcanzar los objetivos propuestos, con la menor inver-
sión inicial que sea posible al igual que los costos de mantenimiento.
3.4.3. Iteración 3 - HCR basado en microservicios
Para esta iteración se consideró la arquitectura de referencia de microservicios
(MSA por sus siglas del inglés MicroServices Architecture), luego de evaluar y
descartar la opción de una arquitectura orientada a servicios SOA, por la compleji-
dad, esfuerzo y costo requerido en la implementación del bus de servicios y la or-
questación requerida para su funcionamiento.
La propuesta de HCR se basó en una arquitectura de microservicios debido a las
ventajas sobre el patrón de arquitectura SOA. En microservicios se simplifica la
noción de servicio, la conectividad y el acceso. Además, se sustituyen orquesta-
ciones complejas de los servicios en SOA, por "coreografías‖ de servicios, donde
cada servicio sabe cómo actuar e interactúa con otros servicios, sin necesidad que
alguien los coordine. Esta simplificación, permite concentrar los esfuerzos en lo-
grar los objetivos de negocio planteados y reducir costos en la implementación y
59
mantenimiento del sistema. Las ventajas y desventajas de la arquitectura de mi-
croservicios aplicadas al contexto del HCR se presentan en la Tabla 18.
Ventajas Desventajas
Escalabilidad Alto consumo de memoria
Funcionalidad por módulos independientes Necesidad de tiempo para poder fragmentar dis-tintos microservicios
Aislamiento entre fallos A mayor número de servicios mayor complejidad de gestión
Se puede hacer uso de múltiples lenguajes de desarrollo
Mayor esfuerzo para solucionar problemas de latencia en la red o balanceo de carga
Permite el uso de contenedores Pruebas o testeos complejos
Despliegue rápido de la aplicación Seguridad
Mayor disponibilidad La consistencia de datos requiere mayor es-fuerzo
No requiere orquestación Latencia de red
Reducción de costos de implementación y mantenimiento
Formato de mensajes complejo
Tabla 18. Ventajas y Desventajas de la arquitectura de microservicios para el HCR
Los componentes del HCR deberán estar disponibles para permitir que los usua-
rios de la EHR realicen operaciones que permitan la interoperabilidad y gestión de
la información en salud, manejo de resultados, manejo de órdenes médicas, so-
porte para la toma de decisiones, comunicación y conectividad, soporte al pacien-
te, procesos administrativos, reportes y salud pública y emisión de informes médi-
cos, a través de las funcionalidades expuestas en los componentes de servicio
que se implementen para cada fin específico. A continuación se describen los mi-
croservicios propuestos del HCR.
Identificación y autenticación de usuarios: Los usuarios pueden tener va-
rios identificadores asignados en diferentes dominios de atención, los cua-
les son validados en el catálogo único de pacientes. Este servicio utiliza
mecanismos de seguridad tales como: firmas digitales, medidas biométri-
cas o certificados digitales. Identificar correctamente al paciente reduce el
número de eventos adversos en la atención, facilita el acceso oportuno y
protege la integridad de la información de clínica.
Servicios para la gestión del PHR: Estos servicios permiten a los usuarios
la autogestión de la información médica (Registro, Consulta y Actualiza-
ción). La construcción incremental de la PHR, con la integración de la in-
formación procedente de las IPS, hace posible consolidar una EHR única.
Para gestionar la PHR se debe considerar varios factores, tales como la di-
versidad de dispositivos tecnológicos, de tipos de datos y de tipos de usua-
rio. Además, se deben tener en cuenta los requisitos de arquitectura del
sistema: disponibilidad, flexibilidad, seguridad y usabilidad.
60
Servicios de procesamiento de la información clínica: Los servicios de
transformación de la EHR en diferentes formatos permiten alcanzar la in-
teroperabilidad de los registros médicos a nivel sintáctico y semántico. El
nivel sintáctico se puede alcanzar mediante el uso de estándares, tales
como HL7, en la transmisión de la información. Para el nivel semántico,
con el uso de vocabularios controlados para las diferentes ámbitos de la
atención en salud, tales como SNOMED CT (The International Health
Terminology Standards Development Organization, 2014), LOINC (LOINC,
2008), CIE-10 (World Health Organization, 2017) o NANDA (Westra,
Delaney, Konicek, & Keenan, 2008) y con los catálogos maestros de datos,
de acuerdo con las necesidades locales propias del sistema de salud. La
ejecución de procesos en batch para importar y exportar datos debe ejecu-
tarse a través de la API del servicio del HCR. No se debe eludir la API y ni
acceder a la fuente de datos de forma directa. El beneficio de realizarlo a
través de la API es la escalabilidad que se puede lograr del componente,
permitiendo la ejecución de procesos en paralelo.
Servicios de prescripción de órdenes médicas: Estos servicios facilitan la
dispensación desde farmacias autorizadas, eliminando el uso de papel. Es-
te proceso optimiza tiempo y costos de dispensación de medicamentos.
Los medicamentos se envían directamente al lugar de residencia del pa-
ciente, evitando desplazamientos innecesarios.
Servicios de Registro y consulta de resultados de exámenes diagnósticos:
Permiten que las IPS reporten los resultados de procedimientos diagnósti-
cos. Disponer de los resultados oportunamente permite a los profesionales
de la salud tomar mejores decisiones basados en la evidencia. Esto impac-
ta en la calidad de la prestación de servicios, evita que se realicen exáme-
nes duplicados y se optimiza el uso de recursos físicos y financieros del
sistema de salud.
Servicios de notificación: Los servicios de notificación permiten el envío de
mensajes de citas y exámenes médicos programados, información de las
actividades de promoción y prevención de acuerdo con la edad y sexo del
usuario e información de programas especiales para el tratamiento de en-
fermedades crónicas. Son servicios de valor agregado en la atención de
los afiliados para una mejor atención, reduciendo filas y tiempos de espera
para realizar trámites.
61
Servicios de consulta para análisis de datos: El HCR involucra un gran vo-
lumen de datos. Estos datos son de interés en la medida que pueden ali-
mentar procesos de minería de datos. Al implementar estrategias de mine-
ría de datos se puede obtener información de gran valor que ayude a la de-
tección de patrones ocultos. Esta información resultante importante para
establecer planes de prevención de enfermedades y generar estudios para
la mejor atención y tratamiento de las enfermedades. El acceso a los datos
está regulado y establece acuerdos de seguridad para obtener la autoriza-
ción del paciente. Se considera el uso de técnicas de registros anónimos
para reportar la información que proteja la confidencialidad de la informa-
ción de la EHR.
En la Figura 19 se presenta el diagrama de arquitectura de alto nivel del modelo
HCR basado en microservicios y sus componentes.
Figura 19. Arquitectura alto nivel del HCR basado en microservicios
62
3.4.3.1. Análisis de la sostenibilidad del HCR Microservicios
Los resultados del análisis de sostenibilidad del HCR basado en microservicios se
presentan en la Tabla 19.
MATRIZ DE IMPACTOS Y OPORTUNIDADES DE SOSTENIBILIDAD DEL HEALTH RECORD BANK EN MICROSERVICIOS
HEALTH RECORD
BANK
Primer Orden Segundo Orden Tercer Orden
(Diseño y Producción) (Aplicación y Uso) (Uso en el tiempo)
Dimensión Impactos Oportunidades Impactos Oportunidades Impactos Oportunidades
Ambiental Disminuye la gene-ración de residuos
Permite un uso efectivo de los
recursos natura-les
Reduce el im-
pacto a la huella de carbono
Social
Requiere habilidades para el equi-po de desa-
rrollo
Evita la dependen-cia entre las institu-
ciones
Requiere leyes que regulen el uso del HRB Permite acceder
a la información clínica de los
pacientes
Posibilita una
mejor atención en salud
Requiere SLA que contemplen la sostenibilidad de la informa-
ción
Técnica
Implica re-dundancia de
pequeñas porciones de
lógica de negocio
Permite un almace-namiento distribui-
do, con reutilización de componentes y servicios flexibles
por demanda
Requiere meca-nismos de al-
macenamiento seguro
Permite un acceso opor-tuno a la EHR consolidada
Evita la obso-lescencia de la plataforma en
sitio Simplificar concep-tos de servicios,
conectividad y ac-ceso
Facilita la Man-tenibilidad
Permite el uso de diferentes lenguajes
de programación
Facilita el des-pliegue de
componentes de servicio
Facilita el re-emplazo de
componentes de servicio obsoletos
Requiere capacidades de desarrollo
en la nube
Elimina las necesi-dades de orquesta-
ción de servicios
Ofrece una alta capacidad de alma-cenamiento, proce-
samiento y escalabi-lidad
Permite el al-macenamiento perdurable de
documentos de salud
Económica
Permite el desarro-llo de componentes por separado, divi-
diendo los costos de inversión
Permite la gene-ración de nue-
vos ingresos por servicios incor-
porados Requiere de un apoyo financiero
constante
Permite nuevos modelos de
negocio Permite una baja
inversión inicial en infraestructura
Evita la inver-sión en licencias
para almace-namiento
Individual
Requiere un diseño cen-trado en el
usuario
Permite privacidad, confidencialidad y protección de la información de
salud
Requiere de muchas habili-dades tecnoló-
gicas
Ofrece accesibi-lidad en línea a la información
de salud
Requiere mayor responsabilidad en seguridad de la información
Permite la ubi-cuidad de la información
Tabla 19. Matriz de impactos y oportunidades de sostenibilidad HCR microservicios
63
Al evaluar la sostenibilidad de la Arquitectura del HCR basada en microservicios,
se encuentra que se conservan la mayoría de las oportunidades del modelo cen-
tralizado basado en SOA, y adicionalmente se incluyen nuevas oportunidades
asociadas a las dimensiones tecnológica y económica. Esto debido en gran medi-
da a la naturaleza desacoplada de los componentes, la facilidad de implementa-
ción y despliegue, la detección de fallos y la eliminación de la necesidad de or-
questación de los servicios propia de la arquitectura de microservicios, caracterís-
ticas que están relacionadas con la, portabilidad, confiabilidad y mantenibilidad,
atributos que están asociados a la sostenibilidad de la arquitectura A continuación
se presenta el análisis realizado a la matriz de impactos y oportunidades de soste-
nibilidad.
Técnica: Simplifica la construcción de los servicios que ejecutan una fun-
ción determinada, facilitando su testeo. Un servicio puede implementarse
con la tecnología y herramienta que mejor se adecue a las necesidades
(―Polyglot Programming‖ las aplicaciones se deben escribir en una mezcla
de lenguajes para explotar sus mejores características). Facilita el desplie-
gue continuo de los servicios independientes, donde pueden trabajar múlti-
ples equipos de desarrolladores. En el caso que un servicio deje de funcio-
nar, solo afectará las partes que dependen directamente de él (si las hay),
mientras el resto del sistema se mantiene estable.
Económica: El escalonamiento de la arquitectura puede ser por servicio de
manera independiente. Podemos escalar solamente los servicios que se
requieran, no es necesario escalar todos. Lo cual impacta positivamente en
los costos de funcionamiento del HCR, esto alienado a las restricciones de
sostenibilidad establecidas para la arquitectura del sistema.
Uno de los impactos relevantes que conlleva los microservicios es la redundancia
de pequeñas porciones de la lógica de negocio debido a que los servicios son in-
dependientes y aislados. El aislamiento entre servicios no permite reutilizar funcio-
nalidades existentes y mantener el principio DRY (Hunt & Thomas, 2000).
El uso del método SADD, apoyó la toma de decisiones arquitecturales. Al realizar
el balance de los impactos y oportunidades que ofrece el HCR Centralizado basa-
do en microservicios, se determina que las oportunidades a mediano y largo plazo
son más relevantes que los impactos. Este análisis permitió determinar que el
HCR Centralizado basado en microservicios cumplió con los criterios de sostenibi-
lidad requeridos y en general, con los drivers establecidos para la arquitectura que
permita la interoperabilidad de la EHR para pacientes en situaciones de emergen-
cia.
64
3.5. VISTAS DE LA ARQUITECTURA
En la presente sección se presentan los diagramas de la arquitectura de sistema
del HCR que fueron elaborados para identificar los patrones y estilos adoptados
en el diseño de la arquitectura para lograr la interoperabilidad de la EHR. Los
componentes y relaciones de la arquitectura del HCR se listan y describen. La dis-
cusión alrededor de las decisiones arquitectónicas se realiza en conjunto con el
análisis de los resultados de la validación de la arquitectura del HCR y los resulta-
dos del proceso de evaluación de la sostenibilidad.
3.5.1. VISTA DE DESPLIEGUE
En la Figura 20 se presenta el diagrama de componentes de contexto general de
la arquitectura del HCR, donde se ilustran los elementos que la conforman y las
relaciones establecidas para permitir la interoperabilidad de la historia clínica elec-
trónica entre los diferentes actores que participan en la atención de pacientes en
situaciones de emergencia.
3.5.1.1. Presentación Principal
Figura 20. Diagrama de Componentes Contexto General
65
3.5.1.2. Catálogo de elementos
A continuación, en la Tabla 20 se listan y se describen los elementos del diagrama
de componentes de la arquitectura del HCR.
Componente Descripción
Configuración
Este componente se encargará de centralizar y proveer remota-mente la configuración a cada microservicio. Esta configuración se mantiene convencionalmente en un repositorio, lo que permiti-rá gestionar su ciclo de vida y versionamiento.
Servicio de registro / descubrimiento
Este servicio centralizado será el encargado de proveer los endpoints de los servicios para su consumo. Todo microservicio deberá estar registrado.
API Gateway
Servidor perimetral para la exposición de servicios. Funciona co-mo un Gateway en el que se expondrán los servicios a consumir (Edge server). Responsable del enrutamiento, composición y la transformación de protocolos. Además permite monitorear fácil-mente el tráfico y uso de los servicios.
Ligthweight Message Broker
Proporciona transporte ligero para acceder a los componentes de servicio mediante mecanismos avanzados de colas de mensaje-ría asíncrona, monitoreo, manejo de errores, balanceo de carga y escalabilidad de los componentes de servicio.
Servicios HCR
Componentes de servicios del HCR para la interoperabilidad de la Historia Clínica Electrónica. Permiten establecer todo tipo de in-teracción con la información asociada a la EHR del paciente, me-diante transacciones, siguiendo las reglas del HRB y cumpliendo con los lineamientos de seguridad y niveles de acceso estableci-dos en el HCR.
Autorización
Permite la autenticación, autorización y la gestión de la informa-ción e identidad de los usuarios del HCR, el cual permite mante-ner una identidad distribuida, disponible para todos los compo-nentes de servicio.
Token Permite generar los token´s que permiten autorizar el acceso a los componentes de servicio del HCR.
Monitorización Permite disponer mecanismos para monitorizar aspectos de los nodos relacionados con el estado y funcionamiento.
Logs Permite establecer un mecanismo centralizado para la gestión de logs de los microservicios.
HIS
Sistema de información de salud de las IPS que gestionan proce-sos clínicos como hospitalización, urgencias, quirófanos, unidad de cuidados intensivos, laboratorio clínico o imágenes diagnósti-cas, que puede interoperar bajo estándares como HL7, SOAP/XML, o REST/JSON
RIS Permite reportar información de estudios radiológicos realizados al paciente.
Dispositivos Médicos Corresponde a los dispositivos médicos que generan datos clíni-cos con los cuales se puede interoperar para compartir su infor-mación.
Tópicos Permite que las aplicaciones o subsistemas se suscriban para recibir información de otros subsistemas. Este sistema hace uso del patrón publicador-suscriptor
66
Componente Descripción
DWH Permite el análisis de información para la toma de decisiones.
Documentos Financieros Información administrativa correspondiente a facturación, tarifas y glosas.
Documentos Administrativos Información administrativa del proceso de atención, autorizacio-nes, consentimientos informados o Peticiones de servicio.
MPI Encargado de resolver el problema de múltiples identificadores en diferentes dominios para un mismo usuario, permitiendo la ges-tión de los datos demográficos del paciente.
MII Permite la centralización, indexación y gestión de los datos de las instituciones de salud
MPHI Permite la centralización, indexación y gestión de los datos de los profesionales de la salud
PACS Permite el almacenamiento e indexación de imágenes médicas.
LABS Permite el almacenamiento e indexación de resultados de exá-menes diagnósticos de laboratorio.
BD Sql Permite la persistencia de datos estructurados, establecimiento de relaciones entre las estructuras de datos y la consulta de la información clínica.
BD NoSQL Permite manejar grandes cantidades de información clínica y el almacenamiento de objetos como bases de datos documentales.
APP Todas las aplicaciones que se ejecutan en smartphones, tablets u otro dispositivo móvil.
Terminología Componente centralizado que permite la gestión de los estánda-res de terminología clínica tales como: SNOMED, LOINC, CIE-10, CUMS, CUPS y ATC.
Web Services Servicios de interoperabilidad de registros médicos basados en estándares, tales como HL7, openEHR o DICOM.
PHR Permite al usuario consultar y gestionar su historia clínica y admi-nistrar los permisos para la consulta y registro por parte del per-sonal asistencial
Balanceador Este patrón de implementación permite el balanceo de carga en-tre distintas instancias de forma transparente a la hora de consu-mir un servicio.
Circuit breaker
Mediante este patrón se consigue que los fallos no se propaguen en cascada por todo el pipeline de llamadas, y poder gestionar el error de forma controlada a nivel local del servicio donde se pro-dujo (Tolerancia a fallas).
Tabla 20. Catálogo de elementos de la arquitectura HCR
3.5.1.3. Guía de variabilidad
En la Tabla 21 se presentan los puntos de variación de la arquitectura del HCR de
acuerdo a las condiciones establecidas y se especifica el momento de asociación
para su adopción.
67
Punto de Va-riación
Elemento o Relación Afectada
Variantes Condiciones Momento de Asociación
Componentes Balanceador Podría estar o no presente Si la estimación inicial de carga no lo requiere
Diseño
Componentes Documentos Administra-tivos, Documentos Fi-nancieros , PACS, LABS
Podrían estar o no Si el alcance de la imple-mentación los requiere
Diseño
Protocolos de comunicación
Relaciones con el API Gateway
Protocolo de transporte y formatos de mensajes es-tandarizados y soportados
Los protocolos son soporta-dos por el componente con el que se necesita integrar o interoperar.
Desarrollo
Tabla 21. Puntos de variación de la arquitectura del HCR
3.5.2. VISTA LÓGICA
En la Figura 21 se presenta el diagrama de secuencia de control de acceso a los
componentes de servicio del HCR. En esta vista se representa la funcionalidad de
control de acceso seguro que el sistema proporcionará a los usuarios de la PHR.
Básicamente se pretende mostrar la secuencia con la cual fluyen los mensajes
entre los componentes de autorización del HCR el Sistema de Órdenes de Com-
pra para obtener el Token y acceder a los servicios del HCR y a los registros clini-
cos desde la PHR.
3.5.2.1. Presentación Principal
Figura 21. Diagrama de secuencia Control de acceso del HCR
68
3.5.2.2. Catálogo de Elementos
En la Tabla 22 se listan y se describen los elementos del diagrama de secuencia
de control de acceso de la arquitectura del HCR.
Elemento Nombre Descripción
Actor Usuario PHR Usuario que realiza peticiones de servicios del HCR a través de la PHR
LifeLine Autorización Componente encargado de la autenticación y autorización de los usuarios del HCR, disponible para todos los componentes de servi-cio
LifeLine Token Componente encargado de generar los token´s de autorización para los componentes de servicio del HCR
LifeLine Servicios HCR Componentes de servicios del HCR que permiten la interoperabili-dad de la PHR
Tabla 22. Catálogo de elementos del diagrama de secuencia de control de acceso del HCR
3.5.2.3. Guía de variabilidad
En la Tabla 23 se presentan los puntos de variación de la arquitectura del HCR de
acuerdo a las condiciones establecidas y se especifica el momento de asociación
para su adopción.
Punto de Variación Elemento o Relación
Afectada Variantes Condiciones
Momento de Asociación
Componentes Token Podría ser un com-ponente externo
Si es requerido Desarrollo
Tabla 23. Puntos de variación de la arquitectura del HCR
3.5.3. VISTA DE PROCESOS
3.5.3.1. Diagrama de Actividades
3.5.3.1.1. Presentación Principal
En la Figura 22 se presenta el diagrama de actividades del proceso de registro de
órdenes médicas reportadas desde un sistema de información de salud, donde se
identifican las actividades y los actores que intervienen en el proceso de validación
y registro de las órdenes médicas.
69
Figura 22. Diagrama de actividades Registro de Ordenes Médicas
3.5.3.1.2. Catálogo de Elementos
En la Tabla 24 se listan y se describen los elementos del Diagrama de actividades
para el registro de órdenes médicas de la arquitectura del HCR.
Elemento Nombre Descripción
Partition HIS
Sistema de información de salud de las IPS que gestionan procesos clínicos que pueden establecer interoperabilidad de los registros médicos bajo estándares como HL7, SOAP/XML, o REST/JSON
Partition Servicios HCR Componentes de servicios del HCR para la interoperabilidad de la Historia Clínica Electrónica
Partition MPI Encargado de resolver el problema de múltiples identificado-res en diferentes dominios para un mismo usuario.
Partition Terminología Componente centralizado para la gestión de los estándares de terminología clínica tales como: SNOMED, LOINC, CIE-10, CUMS, CUPS y ATC.
Partition Logs Permite establecer un mecanismo centralizado para la ges-tión de logs de los microservicios
70
Elemento Nombre Descripción
Initial Node Inicio Inicio del proceso
Activity Final Node
Fin Fin del proceso
Activity Reportar órdenes
médicas Acción realizada en el HIS para reportar las ordenes medi-cas realizadas a un paciente.
Activity Registrar órdenes
médicas Actividades de recepción de órdenes médicas para su regis-tro.
Send Signal Action
Validar Paciente Envía solicitud de validación del paciente.
Activity Validar Paciente Actividades para validar la información del paciente en el índice maestro de pacientes
Accept Event Acction
Recibir Validación Paciente
Acción que consiste en recibir el resultado de la validación del paciente
Send Signal Action
Validar CUMS Envía solicitud de validación de la codificación de los medi-camentos que conforman la orden médica.
Activity Validar CUMS Actividades para validar la codificación de los medicamentos que conforman la orden médica
Accept Event Acction
Recibir Validación CUMS
Acción que consiste en recibir el resultado de la validación del medicamento
Accept Event Acction
Recibir Validación Orden Médica
Acción que consiste en recibir el resultado de la validación general de la orden
Activity Validar Orden Médi-
ca Actividades para validar la información general de la orden médica
Decisión Válida Punto de decisión para determinar si una orden médica cumple con las validaciones
Activity Grabar Orden Médi-
ca Actividades para grabar la orden médica en el HRB e inde-xarla en catálogo de documentos del HCR
Activity Logs Actividades para registrar y reportar errores de validación de las ordenes médicas
Tabla 24. Catálogo de elementos del diagrama de actividades para el registro de ordenes
3.5.3.2. Diagrama de estados - Circuit Breaker
En la Figura 23 se presenta el diagrama de estados para el componente Circuit
Breaker para el control y manejo de fallos. Básicamente se pretende mostrar los
estados y la secuencia en que se ejecutan las llamadas a los componentes de
servicio cuando se presentan fallas de acuerdo al umbral de reintentos y los ti-
meouts establecidos en la configuración. Un mayor detalle del funcionamiento del
componente Circuit Breaker se presenta en la Figura 24 en un diagrama de se-
cuencia.
71
3.5.3.2.1. Presentación Principal
Figura 23. Diagrama de estados Circuit Breaker
3.5.3.2.2. Catálogo de Elementos
En la Tabla 25 se listan y se describen los elementos del diagrama de estados del
patrón para el control de errores - Circuit Breaker de la arquitectura del HCR y en
la Tabla 26 las relaciones entre los elementos que la integran.
Elemento Nombre Descripción
Estado Closed Estado que indica que el componente se está ejecutando exitosa-mente o con fallas por debajo del umbral permitido.
Estado Open Indica que el componente presentó un nivel de fallas en la ejecución que alcanzó el umbral permitido
Estado Half-Open Reintento de ejecución del componente requerido
Tabla 25. Catálogo de elementos del diagrama de estados Circuit Breaker
Estado 1 Estado 2 Relación
Closed Open Ejecución Fallida. Cuando el Umbral fue Alcanzado
Closed Closed Se está ejecutando exitosamente o con fallas por debajo del um-bral permitido.
Open Half-Open Reintento de ejecución del componente requerido
Half-Open Open Indica que el componente reportó fallas al reintentar su ejecución
Half-Open Closed Ejecución Exitosa. Se reinicia el Breaker.
Tabla 26. Catálogo de elementos del diagrama de estados Circuit Breaker
72
3.5.3.3. Diagrama de secuencia - Circuit Breaker
Figura 24. Diagrama de secuencia - Circuit Breaker
73
3.5.3.3.1. Catálogo de Elementos
En la Tabla 27 se listan y se describen los elementos del diagrama de secuencia
para el patrón - Circuit Breaker de la arquitectura del HCR.
Elemento Nombre Descripción
Actor Usuario PHR Usuario que realiza peticiones de servicios del HCR a través de la PHR
LifeLine PHR Permite la gestión, consulta y acceso a la infomación de la EHR
LifeLine API Gateway Componente que permite exponer los servicios. Responsable del enrutamiento, composición y la transformación de protocolos.
LifeLine Circuit Breaker Componente para gestionar el error de forma controlada a nivel local del servicio donde se produjo.
LifeLine HCR Componente de servicios para la gestión de la información clínica
Tabla 27. Catálogo de elementos del diagrama de secuencia del circuit breaker
74
3.6. VALIDACIÓN DE LA ARQUITECTURA
En esta sección se presentan los resultados del proceso de validación de la arqui-
tectura que permite la interoperabilidad de la EHR de los pacientes que son aten-
didos en situaciones de emergencia. De acuerdo a lo propuesto por (Bachmann,
2011), el proceso de validación de la arquitectura se realizó en forma simultánea al
diseño de la arquitectura. Durante el proceso diseño bajo el método SADD, se va-
lidó el diseñó la arquitectura del HCR en cada una de las iteraciones, siguiendo el
enfoque de las revisiones por pares estilo ATAM, apoyado en resultados y el aná-
lisis realizado a la matriz de impactos y oportunidades de sostenibilidad. El análisis
de la matriz permitió validar la sostenibilidad de la arquitectura y además identificar
riesgos asociados a otros drivers diferentes a las sostenibilidad. La validación de
la arquitectura posibilitó la identificación y mitigación de riesgos de manera tem-
prana, mediante el afinamiento de las decisiones arquitectónicas tomadas en la
fase de diseño, con el fin de lograr un mejor balance en el análisis de los tradeoffs.
En la fase final del proyecto, se realiza la validación de la versión final de la arqui-
tectura del HCR con expertos distintos de los que realizaron las revisiones, si-
guiendo prácticas profesionales de SIO S.A.S, como un proyecto interno de la em-
presa. La validación de la arquitectura se realizó con el fin de verificar el cubri-
miento de los drivers de la arquitectura, que se hayan satisfecho las expectativas
de los usuarios identificados en la fase de elicitación de requisitos y la aplicabilidad
de la arquitectura en el contexto del presente proyecto y su adaptabilidad a otros
contextos de prestación de servicios de salud.
3.6.1. RESULTADOS DE LA VALIDACIÓN
Para el proceso de validación de la arquitectura del sistema que permita la inter-
operabilidad de la EHR para pacientes en situaciones de emergencia denominado
HCR, se consideraron los siguientes elementos:
Drivers de la arquitectura: correspondientes a requisitos de negocio de la
EHR, atributos de calidad y las restricciones identificadas en el proceso de
elicitación.
Propuestas arquitectónicas: correspondientes a los patrones, tácticas, ar-
quitecturas de referencia y vistas del diseño de la arquitectura del HCR.
Escenarios: Lista de los escenarios priorizados y refinados asociados a los
atributos de calidad debe contemplar la arquitectura del HCR.
75
Como resultado de la validación de la arquitectura en revisiones por pares estilo
ATAM, realizadas durante el proceso de diseño y la validación de la de la arquitec-
tura con el equipo tecnológico de SIO S.A.S. se obtuvo el árbol de utilidad, el cual
fue usado como herramienta para la priorización y validación del cumplimiento de
los drivers de la arquitectura del HCR. El árbol de utilidad de la arquitectura para el
HCR se presenta en la Figura 25. El proceso de evaluación basada en escenarios
se ejecutó siguiendo los lineamientos del procedimiento establecido por el modelo
de procesos de SIO S.A.S para la validación de una arquitectura.
Figura 25. Árbol de Utilidad de la arquitectura del HCR
76
Cada escenario asociado a cada atributo de calidad fue depurado y priorizado. De
acuerdo con el nivel de prioridad asignado, se analizan los enfoques propuestos
de forma iterativa. En cada iteración del diseño, la revisión por pares, permitió
identificar riesgos que fueron mitigados mediante las tácticas seleccionadas en las
decisiones arquitecturales tomadas en el diseño de la arquitectura del HCR. Pos-
teriormente, se realizó un razonamiento con los puntos sensibles de la arquitectura
identificados y las compensaciones (Tradeoffs) entre los atributos de calidad que
se ven involucrados en cada una de las decisiones arquitectónicas. A continuación
se presenta el resultado del análisis de los escenarios asociados a atributos de
calidad con prioridad alta, en el siguiente orden: en la Tabla 28 el escenario para
compatibilidad, en las Tablas 29 y 30 los escenarios de confiabilidad, en la Tabla
31 el escenario para mantenibilidad, posteriormente, en la Tabla 32 el escenario
relacionado con desempeño, en la Tabla 33 el escenario de adaptabilidad y final-
mente en la Tabla 34 el escenario de seguridad.
Escenario - ESC-003
Las IPS reportan la información en diferentes estándares de interoperabilidad de información clínica tales como HL7, ope-nEHR, DICOM. El sistema debe aceptar y almacenar los datos sin importar su heterogeneidad tecnológica.
Atributo Compatibilidad Subcaracterística Interoperabilidad
Ambiente Operación Normal
Estímulo IPS reportan registros médicos en diversos formatos
Respuesta Registros médicos grabados en el EHR del paciente sin importar la diversidad de los formatos de los registros médicos
Decisiones arquitectónicas Riesgos / No-
Riesgos Sensibilidad Tradeoff
DA-007: Intermediación R1,NR1 S1 T1,T2
DA-008: Conjunto limitado de protocolos de interacción R2, NR1 S1,S2 T1
Razonamiento Con la intermediación de componentes que funcionen como Proxy responsables del enrutamiento de las peticiones de servicio se establecen mecanismos para la interoperabilidad de la EHR bajo distintos estándares. El mediador tiene la ca-pacidad de recibir los registros médicos de un conjunto limitado de estándares (HL7, openEHR o DICOM) y direccionarlo al componente de servicio específico, de acuerdo al estándar requerido, para su tratamiento. El problema de un mediador es que añadirá tareas de administración, pero facilita la implementación de la interoperabilidad y disminuye la exposición de servicios del sistema, favoreciendo la seguridad del sistema.
R1: Aumenta el tiempo y costo del desarrollo
R2: Implica mayor complejidad en la construcción de servicios por cada estándar soportado.
NR1: Corresponde a una táctica de arquitectura para modificabilidad
S1: Entre más componentes, menor desempeño.
S2: Dependerá de interfaces bien definidas por el estándar
T1: Podría afectar el desempeño.
T2: Permite controlar la exposición de los servicios para mejorar la seguridad del sistema
Tabla 28. Análisis de escenario de Compatibilidad - Interoperabilidad
77
Escenario - ESC-004
Si al momento de ejecutar una funcionalidad de la EHR se presenta un fallo, el sistema debe controlarlo. No debe permitir que el error se propague a ningún otro servicio.
Atributo Confiabilidad Subcaracterística Tolerancia a Fallos
Ambiente Error en componente del sistema
Estímulo Ejecución de un componente que presenta un fallo
Respuesta El error es controlado y no afecta el funcionamiento de ninguna otra funcionalidad del sistema
Decisiones arquitectónicas Riesgos / No-
Riesgos Sensibilidad Tradeoff
DA-009: Detección de Fallos R1 S1 T1
DA-010: Monitoreo R2, R3, NR1 S2 T1,T2
Razonamiento Mediante la implementación del patrón Circuit breaker se consigue la protección contra los puntos de integración y el control de fallas en cascadas, capacidades desbalanceadas, y respuestas lentas. Los circuit breakers trabajan de cerca con los timeouts y permiten gestionar el error de forma controlada a nivel local del servicio donde se produjo. El servicio de monitoreo permite disponer de mecanismos para gestionar aspectos de los nodos relacionados con el estado y funcionamiento, permitiendo generar alertas tempranas.
R1: Si no se implementa en todos los componentes de servicio podría ocasionar problemas de integralidad del proceso
R2: Las automatizaciones pueden degradar la funcionalidad, cuando el sistema esté bajo cierto nivel de estrés
R3: El sistema de monitoreo puede generar carga adicional al sistema
NR1. El monitoreo de procesos es una táctica de arquitectura para disponibilidad
S1: Cambios en los estados de circuit breakers deben ser siempre puestos en logs para monitoreo y consultas.
S2: Si la frecuencia de monitoreo es muy alta, podría causar latencias en la operación normal
T1. Se podría afectar el desempeño ya que implican carga adicional de administración
T2. Se podría afectar la seguridad del sistema ya que para monitorear un sistema debe existir una operación que abra un puerto en cada componente (echo). Este puerto puede convertirse en un blanco fácil para los atacantes.
Tabla 29. Análisis de escenario de Confiabilidad – Tolerancia a Fallos
Escenario - ESC-011
El sistema debe estar habilitado 7X24 para que los usuario autorizados realicen transacciones en el EHR de los pacientes. Se espera la repuesta exitosa en el 99% de los casos.
Atributo Confiabilidad Subcaracterística Disponibilidad
Ambiente Operación Normal
Estímulo Registro en la EHR del paciente
Respuesta Operación exitosa en el 99% de los casos
Decisiones arquitectónicas Riesgos / No-
Riesgos Sensibilidad Tradeoff
DA-005: Balanceo de carga R1 S1, S2 T1
DA-010: Monitoreo R2,R3,NR1 S3 T2, T3
Razonamiento El balanceo de carga optimiza la utilización de los recursos del sistema, apoyado en el componente de monitoreo del siste-ma para prevenir posibles fallos, aumentando tiempos de disponibilidad del sistema. (Ver DA-005 en ESC-002). El servicio de monitoreo permite disponer de mecanismos para gestionar aspectos de los nodos relacionados con el estado y funcionamiento, permitiendo generar alertas tempranas (Ver DA-010 en ESC-004)
R1: Implica incremento de la latencia debido al overhead por la administración que le agrega este componente.
R2: Las automatizaciones pueden degradar la funcionalidad, cuando el sistema esté bajo cierto nivel de estrés
R3: El sistema de monitoreo puede generar carga adicional al sistema
NR1. El monitoreo de procesos es una táctica de arquitectura para disponibilidad
S1: Cualquier cambio en alguna regla de un balanceador podría implicar grandes cambios en el sistema.
S2. En condiciones en las que la carga sea baja, el desempeño no será mejorado. Por el contrario, será menor al que se lograría sin un balanceador por el overhead de administración.
S3: Si la frecuencia de monitoreo es muy alta, podría causar latencias en la operación normal
T1. Esta implementación ayudará también con problemas de disponibilidad y escalabilidad.
T2. Se podría afectar el desempeño ya que implican carga adicional de administración
T3. Se podría afectar la seguridad del sistema ya que para monitorear un sistema debe existir una operación que abra un puerto en cada componente (echo). Este puerto puede convertirse en un blanco fácil para los atacantes.
Tabla 30. Análisis de escenario de Confiabilidad – Disponibilidad
78
Escenario - ESC-008
Se desea incorporar una nueva funcionalidad para la interoperabilidad de la EHR. El despliegue de esta funcionalidad no debe afectar el funcionamiento de ninguna otra funcionalidad.
Atributo Mantenibilidad Subcaracterística Modularidad
Ambiente Operación Normal
Estímulo Despliegue de nueva funcionalidad del HCR
Respuesta El despliegue de la nueva funcionalidad se ejecuta en menos de 1 minuto sin afectar ninguna otra funcionalidades del HCR
Decisiones arquitectónicas Riesgos / No-
Riesgos Sensibilidad Tradeoff
DA-003: Diseñar componentes que cumplen un solo propósito R1, R2,R3, NR1 S1 T1,T2, T3
DA-004: Reducir acoplamiento de los componentes R4, NR2 S2 T4
Razonamiento En HCR la arquitectura basada en microservicios permite el diseño de componentes que cumplen una función definida, con bajos niveles de acoplamiento. Los componentes débilmente acoplados permiten adicionar nuevas funcionalidades sin afectar los demás componentes, lo cual incrementa la mantenibilidad del sistema. Para el HCR, esto es muy importante, debido a los cambios constantes en la normatividad del sistema de salud en Colombia y que aún no se han establecido lineamientos técnicos para la interoperabilidad del EHR. Se debe determinar el nivel de granularidad adecuado. La granula-ridad no debe ser muy gruesa para evitar redundancia de la lógica del negocio y no puede ser muy fina para que no se incremente la complejidad de administración y gestión del sistema.
R1: Determinar el nivel adecuado de granularidad de los componentes puede ser un proceso muy complejo
R2: Podría generar redundancia de lógica de negocio
R3: Puede requerir un mayor esfuerzo para mantenimiento
R4: Implica establecer llamadas entre componentes que están correlacionados, incrementando la latencia
NR1: La granularidad de los componentes de servicio no impacta sobre el alcance de los objetivos del EHR
NR2: Corresponde a una táctica de arquitectura
NR3: Cambios normativos pueden ser incorporados sin impactar el sistema en general
S1: Ciertos componentes pueden requerir un gran número de módulos para lograr una funcionalidad completa
S2: Cambios en los requisitos podrían afectar varios componentes de servicio
T1: Mejora la portabilidad e interoperabilidad se puede afectar el desempeño
T2: A mayor granularidad de los componentes de servicio se incrementa la complejidad del sistema
T3: Implica redundancia de lógica de negocio debido a que los servicios son independientes y aislados
T4: Aumentar la mantenibilidad usando componentes desacoplados se puede afectar la integralidad del sistema
Tabla 31. Análisis de escenario de Mantenibilidad - Modularidad
Escenario - ESC-001
Se requiere acceso a la historia clínica del paciente de manera oportuna. El sistema debe procesar en promedio 20 transac-ciones por segundo y el tiempo de respuesta esperado es de 2 segundos y nunca debe exceder los 5 segundos.
Atributo Desempeño Subcaracterística Throughput
Ambiente Operación Normal
Estímulo Médicos consultan la Historia clínica del paciente
Respuesta EHR del paciente en menos de 2 segundos
Decisiones arquitectónicas Riesgos / No-
Riesgos Sensibilidad Tradeoff
DA-001: Priorizar las transacciones de servicios R1, NR1 S1 T1
DA-002: Implementar soluciones de colas de mensajería asíncrona y caché
R2,R3,R4, NR2 S2 T1,T2,T3
Razonamiento Se asegura la atención de todas las peticiones en el tiempo esperado durante la operación normal del sistema, priorizando y segmentando las transacciones de lectura de las de escritura (algoritmos dividir y vencer). El Ligthweight Message Broker proporciona transporte ligero para acceder a los componentes de servicio mediante mecanismos avanzados de colas de mensajería asíncrona, monitoreo, manejo de errores, balanceo de carga y escalabilidad de los componentes de servicio. El uso de soluciones de caché reducirá los tiempos de respuesta.
R1: La priorización implica una actividad más, la cual se debe realizar cuidadosamente para que el resultado de esta decisión sea exitoso
R2: Se podrían exponer algunos datos sensibles del EHR que nunca debe almacenarse en caché,
R3: Implica mayor esfuerzo para mantener la coherencia entre las réplicas de caché y el origen de datos del backend
R4: Implica mayor consumo de recursos
NR1: La priorización y separación de transacciones de lectura y escritura no afecta el funcionamiento del EHR
NR2: Corresponde a una táctica de arquitectura
S1: Ciertas transacciones de lectura podrían requerir colas de mensajería asíncrona
S2: Cambios en la configuración del caché podrían afectar el funcionamiento del componente de servicio
T1: Al aumentar el desempeño del sistema puede afectar la modificabilidad del mismo
T2: Mejora la disponibilidad del sistema
T3: Al aumentar el desempeño se podría poner en riesgo la seguridad de la información
Tabla 32. Análisis de escenario de Desempeño
79
Escenario - ESC-002
El sistema debe ser capaz de manejar picos transaccionales de 50 usuarios concurrentes en ciertos periodos de tiem-po, garantizando que las transacciones se realicen sin pérdida de información.
Atributo Adaptabilidad Subcaracterística Escalabilidad
Ambiente Conexiones concurrentes – pico transaccional
Estímulo IPS reportan registros médicos
Respuesta Registros médicos grabados en la EHR del paciente sin pérdida de información
Decisiones arquitectónicas Riesgos / No-
Riesgos Sensibilidad Tradeoff
DA-005: Balanceo de carga R1 S1, S2 T1
DA-006: Introducir concurrencia R2, NR1, NR2 S3 T2
Razonamiento Cuando exista contención de recursos, el sistema automáticamente localizará un recurso que esté disponible para atender las peticiones, de ser necesario también permitirá su escalabilidad, replicando únicamente los componentes que lo requieran. El manejo de la concurrencia aun con escalabilidad es un factor crítico, puesto que los componentes podrían fallar simultáneamente y podría generar el deadlock sobre los componentes de persistencia, como base de datos tipo RDBMS, situación que podría saturar las conexiones permitidas y afectar la disponibilidad.
R1: Implicar incremento de la latencia en algunos casos, debido al aumento en el overhead de administración que le agrega este componente.
R2. Manejar alta concurrencia implica mayor probabilidad de fallos y mayor complejidad para su resolución.
NR1. La concurrencia es transparente en los Sistemas Operativos, Servidores de Aplicación y los motores de Base de Datos. Esto hace transparente el desarrollo.
NR2. Estas decisiones son tácticas de arquitectura para desempeño y escalabilidad.
S1: Cualquier cambio en alguna regla de un balanceador podría implicar grandes cambios en el sistema.
S2. En condiciones en las que la carga sea baja, el desempeño no será mejorado. Por el contrario, será menor al que se lograría sin un balanceador por el overhead de administración.
S3. Para los casos normales (sistema relajado), la arquitectura podría tener más desgaste computacional.
T1. Esta implementación ayudará también con problemas de disponibilidad y escalabilidad.
T2: Al aumentar el desempeño con tácticas de concurrencia se afecta la modificabilidad y disponibilidad
Tabla 33. Análisis de escenario de Adaptabilidad - Escalabilidad
Escenario - ESC-006
El sistema de EHR dispone de mecanismos de control acceso que garanticen la seguridad de la información, evitando que sea consultada o alterada por personas no autorizadas.
Atributo Seguridad Subcaracterística Confidencialidad
Ambiente Operación Normal
Estímulo Acceso de un usuario al sistema
Respuesta Se valida el acceso, se restringe el acceso a usuarios no autorizados
Decisiones arquitectónicas Riesgos / No-
Riesgos Sensibilidad Tradeoff
DA-011: Autenticación y autorización NR1 S1, S2 T1
DA-012: Limitar exposición R1, NR1 S3 T2
DA-013: Cifrar Datos R2, NR1 S4 T3
Razonamiento Disponer de un componente de autorización centralizado, permite implementar la capa de seguridad de servicios a nivel de API. El componente de autenticación de usuarios emitirá una "credencial" (Token) la cual será entregada a todos los componentes implicados para cada sesión de usuario. El componente de autenticación de usuarios realiza la validación de los privilegios otorgados de acuerdo al tipo de usuario que solicita los servicios (Paciente, profesional de la salud o institución), el nivel de acceso que el usuario haya definido a la información clínica o por el tipo de atención requerido, donde se contemplen reglas excepcionales para el caso de atenciones de emergencia. Con la intermedia-ción de un servidor perimetral para la exposición de servicios que funciona como un Gateway en el que se expondrán los servicios a consumir (API´s), previene el acceso a servicios por usuarios no autorizados. Cifrar los datos implica un gran impacto en el desempeño del sistema. Para protegeré la confidencialidad de la información sensible, se deben desacoplar los datos que deben estar protegidos de los datos de procesamiento e información general. Para el cifrado será necesario establecer límites lógicos entre los flujos de trabajo protegidos y los generales.
R1. Limitar el acceso y la exposición podría eventualmente limitar opciones del negocio
R2. Cifrar la información implica una tarea adicional que afecta el desempeño
NR1. Corresponde a una táctica de arquitectura
S1. Genera dependencia de un componente centralizado de autorización
S2. Un cambio en la configuración de acceso podría dejar inoperables algunos componentes de servicio
S3. Un cambio en alguna política de exposición de servicios podría dejar inoperable al sistema.
S4: Requiere un proceso de identificación de datos sensibles
T1. Se afecta el desempeño porque adiciona overhead computacional
T2. Sistemas limitados afectan la modificabilidad
T3. El costo de la protección de la información afecta el desempeño
Tabla 34. Análisis de escenario de Seguridad - Confidencialidad
80
3.6.2. ANÁLISIS DE LAS DECISIONES DE ARQUITECTURA
Para dar respuesta a los requisitos planteados en el proyecto, se analizaron dife-
rentes aproximaciones arquitectónicas para dar respuesta a los problemas identifi-
cados para lograr el diseño de una arquitectura sostenible que permita la interope-
rabilidad de la EHR en situaciones de emergencia. A continuación se presenta el
análisis de las decisiones arquitectónicas tomadas para satisfacer los requisitos de
acuerdo a las prioridades asignadas y el tradeoff con otros drivers a los cuales im-
pacta.
3.6.2.1. Compatibilidad
El HCR posibilita la integración gradual de los registros médicos de las entidades
de salud en la PHR de los pacientes. Para mantener la compatibilidad con los sis-
temas existentes en las IPS, el registro de eventos en la PHR se realiza en dife-
rentes formatos bajo un conjunto de estándares de documentos clínicos definidos
para la arquitectura del HCR, tomando como referente principal el estándar HL7.
El listado de los estándares soportados por el HCR se presenta en la Tabla 35.
NIVEL TIPO ESTÁNDAR
TÉCNICA Infraestructura en comunicación TCP/IP
SINTÁCTICA
Estándares de sintaxis HTML, XML, JSON
Protocolos de comunicación generales HTTP
Protocolos de comunicación en salud HL7, DICOM, openEHR
SEMÁNTICA Terminología y nomenclatura en salud CIE10, Snomed CT, LOINC, ATC
Modelos de información HL7 RIM, openEHR
ORGANIZACIONAL Arquitectura de comunicación IHE
Tabla 35. Análisis de escenario de Confiabilidad - Disponibilidad
Para soportar el intercambio de información en formatos diferentes a HL7, tales
como DICOM, ISO 13306, openEHR o los establecidos en los acuerdos de servi-
cio interinstitucionales para la interoperabilidad de la EHR, se implementa el pa-
trón proxy el cual se presenta en la Figura 26. El patrón de proxy le permite pro-
porcionar interfaces adicionales a los servicios mediante la creación de un servicio
de contenedor, para luego direccionar las peticiones de servicio al componente de
servicio específico dependiendo del tipo de estándar requerido por la petición. El
servicio contenedor puede agregar funcionalidad adicional al servicio solicitado sin
necesidad de cambiar su código.
81
Figura 26. Patrón proxy para servicios del HCR
3.6.2.2. Mantenibilidad
La arquitectura del HCR basada en microservicios posibilita diseñar componentes
de servicio desacoplados permite que no se afecten los demás componentes al
momento de adicionar nuevas funcionalidades, lo cual incrementa la mantenibili-
dad del sistema. EL HCR dispone de un Gateway que expone los microservicios
asociados a procesos de prestación de los servicios médicos. El uso del patrón
API Gateway, el cual se muestra en la Figura 27, actúa como proxy inverso y po-
sibilita un bajo acoplamiento para que el HCR no esté asociado directamente a
una tecnología específica y pueda ser implementado en diferentes contextos por
las instituciones del SGSSS y particularmente en para este proyecto, por las em-
presas que atienden pacientes en situaciones de emergencia.
Figura 27. Patrón API Gateway
82
La modularidad es un atributo prioritario, debido a los ajustes que deben soportar
los servicios por los cambios constantes en la normatividad del sistema de salud
en Colombia y el riesgo de modificar e incluir servicios porque aún no se han esta-
blecido lineamientos técnicos para la interoperabilidad de la EHR. EL HCR estará
en capacidad de adoptar los lineamientos técnicos de interoperabilidad de la EHR
que el gobierno nacional establezca, reduciendo el impacto para su implementa-
ción y despliegue. La dificultad de la arquitectura del HCR basado en microservi-
cios radica en determinar el nivel de granularidad adecuado. La granularidad no
debe ser muy gruesa para evitar redundancia de la lógica del negocio y no puede
ser muy fina para que no se incremente la complejidad de administración y gestión
del sistema.
3.6.2.3. Confiabilidad
En la arquitectura de microservicios, a diferencia de los enfoques tradicionales,
alcanzar altos niveles de confiabilidad y prevención de fallos implica un mayor ni-
vel de complejidad para medir la disponibilidad debido al gran número de servicios
existentes y las relaciones entre ellos.
Como medida para alcanzar el nivel de disponibilidad del 99% requerido para la
arquitectura de la EHR, se estableció la incorporación de varios patrones en el di-
seño del HCR, que tienen como objetivo optimizar el uso de los recursos, maximi-
zar el desempeño, minimizar el tiempo de respuesta y evitar la sobrecarga de
cualquier recurso.
El patrón de balanceo de carga permite que cada componente de servicio o grupo
de servicios expongan funcionalidades escalables bajo modelos elásticos. El com-
ponente de registro de servicios provee los endpoints para que los servicios del
HCR puedan ser consumidos por los usuarios, por lo tanto, todo servicio deberá
estar registrado. Los componentes de servicio de la EHR se despliegan en conte-
nedores o imágenes que contienen las funcionalidades requeridas por los usua-
rios, pasando por un balanceador que distribuya la carga.
En HCR es posible replicar componentes de servicio ―livianos‖ con mayor carga en
lugar de replicar aplicaciones completas. El balanceador facilita el escalamiento de
forma automática en la medida que se aumente la carga transaccional de determi-
nados servicios de mayor demanda por los usuarios del HCR en un momento es-
pecífico y retornar a su estado inicial cuando la carga haya disminuido.
Otra decisión que se tomó para favorecer la disponibilidad del HCR, fue incluir el
componente para monitoreo del sistema. El componente de monitoreo es respon-
83
sable de detectar las fallas, registrarlas, notificar la ocurrencia, deshabilitar los
componentes que ocasionan la falla de acuerdo a la configuración establecida pa-
ra cada componente y permitir la continuidad del sistema, mientras se solucionan
los problemas. Se consideró el riesgo de afectar el desempeño debido al overhead
por la administración del componente de monitoreo, pero se concluyó que era más
importante controlar los fallos que podrían afectar el funcionamiento general del
HCR.
Entre muchos de los factores que atenta contra la disponibilidad de la EHR, uno
de los más relevantes son los fallos. La disponibilidad no puede verse afectada por
errores no controlados. Como respuesta para controlar fallas se adoptó el patrón
Circuit breaker. Mediante este patrón se busca que cuando ocurra un fallo en un
componente de servicio, este no se propague en cascada hacia otro servicio rela-
cionado, o a todo el flujo de llamadas (Pipeline). Además, el patrón Circuit breaker
permite gestionar de forma controlada el error desde su origen. La implementación
de rutinas de fallo automático tiene que ser parte de cada llamada de servicio. Ba-
jo la premisa que la causa del fallo es transitoria, se contempló la implementación
del patrón de reintentos asincrónicos, con un número dinámico y configurable de
reintentos, basado en metadatos de cada componente de servicio, con el fin de
manejar fallos temporales anticipados cuando se intenta conectar a un componen-
te de servicio y garantizar su ejecución.
En situaciones cuando se trabaje con componentes de servicio más críticos, se
deben establecer tiempos de espera (timeouts) para informar fallos de forma tem-
prana, cuando se exceda el límite establecido. Es clave la determinación de ti-
meouts entre peticiones de microservicios para ejecutar acciones de gestión de
errores. Si algún microservicio no responde en el tiempo máximo pactado definido
en los acuerdos de servicio se ejecutará una acción para el tratamiento de fallo.
Para los fallos relacionados a las colas de mensajería asíncrona, en el caso de un
fallo persistente, los mensajes son direccionados hacia un servicio de compensa-
ción. Los componentes de la arquitectura del HCR relacionados con la confiabili-
dad del sistema se ilustran en la Figura 28.
84
Figura 28. Balanceador de carga de componentes de servicio del HCR
Uno de los riesgos identificados está relacionado con el API Gateway centralizado
como único punto de fallo y los problemas de cuello de botella que esto conlleva.
Para dar solución al problema se propuso que se realice mediante la agrupación
de intermediarios y de la federación de intermediarios. Esto implica implementar
un clúster de API Gateway al dividir el único API Gateway en múltiples instancias,
de acuerdo a las áreas funcionales del HCR, permitiendo repartir la carga entre las
instancias.
3.6.2.4. Desempeño
Debido a la relevancia que tiene la oportunidad de acceso al EHR del paciente en
una atención de emergencia, la arquitectura tiene que ofrecer altos niveles de
desempeño. La naturaleza distribuida de la arquitectura de microservicios no apor-
ta en el desarrollo de aplicaciones de alto rendimiento, debido el overhead inhe-
85
rentemente agregado por la comunicación entre los componentes de servicio dis-
tribuidos. Para mejorar el desempeño de arquitecturas como la requerida para la
interoperabilidad de la EHR, donde son necesarias muchas llamadas entre los
componentes de servicio, y se requiere de invocar a backend externos, se esta-
blece como medidas, la priorización de solicitudes de servicios y el uso de mode-
los de comunicación asíncrona. Todas las peticiones de servicio para la interope-
rabilidad de la EHR deben estar priorizadas. Para tal fin se implementa un media-
dor para la priorización de peticiones, el cual se encarga de poner en cola las peti-
ciones de acuerdo a la prioridad de la solicitud.
La comunicación entre los componentes de servicio de HCR se logra de dos ma-
neras. La primera, para servicios que no son críticos y se desea una respuesta
inmediata del otro servicio, se realiza mediante comunicación directa con peticio-
nes HTTP. La segunda a través de colas de mensajería asíncrona, como solu-
ción de integración y mensajería para microservicios expuestos y conectados a
través de Middleware orientado a mensajes (MOM), implementado en el compo-
nente Ligthweight Message Broker, donde se puede usar una combinación de so-
licitud / respuesta REST y mensajería utilizando el patrón publicación/suscripción,
para servicios críticos donde se requiera mayor control en la ejecución de los ser-
vicios dentro del proceso del registro en la historia clínica del paciente, como se
ilustra en la Figura 29.
En cualquier caso, la cola de mensajería no realiza ninguna orquestación, trans-
formación o enrutamiento complejo. Al usar modelos de comunicación asíncrona,
tales como lo son los servicios de colas mensajería se logra una alta disponibili-
dad, clustering, multiprotocolo y una integración bastante avanzada con otros ser-
vicios.
Figura 29. Colas de mensajería y caché del HCR
86
Como alternativa complementaria a las colas de mensajería, para mejorar el
desempeño de los microservicios, se implementan soluciones de caché. Debido a
la sensibilidad de la información de la EHR, hay que considerar que hay algunos
tipos de datos que nunca debe almacenarse en caché, otros pueden ser almace-
nados en caché de varios niveles. Los aspectos de interfaz de usuario de un mi-
croservicio pueden aprovechar las tecnologías web de alto rendimiento ya dispo-
nibles, como Edge caché, redes de distribución de contenido (CDN) o proxies
HTTP más simples. Todas estas soluciones se basan en la configuración de cadu-
cidad de la caché negociada entre el servidor y el cliente.
Una capa diferente de tecnología de almacenamiento en caché viene en el ba-
ckend. El caso más fácil es utilizar una caché de segundo nivel con un proveedor
JPA o un almacén de datos dedicado en memoria como una capa de almacena-
miento en caché para sus entidades de dominio. El mayor problema es mantener
la coherencia entre las réplicas de caché y entre el caché y el origen de datos del
backend. La implementación de soluciones de caché dependerá de la complejidad
y la criticidad de la información de la EHR que maneje el componente de servicio.
Para reducir la complejidad y mejorar el desempeño, también se separarán las
transacciones de servicios de lectura de la EHR, de las transacciones de servicios
que impliquen escritura sobre la EHR. Esto permite reducir el número peticiones
en cola y de acciones de compensación a realizar, ya que únicamente estarían
dirigidos para los servicios de escritura.
3.6.2.5. Seguridad
Los puntos clave contemplados para dar cumplimiento a seguridad de la EHR son:
Proporcionar protección total de los datos, proteger la EHR en tránsito y en uso,
permitir la gestión del acceso de manera flexible con diversos niveles de acceso y
la capacidad de identificación y autorización que garanticen el acceso a los datos
críticos únicamente a usuarios autorizados. La implementación de estos compo-
nentes permite que el HCR cumpla con las normas de seguridad para la protec-
ción de la información de la EHR, establecidos por los organismos locales
(MINSALUD, 2016) e internacionales tales como: Health Insurance Portability and
Accountability Act HIPPA (CMS, 2003) y European Data Protection Directive
95/46/EC (European Parliament, 1995).
El acceso a los registros médicos en el HCR estará regulado. El HRB expone me-
canismos que garantizan el cifrado de los datos, en el almacenamiento, transmi-
sión (Protocolos de seguridad en redes - TSL) y procesamiento de la información
87
(Fernández-Alemán et al., 2013), que garanticen la confidencialidad, integridad y
disponibilidad del EHR (Triada de la Seguridad) (Sahama et al., 2013).
En cuanto a la seguridad a nivel de aplicación, en HCR las operaciones de consul-
ta, ingreso, actualización de los registros médicos, se definen a través de transac-
ciones, similares al sistema bancario, esto con el fin de estar alineados con los
conceptos establecidos por el HRB. Cada transacción debe venir avalada por el
propietario de su cuenta o la persona autorizada, en el caso del HCR, el paciente
o su acudiente, los profesionales médicos o las instituciones autorizadas. La defi-
nición de usuarios autorizados y certificados, se maneja bajo el estándar de la in-
dustria OAuth2 (Hardt, 2012). OAuth2 define la autenticación, autorización y arqui-
tectura de políticas consistentes y flexibles, el cual permite mantener una identidad
distribuida, disponible para todos los componentes de servicio.
La identificación única de usuarios se hará mediante un componente de servicio
que incluye un índice de pacientes definido por el IHE como Master Patient Index
– MPI (Pazos & de Barros, 2008), el cual es encargado de resolver el problema de
múltiples identificadores en diferentes dominios para un mismo usuario. Así mismo
se contará con un Master Institution Índex (MII) y un Master Physician Index
(MPHI) para el registro de las entidades y profesionales habilitados por el gobierno
nacional para la prestación de servicios de la salud, quienes estarán autorizados
para acceder al EHR de los pacientes que requieran ser atendidos en una situa-
ción de emergencia.
El componente de autenticación de usuarios emitirá una "credencial" (Token) la
cual será entregada a todos los componentes implicados para cada sesión de
usuario. El componente de autenticación de usuarios realiza la validación de los
privilegios otorgados de acuerdo al tipo de usuario que solicita los servicios (Pa-
ciente, profesional de la salud o institución), el nivel de acceso que el usuario haya
definido a la información clínica o por el tipo de atención requerido, donde se con-
templen reglas excepcionales para el caso de atenciones de emergencia, para ga-
rantizar la disponibilidad y oportunidad a la EHR. El componente centralizado de
logs es el encargado de llevar el registro histórico del acceso a la EHR. Esto hace
posible la auditoría sobre eventos que atenten contra la integridad y la privacidad
de la información.
3.6.2.6. Adaptabilidad
La escalabilidad de la arquitectura distribuida de los microservicios permite que se
realice el despliegue de los componentes de servicio de forma separada, de tal
88
forma que también sea posible escalar individualmente cada componente. La es-
calabilidad en la arquitectura propuesta es posible ajustarla de acuerdo a las ne-
cesidades de un contexto específico en un tiempo determinado, lo cual resulta en
una gran versatilidad para escalar algunos componentes o el sistema completo en
caso de ser necesario.
Las implementaciones de componentes de servicio para la interoperabilidad de la
EHR para pacientes en situaciones de emergencia, basados en la arquitectura
propuesta, pueden ser desplegadas en plataformas con mínimas capacidades de
cómputo, de forma simple y eficiente, y posteriormente ser escalados en la medida
que sea requerido, para responder rápidamente a los constantes ca(overall agili-
ty).mbios en el entorno en escenarios más demandantes, con grandes volúmenes
de concurrucia, como los que se podrían presentar en la atención de una catástro-
fe; y luego reducir a su tamaño, lo cual posibilita realizar implementaciones con un
bajo costo
Dado que en la arquitectura del HCR es posible desplegar unidades de forma se-
parada, los cambios se encuentran aislados a componentes de servicio individua-
les con bajo acoplamiento, lo que permite despliegues sencillos y rápidos, facili-
tando la incorporación de los cambios y de nuevos componentes.
Algunas de las características de la arquitectura basada en microservicios son:
Testeabilidad: dada la separación y aislamiento de las funcionalidades de
negocio, las pruebas de regresión para un componente de servicio en parti-
cular, resultan más sencillas y factibles que las mismas pruebas realizadas
a toda una aplicación monolítica. Además, ya que los componentes de ser-
vicio en este patrón están débilmente acoplados, hay menos posibilidades
de que un componente de servicio ―rompa‖ la aplicación completa debido a
la incorporación de un cambio reciente.
Facilidad de desarrollo: como la funcionalidad se encuentra separada en
diferentes componentes de servicio, el desarrollo se vuelve más sencillo
debido a un alcance más pequeño y aislado de cada unidad.
3.6.2.7. Usabilidad
Durante el desarrollo de este proyecto se propuso un diseño de historia clínica
centrado en el usuario, que tome en cuenta aspectos de usabilidad, orientados a
facilitar la navegación sobre la interfaz gráfica, el acceso a las funcionalidades y la
recuperación y corrección de datos. Se tomó como referencia los principios y acti-
89
vidades de diseño centrado en el usuario establecido en el estándar ISO 9241-
210. Los principios que sigue el diseño centrado en el usuario están basados en
una comprensión explícita de usuarios, tareas y entornos, donde los usuarios es-
tán involucrados en el proceso iterativo de diseño y desarrollo, centrándose en las
evaluaciones que realizan. El diseño está dirigido a la experiencia de usuario, para
lo cual, en el equipo de diseño se incluyen habilidades y perspectivas multidiscipli-
narias. Las actividades consideradas en este estándar deben ser iniciadas tem-
pranamente en el proceso de diseño y realizadas iterativamente hasta alcanzar los
requisitos de diseño y necesidades planteadas por los usuarios. Las actividades
del estándar ISO 9241-210 se presentan en la Figura 30.
Figura 30. Actividades del estándar ISO 9241-210. Adaptado de (ISO, 1998)
Una EHR usable incrementa las probabilidades de éxito de implantación para este
tipo de sistemas. Para lograr conseguir este objetivo, se realizó una interpretación
del proceso establecido en el estándar ISO 9241-210, el cual es usado para el di-
seño de la EHR y adaptado a las condiciones específicas del contexto (Villa &
Cabezas, 2014). La interpretación del estándar se ilustra en la Figura 31.
90
Figura 31. Interpretación del estándar ISO 9241-210 (Villa & Cabezas, 2014)
La identificación de requisitos de DCU se abordó considerando las características
de usabilidad. Para una EHR diseñada para la atención de emergencias médicas,
la operabilidad es una característica fundamental. La EHR debe ser fácil de usar y
controlar, debido a las restricciones de tiempo, tanto para la consulta como para la
grabación de los registros médicos. En la práctica, una baja operatividad puede
producir una mala calidad de los registros médicos. Por lo tanto, un DCU debe
ayudar a proteger contra los errores no intencionales introducidos por los usuarios.
Además, deben tenerse en cuenta características como la estética, la inteligibili-
dad y la capacidad de aprendizaje. La estética de las interfaces de usuario facilita-
rá el uso y mejorará la experiencia del usuario. De acuerdo con la inteligibilidad, el
contenido de la EHR estará adaptado a los requisitos de información, indispensa-
bles en una atención de emergencia. Por último, una capacidad de aprendizaje
adecuada reducirá la curva de aprendizaje requerida por los usuarios. Para identi-
ficar las necesidades de diseño de la EHR, se realiza el análisis de las caracterís-
ticas de los usuarios y las interacciones entre los usuarios y la EHR, para definir
perfiles de usuario mediante el uso de técnicas de DCU tales como la técnica Per-
sonas (Cooper, By-Saffo, & Paul, 1999). Los perfiles identificados deberán ser
tomados en cuenta en el diseño de la interfaz de usuario, con el fin de lograr dis-
minuir la resistencia de los usuarios a usar la EHR, reducir factores de fracaso en
la implantación y minimizar las preocupaciones de los usuarios con el uso del
sistema, tales como las pérdidas de información.
91
4. OBSERVACIONES FINALES, CONCLUSIONES Y TRABAJOS
FUTUROS
En esta sección se presenta un resumen del análisis de las actividades que permi-
tieron lograr el cumplimiento de los objetivos propuestos, las conclusiones obteni-
das y las propuestas de trabajo futuro que pueden desarrollarse a partir del pre-
sente proyecto.
92
4.1. CUMPLIMIENTO DE OBJETIVOS
La arquitectura denominada HCR, tiene como objetivo atacar los problemas de
fraccionamiento, disponibilidad y oportunidad de la EHR, manteniendo la confiden-
cialidad e integridad de la información. Este objetivo se aborda mediante la oferta
de un conjunto de servicios en la nube que genere un ambiente colaborativo entre
los actores del sistema de salud. La relación entre las características de la solu-
ción propuesta y los problemas que motivaron la investigación se presenta en la
Tabla 36.
Características Fraccionamiento Disponibilidad Oportunidad
Interoperabilidad entre los sistemas de las institu-ciones de salud (HCR)
X X
Historia Clínica para Atención de Emergencias como PHR
X X
Repositorio centralizado (HRB) X X X
Ubicuidad de la EHR (Servicios en la Nube) X X
Uso de estándares (HL7, DICOM, openEHR) X
Alta disponibilidad (Load Balancer) X X
Tolerancia a Fallos (Circuit breaker) X
Exposición de Servicios de EHR (API Gateway) X X X
Servicios de Identificación y Autorización X
Ambiente colaborativo entre actores del sistema X X
Monitoreo del sistema X
Tabla 36. Relación entre características de la propuesta y problemas abordados
El modelo propuesto se puede considerar como una adaptación de la arquitectura
empleada en la prestación de servicios en salud de países desarrollados, al con-
texto Colombiano, el cual es similar al de otros países en vía de desarrollo. Sin
embargo, para promover la implementación de sistemas de interoperabilidad de la
EHR, se requiere una participación más activa del gobierno, con la reglamentación
técnica, donde se especifique un marco de referencia común para el intercambio
de información clínica, se establezcan los estándares de interoperabilidad y voca-
bularios controlados en salud que deben ser implementados por las instituciones
de salud en Colombia. Estos lineamientos y definición de estándares facilitarán el
desarrollo de sistemas para la interoperabilidad de la EHR, basados en arquitectu-
ras como la propuesta en este trabajo.
Debido a la falta de reglamentación, la arquitectura del HCR, establece la adapta-
bilidad como uno de sus atributos de mayor fortaleza. La arquitectura del HCR
propone una interoperabilidad adaptable y escalable en el tiempo, en la medida en
que la legislación establezca las normas técnicas para interoperabilidad de la
EHR. El HCR facilita la adición de nuevos componentes para abordar temas aso-
ciados a la prestación de servicios en salud tales como autorizaciones, traslados y
facturación, o que se adapten los componentes de servicio existentes a otros es-
tándares que el gobierno nacional defina, ocasionando el menor impacto el funcio-
93
namiento general del sistema. EL HCR contempla los estándares HL7, DICOM y
openEHR para la interoperabilidad de los registros clínicos y los acuerdos de nivel
de servicio que se establezcan entre las Instituciones que requiera establecer me-
canismos de interoperabilidad con el HCR, mientras se llenan los vacíos legales
de establecimiento de estándares interoperabilidad para el sistema de salud Co-
lombiano.
En este trabajo se abordó el diseño de la arquitectura desde la perspectiva de la
sostenibilidad. La principal contribución consiste en la propuesta del método SADD
el cual es una adaptación del método ADD, donde el diseño se centra en la soste-
nibilidad de la arquitectura. El SADD permite realizar un análisis multidimensional
de la arquitectura, de acuerdo con las cinco dimensiones en relación con los tres
niveles de impacto de sostenibilidad considerados en el Manifiesto de Karlskrona,
mediante el uso de la herramienta denominada matriz de impactos y oportunida-
des de sostenibilidad propuesta. Esta matriz permite una discusión, así como una
comprensión por parte de las partes interesadas sobre la sostenibilidad del diseño
arquitectónico. La propuesta fue aplicada y ejemplificada en el contexto del HCR.
En el proceso de diseño de la arquitectura para la interoperabilidad del EHR para
la atención de pacientes en situaciones de emergencia, se incluyó una fase de
identificación de requisitos se involucraron varios actores con distintas perspecti-
vas. Por una parte, la revisión de la literatura permitió tener un enfoque del estado
del arte relacionado con EHR, el uso de tecnologías en la nube a nivel mundial, y
establecer el avance y los logros a nivel nacional. Por otra parte, con las entrevis-
tas al personal de la institución que presta los servicios de atención de pacientes
en situación de emergencia, se obtuvo una perspectiva técnica de los requisitos en
términos de la practicidad y la experiencia en el negocio, donde se busca que la
arquitectura sirva de apoyo a la toma de decisiones en la atención de los pacien-
tes y genere un valor agregado al servicio que prestan. Finalmente, la revisión de
la normatividad Colombiana relacionada con la EHR, permitió establecer, tanto
requisitos como restricciones, para la interoperabilidad de la información clínica de
los pacientes. Se considera como un acierto incluir estas perspectivas en la defini-
ción de los requisitos de la arquitectura, ya que permitió definir un contexto general
en el que se desarrolló el proyecto, con la expectativa de lograr un avance tecno-
lógico ajustado a las condiciones y limitaciones del sistema de salud Colombiano.
La propuesta es analizada y discutida de manera cualitativa, considerando múlti-
ples factores de éxito, tales como: la aceptación del sistema por parte de los usua-
rios, la participación del personal médico, la sostenibilidad financiera de la infraes-
tructura, el aseguramiento de la confidencialidad de la información sensible y los
lineamientos del gobierno para el establecimiento mecanismos que promuevan la
interoperabilidad de la información del sector salud.
94
4.2. CONCLUSIONES
Como resultado del proceso del presente proyecto, se resaltan tres productos
principales: la arquitectura para la interoperabilidad de la EHR, el método SADD y
la usabilidad en el diseño de la EHR. El primero de ellos fue la arquitectura para la
interoperabilidad de la EHR para pacientes en situaciones de emergencia denomi-
nada HCR (Villa et al., 2015). El HCR establece los lineamientos que permiten el
intercambio de información clínica dentro de un ambiente colaborativo entre los
actores del sistema de salud de Colombia y brinda la posibilidad de integrar la in-
formación clínica de los pacientes en un repositorio único de historias clínicas
electrónicas gestionadas por los pacientes, quienes son los propietarios de su in-
formación. La arquitectura puede ser adaptada a otros contextos de atención mé-
dica donde se requiera el acceso oportuno a la EHR de los pacientes para apoyar
la toma de decisiones basadas en evidencia. Algunos de los beneficios e impactos
esperados con la implementación de soluciones para interoperabilidad de la EHR
basados en la arquitectura del HCR propuesta en este trabajo, se presentan en la
Figura 32.
Figura 32. Beneficios e impactos esperados del HCR
95
El segundo producto fue el método SADD (Villa et al., 2016). SADD es el resulta-
do de combinar los conceptos de sostenibilidad y elicitación de requisitos, e incluir-
los como una adaptación al método ADD. El método SADD provee una herramien-
ta de apoyo para los arquitectos en la toma de decisiones arquitectónicas, deno-
minada Matriz de impactos y oportunidades de sostenibilidad, con el fin de produ-
cir diseños arquitectónicos sostenibles. El valor de la utilidad del SADD se basa en
que provee a los arquitectos de software de herramientas concretas para llevar a
cabo una tarea abstracta, dentro de un contexto que históricamente sólo ha consi-
derado los impactos directos de sostenibilidad en un diseño arquitectónico. El mé-
todo brinda la posibilidad de analizar la sostenibilidad de la arquitectura desde 5
dimensiones más allá de los aspectos ambientales y económicos, considerando
para cada dimensión, los efectos a corto, mediano y largo plazo. La efectividad del
método SADD, se validó con el diseño de la arquitectura sostenible para la inter-
operabilidad de la EHR para situaciones de emergencia.
El tercer producto fue la interpretación del estándar ISO 9241-210 (Villa &
Cabezas, 2014), donde se tomó como referencia los principios y actividades de
diseño centrado en el usuario para el diseño de la EHR que fuera usable. En este
proceso de arquitectura se estableció que el diseño de la EHR debe estar centra-
do en el usuario, debido a que uno de los factores de éxito en la fase de la imple-
mentación de la EHR es la usabilidad. La aplicación del estándar en el diseño del
HCR permitió tomar decisiones arquitecturales orientadas al cumplimiento de los
requisitos de usabilidad de la EHR. El diseño de la EHR está orientado a facilitar la
navegación sobre la interfaz gráfica, el acceso a las funcionalidades y la recupera-
ción y corrección de datos. La usabilidad de la EHR se contempló como uno de los
drivers prioritarios desde las primeras etapas del diseño para alcanzar los requisi-
tos de diseño y necesidades de usabilidad de la arquitectura.
4.3. TRABAJOS FUTUROS
Como posibles trabajos futuros y en concordancia con los logros del presente pro-
yecto de investigación, se identifican las siguientes alternativas:
Evaluar la arquitectura del HCR mediante un prototipo: Diseño de un proto-
tipo basado en la arquitectura propuesta bajo el contexto de la atención a
pacientes en situaciones de emergencia, para ser probado por un institu-
ción que preste servicios de atención de emergencias, que permita validar
atributos de calidad de arquitectura tales como desempeño, adaptabilidad y
96
escalabilidad, simulando escenarios de alto tráfico de información, escena-
rios con un número elevado de solicitudes de servicios concurrentes y es-
cenarios donde se introduzcan errores que deben ser controlados.
Analizar la adaptabilidad de la arquitectura del HCR a otros contextos: To-
mando en cuenta que la arquitectura del HCR se diseñó bajo el contexto de
la atención de emergencias, se podría evaluar la pertinencia de la arquitec-
tura del HCR en otros contextos de la prestación de salud, tales como la
atención de servicios ambulatorios, hospitalarios o urgencias, que permita
establecer la interoperabilidad de la EHR y el acceso oportuno a los profe-
sionales de la salud en la toma de decisiones apoyados en evidencia.
HCR desconectado: Definir mecanismos para establecer interoperabilidad
del EHR en condiciones adversas, tales como situaciones de prestación de
servicios donde no hay conectividad, la velocidad de conexión es muy lenta
la conexión es intermitente o los registros médicos que se requieren son
muy ―pesados‖.
97
REFERENCIAS
Alliance, T. N., Information, H., Report, T., Coordinator, N., & Technology, H. I. (2008). Defining Key Health Information Technology Terms. Health (San Francisco). https://doi.org/10.1017/S0266462300010667
Amatayakul, M. K. (2004). Electronic Health Records. A Practical Guide for Professionals and Organizations. Retrieved from http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_015872.pdf
Australian Digital Health Agency. (2016). Welcome to My Health Record. Retrieved from https://myhealthrecord.gov.au/internet/mhr/publishing.nsf/content/home
Australian Government Department of Health. (2011). Health Connect. Retrieved January 31, 2016, from http://www.health.gov.au/internet/main/publishing.nsf/Content/EHeath+Healthconnect
Bachmann, F. (2011). Design Peer Reviews the ATAM Style. Retrieved from https://pdfs.semanticscholar.org/7740/7581372080832b538f28b223c9b72a12d016.pdf
Bannerman, P. (2010). Cloud computing adoption risks: state of play. Retrieved from http://www.nicta.com.au/pub?doc=4387
Barbacci, M., Ellison, R., Lattanze, A., Stafford, J., Weinstock, C., & Wood, W. (2003). Quality Attribute Workshops (QAWs), Third Edition. Retrieved April 9, 2014, from http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=6687#
Becker, C., Penzenstadler, B., Chitchyan, R., Seyff, N., Duboc, L., Venters, C. C., & Easterbrook, S. (2015). Sustainability Design and Software: The Karlskrona Manifesto. In ICSE’15: 37th International Conference on Software Engineering. https://doi.org/http://eprints.hud.ac.uk/23424/
Bengtsson, P., Lassing, N., Bosch, J., & Van Vliet, H. (2004). Architecture-level modifiability analysis (ALMA). Journal of Systems and Software, 69(1–2), 129–147. https://doi.org/10.1016/S0164-1212(03)00080-3
Black, A., & Sahama, T. (2014). eHealth-as-a-Service (eHaaS): The industrialisation of health informatics, a practical approach. In e-Health Networking, Applications and Services (Healthcom), 2014 IEEE 16th International Conference on (pp. 555–559). https://doi.org/10.1109/HealthCom.2014.7001902
Black, A., Sahama, T., & Gajanayake, R. (2014, January 1). eHealth-as-a-Service (eHaaS) : a data-driven decision making approach in Australian context. Studies in Health Technology and Informatics [E-Health - For Continuity of Care]. IOS Press. Retrieved from http://eprints.qut.edu.au/72798/1/eHealth-as-a-Service_(eHaaS)_A_data-driven_decision_making_approach_in_Australian_context.pdf
Cabezas, I., & Trujillo, M. (2012). A Method for Reducing the Cardinality of the Pareto Front. In L. Alvarez, M. Mejail, L. Gomez, & J. Jacobo (Eds.), Progress in Pattern Recognition, Image Analysis, Computer Vision, and Applications (Vol. 7441). Berlin, Heidelberg: Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-642-33275-3
CAC, C. de A. C. (2007). Patologías de Alto Costo. Retrieved September 10, 2016, from https://cuentadealtocosto.org/site/index.php/patologias
Calero, C., Moraga, M. A., & Bertoa, M. F. (2013). Towards a Software Product Sustainability Model. Journal of Sustainability, 25010, 4. Retrieved from http://arxiv.org/abs/1309.1640
Canada Health Infoway. (2013). Canada Health Infoway. Retrieved January 30, 2014, from https://www.infoway-inforoute.ca/index.php
Cantale, C. R. (2006). HISTORIA CLINICA ORIENTADA A PROBLEMAS. Diplomatura Universitaria En Medicina Familiar. Retrieved from http://www.intramed.net/userfiles/files/hcop.pdf
Carnicero, J. (2012). Manual de Salud Electronica para Directivos de Servicios y Sistemas de Salud. CEPAL.
Castrillón, H. Y., González, C., & López, D. M. (2012). Modelo Arquitectónico para Interoperabilidad entre Instituciones Prestadoras de Salud en Colombia. Universidad Del Cauca, Programa de Maestría En Computación.
Chowdhary, S. K., Yadav, A., & Garg, N. (2011). Cloud computing: Future prospect for e-health. In ICECT 2011 - 2011 3rd International Conference on Electronics Computer Technology (Vol. 3, pp. 297–299). https://doi.org/10.1109/ICECTECH.2011.5941758
CMS. (2003). Health Insurance Reform: Security Standards. Federal Register, 68(34), 8334. https://doi.org/10.1089/hum.1996.7.15-1923
Congreso de la República de Colombia. (2012). LEY ESTATUTARIA 1581 DE 2012. Retrieved from http://www.secretariasenado.gov.co/senado/basedoc/ley_1581_2012.html
98
Cooper, A., By-Saffo, A., & Paul. (1999). The inmates are running the asylum. Sams. Retrieved from http://dl.acm.org/citation.cfm?id=553473
de Toledo Heras, P., Carrero, A. M., Segura, J. A. M., Pérez, E. H., Cristóbal, R. S., Molina, P. C., … Méndez, J. A. F. (2005). Arquitectura genérica para sistemas de e-salud basada en componentes middleware. In Libro de Actas del XXIII Congreso Anual de la Sociedad Española de Ingeniería Biomédica (CASEIB’05) (pp. 29–32). Retrieved from http://pangea.upv.es/bie/index.php?option=com_jombib&task=showbib&id=15
Dietzel, G. T. W., & Riepe, C. (2006). Modernizing healthcare in Germany by introducing the eHealthcard. Retrieved from http://www.luebeck.org/file/sim52-18-22-germany.pdf
EN13606 Association. (2011). The CEN/ISO EN13606 standard. Retrieved February 21, 2014, from http://www.en13606.org/the-ceniso-en13606-standard
European Parliament. (1995). EU Directive 95/46/EC. Official Journal L 281 , 23/11/1995 P. 0031 - 0050;
Fernández-Alemán, J. L., Señor, I. C., Lozoya, P. Á. O., & Toval, A. (2013). Security and privacy in electronic health records: a systematic literature review. Journal of Biomedical Informatics, 46(3), 541–62. https://doi.org/10.1016/j.jbi.2012.12.003
Gajanayake, R., Iannella, R., & Sahama, T. (2011). Privacy by information accountability for e-health systems. In 2011 6th International Conference on Industrial and Information Systems (pp. 49–53). IEEE. https://doi.org/10.1109/ICIINFS.2011.6038039
Gans, D., Kralewski, J., Hammons, T., & Dowd, B. (2005). Medical groups’ adoption of electronic health records and information systems. Health Affairs (Project Hope), 24(5), 1323–33. https://doi.org/10.1377/hlthaff.24.5.1323
Garcia, E., Tyson, G., & Miles, S. (2012). An analysis of agent-oriented engineering of e-health systems. In 13th International Workshop on Agent-Oriented Software Engineering (AOSE-AAMAS) (p. 117). Retrieved from http://www.eecs.qmul.ac.uk/~tysong/files/AOSE12.pdf
Gold, J. D., & Ball, M. J. (2007). The Health Record Banking imperative: A conceptual model. IBM Systems Journal. https://doi.org/10.1147/sj.461.0043
Goldberg, L., Lide, B., Lowry, S., Massett, H. A., O’Connell, T., Preece, J., … Shneiderman, B. (2011). Usability and Accessibility in Consumer Health Informatics Current Trends and Future Challenges. American Journal of Preventive Medicine, 40, S187–S197. https://doi.org/10.1016/j.amepre.2011.01.009
Goodland, R., & Bank, W. (2002). Sustainability : Human , Social , Economic and Environmental. Social Science, 6(11), 220–225. Retrieved from www.balticuniv.uu.se/index.php/download/doc_download/435-sustainability-human-social-economic-and-environmental
Gorton, I. (2006). Essential Software Architecture. Springer. Retrieved from http://www.amazon.com/exec/obidos/redirect?tag=citeulike07-20&path=ASIN/3540287132
Greenpeace International. (2010). Make It Green - Cloud Computing and its Contribution to Climate Change. Forbes, 12. Retrieved from http://www.serverwatch.com/virtualization/article.php/3875266/The-Power-Behind--Cloud-Computing.htm
Hardt, D. (2012). The OAuth 2.0 Authorization Framework [RFC 6749]. RFC 6749. https://doi.org/10.1109/MIC.2012.11
Harno, K., & Ruotsalainen, P. (2006). Sharable EHR systems in Finland. Studies in Health Technology and Informatics, 121, 364–70. Retrieved from http://www.ncbi.nlm.nih.gov/pubmed/17095834
Harris, J. (2001). A survey of sustainable development: Social and economic dimensions (Vol. 6). Island Press.
Health Level Seven International. (2013a). Health Level Seven International - Homepage. Retrieved January 30, 2014, from https://www.hl7.org/
Health Level Seven International. (2013b). HL7 Standards Product Brief - CDA® Release 2. Retrieved from http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
Hill, J. W., & Powell, P. (2009). The national healthcare crisis: Is eHealth a key solution? Business Horizons, 52(3), 265–277. https://doi.org/10.1016/j.bushor.2009.01.006
Hilty, L. M., Arnfalk, P., Erdmann, L., Goodman, J., Lehmann, M., & Wäger, P. a. (2006). The relevance of information and communication technologies for environmental sustainability - A prospective simulation study. Environmental Modelling and Software, 21(11), 1618–1629. https://doi.org/10.1016/j.envsoft.2006.05.007
99
Hunt, A., & Thomas, D. (2000). The pragmatic programmer : from journeyman to master. Addison-Wesley. Retrieved from https://pragprog.com/book/tpp/the-pragmatic-programmer
Indarte, S., & pazos gutiérrez, P. (2012). Estándares e interoperabilidad en salud electrónica: Requisitos para una gestión sanitaria efectiva y eficiente. In CEPAL. Retrieved from http://www.cepal.org/cgi-bin/getProd.asp?xml=/publicaciones/xml/4/45524/P45524.xml&xsl=/dds/tpl/p9f.xsl&base=/dds/tpl/top-bottom.xsl
International Organization For Standardization. (2011). ISO/IEC 25010:2011. Software Process: Improvement and Practice. Retrieved from http://www.iso.org
International Organization For Standardization ISO. (1998). INTERNATIONAL Ergonomic requirements for office work with visual display terminals ( VDTs ) - Part 11 : Guidance on usability. International Organization, 1998(2), 28. https://doi.org/10.1038/sj.mp.4001776
ISO. (2009). ISO/TR 12773 Business requirements for health summary records. Retrieved from www.iso.org
ISO, I. O. F. S. (1998). ISO 9241-11: 1998: Ergonomic Requirements for Office Work with Visual Display Terminals (VDTs) - Part 11: Guidance on Usability. International Organization for Standardization. Retrieved from http://books.google.com.co/books?id=TzXYZwEACAAJ
Kazman, R., Abowd, G., Bass, L., & Clements, P. (1996). Scenario-Based Analysis of Software Architecture.
Kazman, R., Klein, M., & Clements, P. (2000). ATAM: Method for Architecture Evaluation | SEI Digital Library. Retrieved April 9, 2014, from http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=5177
Kuo, M.-H., Kushniruk, A., & Borycki, E. (2011). A Comparison of National Health Data Interoperability Approaches in Taiwan, Denmark and Canada. e18 ElectronicHealthcare, 10(2). Retrieved from http://dspace.library.uvic.ca:8080/bitstream/handle/1828/6387/Kuo_Mu-Hsing_EH_2011.pdf?sequence=1&isAllowed=y
LOINC. (2008). Logical Observation Identifiers Names and Codes (LOINC®) — LOINC. Retrieved January 30, 2014, from http://loinc.org/documentation
Michalas, A., Paladi, N., & Gehrmann, C. (2014). Security aspects of e-Health systems migration to the cloud. In 2014 IEEE 16th International Conference on e-Health Networking, Applications and Services (Healthcom) (pp. 212–218). IEEE. https://doi.org/10.1109/HealthCom.2014.7001843
Ministerio de Salud. (2000). Resolución 003374 de 2000. Retrieved from https://www.minsalud.gov.co/sites/rid/Lists/BibliotecaDigital/RIDE/DE/DIJ/Resolución_3374_de_2000.pdf
MinSalud. (1993). Ley 100 de 1993. Retrieved January 31, 2014, from http://www.minsalud.gov.co/Normatividad/LEY 0100 DE 1993.pdf
MinSalud. (1995). Resolucion 1995 de 1999. Retrieved February 1, 2014, from http://www.minsalud.gov.co/Normatividad/RESOLUCIÓN 1995 DE 1999.pdf
MinSalud. (2011). Reforma a la Salud: Ley 1438 de 2011. Retrieved January 31, 2014, from http://www.minsalud.gov.co/comunicadosPrensa/Paginas/ReformaalasaludLey1438de2011.aspx
MINSALUD. (2016). Normativa. Retrieved from https://www.minsalud.gov.co/Normativa/Paginas/normativa.aspx
MINTIC. (2014). AGENDA ESTRATÉGICA DE INNOVACIÓN NODO SALUD. Retrieved January 31, 2014, from http://www.mintic.gov.co/portal/604/w3-article-6118.html
Morville, P., Rosenfeld, L., & Rosenfeld, L. (2007). Information architecture for the World Wide Web. O’Reilly.
National Electrical Manufactures Association. (2011). Digital Imaging and Communications in Medicine (DICOM) - NEMA. Retrieved September 9, 2017, from http://www.nema.org/Standards/Pages/Digital-Imaging-and-Communications-in-Medicine.aspx
National Health Insurance Administration of Taiwan. (2015). My Health Bank. Retrieved August 16, 2016, from http://www.nhi.gov.tw/english/Content_List.aspx?n=21D194F3C675DB0E&topn=BCB2B0D2433F6491
National Health Service. (2013). NHS Connecting for Health. Retrieved August 16, 2016, from http://webarchive.nationalarchives.gov.uk/20130502102046/http://www.connectingforhealth.nhs.uk/
NIST. (2015). Cybersecurity Framework NIST. Retrieved from https://www.nist.gov/cyberframework
100
openEHR. (2009). Top 10 archetypes for use in an Emergency. Retrieved July 25, 2014, from https://openehr.atlassian.net/wiki/display/healthmod/Poll+Results+-+Top+10+archetypes+for+use+in+an+Emergency
openEHR Foundation. (2014). openEHR - Clinical Models Program. Retrieved January 30, 2014, from http://www.openehr.org/programs/clinicalmodels/
Organización Mundial de la Salud (OMS). (2015). OMS | Emergencias. WHO. Retrieved from http://www.who.int/topics/emergencies/es/
Oude Nijeweme - d’Hollosy, W., van Velsen, L., Huygens, M., & Hermens, H. (2015). Requirements for and barriers towards interoperable eHealth technology in primary care. IEEE Internet Computing, 1–1. https://doi.org/10.1109/MIC.2015.53
Pazos, P. (2011). Informática Médica, Estándares e Interoperabilidad: HL7 normalizando la comunicacion en salud. Retrieved from http://informatica-medica.blogspot.com.co/2011/02/hl7-normalizando-la-comunicacion-en.html
Pazos, P., & de Barros, S. (2008). Arquitectura Orientada a Servicios para Sistemas que utilizan HL7. Retrieved December 12, 2014, from http://www.fing.edu.uy/inco/cursos/tsi/TSI3/2008/trabajos/HL7.pdf
Penzenstadler, B., & Femmer, H. (2013). A generic model for sustainability with process- and product-specific instances. GIBSE 2013 - Proceedings of the 2013 Workshop on Green in Software Engineering, Green by Software Engineering, (June 2015), 3–7. https://doi.org/10.1145/2451605.2451609
Polèse, M., & Stren, R. E. (2000). The Social Sustainability of Cities: Diversity and the Management of Change. Retrieved from https://books.google.com/books?hl=es&lr=&id=KQOi063YxiAC&pgis=1
Real Academia Española. (2016). DLE: emergencia - Diccionario de la lengua española - Edición del Tricentenario. Retrieved from http://dle.rae.es/?id=EiX5X40
Renau, J., & Pérez-Salinas, I. (2001). Evaluación de la calidad de las historias clínicas. Papeles Médicos, 10(1), 32–40.
Richards, M. (2016). Microservices vs. Service-Oriented Architecture. O’Reilly Media, Inc. Retrieved from https://www.safaribooksonline.com/library/view/microservices-vs-service-oriented/9781491975657/
Safety, I. of M. (US) C. on D. S. for P., Aspden, P., Corrigan, J. M., Wolcott, J., & Erickson, S. M. (2004). Components of a National Health Information Infrastructure. Retrieved from https://www.ncbi.nlm.nih.gov/books/NBK216080/
Sahama, T., Simpson, L., & Lane, B. (2013). Security and Privacy in eHealth: Is it possible? In 2013 IEEE 15th International Conference on e-Health Networking, Applications and Services (Healthcom 2013) (pp. 249–253). IEEE. https://doi.org/10.1109/HealthCom.2013.6720676
Schumacher, R. M., & Lowry, S. Z. (2010). NIST Guide to the Process Approach for Improving theUsability of Electronic Health Records. National Institute of Standards and Technology, 5–10. Retrieved from http://www.nist.gov/itl/hit/upload/Guide_Final_Publication_Version.pdf
SEI. (2013). Software Architecture Tools and Methods for Evaluating the Architecture. Retrieved March 14, 2014, from https://www.sei.cmu.edu/architecture/tools/evaluate/?location=tertiary-nav&source=651961
The International Health Terminology Standards Development Organization. (2014). SNOMED CT. Retrieved January 30, 2014, from http://www.ihtsdo.org/snomed-ct/
Tuomainen, M., & Mykkänen, J. (2012). Interoperability design of personal health information import service. Studies in Health Technology and Informatics, 180, 462–6. Retrieved from http://www.ncbi.nlm.nih.gov/pubmed/22874233
Villa, L., & Cabezas, I. (2014). A review on usability features for designing electronic health records. In 2014 IEEE 16th International Conference on e-Health Networking, Applications and Services (Healthcom) (pp. 49–54). IEEE. https://doi.org/10.1109/HealthCom.2014.7001812
Villa, L., Cabezas, I., & Cruz, J. (2015). Electronic Health Record as an eHaaS. In 2015 10th Computing Colombian Conference (10CCC).
Villa, L., Cabezas, I., Lopez, M., & Casas, O. (2016). Towards a Sustainable Architectural Design by an Adaptation of the Architectural Driven Design Method (pp. 71–86). Springer International Publishing. https://doi.org/10.1007/978-3-319-42108-7_6
WCED, U. (1987). Our common future. World Commission on Environment and Development. Oxford University Press.
Westra, B. L., Delaney, C. W., Konicek, D., & Keenan, G. (2008). Nursing standards to support the electronic health record. Nursing Outlook, 56(5), 258–266.e1. https://doi.org/10.1016/j.outlook.2008.06.005
101
Wojcik, R. (2006). Attribute-Driven Design Method - ADD. Retrieved December 5, 2014, from http://www.sei.cmu.edu/architecture/tools/define/add.cfm
World Health Organization. (2013). WHO | E-Health. Retrieved May 5, 2015, from http://www.who.int/trade/glossary/story021/en/
World Health Organization. (2017). WHO | International Classification of Diseases. WHO. Retrieved from http://www.who.int/classifications/icd/en/#
102
ANEXOS
103
ANEXO 1. ELICITACIÓN DE REQUISITOS
CONSOLIDADO DE ENTREVISTAS
Resumen de la información recolectada en el proceso de las entrevistas realizadas al personal de una institución prestadora de servicios de salud que atiende a pa-cientes en situaciones de emergencia.
1. Definición y Descripción de Procesos
El proceso de atención de la emergencia se origina con una llamada que el usua-
rio o un familiar realiza al centro de atención para reportar la emergencia. Los
usuarios principales son personas que se encuentran afiliados y pagan una men-
sualidad por la prestación del servicio. La llamada es atendida por un funcionario
que se encarga de registrar la información de la emergencia. Con la información
recibida realiza una clasificación del nivel de prioridad de la emergencia (Triage) y
asigna una unidad médica para que preste el servicio.
La unidad médica está compuesta por un médico, uno o dos paramédicos y una
ambulancia o vehículo dotado con equipos biomédicos, medicamentos y otros
elementos para la prestación de los servicios. Los vehículos se clasifican en TAM
y TAB los cuales se encuentran equipados de acuerdo a lo dispuesto en el decreto
2003 de 2014 del registro de habilitación. La unidad médica asignada depende de
la disponibilidad y del nivel de clasificación de la emergencia.De ser necesario, el
funcionario puede acceder al sistema actual para consultar si al usuario se le ha
prestado servicios anteriormente y los motivos de atención. Esto con el fin de iden-
tificar datos que puedan ser relevantes y que deben ser informados a la unidad
médica que va a atender la emergencia.
Al personal médico de la unidad asignada se le notifica de la emergencia vía
AVANTEL y por correo electrónico, el cual puede ser leído desde un iPad que está
asignado al médico de cada Unidad Médica. Cada vehículo también cuenta con un
dispositivo GPS, el cual le permite al Centro de despacho, conocer la ubicación de
los vehículos y realizar el seguimiento del proceso de atención de la emergencia.
Una vez la unidad móvil llega al sitio de la emergencia, procede a realizar la aten-
ción del paciente, a realizar su identificación de derechos y prestar los servicios
104
para lograr la estabilización del paciente. En el proceso de atención se puede utili-
zar los diferentes equipos biomédicos con los que cuenta la unidad móvil, se to-
man los datos y se registra la información de la atención médica. Si la situación lo
amerita, de acuerdo al criterio del médico, el paciente es trasladado a una IPS del
nivel que la complejidad y gravedad del estado del paciente lo requieran, y a las
opciones que tiene derecho de acuerdo al tipo de afiliación al sistema de seguri-
dad de salud. El proceso de traslado es informado al puesto de control quien se
encarga de gestionar los trámites para la remisión del paciente a la IPS que co-
rresponda. La unidad móvil traslada el paciente a la IPS donde lo entrega para
que continúen con los procesos de atención hospitalarios, donde se solicita la fir-
ma de aceptación del paciente por parte de la IPS receptora.
El puesto de Control Nacional atiende las regiones de la costa atlántica, Medellín,
Bogotá y Cali. En el puesto de control se realizan los 2 pasos para la atención de
la emergencia: La recepción y el despacho. La recepción inicia desde el momento
en que se recibe una llamada que el usuario o un familiar realiza para reportar la
emergencia. La llamada es atendida por un funcionario que se encarga de regis-
trar la información de la emergencia en el sistema actual, donde realiza la valida-
ción de derechos del usuario y verifica la dirección donde se reporta la emergen-
cia. Luego se realiza una clasificación del nivel de prioridad de la emergencia la
cual puede ser: 1. Consulta, 2. Urgencia y 3. Emergencia, de acuerdo a la infor-
mación reportada telefónicamente.
El siguiente paso es realizar el despacho, donde un funcionario asigna una unidad
médica para que preste el servicio, de acuerdo a la disponibilidad y cercanía al
lugar donde se reporta la emergencia. Una vez se asigna la unidad médica, esta
queda notificada mediante el sistema. Las unidades médicas cuentan con un iPad
donde pueden consultar las atenciones a las cuales ha sido asignado.
Una vez aceptado el servicio, la unidad médica procede al desplazamiento al lugar
de la emergencia. El personal médico puede consultar la historia clínica de las
atenciones médicas que tenga registrada en el sistema. La historia clínica no se
encuentra integrada con el sistema de las EPS. Una vez el medico realiza la aten-
105
ción del paciente, debe registrar en la historia clínica los datos de la atención. La
aplicación de la Historia clínica cuenta con la funcionalidad para hacer la remisión
del paciente a la IPS que continuará con el tratamiento del paciente en caso de ser
necesario.
La aplicación permite la captura de la firma de la persona que recibe al paciente.
También se cuenta con la opción de enviar por correo electrónico la Historia Clíni-
ca del paciente a la IPS que se remite al paciente con la información de la aten-
ción de la emergencia.
2. Historia Clínica Electrónica de Emergencias
La historia clínica electrónica (HCE) para emergencias fue el resultado de un con-
ceso del equipo médico, el cual tomó como base el formato en papel que se usaba
anteriormente. Para su diseño se tomaron los criterios y observaciones del perso-
nal médico, donde el objetivo fue utilizar el menor número de clic para ejecutar los
procesos.
La historia clínica contiene la siguiente información:
Datos demográficos: Corresponde a los dato básicos del paciente: nombre,
dirección, teléfono.
Antecedentes: permite el registro del historial de enfermedades, patologías,
alergias, cirugías y tratamientos asociados al paciente.
Examen físico: Permite de manera parametrizable la captura de los datos
asociados al examen exploratorio que realiza el médico en la atención.
Diagnóstico: Captura el diagnóstico ―presuntivo‖ de la atención.
Evolución: Registro de la atención del paciente
Datos adicionales: Campo para datos de uso informativo a nivel interno.
Consentimiento informado: permite el registro de la aceptación del paciente
para practicarle el procedimiento o el tratamiento médico.
Incapacidades: Permite generar las incapacidades médicas de acuerdo al
diagnóstico realizado en la atención y el control de las prórrogas.
106
3. Funcionalidades adicionales del sistema
Entregas de turno
Reportes para la gestión del servicio (10 ultimas atenciones)
Envío HCE vía e-mail
4. Etapas de la Historia Clínica Electrónica
5. Estándares Usados
CIE 10: Diagnóstico de los pacientes
CUPS: Procedimientos realizados
6. Proyectos Actuales
Encuesta de satisfacción de pacientes
Pre asignación de servicios de atención
Mejorar la interfaz gráfica de la HCE
7. Proyectos de Interés
Tele asistencia
Tele-educación
B.I. toma de decisiones y control de tiempos y oportunidad
Disponibilidad de camas para traslados
HCE off-line: para sitios sin cobertura o problemas de comunicación.
Establecer mecanismos de seguridad en la comunicación de la información
de la atención médica.
Mejoras asociadas a los objetivos del negocio
1. ADMINISTRATIVA
•Realiza la identificación del paciente y la validación de derechos.
2. REGISTRO DE LA ATENCION
•Registra los datos de la atención médica
3. FIRMA
•El paciente valida la atención prestada
4. RECATEGORIZACI
ON
•El medico revisa y valida la categoria de la atención prestada
5. CIERRE
•Se realiza el cierre de la atención médica
107
8. Oportunidades de Mejora
Dificultad en el manejo de la HCE en el iPad de algunos médicos.
No se cuenta con una capa de seguridad en el acceso a la HCE.
No se cuenta con firma digital
Aplicación y control de medicamentos de forma manual
9. Recursos Utilizados
Servidor IBM 870: 2 procesadores Risc IBM power4, 32 GB RAM, S.O.: AS-
400 Base de datos: DB2
Servidor de aplicaciones: 4 procesadores Xeon S.O.: Windows Server Ba-
se de datos: Oracle
Lenguajes de programación: java, php, rpg
Comunicación: datos (Tigo) y voz (Claro y Avantel).
108
ANEXO 2. ENCUESTAS
CONSOLIDADO DE ENCUESTAS
Dentro del marco de las actividades realizadas a nivel de elicitación de los requisi-
tos de la arquitectura de sistema que soporte la interoperabilidad de la historia clí-
nica electrónica de pacientes en situaciones de emergencia, se realizó una en-
cuesta para identificar algunos aspectos relacionados con el uso de los sistemas,
las expectativas y preocupaciones de los distintos roles que intervienen en el pro-
ceso de atención de pacientes en situaciones de emergencia, que permitan esta-
blecer los requisitos de la arquitectura y determinar el nivel de prioridad asignado
por los encuestados para cada uno de los requisitos con respecto al rol que
desempeñan en torno a la historia clínica electrónica, analizada desde diferentes
enfoques de la atención del paciente. El consolidado de resultados de las encues-
tas con relación a la priorización de los requisitos se ilustra en la siguiente gráfica.
Gráfica
Priorización de requisitos
109
ANEXO 3. VALIDACIÓN
VALIDACIÓN DE LA ARQUITECTURA BASADO EN ESCENARIOS
Como parte del ejercicio profesional se realizó la validación de la arquitectura para
la interoperabilidad de la Historia Clínica Electrónica de pacientes atendidos en
situaciones de emergencia siguiendo el proceso de evaluación por escenarios de
la empresa SIO S.A. en el cual participaron el arquitecto y el equipo evaluador. En
el proceso de evaluación se ejecutaron las siguientes actividades:
1. Planear la evaluación
2. Preparar la evaluación
3. Presentar contexto y requisitos
4. Presentar escenario
5. Evaluar escenario
6. Generar reporte
7. Atender observaciones
Los pasos 4 y 5 se ejecutan para cada escenario evaluado, con el fin de recibir la
retroalimentación del equipo evaluador.
Los resultados de la evaluación de los escenarios se presentan a continuación:
ESCENARIO DE CALIDAD PARA INTEROPERABILIDAD
Las IPS reportan la información en diferentes estándares de interoperabilidad de
información clínica tales como HL7, openEHR, DICOM. El sistema debe aceptar y
almacenar los datos sin importar su heterogeneidad tecnológica.
RAZONAMIENTO: Con la intermediación de componentes que funcionen como
Proxy responsables del enrutamiento de las peticiones de servicio se establecen
mecanismos para la interoperabilidad de la EHR bajo distintos estándares. El me-
diador tiene la capacidad de recibir los registros médicos de un conjunto limitado
de estándares (HL7, openEHR o DICOM) y direccionarlo al componente de servi-
cio específico, de acuerdo al estándar requerido, para su tratamiento. El problema
110
de un mediador es que añadirá tareas de administración, pero facilita la implemen-
tación de la interoperabilidad y disminuye la exposición de servicios del sistema,
favoreciendo la seguridad del sistema.
RIESGOS: Aumenta el tiempo y costo del desarrollo. Implica mayor complejidad
en la construcción de servicios por cada estándar soportado.
NO RIESGOS: La intermediación es una táctica de arquitectura para resolver pro-
blemas de modificabilidad.
SENSIBILIDAD: Entre más componentes, menor desempeño. Dependerá de in-
terfaces bien definidas por el estándar.
TRADEOFF: Podría afectar el desempeño.Permite controlar la exposición de los
servicios para mejorar la seguridad del sistema.
ESCENARIO DE CALIDAD PARA DESEMPEÑO
Se requiere acceso a la historia clínica del paciente de manera oportuna. El siste-
ma debe procesar en promedio 20 transacciones por segundo y el tiempo de res-
puesta esperado es de 2 segundos y nunca debe exceder los 5 segundos.
RAZONAMIENTO: Se asegura la atención de todas las peticiones en el tiempo
esperado durante la operación normal del sistema, priorizando y segmentando las
transacciones de lectura de las de escritura (algoritmos dividir y vencer). El Ligth-
weight Message Broker proporciona transporte ligero para acceder a los compo-
nentes de servicio mediante mecanismos avanzados de colas de mensajería asín-
crona, monitoreo, manejo de errores, balanceo de carga y escalabilidad de los
componentes de servicio. El uso de soluciones de caché reducirá los tiempos de
respuesta.
RIESGOS: La priorización implica una actividad más, la cual se debe realizar cui-
dadosamente para que el resultado de esta decisión sea éxitos. Se podrían expo-
ner algunos datos sensibles del EHR que nunca debe almacenarse en caché, Im-
plica mayor esfuerzo para mantener la coherencia entre las réplicas de caché y el
origen de datos del backend.
111
NO RIESGOS: La priorización y separación de transacciones de lectura y escritura
no afecta el funcionamiento del EHR.
SENSIBILIDAD: Ciertas transacciones de lectura podrían requerir colas de men-
sajería asíncrona. Cambios en la configuración del caché podrían afectar el fun-
cionamiento del componente de servicio.
TRADEOFF: Al aumentar el desempeño del sistema puede afectar la modificabili-
dad del mismo. Al aumentar el desempeño se podría poner en riesgo la seguridad
de la información.
ESCENARIO DE CALIDAD PARA ESCALABILIDAD
El sistema debe ser capaz de manejar picos transaccionales de 50 usuarios con-
currentes en ciertos periodos de tiempo, garantizando que las transacciones se
realicen sin pérdida de información.
RAZONAMIENTO: Cuando exista contención de recursos, el sistema automáti-
camente localizará un recurso que esté disponible para atender las peticiones, de
ser necesario también permitirá su escalabilidad, replicando únicamente los com-
ponentes que lo requieran. El manejo de la concurrencia aun con escalabilidad es
un factor crítico, puesto que los componentes podrían fallar simultáneamente y
podría generar el deadlock sobre los componentes de persistencia, como base de
datos tipo RDBMS, situación que podría saturar las conexiones permitidas y afec-
tar la disponibilidad.
RIESGOS: Implicar incremento de la latencia en algunos casos, debido al aumen-
to en el overhead de administración que le agrega este componente. Manejar alta
concurrencia implica mayor probabilidad de fallos y mayor complejidad para su
resolución.
NO RIESGOS: La concurrencia es transparente en los Sistemas Operativos, Ser-
vidores de Aplicación y los motores de Base de Datos. Esto hace transparente el
desarrollo. Estas decisiones son tácticas de arquitectura para desempeño y esca-
labilidad.
112
SENSIBILIDAD: Cualquier cambio en alguna regla de un balanceador podría im-
plicar grandes cambios en el sistema. En condiciones en las que la carga sea ba-
ja, el desempeño no será mejorado. Por el contrario, será menor al que se lograría
sin un balanceador por el overhead de administración.
TRADEOFF: Esta implementación ayudará también con problemas de disponibili-
dad y escalabilidad. Al aumentar el desempeño con tácticas de concurrencia se
afecta la modificabilidad y disponibilidad.
ESCENARIO DE CALIDAD DE TOLERANCIA A FALLOS
Si al momento de ejecutar una funcionalidad de la EHR se presenta un fallo, el
sistema debe controlarlo. No debe permitir que el error se propague a ningún otro
servicio.
RAZONAMIENTO: Mediante la implementación del patrón Circuit breaker se con-
sigue la protección contra los puntos de integración y el control de fallas en casca-
das, capacidades desbalanceadas, y respuestas lentas. Los circuit breakers traba-
jan de cerca con los timeouts y permiten gestionar el error de forma controlada a
nivel local del servicio donde se produjo.
El servicio de monitoreo permite disponer de mecanismos para gestionar aspectos
de los nodos relacionados con el estado y funcionamiento, permitiendo generar
alertas tempranas..
RIESGOS: Si no se implementa en todos los componentes de servicio podría oca-
sionar problemas de integralidad del proceso. Las automatizaciones pueden de-
gradar la funcionalidad, cuando el sistema esté bajo cierto nivel de estrés. El sis-
tema de monitoreo puede generar carga adicional al sistema.
NO RIESGOS: El monitoreo de procesos es una táctica de arquitectura para dis-
ponibilidad.
SENSIBILIDAD: Cambios en los estados de circuit breakers deben ser siempre
puestos en logs para monitoreo y consultas.Si la frecuencia de monitoreo es muy
alta, podría causar latencias en la operación normal.
113
TRADEOFF: Se podría afectar el desempeño ya que implican carga adicional de
administración. Se podría afectar la seguridad del sistema ya que para monitorear
un sistema debe existir una operación que abra un puerto en cada componente
(echo). Este puerto puede convertirse en un blanco fácil para los atacantes.
ESCENARIO DE CALIDAD PARA SEGURIDAD
El sistema de EHR dispone de mecanismos de control acceso que garanticen la
seguridad de la información, evitando que sea consultada o alterada por personas
no autorizadas.
RAZONAMIENTO: Disponer de un componente de autorización centralizado,
permite implementar la capa de seguridad de servicios a nivel de API. El compo-
nente de autenticación de usuarios emitirá una "credencial" (Token) la cual será
entregada a todos los componentes implicados para cada sesión de usuario. El
componente de autenticación de usuarios realiza la validación de los privilegios
otorgados de acuerdo al tipo de usuario que solicita los servicios (Paciente, profe-
sional de la salud o institución), el nivel de acceso que el usuario haya definido a la
información clínica o por el tipo de atención requerido, donde se contemplen re-
glas excepcionales para el caso de atenciones de emergencia. Con la intermedia-
ción de un servidor perimetral para la exposición de servicios que funciona como
un Gateway en el que se expondrán los servicios a consumir (API´s), previene el
acceso a servicios por usuarios no autorizados. Cifrar los datos implica un gran
impacto en el desempeño del sistema. Para protegeré la confidencialidad de la
información sensible, se deben desacoplar los datos que deben estar protegidos
de los datos de procesamiento e información general. Para el cifrado será necesa-
rio establecer límites lógicos entre los flujos de trabajo protegidos y los generales.
El servicio de monitoreo permite disponer de mecanismos para gestionar aspectos
de los nodos relacionados con el estado y funcionamiento, permitiendo generar
alertas tempranas.
114
RIESGOS: Limitar el acceso y la exposición podría eventualmente limitar opciones
del negocio. Cifrar la información implica una tarea adicional que afecta el desem-
peño.
NO RIESGOS: La autenticación de usuarios es una táctica de arquitectura para
atacar problemas de seguridad.
SENSIBILIDAD: Genera dependencia de un componente centralizado de autori-
zación. Un cambio en la configuración de acceso podría dejar inoperables algunos
componentes de servicio. Un cambio en alguna política de exposición de servicios
podría dejar inoperable al sistema. Requiere un proceso de identificación de datos
sensibles.
TRADEOFF: Se afecta el desempeño porque adiciona overhead computacional.
Sistemas limitados afectan la modificabilidad. El costo de la protección de la infor-
mación afecta el desempeño.
ESCENARIO DE CALIDAD PARA MANTENIBILIDAD
Se desea incorporar una nueva funcionalidad para la interoperabilidad de la EHR.
El despliegue de esta funcionalidad no debe afectar el funcionamiento de ninguna
otra funcionalidad.
RAZONAMIENTO: En HCR la arquitectura basada en microservicios permite el
diseño de componentes que cumplen una función definida, con bajos niveles de
acoplamiento. Los componentes débilmente acoplados permiten adicionar nuevas
funcionalidades sin afectar los demás componentes, lo cual incrementa la mante-
nibilidad del sistema. Para el HCR, esto es muy importante, debido a los cambios
constantes en la normatividad del sistema de salud en Colombia y que aún no se
han establecido lineamientos técnicos para la interoperabilidad del EHR. Se debe
determinar el nivel de granularidad adecuado. La granularidad no debe ser muy
gruesa para evitar redundancia de la lógica del negocio y no puede ser muy fina
para que no se incremente la complejidad de administración y gestión del sistema.
115
RIESGOS: Determinar el nivel adecuado de granularidad de los componentes
puede ser un proceso muy complejo. Podría generar redundancia de lógica de ne-
gocio.
NO RIESGOS: La granularidad de los componentes de servicio no impacta sobre
el alcance de los objetivos del EHR. Corresponde a una táctica de arquitectura.
Cambios normativos pueden ser incorporados sin impactar el sistema en general.
SENSIBILIDAD: Ciertos componentes pueden requerir un gran número de módu-
los para lograr una funcionalidad completa. Cambios en los requisitos podrían
afectar varios componentes de servicio.
TRADEOFF: Mejora la portabilidad e interoperabilidad se puede afectar el desem-
peño. A mayor granularidad de los componentes de servicio se incrementa la
complejidad del sistema. Implica redundancia de lógica de negocio debido a que
los servicios son independientes y aislados. Aumentar la mantenibilidad usando
componentes desacoplados se puede afectar la integralidad del sistema.
ESCENARIO DE CALIDAD PARA DISPONIBILIDAD
El sistema debe estar habilitado 7X24 para que los usuario autorizados realicen
transacciones en el EHR de los pacientes. Se espera la repuesta exitosa en el
99% de los casos.
RAZONAMIENTO: El balanceo de carga optimiza la utilización de los recursos del
sistema, apoyado en el componente de monitoreo del sistema para prevenir posi-
bles fallos, aumentando tiempos de disponibilidad del sistema. El servicio de moni-
toreo permite disponer de mecanismos para gestionar aspectos de los nodos rela-
cionados con el estado y funcionamiento, permitiendo generar alertas tempranas.
RIESGOS: Implica incremento de la latencia debido al overhead por la administra-
ción que le agrega este componente. Las automatizaciones pueden degradar la
funcionalidad, cuando el sistema esté bajo cierto nivel de estrés.
NO RIESGOS: El monitoreo de procesos es una táctica de arquitectura para dis-
ponibilidad.
116
SENSIBILIDAD: En condiciones en las que la carga sea baja, el desempeño no
será mejorado. Por el contrario, será menor al que se lograría sin un balanceador
por el overhead de administración. Si la frecuencia de monitoreo es muy alta, po-
dría causar latencias en la operación normal.
TRADEOFF: Esta implementación ayudará también con problemas de disponibili-
dad y escalabilidad. Se podría afectar el desempeño ya que implican carga adicio-
nal de administración. Se podría afectar la seguridad del sistema ya que para mo-
nitorear un sistema debe existir una operación que abra un puerto en cada com-
ponente (echo). Este puerto puede convertirse en un blanco fácil para los atacan-
tes.