Arquitecturas para la Implementación de Sistemas de Información en Salud Basadas en el Estándar HL7

1 Introducción

La integración de sistemas de información heredados con nuevos sistemas de información es una práctica muy común en el ámbito de los sistemas de información en salud, debido principalmente a las necesidades de migración de datos y a la propia evolución de los sistemas. Este proceso de integración es bastante complejo especialmente cuando se debe ofrecer soluciones de interoperabilidad en el nivel semántico y de servicios. Restricciones políticas y administrativas, escasa documentación, la necesidad de migrar grandes cantidades de datos que han sido recolectados durante años, el impacto en otros sistemas con los que se comparte la información, y la disponibilidad de personal capacitado para desarrollar o mantener las tecnologías de integración [1] , [2], son los principales factores que afectan dicha decisión.

Para tener éxito en un proyecto de integración de estas características, es muy importante el uso de una metodología unificada de desarrollo de sistemas de información en salud (SIS) que permita analizar de forma separada diferentes aspectos de la arquitectura como los procesos de la organización, la información a ser procesada, la distribución de componentes, así como aspectos específicos de las tecnologías a emplear [3], [4]. Las metodologías de desarrollo software existentes, así como nuevas herramientas y tecnologías soportan el desarrollo de soluciones de interoperabilidad. Sin embargo, para alcanzar interoperabilidad semántica, algunos estándares para modelar la información en salud deben ser especialmente considerados en el proceso de desarrollo. Algunas alternativas en estandarización incluyen por ejemplo los arquetipos de openEHR, sin embargo los autores de este artículo creen que la familia de estándares HL7 versión 3, y especialmente algunos elementos (artefactos) del Marco Integral de Desarrollo de HL7 (HL7 Development Framework, HDF), pueden ser utilizados de manera innovadora para apoyar el desarrollo aplicaciones en salud basadas en una arquitectura orientada a servicios.

El objetivo de este trabajo es analizar y demostrar, desde el punto de vista de su implementación (esto es aspectos computacionales y tecnológicos de la arquitectura del sistema), la forma en que el conjunto de especificaciones HL7 pueden ser usados para soportar el desarrollo de sistemas de información en salud, soportados además en los paradigmas del desarrollo dirigido por modelos (Model-Driven Development, MDD), el desarrollo basado en componentes (component-based development) y la arquitectura orientada a servicios (Service Oriented Architecture, SOA).

2 Métodos y Materiales

El análisis de diferentes enfoques arquitectónicos basados en estándares HL7, se realiza teniendo en cuenta los modelos más comunes para la integración de sistemas propuestos en el dominio de los sistemas de información. Basados en estos modelos, el artículo analiza un escenario de integración en salud considerando los diferentes modelos arquitectónicos, centrado principalmente en aspectos de implementación del sistema. La implementación del escenario de integración está guiada por el Marco Integral de Desarrollo para Sistemas de Información en Salud (HIS-DF). A continuación se describen brevemente los modelos de integración y la metodología HIS-DF.

2.1 Modelos Comunes para la Integración de Sistemas de Información

Algunos enfoques que describen arquitecturas para la integración de sistemas de información han sido propuestos en la literatura, por ejemplo [5], [6], [7]. La Fig. 1 resume los más importantes, considerando la integración de un par de sistemas de información.

Fig. 1 Modelos Comunes para la Integración de Sistemas Heredados.

El modelo Interfaz Punto a Punto (Point to Point Interface) define un canal de comunicación directa entre cada par de aplicaciones. Este modelo es apropiado cuando un sistema heredado debe ser integrado a unos pocos sistemas de información. La extensibilidad del sistema, es decir, su capacidad de ser modificado para aumentar su capacidad funcional [8], se ve comprometida en este modelo porque para interconectar (n) aplicaciones, es necesario crear n * (n-1)/2 interfaces.

