MODELO ARQUITECTÓNICO PARA INTEROPERABILIDAD ENTRE INSTITUCIONES PRESTADORAS DE SALUD EN COLOMBIA

ARCHITECTURAL MODEL FOR INTEROPERABILITY BETWEEN HEALTHCARE SERVICE PROVIDERS IN COLOMBIA

Helder Y. Castrillón^1,3, Carolina González^1,2 y Diego M. López³

1 Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones, Grupo de Investigación en Inteligencia Computacional- GICO.
2 Dirección para correspondencia: cgonzals@unicauca.edu.co.
3 Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones, Grupo de Ingeniería Telemática - GIT.

Recibido 30 de abril de 2012. Aceptado 03 de julio de 2012

RESUMEN

En la actualidad Gobiernos, IPS y desarrolladores de software enfrentan la necesidad de mejorar la eficiencia de los sistemas de información en salud mediante una adecuada gestión de la información y la implementación de TICS. Una de las áreas de interés, es el desarrollo de perfiles de interoperabilidad que permita intercambiar información y mejorar la colaboración entre los diferentes actores del sistema de salud. El objetivo del presente artículo es definir y validar un modelo arquitectónico de interoperabilidad entre sistemas de información de IPS en Colombia. El modelo, sustentando en normatividad Colombiana, sugiere el uso de SOA como referencia para definir la arquitectura software y el estándar HL7 para el intercambio de mensajes y documentos clínicos. Posteriormente se evalúa el modelo mediante un grupo de profesionales con experiencia en desarrollo de sistemas de información y una prueba piloto basada en dos escenarios de interoperabilidad en tres IPS de Popayán. El modelo busca aportar una metodología de modelamiento y desarrollo de software en IPS y empresas desarrolladoras, mejorando así el nivel de entendimiento y control sobre las transacciones de información presentes en la prestación de servicios.

PALABRAS CLAVE: Interoperabilidad, Modelo Arquitectónico, Sistemas de información en salud, Reference Model Open Distributed Processing, SOA, HL7, Colombia.

ABSTRACT

Nowadays governments, health services organizations and software developers face the need to improve the efficiency of information systems in health through information management and ICT implementation. One of the areas of interest is the development of interoperability profiles that allow exchange information and improve collaboration between different actors in the health system. The aim of this paper is to define and validate an architectural model of interoperability between information systems on IPS in Colombia. The model, grounded in Colombian legislation, suggests the use of SOA as a reference to define the software architecture and HL7 standard for the exchange of messages and clinical documents. Subsequently the model is evaluated by a group of professionals with experience in information systems development and piloted based on two interoperability scenarios in three IPS of Popayán. The model aims to provide a methodology for software modeling and development among health services organizations, improving the level of understanding and control over information transactions present in the delivery of services.

KEY WORDS: Interoperability, Architectural Model, Health information system, Reference Model Open Distributed Processing, SOA, HL7, Colombia.

I. INTRODUCCIÓN

El intercambio de información clínica y administrativa entre entidades del Sistema General de Seguridad Social en Salud en Colombia (SGSSS) es necesario para el adecuado funcionamiento del mismo. Actualmente el SGSSS es administrado por el Estado gracias a la Ley 100 de 1993 [1], la cual dio oportunidad a otras empresas de participar dentro de la estructura del sistema [2]. SGSSS está compuesto por el Estado, quien participa con el Ministerio de Salud y el Ministerio de la Protección Social; la Comisión de Regulación en Salud (CRES); los aseguradores que incluyen las Entidades Promotoras de Salud-EPS y las Administradoras de Fondos de Pensiones (AFP) y los prestadores denominados Instituciones Prestadoras de Salud (IPS), que generalmente son hospitales, clínicas, laboratorios. Estos últimos se clasifican en cuatro niveles de acuerdo a la complejidad de los servicios prestados. En el nivel uno se encuentran las instituciones que prestan servicios de baja complejidad como consulta médica, odontología, atención de urgencia, actividades de promoción y prevención. El nivel dos presta servicios de mediana complejidad, atendiendo especialidades básicas, como medicina interna, ortopedia, gineco-obstetricia, cirugía general, pediatría, urgencias 24 horas, entre otras. El nivel tres presta servicios de alta complejidad, como neurocirugía, cirugía vascular, neumología, dermatología, Unidades de Cuidados Intensivos (UCI), entre otros. Finalmente, el cuarto nivel apoya el tratamiento de enfermedades crónicas de difícil tratamiento como VIH, cáncer, entre otras.

El intercambio de información en salud es un problema mundial. Diferentes países alrededor del mundo están invirtiendo en Tecnología de la Información y Comunicación (TIC) con el fin de lograr plataformas que permitan la integración de Sistemas de Información en Salud (Health Information Systems - HIS), como es el caso de Canadá [3], Australia [4], Taiwán [5], para mencionar algunos. Al igual que en otros países, en Colombia es necesario contar con mecanismos y sistemas que permitan la interoperabilidad entre entidades del SGSSS y especialmente entre las IPS, ya que son las instituciones base de todo el sistema, al ser responsables de la prestación de los servicios de salud. En este sentido el gobierno de Colombia ha aprobado recientemente la Ley 1438 de 2011, la cual propone varias acciones para fortalecer el SGSSS, entre las que se incluyen algunas relacionadas con el fortalecimiento de sistemas de información en salud. Se determina la obligatoriedad del uso y adopción de sistemas de Historia Clínica Electrónica (Electronic Health Record- EHR) por parte de las IPS, las cuales deben ser capaces de comunicarse con el Sistema de Información Integrado del Sector Salud. También expresa la necesidad de intercambiar información clínica obtenida en los diferentes escenarios de atención, la coordinación de esquemas de comunicación electrónica, servicios de telemedicina, asistencia y atención domiciliaria [6]. Para lo anterior es indispensable ofrecer mecanismos de interoperabilidad entre sistemas de información, que permitan la colaboración entre los diferentes actores del SGSSS, especialmente las IPS.

