asesor: iván mauricio cabezas troyano, doctor (phd) en...

116
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

Upload: others

Post on 22-Jan-2021

21 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 2: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 3: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 4: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 5: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 6: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 7: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 8: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 9: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 10: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 11: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 12: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 13: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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).

Page 14: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 15: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 16: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 17: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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)

Page 18: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 19: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 20: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 21: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 22: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 23: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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-

Page 24: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 25: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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-

Page 26: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 27: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 28: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 29: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 30: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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).

Page 31: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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:

Page 32: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 33: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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).

Page 34: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 35: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 36: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 37: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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)

Page 38: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 39: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 40: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 41: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 42: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 43: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 44: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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-

Page 45: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 46: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 47: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 48: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 49: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 50: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 51: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 52: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 53: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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 /

Page 54: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 55: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 56: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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-

Page 57: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 58: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 59: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 60: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 61: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 62: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 63: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 64: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 65: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 66: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 67: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 68: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 69: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 70: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 71: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 72: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

72

3.5.3.3. Diagrama de secuencia - Circuit Breaker

Figura 24. Diagrama de secuencia - Circuit Breaker

Page 73: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 74: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 75: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 76: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 77: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 78: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 79: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 80: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 81: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 82: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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-

Page 83: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 84: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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-

Page 85: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 86: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 87: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 88: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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-

Page 89: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 90: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 91: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 92: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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-

Page 93: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 94: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 95: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 96: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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‖.

Page 97: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 98: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 99: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 100: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 101: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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/#

Page 102: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

102

ANEXOS

Page 103: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 104: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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-

Page 105: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 106: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 107: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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).

Page 108: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 109: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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

Page 110: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 111: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 112: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 113: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 114: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 115: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.

Page 116: Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en ...bibliotecadigital.usb.edu.co/bitstream/10819/5469/1...Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería

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.