El modelo Servidor de Mensajes (Messages Server) está basado en la utilización de un enrutador de mensajes el cual actúa como un "puente", encargado de la recepción, mapeo y distribución de los mensajes intercambiados entre las aplicaciones. Este enfoque aumenta la extensibilidad de la solución porque cada vez que se desee integrar un nuevo sistema de información, este puede integrarse de manera sencilla mediante la adición de una sola interfaz hacia el servidor de mensajes. El principal problema con este modelo es que toda la lógica de integración (enrutamiento, mapeo, transformación) está soportada en el Servidor de Mensajes, lo que dificulta la ampliación o creación de nuevas funcionalidades del sistema.

El modelo de Mediación (Mediator) está basado en un servicio central que gestiona las peticiones de las aplicaciones a ser integradas. A diferencia del modelo de Servidor de Mensajes, el modelo de Mediación expone su funcionalidad (lógica de negocio) como un conjunto de servicios o componentes que pueden ser invocados por las diferentes aplicaciones, siendo capaces de compartir su funcionalidad, mientras que esconden su implementación interna. Este modelo abstrae los conceptos de SOA o de Middleware. Un Middleware, desde una perspectiva tecnológica, define las interfaces y los protocolos entre aplicaciones distribuidas en un entorno empresarial, que se ejecutan a su vez en múltiples plataformas [9]. Por otro lado, SOA sería un estilo arquitectónico para el Mediador, definiendo el modelo de orquestación de servicios y la interoperabilidad.

Entre los diferentes modelos de integración, el modelo de Mediación es el enfoque más flexible, el que permite mayor reuso, así como la extensibilidad, mantenimiento, y garantiza la interoperabilidad semántica de los servicios/aplicaciones. Sin embargo por su complejidad y costos de implantación, este enfoque es efectivo sólo en soluciones empresariales de gran escala.

2.2 El Marco Integral de Desarrollo para Sistemas de Información en Salud

HIS-DF es una metodología genérica y personalizable para el análisis arquitectónico de sistemas de información en salud, desarrollado recientemente en el centro de investigación eHealth Competence Center Regensburg [4].

HIS-DF consta principalmente de una base de conocimiento de referencia que incluye las diferentes tareas, roles (miembros del equipo de desarrollo encargados de ejecutar las tareas), productos (artefactos resultantes de cada tarea), guías, fases, flujos de trabajo, etc., necesarios para el análisis de la arquitectura del sistema en proyectos de desarrollo de software de salud, especialmente orientado al desarrollo de soluciones que soporten interoperabilidad semántica. Esta metodología se basa en los principios de la teoría de sistemas tomando como referencia el modelo de componentes genéricos (GCM) [10]. Este enfoque permite modelar el comportamiento estático de los SIS como una agregación de componentes, así como su comportamiento dinámico, descrito como la interacción entre estos componentes. HIS-DF aborda también la complejidad intrínseca de sistemas de información en salud mediante un análisis por separado los diferentes dominios cubiertos por el sistema de información (por ejemplo separando el dominio médico del técnico), además de ofrecer un método para abstraer los diferentes puntos de vista desde los que se puede describir la arquitectura de un sistema de información. Esta abstracción está soportada en el uso del modelo de referencia del estándar abierto para el procesamiento distribuido ISO 10746 (Open Distributed Processing – Reference Model, RM-ODP) [11], el cual define cinco puntos de vista (viewpoints) y un lenguaje para cada vista, con los cuales se puede describir de manera formal los diferentes componentes de un sistema de información. Además, la Arquitectura Dirigida por Modelos (MDA) es también empleada dentro de este marco de desarrollo definiendo un proceso para la transformación de los modelos de la organización a un modelo independiente de la plataforma, y finalmente su transformación a un modelo específico de la plataforma, este último describiendo aspectos tecnológicos de implementación. En la metodología, la implementación de los modelos específicos de la plataforma hace parte del proceso de desarrollo a utilizar (e.g., RUP), sin embargo HIS-DF sugiere el uso de métodos de desarrollo dirigido por modelos (MDD) para facilitar portabilidad a cualquier entorno de desarrollo. Para permitir el uso y adaptación del MDD, unos Perfiles para el Lenguaje Unificado de Modelado (Unified Modeling Language, UML) son aplicados a los modelos de información HL7 [12]. Para una descripción completa de la metodología, se puede consultar las siguientes referencias [4], [13].