En este artículo se presenta un modelo arquitectónico de interoperabilidad (MAI) que hace uso de estándares internacionales, y el concepto de Arquitecturas Orientadas a Servicios (Services Oriented Architecture - SOA), para apoyar el intercambio de información asistencial, administrativa y de procesos del negocio, entre los HIS de las diversas IPS en Colombia. Este modelo arquitectónico puede ser usado para detallar escenarios concretos de interoperabilidad, tal como es descrito en las secciones de evaluación y prototipos de interoperabilidad.

II. MATERIALES Y MÉTODOS

Para ofrecer un modelo de interoperabilidad es necesario, primero, tener claridad en el concepto. Una de las definiciones más extendidas para el concepto de interoperabilidad es la propuesta por la IEEE que la considera como "la habilidad de dos o más sistemas o componentes para intercambiar y utilizar la información intercambiada" [7]. Esta definición ha sido ampliamente criticada, especialmente en el ámbito de la salud, porque se considera que está restringida al ámbito tecnológico desconociendo los procesos de colaboración a nivel del "negocio", es decir la prestación de servicios de salud. Los principales niveles de interoperabilidad son: técnico, sintáctico, semántico y organizacional. La interoperabilidad técnica es aquella que soporta la comunicación entre dos sistemas a nivel de señales y protocolos de comunicación (e.g. TCP/IP y USB). La interoperabilidad sintáctica se define como el intercambio de mensajes basado en la definición de estructuras comunes de datos (e.g. HTML y XML). Vale la pena mencionar que el conjunto de protocolos y estándares para descripción de servicios Web, mensajería y transporte (e.g., SOAP, WSDL, UDDI) caben dentro de este nivel de interoperabilidad. La interoperabilidad semántica se define como la capacidad de interpretar la información que se recibe y hacer uso de ella. Para esto es necesario lograr un acuerdo entre modelos de información, vocabularios y terminologías específicas del dominio. La mayor parte del trabajo de investigación y desarrollo sobre interoperabilidad en el dominio de la salud se ha centrado en la interoperabilidad semántica, siendo estándares internacionales como HL7, DICOM, SNOMED-CT y Open EHR los más utilizados. Finalmente, el nivel más completo de interoperabilidad es el nivel de interoperabilidad organizacional -o de servicios-, definido como la capacidad de colaborar a nivel de procesos de negocio y cadenas de valor (cadenas de servicios). En este nivel es necesario implementar y evaluar procesos de negocio, políticas y estrategias de cambio organizacional, para apoyar colaboración e intercambio de información entre los diferentes actores del SGSSS.

El modelo arquitectónico propuesto en este artículo busca alcanzar el nivel de interoperabilidad semántica, con el propósito de establecer las bases para alcanzar el nivel de interoperabilidad organizacional. Las arquitecturas empresariales y orientadas a servicios (SOA) son fundamentales para soportar este último nivel de interoperabilidad.

Este artículo abarca tres resultados principales: (i) trabajos relacionados, (ii) una caracterización general de los sistemas de información de las IPS, (iii) un Modelo Arquitectónico de Interoperabilidad (MAI) entre las IPS -basado en estándares internacionales de información en salud y arquitecturas comunes de sistemas de información como SOA-, y (iv) evaluación del modelo arquitectónico mediante un estudio de caso en dos escenarios de interoperabilidad en el que participan tres IPS de la ciudad de Popayán. A continuación se describen los métodos y tecnologías utilizados para alcanzar cada uno de estos resultados.

2.1 Caracterización de los sistemas de información de algunas IPS en Popayán y Medellín

Para describir las necesidades de interoperabilidad de los HIS de las IPS en las regiones de interés, además de analizar la normativa existente, fue necesario contar con la visión que presentan las propias IPS. Por lo tanto se consideró importante realizar una encuesta estructurada a algunas IPS de las ciudades de Medellín en Antioquia y Popayán en el Departamento del Cauca. Como requisito, se estableció que las IPS tuvieran sistemas de información apoyados en TIC y que prestaran servicios de nivel dos o superior. De esta forma fue posible identificar los estándares y mecanismos de interoperabilidad utilizados.

La encuesta se realizó a profesionales de las áreas de sistemas de información del Hospital Universitario San José (HUSJ), la Clínica la Estancia (CLE) y el Hospital Susana López de Valencia (HSLV) en la ciudad de Popayán. De igual forma se entrevistó a personal del Hospital Pablo Tobón Uribe (HPTU) y a la IPS Universitaria de Medellín (IPS-UM). La encuesta estuvo compuesta de tres partes: (i) identificación de los sistemas que conforman el HIS utilizado, los estándares de comunicación, de acceso a información y tecnologías que manejan, (ii) identificación de las terminologías, vocabularios y clasificaciones relacionadas con servicios, procedimientos, medicamentos y exámenes que maneja la institución, e (iii) identificación de las necesidades de interoperabilidad más relevantes de cada institución.

2.2 Herramientas para definir un modelo arquitectónico de interoperabilidad

Para la definición del modelo arquitectónico entre IPS se realizó inicialmente un estudio de los trabajos relacionados con interoperabilidad entre Sistemas de Información en Salud [8]. Para formalizar el proceso de diseño del modelo arquitectónico propuesto se utilizó como referencia el estándar internacional de la ISO: Reference Model Open Distributed Processing (RMODP), el cual normaliza el desarrollo del modelo de interoperabilidad permitiendo especificar una arquitectura que soporte, principalmente distribución y portabilidad. RM-ODP define cinco vistas para la arquitectura de un sistema: Vista Empresarial, Vista de la Información, Vista Computacional, Vista de la Ingeniería y Vista Tecnológica. RM-ODP no está orientada explícitamente a la definición de servicios, por lo tanto fue necesario seguir una metodología para la identificación de los mismos. Para esto se utilizó la guía de implementación de SOA en el sector salud del proyecto denominado Healthcare Services Specification Project (HSSP) [9]. Este grupo ofrece metodologías, servicios y una guía de implementación de SOA, que a través de ocho pasos permite identificar servicios, la especificación de la arquitectura a implementar y la construcción de un plan de trabajo para el desarrollo de interfaces, así como el despliegue de servicios.

2.3 Evaluación del modelo

La evaluación formal del modelo arquitectónico propuesto se apoyó en el enfoque sistémico DESMET [10], el cual guía a las organizaciones a planificar y ejecutar un proceso de evaluación que es imparcial y confiable, con el objetivo de identificar el método de valoración más adecuado para un producto o elemento del software (un modelo arquitectónico en este caso) que se adapte a un contexto específico. La metodología propone varios métodos de evaluación y los caracteriza, estableciendo criterios técnicos y prácticos para seleccionar el más adecuado. Después de realizar el análisis sobre los tipos de valoración y las formas de organizar un ejercicio de evaluación definidas por DESMET, se considera que el método más adecuado es el Análisis de Características por Encuesta (ACE).

El objetivo del ACE es proveer un método para evaluación de productos software basado en análisis de sus funciones o características. Su enfoque es presentar el producto a evaluación a un grupo de personas con experiencia en los métodos, herramientas y diseños de sistemas de información en IPS. Además de la evaluación formal del modelo, se realizó otra paralela sobre un escenario concreto de interoperabilidad; el intercambio de órdenes de laboratorio en la que participaron tres IPS de la ciudad de Popayán.

III. TRABAJOS RELACIONADOS

3.1 Proyectos Internacionales en Arquitecturas de Interoperabilidad

En el mundo existen diversas propuestas que demuestran el gran interés de integrar los sistemas de información a nivel nacional [11]. En un reporte de la Organización Panamericana de la Salud (OPS) se relacionan algunos de estos esfuerzos de integración [12]. Algunos de los proyectos más representativos son: (i) Reino Unido, con el proyecto National Health Service (NHS) [13], el cual establece una arquitectura que integra un conjunto principal de servicios denominado "La Espina", utilizada para la gestión de información clínica. La arquitectura está dividida en una serie de productos o servicios principales que son: servicios de registros clínicos integrados, prescripción electrónica, agendas médicas, imágenes, gestión de desempeño en Atención Primaria en Salud (APS), e-mail, y directorio de servicios. Este proyecto hace uso de estándares HL7 como Documentos Clínicos Electrónicos (Clinical Document Architecture - CDA) [14] . También se está trabajando en la arquitectura de los EHR en el proyecto Logical Record Architecture (LRA) el cual está basado en SNOMED-CT. (ii) Alemania con el proyecto BIT4health [15], incluye la red nacional de tarjetas electrónicas de salud, cuyo fin es desarrollar un marco arquitectónico abierto y una infraestructura para la gestión de comunicaciones seguras entre instituciones del sistema de salud. A diferencia de otras propuestas, BIT4health es una solución que no es en línea. Está basada en las especificaciones HL7, especialmente CDA. (iii) Australia Health Connect NEHTA [4], es un framework de interoperabilidad que permite a usuarios autorizados el acceso a la historia clínica del paciente e información específica, como resultados de laboratorio, prescripciones y notas médicas, entre otros. El modelo con el cual se diseñó el framework está bajo el concepto de SOA como modelo arquitectónico para compartir registros clínicos. Como estándar para el intercambio de información se han utilizado tanto las especificaciones OpenEHR [16] como las de HL7. (iv) Canadá Health Infoway [3] es una organización apoyada por el Gobierno de Canadá que ha desarrollado un framework denominado (Electronic Health Record Solution - EHRS), el cual provee la denominada "Infoestructura" para registros de salud electrónicos, que consiste en un conjunto de servicios comunes y reusables siguiendo los principios de SOA. EHRS usa varias especificaciones HL7, lo que ha permitido estandarizar interfaces, la estructura de datos, vocabularios, funcionalidad y comportamiento. (v) Taiwán con el proyecto National Health Information Infrastructure (NHII) [5], propone un sistema que brinda la interoperabilidad y seguridad necesaria para intercambiar información relacionada con el cuidado del paciente a nivel nacional. Utilizan una arquitectura basada en las terminologías LOINC, SNOMED, y códigos NHI (vocabulario propio para la identificación de medicamentos, diagnósticos, procedimientos, resultados). Para el intercambio de mensajes utilizan HL7, y para el contenido o estructura de datos usan el sistema Taiwan Electronic Medical record Template (TMT). La seguridad del servicio la alcanzan empleando Redes Privadas Virtuales (Virtual Private Networks- VPN) entre instituciones, y el uso de tarjetas inteligentes para la identificación y transporte de registros clínicos personales.

3.2 Estudios relacionados con interoperabilidad de HIS en Colombia

Dentro del programa de Gobierno en Línea del gobierno colombiano se ha definido un marco para la interoperabilidad, el cual determina políticas, lineamientos y recomendaciones para el intercambio eficiente de información entre entidades del Estado. Las políticas y recomendaciones abarcan los niveles de interoperabilidad más comunes y más representativos en el contexto de la informática y las telecomunicaciones: técnico, sintáctico, semántico y organizativo [18]. El programa de Gobierno en Línea también contempla la definición y gestión de un lenguaje común orientado a que diferentes instituciones compartan información, a través de una estructura de datos estándar definida sobre XML denominada GEL-XML. Este estándar no considera particularidades de mensajería de información en salud, como sí lo hace el conjunto de estándares HL7. El Sistema Integrado de Información de la Protección Social (SISPRO) [19], a pesar que tiene como objetivo soportar la integración de sistemas de información en salud, es técnicamente una solución de bodega de datos que integra de forma estática las fuentes de datos de HIS, riesgos profesionales, pensiones, asistencia social y empleo en Colombia.

Otros autores han estudiado la necesidad de integrar HIS [20], donde proponen un modelo conceptual para lograr interoperabilidad dentro del modelo de salud colombiano, justificando la implementación de soluciones basadas en estándares internacionales. En [21] se muestra cómo desarrollar una aplicación para vigilancia de alertas tempranas con características de reusabilidad, flexibilidad, desarrollo basado en componentes, interoperabilidad y utilización de tecnologías abiertas. Otro autor [22] presenta la evolución de los sistemas de información de salud en Colombia y de los primeros pasos que se han dado en la adopción del estándar internacional HL7.