3 Análisis del Uso de la Familia de Estándares HL7 en el Diseño de Arquitecturas de Sistemas de Información en Salud

Un análisis de HL7 comparado con otras aproximaciones arquitectónicas como CORBA y DHE [5], [14] por un lado, y su análisis comparado con estándares para registros electrónicos en salud [15] por el otro, ha sido discutido previamente en la literatura. Para realizar un análisis de HL7 desde la perspectiva de implementación de sistemas de información en salud como el que se realiza en este artículo, la reciente Versión 3 de HL7 ha de tenerse en cuenta. Siguiendo las recomendaciones de la metodología HIS-DF, HL7 versión 3 servirá para apoyar el modelado de SIS apoyado en su Modelo de Referencia de Información (RIM) y el conjunto de modelos de información derivados del mismo (e.g., DIM, CIM). Los modelos de información representan el universo de discurso de los mensajes intercambiados por los sistemas en sus respectivos dominios (e.g., administración de pacientes, laboratorios, salud pública, etc.). Es importante también mencionar que los artefactos definidos en la metodología de desarrollo de HL7 versión 3 (HDF) como por ejemplo diagramas de estado (state diagrams), eventos disparadores (trigger events) y las interacciones (interactions); pueden ser utilizados para describir el comportamiento dinámico de la aplicación, así como detalles funcionales del sistema. Sin embargo, más allá de las especificaciones para tecnologías de implementación (Implementable Technology Specifications, ITS), el estándar HL7 versión 3 no prescribe formalmente ninguna solución arquitectónica para la interoperabilidad de los sistemas de salud, ni tampoco una arquitectura de referencia o middleware de integración. Los estándares HL7 que más se acercan una solución tecnológica para la integración de aplicaciones son la especificación para el transporte de mensajes HL7 (HL7 message transport specifications), las cuales proporcionan guías de cómo trasportar mensajes HL7 usando tecnologías de comunicación bien conocidas (por ejemplo Web Services y ebXML); así como algunas especificaciones desarrolladas en el grupo de trabajo interno a HL7 sobre Arquitectura Orientada a Servicios (SIG SOA).

Concretamente, el uso de Servicios Web como transporte se define en la especificación Perfil para Servicios Web (HL7 Web Service Profile, WSP) [16]. WSP restringe el uso de protocolos de Servicios Web como una capa de transporte para el intercambio de mensajes HL7 versión 3. En esta especificación no se considerada, sin embargo, la especificación de la funcionalidad de los servicios (servicios del negocio), las interfaces, las operaciones y el gobierno de servicios.

Por su parte, SIG SOA es un grupo de trabajo comprometido con la definición y documentación de especificaciones funcionales de servicios de e-salud, tratando de asegurar al máximo su conformidad con el estándar HL7. Este enfoque se basa paradigma diferente al del WSP, evolucionando desde mensajería tradicional HL7 hacia la definición de una arquitectura SOA. El SOA SIG define una metodología para la especificación de servicios, y un conjunto de especificaciones funcionales para servicios básicos como el Servicio de Identificación de Entidades (Entity Identification Service, EIS), el servicio de Recuperación, Localización y Actualización (Retrieve, Locate, Update Service, RLUS), y el Servicio de Apoyo a la Toma de Decisiones (Decision Support Service, DSS). Cabe destacar que SOA SIG solamente desarrolla especificaciones funcionales al igual que lo hace por ejemplo el bastante difundido modelo funcional para registros clínicos electrónicos (EHR-S Functional Model Specification). La especificación de los servicios es responsabilidad de la OMG (Object Management Group). SOA SIG tiene por tanto un objetivo más amplio que WSP proveyendo una solución basada en servicios.