Por otro lado IPS como el Pablo Tobón Uribe, la Fundación Cardiovascular, el Hospital Susana López de Valencia y la Fundación Santa Fe han desarrollado proyectos de interoperabilidad puntuales, consistentes en su mayoría en la implementación de interfaces para operar sus sistemas de información y mejorar procesos internos y externos. También la fundación HL7 Colombia, a través de sus socios (hospitales, universidades, empresas del sector), ha ejecutado algunos proyectos piloto de interoperabilidad [23].

De lo anterior se destaca que muchos países ya cuentan con plataformas nacionales que permiten la interoperabilidad entre los distintos actores que conforman el sector de la salud, y muchos otros tienen proyectos en desarrollo. A nivel de arquitectura computacional, la tendencia es el uso de SOA como modelo de referencia arquitectónica, generalmente implementada con soluciones de Bus de Servicios Empresariales (Enterprise Service Bus -ESB) o propietarias y, en su mayoría, soportadas en estándares HL7. Sin embargo, en Colombia, a pesar de algunos desarrollos tecnológicos concretos, no se ha avanzado en la definición formal de un Modelo Arquitectónico de Interoperabilidad (MAI) para en el sector salud.

IV. PROPUESTA DE MODELO ARQUITECTÓNICO DE INTEROPERABILIDAD

4.1 Caracterización de los sistemas de información de las IPS en Popayán y Medellín

Los resultados del proceso de caracterización de sistemas de información de las IPS fueron los siguientes: (i) los sistemas básicos que conforman los mecanismos de información de las IPS son: EHR, laboratorio, imágenes diagnósticas, sistema administrativo, sistema de gestión documental, sistema de hospitalización, sistema de admisiones, autorizaciones, sistema de asignación de citas, sistema farmacéutico; (ii) los estándares y mecanismos de interoperabilidad se encuentran principalmente en el nivel técnico o sintáctico de interoperabilidad mediante el uso de: archivos planos, documentos digitalizados, acceso estandarizado a bases de datos, archivos XML y Servicios Web; (iii) el uso de terminologías y ontologías internacionales no es común, a excepción del sistema Clasificación Internacional de Enfermedades (CIE 10). La mayoría de los sistemas se soportan en métodos de clasificación y codificación propios del sistema, como la Clasificación Única de Procedimientos (CUPS) y los Códigos Únicos de Medicamentos (CUM). El uso de estos sistemas de codificación ha sido importante porque ha permitido a las instituciones realizar homologación de servicios entre instituciones, autorización y remisión de servicios de salud.

Finalmente, en el proceso de caracterización también fueron identificadas las necesidades más comunes de interoperabilidad entre IPS, que son: (i) compartir la historia clínica con otras instituciones, (ii) gestión informática de imágenes diagnósticas, (iii) gestión de exámenes de laboratorio, (iv) autorización de servicios, (v) referencia y contra referencia de pacientes, (vi) gestión de documentos clínicos anexos y sistemas administrativos, y (vii) reporte de entidades de control.

4.2 Modelo Arquitectónico de Interoperabilidad entre las IPS

Al ser un MAI de referencia, solamente se especificaron las Vistas de la Información, Computacional y de la ingeniería del modelo RM-ODP. Estas vistas corresponden, según el Modelado Dirigido por la Arquitectura (MDA), al Modelo Independiente de la Plataforma (MIP).

4.2.1 Vista Empresarial

El objetivo principal de la Vista Empresarial es identificar los objetivos, ámbito, políticas y procesos de negocio del sistema. La figura 1 representa un modelo de alto nivel de la Vista Empresarial, donde los componentes de ésta se representan formalmente usando un perfil UML para RM-ODP. La descripción detallada de estos componentes puede consultarse en [8].

Figura 1

4.2.2 Vista de la Información

Esta vista describe el tipo de información que va a manejar el sistema, así como la estructura de los datos. Los elementos del modelo son las clases de información gestionadas por el sistema, su semántica y las restricciones impuestas sobre la utilización e interpretación de dicha información. A partir de los procesos de interoperabilidad de la Vista Empresarial fueron identificados cinco paquetes de información que son: (i) registros asistenciales, (ii) registros administrativos, (iii) reporte de interés público, (iv) terminologías y sistemas de clasificación y (v) datos de infraestructura.

4.2.3 Vista Computacional

La vista computacional permite identificar los diferentes componentes que conforman la arquitectura, al igual que la distribución y comunicación entre los mismos. Al diseñar la arquitectura basada en SOA se obtiene una solución modular que permite distribuir los componentes entre los actores del entorno; de igual forma, centralizar y administrar las transacciones, publicación, suscripción de servicios, transmisión de mensajes en formato HL7 y su interpretación. Ver figura 2.

Figura 2

La vista computacional del modelo arquitectónico propuesto (figura 2) propone los componentes necesarios para garantizar la interoperabilidad, tanto entre los sistemas de información de las IPS como en una futura Infraestructura Nacional de Interoperabilidad de Sistemas (INIS) donde se interconectarán varias IPS. Este modelo involucra componentes necesarios dentro de una arquitectura SOA como son servicios de orquestación, secuenciación y enrutamiento. A pesar de que no ha sido definido aún un conjunto de estándares técnicos para interoperabilidad en salud por parte del gobierno, se propone el uso de mensajería HL7 y documentos clínicos CDA, por ser los estándares que han sido usados con mayor éxito a nivel internacional. Inevitablemente deberá coexistir mensajería HL7 V2 y V3, al haber soluciones actuales basadas en versiones anteriores del estándar; por lo tanto sería necesario incluir servicios de mapeo de estas dos versiones [24]. También es importante contar con servicios para la gestión de información, tanto a nivel interno de las IPS como en las bases y bodegas de datos concretadas para la INIS. Esto incluye servicios de indexación de pacientes y de usuarios, que son procesos necesarios para garantizar la identificación correcta de pacientes y de usuarios.

Es importante anotar que en el proceso de intercambio de información pueden generarse cambios específicos de acuerdo a los servicios prestados por las IPS involucradas, resultando en diversos escenarios de interoperabilidad donde cada IPS tiene un rol concreto por cada uno de ellos. La definición de escenarios precisos de interoperabilidad se realiza en la Vista de la Ingeniería y Tecnología, las cuales están fuera del alcance de este modelo arquitectónico. En el informe técnico detallado del proyecto se describen dos escenarios concretos de interoperabilidad basados en este Modelo Arquitectónico de Referencia. Estos escenarios soportan procesos de referencia y contra referencia de pacientes. Por limitación en la extensión del reporte, no se describen de manera detallada los componentes del modelo arquitectónico. Una descripción completa de los mismos se encuentra en el informe técnico [8].

V. EVALUACIÓN DEL MODELO ARQUITECTÓNICO DE INTEROPERABILIDAD

5.1 Definición del modelo arquitectónico a evaluar

La evaluación pretende determinar la idoneidad del modelo propuesto como referencia para definir arquitecturas de interoperabilidad entre instituciones del sector salud. Esto significa que el modelo arquitectónico genérico presentado en la sección anterior puede ser instanciado en arquitecturas de interoperabilidad para escenarios definidos y usando tecnologías concretas. El escenario candidato para la instanciación del modelo arquitectónico es el proceso de referencia y contra referencia de pacientes entre IPS, identificado como uno de los escenarios de interoperabilidad en el proceso de caracterización de las IPS. Para demostrar la flexibilidad y escalabilidad del modelo arquitectónico se derivaron dos casos macro de interoperabilidad: (i) una solución interinstitucional para el proceso de referencia entre dos IPS, y (ii) una solución nacional para la interacción de más servicios y actores del entorno. Es de aclarar que los modelos propuestos no son la única forma de efectuar las soluciones de interoperabilidad. Cualquier arquitectura que tenga como referencia el modelo arquitectónico podrá implementar los componentes con la tecnología que se desee. Esta evaluación se describe en detalle en [22], y en el presente artículo se presentan los resultados más importantes de la evaluación, además de la implementación de dos prototipos de interoperabilidad basados en la solución (i).

5.2 Definición de características a evaluar en el modelo

Considerando que el principal objetivo del modelo propuesto es la interoperabilidad de sistemas, esta sería la principal característica a evaluar. Desde el punto de vista de calidad de sistemas software, el estándar ISO 9126 actual ISO 25000:2005 [25] define la interoperabilidad como un atributo de calidad de software, y establece métricas para su evaluación. Sin embargo, esta definición evalúa solamente interoperabilidad en su nivel técnico. En el trabajo [26], se definen atributos de interoperabilidad desde la perspectiva de las arquitecturas de sistemas, las cuales son mucho más amplias que las propuestas en el estándar ISO. Estos atributos son: (i) apertura, escalabilidad, flexibilidad, (ii) distribución a nivel de Internet, (iii) cumplimiento de estándares, (iv) orientación a procesos de negocio, (v) cumplimiento de normativas, y (vi) seguridad y servicios apropiados de privacidad. Con base en esta definición, se elaboró un instrumento que es usado para encuestar a los expertos (información disponible por autores a petición del lector).

5.3 Planeación de la evaluación

Posterior a la construcción del instrumento de evaluación y la definición el producto, se seleccionan los sujetos de la investigación, los cuales corresponden a ingenieros con conocimientos en arquitectura de sistemas en salud. Para tal fin se solicitó a ingenieros que brindan desarrollo, soporte y administración de sistemas de información para el sector salud; que participen en el estudio. Un total de nueve respondieron a la encuesta quienes, en general, fueron ingenieros de sistemas con conocimientos en HIS (provenientes de empresas de desarrollo, clínicas u hospitales) y arquitecturas de sistemas de salud con mínimo tres años de experiencia. Cada experto recibió una presentación que explicaba en detalle el modelo arquitectónico, los objetivos del proyecto y el instrumento de evaluación. Posteriormente, cada evaluador respondió a las preguntas del instrumento y los resultados fueron consolidados y agrupados en cinco secciones que determinan la calidad del modelo.

5.4 Análisis de resultados

Los resultados de la evaluación del modelo arquitectónico se han organizado en cinco secciones de evaluación así: (i) Vista Empresarial, (ii) Vista de Información, (iii) Vista Computacional, (iv) Vistas de la Ingeniería y la Tecnología e (v) Interoperabilidad. A continuación se describe el resultado de cada sección y el respectivo análisis.

5.4.1 Evaluación de la Vista Empresarial

En esta sección se evaluó si el modelo arquitectónico ha tenido en cuenta los actores, requisitos, necesidades y procesos del negocio relacionados con la interoperabilidad entre sistemas de información de las IPS, al igual que la normatividad relacionada en Colombia. En general, el 92% de los encuestados tienen un grado de satisfacción adecuado sobre el modelo presentado en materia de identificación de necesidades, actores, servicios y soporte.

5.4.2 Evaluación de Vista de la Información

Define qué información es requerida en los distintos ámbitos del sector salud (asistencial, administrativo, de infraestructura y de interoperabilidad). En este sentido, las preguntas fueron enfocadas en cada ámbito para que los evaluadores determinaran si están en total acuerdo con los componentes de información identificados. El 94% de los encuestados están de acuerdo con los componentes de información descritos.

5.4.3 Evaluación de la Vista Computacional

Esta sección evalúa los componentes descritos en el modelo arquitectónico que soportan la interoperabilidad entre las IPS. Las preguntas fueron enfocadas en definir la capacidad de construir soluciones interoperables para el sector salud a partir de la distribución de componentes (vista computacional). A nivel de componentes existe una mayor satisfacción que en las otras secciones, ya que el 98% de los encuestados están de acuerdo con los componentes, determinando que es posible, a partir del modelo de referencia, ofrecer soluciones arquitectónicas para diferentes escenarios de interoperabilidad.