SOA SIG también viene trabajando en la definición de una arquitectura SOA de referencia para servicios de e-Salud, la cual define entre otras cosas una taxonomía, y las normas de información y referencia para la implementación de las especificaciones funcionales [17]. Esta arquitectura de referencia ofrecerá un marco genérico de referencia para la facilitar la interoperabilidad de servicios de e-Salud, definiendo una conjunto de servicios genéricos y reusables que puedan ser especializados (adaptados) a proyectos específicos de e-Salud (tecnologías de la información aplicada a salud).

4 El Rol de HL7 en los Diferentes Modelos de Integración

Con el objetivo de demostrar el papel de HL7 versión 3 en los modelos de integración anteriormente expuestos, diferentes alternativas para una solución de integración de sistemas de información heredados en el contexto del Sistema de Información Integrado de Salud en Colombia (SIIS) [18] se analizan a continuación.

En Colombia, especialmente en la última década, varios sistemas de información computarizados han sido desarrollados para apoyar el Sistema Nacional de Vigilancia en Salud Pública (SIVIGILA) [19]. Estos sistemas son principalmente aplicaciones de escritorio, que usan diferentes tecnologías y son a su vez diversos en cuanto a funcionalidad. Recientemente, el Instituto Nacional de Salud (INS) como la oficina gubernamental encargada de la gestión del sistema SIVIGILA, ha diseñado, desarrollado y desplegado una aplicación cliente/servidor (denominada SIVIGILA2007) para apoyar la recolección y reporte de enfermedades transmisibles a las autoridades de salud pública. La situación actual es que todas estas aplicaciones heredadas funcionan de forma totalmente independiente uno de la otra, salvo algunos pocos sistemas que son capaces de intercambiar alguna información en forma de archivos de texto que son importados manualmente. La idea detrás de la propuesta de integración en este artículo, es apoyar el proceso de notificación de eventos de salud pública a las autoridades de salud locales, mediante el desarrollo de un componente de integración que permita la captura de información epidemiológica necesaria por el sistema SIVIGILA directamente de los registros clínicos existentes en los sistemas de información hospitalarios (por ejemplo los llamados Registro Individual de Prestación de Servicios de Salud, RIPS). Ninguno de los sistemas de información existentes actualmente soporta esta funcionalidad.

Considerando los modelos de integración discutidos en la sección anterior, y soportados en las especificaciones HL7 disponibles, las diferentes alternativas para la integración de aplicaciones heredadas para el escenario de integración del sistema de salud colombiano se analizan a continuación.

4.1 Interfaz Punto a Punto

El modelo de Interfaz Punto a Punto puede ser implementado utilizando mensajes HL7 versión 3 como se muestra en la Fig. 2(a). Para conectar los diferentes sistemas de información heredados que hacen parte del sistema de vigilancia en salud pública colombiano, cada sistema debe crear una interfaz HL7 con el fin de permitir el intercambio de información sobre eventos de salud pública. Un mensaje HL7 que puede soportar dicho intercambio de información es el Notifiable Condition Report HMD (PORR_HD100001UV01), definido dentro del Dominio HL7 de salud pública. Así mismo, para comunicar información de diagnósticos clínicos desde los cuales pueda extraerse la información de posibles casos (eventos) de salud pública, el mensaje HL7 Ambulatory Encounter Event Complete (PRPA_HD401003UV01) puede ser utilizado.Cada interfaz HL7 puede ser implementada usando interfaces de programación de aplicaciones (API) para HL7 como por ejemplo Java SIG API [20], que permite analizar y construir mensajes HL7 versión 3. Los mensajes HL7 pueden ser transferidos mediante cualquier protocolo tradicional de transporte (HTTP, TCP, UDP, SMTP, etc.) y usando mecanismos de transporte como por ejemplo una infraestructura de mensajería basada en Servicios Web.

Fig. 2 Aproximaciones de Integración Comunes Usando HL7.

4.2 Servidor de Mensajes