5.4.4 Evaluación de las Vistas de la Ingeniería y la Tecnología

Para demostrar la capacidad de diseñar una arquitectura se ha definido el escenario de referencia de pacientes, con dos opciones de implementación, una nacional y otra interinstitucional. Para los dos casos existen tecnologías distintas (una basada en una solución con ESB, la otra establecida en un Gateway de Interoperabilidad, soportado en la plataforma Mirth). Se demuestra la flexibilidad del modelo porque permite definir, a partir de unos componentes genéricos, la arquitectura de software para un caso particular, usando una tecnología específica. La tecnología definida para las dos soluciones garantiza la gestión de información y la interoperabilidad entre los sistemas de información a distintas escalas. El 92% de los encuestados está de acuerdo con la tecnología utilizada en las arquitecturas presentadas, brindando una aproximación a la que podría llegar a ser una implementación con tecnologías de alta aceptación en sistemas de información.

5.4.5 Evaluación de Interoperabilidad

De acuerdo con los atributos definidos en [26] se preguntó sobre la (i) escalabilidad, (ii) qué tan abierto es el sistema, (iii) flexibilidad, además del uso de estándares y de SOA como concepto arquitectónico. Del análisis de los resultados se concluye que el 96% de los encuestados opina que el modelo propuesto permite diseñar arquitecturas interoperables y que es suficientemente abierto, flexible y escalable para construir arquitecturas para el sector salud.

VI. PROTOTIPO DE INTEROPERABILIDAD

El prototipo se enfocó en dar solución a las necesidades planteadas en la caracterización de los HIS en IPS de Popayán y Medellín. Específicamente, se ofrecen mecanismos para intercambiar: (i) documentos clínicos necesarios para realizar una interconsulta entre dos IPS que colaboraron en el desarrollo de la prueba piloto y (ii) resultados de laboratorio desde un laboratorio especializado a un hospital.

6.1 Implementación de prototipos de interoperabilidad

El primer paso es definir la tecnología a utilizar. Se decide que se va a usar un ESB, para lo cual se establecen unos criterios de selección del proveedor de esta tecnología. Los criterios decisivos para la selección del ESB son: el manejo de HL7, orquestación de servicios, enrutamiento, transformación de mensajes y seguridad. Varias herramientas cumplen con estos criterios, entre ellas: ChainBuilder [27], OpenESB [28], Apache Server Mix [29] y BizTalk [30] entre otros. HL7 recomienda utilizar software comercial, ya que generalmente presta soporte personalizado, mejor documentación y actualizaciones seguras y continuas.

Con base en lo descrito, además por la experiencia del equipo de desarrollo, se utilizó BizTalk Server 2010 [31], servidor de gestión de procesos de negocio desarrollado por Microsoft, que extiende sus capacidades a través de aceleradores y de utilidades. Para dotar BizTalk de componentes que soporten a SOA y a HL7 se utilizó ESB Toolkit versión 2.1 [31] y el acelerador para HL7 [32], respectivamente, permitiendo adaptar de forma más fácil las interfaces desarrolladas a los HIS de las IPS HSLV y CLE. Dado que los sistemas de información de estas dos IPS están sobre la plataforma Microsoft, este fue un criterio decisivo para implementar BizTalk Server en su última versión. Con el ESB en funcionamiento se logró efectuar la orquestación de los servicios, la especificación y mapeo de mensajes HL7, mientras que el componente de interfaz ubicado en cada IPS se desarrolló con Visual Studio 2010.

6.2 Pruebas de prototipos de interoperabilidad

El primer escenario de interoperabilidad fue el de un servicio de interconsulta. Ninguna de las IPS HSLV (remisor) y CLE (receptor) cuenta con mecanismos para intercambiar información clínica. La interconsulta abarca el flujo de información: (i) elaboración del folio de solicitud de interconsulta, (ii) solicitud de la interconsulta, (iii) autorización del servicio, (iv) envío de la epicrisis a la IPS de referencia en un CDA y (v) envío de respuesta a la interconsulta. Para garantizar el acceso a la información en cada IPS fue necesario acceder a bases de datos, previos acuerdos de confidencialidad y protección de la información. Para esta actividad los ingenieros de soporte de cada IPS colaboraron con el acceso a los datos y la elaboración de las consultas SQL a integrar en la interfaz, la cual publica la información a través de servicios Web. Es importante aclarar que para el CDA de epicrisis no fue elaborada una guía de implementación formal como establece la Fundación HL7 Colombia. El trabajo de elaborar una guía de implementación debe ser un proceso consensuado por un grupo de expertos en historia clínica y expertos en CDA; además de requerir un tiempo de desarrollo mínimo (por experiencia en otros proyectos) de al menos dos meses. El CDA propuesto es un CDA nivel 2 que define el encabezado del documento, y una estructura para las secciones, según los formatos actuales para la epicrisis. El CDA fue visualizado en ambas IPS, a través de diversos navegadores Web logrando intercambiar información de forma adecuada.

El segundo escenario consistió en el envío de resultados de laboratorio desde un laboratorio especializado de Popayán (Laboratorio Martha Perdomo) hacia el HSLV. En las Figuras 3 y 4 se muestra la arquitectura de la solución de interoperabilidad implementada, la cual corresponde a las Vistas de la Ingeniería y la Tecnología según el modelo RM-ODP, y que son derivadas del modelo arquitectónico presentado en la sección anterior.

Figura 3

La prueba se basa en un escenario real, con la diferencia que no requiere la autorización de servicios, debido a que el intercambio se hace a través de un acuerdo contractual entre las IPS relacionadas, como es el caso de los exámenes de laboratorio, que contrata el HSLV con el laboratorio especializado. Para este escenario, se hizo uso de la guía de implementación para resultados de laboratorio propuesta por la Fundación HL7 Colombia [22]. Finamente el resultado es procesado y visualizado en el HIS del HSLV, gracias al mapeo realizado por la interfaz. Cabe señalar que se garantiza la confiabilidad de la información al usar códigos CUPS en la identificación de los servicios, de tal forma que el servicio coincida en las dos IPS. Después de una semana de la implementación del servicio, se solicitaron 240 resultados de los cuales 74 se han respondido a través de la interfaz; correspondiendo al 31% de los exámenes requeridos. Se logró aumentar la oportunidad en la entrega de exámenes, disminuir el uso de papel y prevenir error humano al momento de transcribir los resultados.

VI. DISCUSIÓN Y CONCLUSIONES

El proceso de caracterización formal de los requisitos de interoperabilidad en IPS en Popayán y Medellín incluyó la identificación de necesidades y fortalezas en interoperabilidad. Una de las necesidades, que el presente modelo busca abordar, es alcanzar niveles de interoperabilidad semánticos estables con el fin de destinar próximos recursos a la incursión en metodologías de software y modelamiento de servicios para la interoperabilidad organizacional. Aunque esta afirmación proviene de un número limitado de IPS y profesionales, estas representan instituciones con experiencia en la implementación de HIS en Colombia. Varias de ellas apoyadas por universidades y HL7 Colombia. Por lo tanto es importante seguir vinculando a diversas IPS y empresas de software en la ejecución del presente modelo, con el fin de validar con mayor rigurosidad, escalabilidad y flexibilidad que permitan su mayor difusión.

El modelo propuesto es principalmente una referencia metodológica para seguir apoyando a las IPS en su continua implementación de escenarios de interoperabilidad en la prestación de sus servicios. El modelo sugiere el uso de SOA como alternativa para la arquitectura software y el uso de la familia de estándares HL7 para el intercambio de mensajes y documentos clínicos. Al nivel sintáctico y semántico este modelo ayuda en la planeación y definición de perfiles de estándares técnicos de interoperabilidad que incluyen modelos de referencia para la información, vocabularios y terminologías, representación de conceptos clínicos y servicios. Esto apoya las metodologías de desarrollo o adquisición de software y permite aumentar el nivel de entendimiento y control que tienen las IPS sobre la totalidad de las transacciones de información. Dicho entendimiento promueve la gestión transparente y eficiente de los recursos del SGSSS.

Sin embargo es necesario un liderazgo a nivel de gobierno en este proceso. El Ministerio de Salud y Protección Social creó la oficina de eSalud que tiene como principal función la reglamentación y puesta en marcha del EHR unificado. Parte de las actividades de esta oficina es reglamentar los estándares de interoperabilidad que se deben implementar, además de determinar los procesos de definición, localización y gestión de estándares internacionales en Colombia. Estos estándares facilitan el desarrollo de software por parte de las IPS y empresas, siguiendo un marco de referencia común que les permita intercambiar información en un vocabulario conocido y mejorar su colaboración. Así mismo es necesario establecer procesos y asignar organizaciones responsables del estudio y adaptación de los estándares a la realidad del SGSSS, en los cuales debe permitirse la participación, tanto de los prestadores y aseguradores del sistema como empresas de software, universidades y los mismos usuarios. Para lograr estos objetivos es importante que en Colombia se fortalezcan las organizaciones desarrolladoras de estándares como HL7 Colombia y comités técnicos en eSalud de otras organizaciones como ISO.

Como trabajo futuro, técnicamente, se debe considerar el desarrollo e implementación de escenarios de interoperabilidad para documentos administrativos (e.g. cuentas de cobro), soportados por ejemplo en el estándar de administración de Registros Médicos (Medical Records) [33]de HL7. También es necesario definir formalmente la estructura de los CDA a intercambiar, mediante el diseño de guías de implementación para cada escenario de interoperabilidad. Así mismo dentro del modelo se sugiere la incorporación de las clasificaciones CUPS, CUM y CIE10 para la codificación de la información. No obstante, con estas clasificaciones no se garantiza total interoperabilidad, por tanto es necesario avanzar en la armonización de estos sistemas de clasificación con terminologías internacionales como SNOMED-CT y LOINC, garantizando interoperabilidad a nivel nacional e internacional. Para avanzar al nivel de interoperabilidad organizacional, es necesario también estandarizar los modelos que representan los procesos de negocio de las diferentes organizaciones que conforman el SGSSS. Estos modelos hacen parte de la vista empresarial descrita en el MAI. Adicionalmente, se recomienda tomar como referencia el modelo funcional para sistemas de gestión de registros de salud electrónicos (EHR-FM), el definido por HL7 y soportado por ISO [34].

AGRADECIMIENTO

Este trabajo fue apoyado financieramente por el programa QUIPU: The Andean Global Health Informatics Research and Training Center (D43TW008438-0109), el DAAD (Proyecto pHealth) y la Universidad del Cauca. Los autores agradecen especialmente al MSC. Carlos Ruíz, por las correcciones y gran trabajo editorial.

REFERENCIAS

[1]. Congreso de la República de Colombia. Ley 100 de 1993 (1993). Consultado el 12 de febrero de 2011, en: www.secretariasenado.gov.co/senado/basedoc/ley/1993/ley_0100_1993_pr001.html.         [ Links ]

[2]. Ministerio de Protección Social de Colombia, Política Nacional de Prestación de Servicios de Salud (2005). Consultado el 14 de noviembre de 2011 en: www.minsalud.gov.co/Ministerio/Documents/Politica Nacional de Prestaci%C3%B3n de Servicios de Salud.pdf.         [ Links ]

[3]. Canada Government. Canada Health infoway, (2001). Consultado el 15 de marzo de 2011 en: www.infoway-inforoute.ca/lang-en/.         [ Links ]

[4]. Australian Government Departament of Health and Ageing. Health Connect- NEHTA (2004). Consultado el 11 de marzo de 2011 en: www.health.gov.au.         [ Links ]