El modelo de servidor de mensajes de la Fig. 2(b) simplifica el intercambio de mensajes entre sistemas de vigilancia de la salud pública y sistemas de información clínica, mediante el uso de servidores HL7. La lógica necesaria para transformar y enrutar mensajes reside en el interior del servidor de mensajes, junto con los conectores a sistemas heredados. Varios productos comerciales están disponibles en el mercado que actúan como servidores de mensajes HL7, por ejemplo, Interfaceware Iguana, HL7Connect, NeoIntegrate, iWay, Cloverleaf, etc. Un servidor HL7 de código abierto muy prometedor es el ofrecido por el proyecto Mirth [21]. Este sistema ofrece fucionalidades de filtrado, transformación y enrutamiento de mensajes; además que recientemente ha incorporado dentro de sus funcionalidades la gestión de mensajes HL7 versión 3. Mediante configuraciones muy simples, es posible la comunicación de mensajes a través de protocolos LLP, SQL, JMS, SOAP Web Services, y FTP.

4.3 Mediación

La Fig. 2(c) muestra una solución basada en el modelo de Mediación. Esta aproximación está basada en una federación de servicios de acuerdo con la arquitectura de referencia SOA para servicios de salud propuesta por HL7. En la arquitectura propuesta en este artículo, los servicios se interconectan a través de una solución de Bus de Servicios Empresariales (Enterprise Service Bus, ESB), que proporciona además acceso a/desde las aplicaciones heredadas. Los denominados Servicios del Negocio (Business Services) están agrupados de acuerdo los diferentes dominios de salud definidos en las especificaciones HL7 (HL7 Universal Domains) como por ejemplo, Salud Pública, Administración de pacientes, Atención en Salud, Contabilidad y Facturación, etc. Aquí, las especificaciones funcionales de servicios HL7 existentes se utilizan para definir los Servicios Básicos de Negocios (Core Business Services) incluyendo EIS, RLUS, y DSS. Finalmente, los Servicios Comunes (Common Services) incluyen servicios como Seguridad, Interoperabilidad, Servicios de Infraestructura.

Volviendo a la arquitectura del Sistema Integrado de Información Nacional de Colombia, el servicio propuesto para el apoyo a la notificación de eventos de salud pública es el Servicio de Salud Pública, incluido dentro de los servicios del negocio (representado en la figura en color gris oscuro). Este servicio puede ser invocado por los sistemas de información hospitalarios para ejecutar automáticamente la notificación obligatoria de los eventos de salud pública. De esta forma también los sistemas de vigilancia en salud existentes (por ejemplo, SIVIGILA2007) pueden invocar este servicio para efectuar el reporte de eventos en salud pública a la autoridad de salud pública correspondiente (por ejemplo, el sistema regional de salud pública). Esta arquitectura provee además una integración completa con otros sistemas fuera del sistema de salud pública, por ejemplo, proveyendo interconexión con sistemas de información de laboratorio para efectual la confirmación clínica de casos dudosos. De esta forma, los servicios comunes se asegurarían interoperabilidad semántica, e interoperabilidad a nivel de servicios.

5 La Implementación del Proyecto de Integración

El modelo de Mediación es el más avanzado entre los enfoques anteriormente investigados dado que soporta interoperabilidad semántica, ofrece una arquitectura orientada a servicios, es flexible, abierto y facilita la conformidad con estándares de información en e-salud. Sin embargo, y especialmente para el escenario de integración expuesto, debe existir un equilibrio entre la disponibilidad y la complejidad de la solución de integración. Siendo el caso de países en desarrollo como Colombia, la principal desventaja para la implantación de una arquitectura robusta como la del modelo Mediador sería la necesidad de desarrollar (o adquirir) en primera instancia los servicios del negocio.

La solución de integración propuesta para el escenario Colombiano combina en una sola arquitectura los modelos de integración de Servidor de Mensajes y de Mediación. Se propone del modelo Servidor de Mensajes como una solución simple y eficiente a mediano plazo basada en la implementación de una interfaz HL7 versión 3 para la interoperabilidad con sistemas de información hospitalarios heredados. Junto a esta solución, se desarrolla un servicio de Salud Pública conforme al modelo de Mediación usando HL7 presentado en la Fig. 2 (c). En el futuro, cuando este servicio pueda ser desplegado y otros Servicios del Negocio y Servicios Básicos estén disponibles, esta solución puede ser integrada en una arquitectura ESB. Si se desean conocer los detalles de la plataforma independiente de la arquitectura utilizada para desplegar el Servicio de Salud Pública, puede consultarse la referencia [12]. En las sub-secciones que siguen, se describen los detalles de implementación de una plataforma independiente de la arquitectura diseñada estrictamente usando la metodología HIS-DF.

5.1 La Solución de Integración en el Contexto de HIS-DF

Tal como es definido en HIS-DF, para la fase de implementación de la solución se ejecuta mediante la trasformación de la arquitectura del sistema descrita en el modelo computacional (Modelo Independiente de Plataforma), a los respectivos modelos de ingeniería y tecnológicos, tal como se detalla en la Fig. 3. En la figura, el modelo de componentes derivado del punto de vista computacional de HIS-DF se transforma en un modelo de componentes Java que representa el punto de vista de ingeniería. Esta transformación está soportada en el modelo de desarrollo dirigido por modelos (MDD) concretamente mediante el uso de transformaciones UML modelo a modelo y su posterior transformación en código fuente usando perfiles UML, por ejemplo, Perfiles UML para Web Services o Enterprise Java Beans (EJB).

Hay dos grandes decisiones que hay que tomar al abordar el punto de vista de ingeniería. La primera es elección de la plataforma de implementación (por ejemplo, CORBA, J2EE, Microsoft^® COM) y la segunda corresponde a los estilos arquitectónicos (por ejemplo SOA, Modelo-Vista-Controlador (MVC) y N-nivel).

La plataforma debe apoyar la interacción distribuida entre los componentes del sistema, es decir, el apoyo a la gestión de transacciones, la persistencia entre objetos, multihilos, la seguridad y el repositorio de los datos. La plataforma seleccionada para el escenario de integración del sistema de información de salud pública es J2EE, debido a su gran aceptación de la industria, la disponibilidad de servicios de código fuente abierto, además de la experiencia previa del equipo de desarrollado en programación de EJBs. La plataforma tecnológica usada es IBM Websphere debido a su disponibilidad dentro del proyecto, además de la plena compatibilidad con la herramienta de modelado utilizado a lo largo del proyecto, es decir, IBM Rational Software Architect (RSA).

El estilo arquitectónico utilizado se ve reflejado en el modelo específico de la plataforma (Platform Specific Model, PSM) de la Fig 3(b). Esta arquitectura se basa en el MVC y la arquitectura multinivel definiendo al menos cuatro niveles: nivel de presentación, nivel del negocio, nivel de datos y nivel de integración.

Fig. 3 Esquema del Proceso de Implementación.

5.2 La Arquitectura Multinivel

En el modelo de la Fig. 3 (b), el nivel de presentación (presentation tier) representa las interfaces de usuario implementadas utilizando la tecnología Java Server Faces (JSF). JSF es un conjunto de APIs de Java que permite desarrollo de interfaces de usuario flexibles e independientes del dispositivo de visualización, además que provee una separación entre la lógica de negocio y el nivel de presentación. JSF es importante en el contexto del proyecto, ya que permite crear fácilmente dos interfaces diferentes a partir de una sola página JSF: una para clientes Web tradicionales mediante una librería JSP (Java Services Pages) para la presentación en HTML, y la otro para clientes que usan dispositivos móviles mediante una librería JSF para la transformación a documentos WML (Wireless Markup Language).

El nivel de negocio (business tier) comprende la lógica de aplicación tal como se describe en el PIM del Servicio de Salud Pública (véase el diagrama de componentes de la Fig. 3 (a)). La lógica se implementa como un conjunto de Java Beans de Sesión y Entidad (Session and Entity Beans). Los Beans de Sesión "Receive Case" y "Delivery Report" encapsulan las operaciones necesarias para implementar la funcionalidad descrita en los respectivos Casos de Uso del servicio de Salud Publica. Los EJBs restantes son objetos que proveen persistencia al modelo de datos definido en el nivel de datos.