[5]. Li, Y. National Health Information Infrastructure (NHII) and International Standards. Graduate Institute of Medical Informatics, Taipei Medical University. Consultado el 15 de diciembre de 2012 en: www.himss.org/asp/ContentRedirector.asp?ContentID=65389.         [ Links ]

[6]. Congreso de la República de Colombia. Ley 1438 de 2011 (2011). Consultado el 12 de febrero de 2012 en: www.secretariasenado.gov.co/senado/basedoc/ley/2011/ley_1438_2011.html.         [ Links ]

[7]. IEEE. Standard Computer Dictionary. A Compilation of IEEE Standard Computer (1991), Glossaries, p. 1,         [ Links ].

[8]. Castrillón, H. Modelo arquitectónico de interoperabilidad entre Instituciones Prestadoras de Salud en Colombia. Tesis de Maestría, Maestría en computación, Universidad del Cauca, 2012.         [ Links ]

[9]. HSSP. Healthcare Services Specification Project (2005). Consultado el 07 de agosto de 2010 en: http://hssp.wikispaces.com/standards.         [ Links ]

[10]. Kitchenham, B. DESMET: A method for evaluating software engineering methods and tools. Computing and Control Engineering Journal, 8, 3, 120 - 126, 1996.         [ Links ]

[11]. Pan American Health Organization. HSS - Integrated Heath Service (2010). Consultado el 05 de marzo de 2011 en: new.paho.org/hss/.         [ Links ]

[12]. Pan American Health Organization. Infraestructura de Salud Pública - Bibliografía Anotada (2010). Consultado el 05 de marzo de 2011 en: http://new.paho.org/hss/index2.php?option=com_docman&task=doc_view&gid=10258&Itemid=99999999&ei=8NxzTdrFFYW2tgebyeX2Dg&usg=AFQjCNHxDzuSty-USIDOAR58Pi07_W8gVw.         [ Links ]

[13]. Department of Health Informatics Directorate UK. NHS Connecting for Health (NHS CFH) (2004). Consultado el 01 de marzo de2011. en: http://www.connectingforhealth.nhs.uk/.         [ Links ]

[14]. HL7. CDA Release 2 (2012). Consultado el 12 de Febrero de 2012 en: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7.         [ Links ]

[15]. ICW. Technologies für Gesundheit, Reference Case: BIT4health (2003). Consultado el 10 de abril de 2011 en: http://www.icwglobal.com/.         [ Links ]

[16]. The openEHR Foundation. OpenEHR specifications, (2011). Consultado el 14 de febrero de 2011en: http://www.openehr.org/home.html.         [ Links ]

[17]. Canada Government. International Standard from Infoway (2004). Consultado el 14 de febrero de 2011 en: https://www.infoway-inforoute.ca/flash/lang-en/scguide/docs/StandardsCatalogue_en.pdf.         [ Links ]

[18]. Presidencia de la República de Colombia. Programa Gobierno en Línea (2011). Consultado el 10 de febrero de 2011 en: http://programa.gobiernoenlinea.gov.co/.         [ Links ]

[19]. Ministerio de Protección Social de Colombia. Sistema integral de información para la protección social (2007). Consultado el 20 de julio de 2011 en: http://www.sispro.gov.co/.         [ Links ]

[20]. Liñeiro, A.B. Estandarización e interoperabilidad sanitaria desde las TIC y el impacto en el modelo colombiano. Sintel, 6, 2008.         [ Links ]

[21]. López, D. Un sistema de vigilancia en salud pública para alertas tempranas. Sistemas y Telemática, 5, 10, 57-72, 2007.         [ Links ]

[22]. Portilla, F., Tamura, G., Villegas, N. Aspectos metodológicos del proceso de adopción del estándar HL7 v3 en Colombia: la experiencia del Comité Técnico de Casos de Uso de Laboratorio Clínico. Sistemas y Telemática, 7, 22, 71-90, 2009.         [ Links ]

[23]. HL7 Colombia. Boletín informativo HL7 Colombia (2007). Consultado el 03 de febrero de 2012 en: www.hl7.org.co/files/hl7col_pub_boletin.pdf.         [ Links ]

[24]. Oemig, F. Blobel, B. A communication standards ontology using basic formal ontologies. Studies in Health Technology and Informatics, 156, 105-13, 2010.         [ Links ]

[25]. ISO. FCD 9126-1.2 Information Technology Software Product Quality, (1998). Consultado el 15 de marzo de 2012 en: www.issco.unige.ch/en/research/projects/ewg96/node14.html#SECTION00311000000000000000.         [ Links ]

[26]. Blobel, B., Oemig, F. What is needed to finally achieve semantic interoperability? World Congress on Medical Physics and Biomedical Engineering, 411-414, 2009.         [ Links ]

[27]. Bostech. ChainBuilder (2004). Consultado el 02 abril de 2011 en: www.chainforge.net.         [ Links ]

[28]. Java. The Open Enterprise Service Bus (2005). Consultado el 02 de abril 2011en: http://wiki.open-esb.java.net/.         [ Links ]

[29]. Apache Software Fundation. Project Apache Servermix (2004). Consultado el 02 de abril de 2011 en: http://servicemix.apache.org.         [ Links ]

[30]. Microsoft. Biztalk ESB Toolkit (2008). Consultado el 02 de febrero de 2011 en: http://msdn.microsoft.com/en-us/biztalk/dd876606.         [ Links ]

[31]. Microsoft, Biztalk server 2010, (2009). Consultado el 01 de febrero de 2012 en: www.microsoft.com/biztalk/.         [ Links ]

[32]. Microsoft, BizTalk Accelerator for HL7, (2007). Consultado el 02 febrero de 2011 en: http://www.microsoft.com/biztalk/en/us/accelerator-hl7.aspx.         [ Links ]

[33]. HL7. Hl7-Medical Record (2012). Consultado el 12 de febrero de 2012en: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=74.         [ Links ]

[34]. ISO/HL7. DIS 10781: Electronic Health Record-System Functional Model, Release 2.0 (EHR FM), (2012). Consultado el 15 de marzo de 2012 en: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=57757.         [ Links ]