El nivel de datos (data tier) se implementa usando Apache Derby, que es una base de datos relacional de código abierto en Java. Esta base de datos almacena de forma permanente los objetos que representan la información sobre eventos de salud pública (Casos) del sistema SIVIGILA, por ejemplo, Pacientes, Servicios de Salud, Lugar del Evento, Reporte de Caso y Reporte Consolidado (Patient, HealthService, Place, CaseReport, and ConsolidateReport).

Finalmente, el nivel de integración (integration tier) incluye las interfaces para la interoperabilidad del sistema con sistemas de información hospitalarios heredados. En el escenario, el EJB denominado "Receive Case" hace uso de la interfaz HL7 "EHR-S HL7 Interface" para intercambiar mensajes HL7 versión 3 con otros sistemas. Esta interfaz se implementa como un conjunto de canales usando el servidor Mirth 1.7, implementando así el modelo de integración de Servidor de Mensajes.

5.3 Transformaciones usando MDD

En el proyecto se utilizaron las funcionalidades de transformación de la herramienta RSA, con el fin de apoyar el proceso de transformación de modelos UML a código Java. La transformación de PIM a PSM (transformación del modelo de la fig. 3 (a) al modelo de la fig. 3 (b)) utiliza el perfil UML para EJB incluido en la herramienta RSA. Además, unos Perfiles UML especialmente creados para el HL7 RIM y algunos DIMs se utilizaron con el fin de "anotar" los modelos UML con la semántica de los modelos de información HL7 [13]. La herramienta de modelado RSA genera el esqueleto del modelo de clases y su correspondiente código Java para los Beans de Entidad, incluyendo de manera especial las operaciones y tipos de datos definidos por HL7. Cabe aclarar que la lógica de las operaciones es codificada posteriormente, de acuerdo a los requerimientos específicos de la aplicación. Detalles sobre esta transformación y los perfiles utilizados se describen en [13].

La comunicación entre los Beans de Entidad y la base de datos relacional es soportada mediante una transformación (mapping) entre los elementos del EJB, y los elementos del Modelo Relacional. Además, el código WML y HTML para las interfaces de usuario también fue generado de manera automática mediante transformaciones a partir de los documentos JSF. Fig. 3(c) muestra una de las interfaces de usuario resultantes después de la transformación. Estas transformaciones también fueron ejecutadas con la herramienta de modelado de IBM.

6 Discusión

En un proyecto de integración de sistemas de información en salud la decisión acerca de qué estilos arquitectónicos y plataformas son más apropiados, depende en gran medida de las necesidades específicas de la organización y sus limitaciones. En consecuencia, es siempre necesario adaptar la arquitectura del sistema a los requisitos específicos del proyecto. El documento aporta un análisis exhaustivo sobre cómo pueden utilizarse el conjunto de estándares HL7 en la integración de sistemas heredados, sobre la base de algunos modelos genéricos de integración y soportado en aproximaciones arquitectónicas maduras como el desarrollo dirigido por modelos (MDD), el desarrollo basado en componentes y en SOA.

Después de analizar los diferentes modelos de integración, se constató que los modelos de Interfaz Punto a Punto y de Servidor de Mensajes pueden ser completamente soportados por mensajes HL7 versión 2 y versión 3; mientras que el modelo de integración de Mediación es parcialmente apoyado por algunos modelos de información del estándar HL7 versión 3. El modelo de integración de Servidor de Mensajes, a pesar de no ser la opción más avanzada, es muy valioso especialmente en proyectos de integración de mediana complejidad, debido a la facilidad ofrecida para implementar de forma rápida interfaces HL7.

Este artículo se ocupa exclusivamente de las perspectivas de la ingeniería y aspectos tecnológicos de las arquitecturas de sistemas de información en salud basados en estándares HL7. Hasta donde es conocido por los autores, estos aspectos no han sido abordados dentro de HL7, ni discutido con anterioridad en la literatura. La arquitectura propuesta se basa en la plataforma EJB que es un modelo de componentes en Java para el desarrollo y despliegue de componentes orientado a objetos y distribuidos. La lógica de aplicación se implementa como un conjunto de EJBs de Sesión y Entidad, lo que permite la escalabilidad, distribución e interoperabilidad de la solución. El uso de EJBs es también es importante, debido a que estos pueden ser fácilmente agregados para el despliegue de Servicios Web (bottom-up development approach) en la implantación de una arquitectura SOA. Considerando que los EJB implementan una serie de operaciones que intercambian mensajes HL7, los sistemas desarrollados pueden interactuar directamente con sistemas de información heredados que implementen interfaces HL7, evitando así la creación de nuevas interfaces. Los servicios pueden ser fácilmente integrados en una infraestructura de ESB.

La aproximación arquitectónica presentada es avanzada porque facilita el desarrollo de sistemas de información en salud semánticamente interoperables, portables, escalables y basados en estándares. Es evidente que entre más detallada sea la arquitectura independiente de la plataforma (PIM), el esfuerzo necesario su para implementación es menor. Además, el uso de modelos y Perfiles UML en forma consistente facilita la reutilización de la arquitectura.

En cuanto a los desafíos metodológicos y tecnológicos abordados, se ha mostrado como puede completarse el ciclo de desarrollo propuesto en HIS-DF, afrontando la fase de implementación mediante la transformación de una arquitectura independiente de la plataforma en código ejecutable. El entorno de desarrollo utilizado fue la familia de herramientas de IBM Rational Software para el análisis, diseño e implementación de sistemas; junto con una base de datos de código abierto y un servidor de mensajes HL7. Las herramientas de IBM fueron elegidas debido a su disponibilidad, robustez, soporte y documentación. Sin embargo, esta no es el entorno de desarrollo óptimo en proyectos de pequeña y mediana escala con presupuestos limitados. La ventaja de usar las herramientas de IBM es que todas ellas se basan en la plataforma Eclipse, existiendo siempre variantes de código abierto para las mismas.

El enfoque arquitectónico presentado demuestra la viabilidad de una solución escalable que combina mensajería HL7 tradicional, con una aproximación más innovadora basada en una arquitectura SOA. Una limitación importante de este estudio de viabilidad es el hecho de que debido a la escasez de recursos, y siendo principalmente un trabajo académico, los autores evaluaron por sí mismos los desarrollos software. Por lo tanto la comparación y evaluación que se presenta en este artículo corre el riesgo de estar sesgada. Como trabajo futuro es deseable una evaluación formal preferiblemente empírica a través de un experimento o un estudio de caso. Actualmente se está negociando la colaboración con el Instituto Nacional de Salud en Colombia (INS), entidad encargada de la gestión del sistema SIVIGILA, a fin de completar la aplicación y evaluar los resultados mediante el desarrollo de un estudio de caso.

7 Conclusión

La integración de sistemas heredados implica un análisis detallado de los procesos del negocio y de los requisitos de interoperabilidad. HIS-DF soporta dicho análisis ofreciendo una metodología detallada para el diseño de la arquitectura del sistema, soportado en un proceso de desarrollo dirigido por modelos (MDD). En el artículo se demuestra cómo, a través de un ejemplo de integración, de los paradigmas del MDD, del desarrollo basado en componentes, SOA, y un conjunto de especificaciones de HL7; es posible desarrollar un proyecto completo de integración de sistemas heredados. El análisis está basado en tres modelos que son los más comunes para la integración de sistemas de información.

Agradecimientos

Este trabajo ha sido parcilamente financiado por el servicio de intercambio del gobierno alemán (German Academic Exchange Service, DAAD) y la Universidad del Cauca en Colombia. Los autores agradecen la colaboración de colegas dentro de la organización HL7 y otros organismos de estandarización en e-salud.

Referencias