Cardea. Una Plataforma Osgi Para Servicios Hospitalarios

Cardea. Una plataforma OSGi para Servicios Hospitalarios Saúl Navarro

Silvia Platas

Ramón Alcarria

Grupo Gesfor Avda Manoteras, 32 28050 Madrid [email protected]

Grupo Gesfor Avda Manoteras, 32 28050 Madrid [email protected]

Depto Ingeniería de Sistemas Telemáticos Universidad Politécnica de Madrid Ciudad Universitaria s/n 28040 Madrid [email protected]

Resumen—Este artículo presenta una plataforma OSGi para el despliegue de Servicios hospitalarios. Cardea es una plataforma de servicios de seguimiento hospitalario basada en estándares que permite el despliegue de servicios de forma estándar, segura y controlada, facilitando la integración de la nueva generación de servicios multimedia de una forma homogénea. Se presenta la arquitectura general del sistema y se describen los principales servicios desarrollados. Estos servicios ofrecen funcionalidades tales como la localización e identificación de personas y medicamentos mediante tecnologías de radiofrecuencia, integración con sistemas externos utilizando tecnologías de bus, servicios colaborativos con acceso multidispositivio basados en SIP o la gestión de la información dinámica de las entidades modeladas en el sistema. Finalmente se muestran los resultados del piloto desplegado en el servicio de farmacia del Hospital Gregorio Marañón para la gestión de medicamentos dentro del recinto de farmacia. Palabras Clave—RFID, OSGi, ESB, hospital, contexto

I. I NTRODUCCIÓN Un recinto hospitalario es un entorno complejo y dinámico con un enorme número de habitaciones y dependencias, si bien no son caóticos, tienen un alto grado de impredecibilidad, dado el continuo cambio de personal sanitario, pacientes y medicamentos. La farmacia hospitalaria es uno de los servicios con mayores necesidades de mejora en la automatización, control y seguimiento de medicamentos. La seguridad y el control de la trazabilidad es fundamental para los casos de retirada de lotes defectuosos o medicamentos no autorizados. Los sistemas actuales de gestión de medicamentos basados en lecturas de códigos de barras inducen a errores en la gestión del inventario. Estos errores viene provocados por una gestión manual de la entradas y salidas de medicamentos por parte del personal farmacéutico a través de los sistemas tradicionales de lectura de códigos de barras, pudiendo haber salidas y entradas de medicamentos no registradas. Por otro lado, el control manual del estado de los medicamentos puede provocar falta de previsión de bajo stock o vencimiento de la caducidad de medicamentos, provocando ineficiencias en el servicio y un desaprovechamiento de recursos. Además los sistemas actuales no utilizan de forma automática la información ambiental de las personas y activos, como puede ser su localización dentro del recinto, información de temperatura y humedad, o información proveniente de sensores biométricos. En la línea de trabajo de dar solución a los problemas detectados en el entorno sanitario, Cardea ha propuesto una plataforma de servicios hospitalarios dentro del Subprograma Avanza I+D 2008 (TSI-020302-2008-78), que aborda el

problema del desarrollo de una plataforma de servicios abierta y estándar basada en tecnologías OSGi, RFID y SIP. Por una parte, se ha definido una plataforma que permite el despliegue de servicios de forma estándar, segura y controlada. El framework OSGi[2] permite la definición de unas especificaciones estándar para el desarrollo de servicios. Esto permite el desarrollo de nuevos servicios por parte de terceros y una gestión integral y remota de los mismo, creando un entorno escalable y configurable en función de las necesidades específicas del entorno de despliegue. Por otra parte, se han definido y desplegado unos servicios básico que permiten cubrir las necesidades iniciales de la plataforma, integrando tecnologías que cubren los requisitos iniciales de la plataforma. Las tecnologías de radiofrecuencia RFID [10] han demostrado su potencial para la identificación de personas y objetos, por lo que su uso se está extendiendo en entornos complejos dónde la trazabilidad e inventariado son importantes. Por otro lado, el uso de SIP combinado con OSGi permite el desarrollo de servicios colaborativos entre los distintos actores del entorno hospitalario. Además, la gestión de información contextual permite el acceso a información dinámica y estática de las entidades a gestionar, permitiendo controlar la trazabilidad o detectar posibles alertas. El resto del artículo se estructura como sigue. La sección II enmarca el escenario inicial de la plataforma. La sección III describe la arquitectura de la plataforma propuesta, describiendo con detalle cada uno de sus componentes. La sección IV describe la integración de la pila SIP en la plataforma y en la sección V se detalla la integración de la plataforma con servicios de empresa. Por último, se describe un piloto implantado en el Hospital Gregorio Marañón en la sección VI y se recogen las conclusiones y trabajos futuros sección VII. II. E SCENARIO INICIAL DE C ARDEA Cardea pretendía ofrecer una plataforma de servicios para ser desplegada en un servicio hospitalario. El servicio elegido fue el servicio de farmacia en el hospital Gregorio Marañón. Este servicio se encarga de recibir los pedidos de los medicamentos por parte de los proveedores y de elaborar medicamentos en los laboratorios propios. Una vez recibidos, los medicamentos se clasifican y se almacenan de forma adecuada en las dependencias desde las cuales el personal farmacéutico despacha los medicamentos a los pacientes con receta médica. Además de despachar los medicamentos por ventanilla, también se distribuyen medicamentos a las

diferentes áreas del Hospital Gregorio Marañón. Cardea pretendía satisfacer las carencias del sistema actual basado en lectura de código de barras, el cual inducía muchos errores humanos a la hora de gestionar el inventario de los medicamentos. Los requisitos iniciales de la plataforma fueron: • El sistema debía localizar e identificar al personal farmacéutico, pacientes y medicamentos dentro de las dependencias del servicio de farmacia. • El sistema debía gestionar la diferente información dinámica y estática de las diferentes actores del sistema. El sistema debía gestionar el estado de los medicamentos, quién los ha dispensado y a qué paciente. • El sistema debía proporcionar servicios aviso al personal farmacéutico en situaciones de alerta. • El sistema debía permitir la sincronización de la información relevante con los diferentes sistemas utilizados actualmente, como el sistema de gestión de los medicamentos. Partiendo de estos requisitos, en la siguiente sección se muestra la arquitectura del sistema. III. A RQUITECTURA DE C ARDEA La arquitectura del sistema Cardea [6] se muestra en la figura 1. En esta arquitectura se distinguen tres componentes principales: la plataforma de despliegue de servicios, los servicios desarrollados y la infraestructura RFID. El núcleo principal de la plataforma de servicios Cardea es el framework OSGi (Open Service Gateway initiative). Este framework proporciona un entorno estandarizado para las aplicaciones (conocidas como bundles), definiendo un modelo de ciclo de vida para ellas y un registro de servicios (service registry) para facilitar la integración y descubrimiento entre aplicaciones, generando un modelo de componentes dinámico y completo. Entre los múltiples frameworks existentes, el framework Knopflerfish [9] ha sido elegido por proporcionar la funcionalidad requerida para la plataforma, destacando la consola de administración que permite un control remoto de las aplicaciones desplegadas. Sobre este framework OSGi se despliegan los diferentes servicios hospitalarios desarrollados. La localización e identificación se realiza mediante el uso de etiquetas, lectores y antenas RFID. Dadas las especificaciones de trazabilidad requeridas para este sistema como distancia, velocidad de lectura y licencias, se eligió la banda UHF para realizar la identificación. Las etiquetas permiten identificar a los diferentes elementos trazables a los cuales son adheridas. El registro de estas etiquetas se realiza mediante un lector de tarjetas integrado en una PDA. Esta PDA contiene una aplicación de lectura, actualización y registro de etiquetas, que permite actualizar la información en la plataforma Cardea. La identificación de la localización se consigue mediante la lectura de las etiquetas por parte de arcos de antenas situadas en los puntos de control. Estas antenas están conectadas a concentradores que envían la actividad a través de la red hacia la plataforma. La integración con sistemas RFID no está cubierto por OSGi. Soluciones previas han propuesto la integración de estos sensores en el framework [12], sin embargo en Cardea se integra el sistema de captura de información de los sensores

Fig. 1.

Arquitectura de Cardea

RFID con aplicaciones que hacen uso de esta información. El bundle RFID permite manejar e interpretar la información enviada a través de la red por parte de la infraestructura RFID. Cardea proporciona una plataforma de servicios hospitalarios sensible al contexto. Contexto hace referencia a los factores ambientales y circustanciales que proporcionan información relevante para las diferentes personas y elementos involucrados en el sistema, tales como situación, temperatura y humedad o dispensación. Los actores involucrados en el sistema, como el personal hospitalario y los medicamentos, componen un conjunto de elementos heterogéneos. Se han definido ontologías para su representación, ya que su uso no requiere una correspondencia exacta entre la información disponible y la requerida por el sistema [4][5][8][1]. Se ha integrado una ontología basada en la Web Semántica y en el estándar médico HL7, gestionada a través de Jena [7], un API de reglas del conocimiento y un middleware para capturar, almacenar y proveer información de contexto. Con ello, se ha conseguido un procesamiento inteligente de dicha información contextual que permite generar proactividad en la aplicación. El subsistema descrito recibe el nombre de OCP (Open Context Platform). La plataforma Cardea debe permitir la comunicación con dispositivos y sistemas ajenos a la plataforma. OSGi proporciona servicios que permiten comunicarse con el exterior usando el protocolo http. Estos servicios no proporcionan la flexibilidad para integrarse con dispositivos y sistemas externos. Cardea proporciona un servicio que permite el establecimiento de sesiones SIP con dispositivos que soporten este protocolo. El bundle SIP permite a las aplicaciones desplegadas en Cardea el envío de mensajes de alarmas hacia los agentes SIP integrados en los diferentes dispositivos, proporcionando así un acceso multidispositivo a la plataforma. La arquitectura de este bundle se mostrará en la sección IV. Por otra parte, para cubrir la integración con sistemas externos, Cardea proporciona un middleware de mensajería síncrona y asíncrona que proporciona esta comunicación. El bundle ESB proporciona la flexibilidad para la definición los puntos de acceso a los servicios externos, así como la capacidad de lógica y de transformación de la información recibida para adecuarla a los sistemas externos. La integración con servicios de empresa se detalla en la sección V.

Fig. 2.

Arquitectura del bundle SIP

IV. S ERVICIOS SIP La integración de servicios SIP permite establecer comunicación entre el framework de OSGi y elementos externos utilizados para la recepción de mensajes de alarma. La arquitectura del servicio se muestra en la Fig. 2. Este servicio integra principalmente tres elementos de la arquitectura SIP: •

•

•

Agente de usuario: Constituye el elemento principal de las comunicaciones SIP. El protocolo SIP es un protocolo de nivel de aplicación que utiliza la estructura clienteservidor para realizar conexiones extremo a extremo. Los elementos situados en los extremos son los agentes de usuario (UA). Servidor proxy: Un proxy es un elemento intermedio del proceso de comunicación SIP que se encarga de recibir peticiones SIP y reenviarlas hacia su destino. Aunque no es un elemento fundamental para desarrollar un sistema de comunicaciones, se ha añadido a la arquitectura para observar el comportamiento de la red SIP. Servidor de registro: El servidor de registro es un elemento encargado de recibir las peticiones de registro SIP y su procesamiento, actualizando la información del agente de usuario (dirección, disponibilidad u otras preferencias) situado en el servicio de localización (SIP Location Service). El servicio de localización se implementa como una tabla “Hashtable” donde se almacena la correspondencia entre la dirección URI de los usuarios y su dirección física.

La integración de SIP en un sistema OSGi genera dos ventajas fundamentales. En primer lugar se convierte cualquier servicio OSGi en un SIP UA “virtual”. De esta forma, un dispositivo SIP externo puede establecer comunicaciones utilizando este protocolo sobre un entorno de desarrollo OSGi. Por otra parte, se extiende OSGi para poder manejar un dispositivo SIP desde las aplicaciones instaladas en su framework. De esta forma se dota a los servicios desplegados en la plataforma OSGi de las características de movilidad, presencia, flexibilidad del protocolo SIP. Cardea permite que los terminales móviles o PDAs, con capacidad de comunicaciones por SIP, se registren en el servidor de registro implementado en la plataforma. En este momento, las aplicaciones desplegadas en Cardea pueden hacer uso de la funcionalidad proporcionada por el bundle

Fig. 3.

Arquitectura ESB

SIP, permitiendo conectarse al dispositivo y enviarle mensajes usando la URI registrada. V. S ERVICIOS DE E MPRESA Gracias a la gran aceptación de los ESB (Enterprise Service Bus) en la actualidad, podemos encontrar conectores con los principales productos de código abierto y componentes COTS (Commercial Off The Shelf). El empleo de servicios web, tanto REST como SOAP reduce drásticamente las tareas de integración, que se desacoplan gracias a la integración en el bus. El ESB [3] es un elemento middleware que se basa en mensajería síncrona o asíncrona y que proporciona interoperabilidad segura entre aplicaciones de empresa por medio de XML, interfaces de Servicios Web y reglas de enrutamiento estandarizado de documentos. En la práctica esto significa que los datos son transferidos hacia y desde sus destinatarios basados en directrices preestablecidas que son comunes a todos los grupos que comparten la información, para asegurar que los datos se mantienen tal y como son enrutados. Cardea integra en su plataforma de despliegue un bundle ESB. Este bundle proporciona servicios de envío y suscripción de mensajería al resto de bundles desplegados en la plataforma. El bundle usa el framework de mensajería Mule [11] que permite un configuración dinámica de puntos de entrada, puntos de salida y colas. El bundle ESB despliega un bus que interconecta los servicios de empresa que dan soporte a las diferentes aplicaciones con las que la plataforma Cardea interacciona (Fig. 3). Los servicios de mensajería se definen mediante un fichero XML de configuración del bus, en el cual se establecen los diferentes servicios, sus puntos de entrada y salida al bus, así como componentes y transformadores de mensajes. De esta forma, la configuración del sistema se hace de manera

rápida y dinámica. Se ha establecido un servicio denominado Cardea Gateway, el cual es el encargado de enviar al bus los datos procedentes de la plataforma hacia otras aplicaciones, así como de obtener del bus diferentes datos y redirigirlos a los correspondientes servicios de la plataforma. Cada uno de los servicios tiene asociados una serie de transformadores desarrollados en java encargados de adecuar los datos que se introducen en el bus al formato adecuado esperado por las aplicaciones destino. Con todo ello, el servicio ESB desplegado en Cardea es altamente escalable, permitiendo la integración con nuevos sistemas de empresa de forma dinámica mediante la definición de la configuración. Maneja todas las interacciones entre aplicaciones y componentes de forma transparente, independientemente si las aplicaciones están desplegadas en la misma máquina o si son accesibles a través de internet, y también es independiente de los protocolos de transporte utilizados. VI. E XPERIMENTACIÓN El sistema propuesto ha sido implantado de forma experimental en el servicio de farmacia del Hospital Gregorio Marañón durante el mes de marzo de 2009. La plataforma Cardea pretendía gestionar un grupo de ocho medicamentos representativos que permitiese evaluar la plataforma. Durante la fase de experimentación, sólo los medicamentos fueron gestionados a través de la plataforma Cardea, ya que la involucración de pacientes hubiese requerido la autorización de los mismos debido al manejo de información sensible de los pacientes y ésto hubiese provocado retrasos en la implantación. En este escenario de experimentación se definieron dos servicios externos. Estos servicios fueron simulados para que la plataforma no fuera intrusiva con los sistemas actuales. Los sistemas definidos fueron: • Sistema Gestor de Alarmas: Este sistema se encarga de la gestión de las alarmas producidas. En Cardea, se definieron dos tipos de alarmas: un medicamento está caducado o el stock de un tipo de medicamento está por debajo del umbral deseado. El bundle OCP es el encargado de detectar las alarmas por caducidad y el bundle RFID de la gestión de stock bajo. Estos bundles hacen uso de los servicios del bundle ESB para enviar las alarmas a este sistema de gestión de alarmas. • Sistema de Gestión Farmacéutica: Este sistema es el encargado de gestionar la actividad de los medicamentos dentro de la farmacia. El bundle OCP detecta los cambios de contexto de los medicamentos y envía la información de contexto hacia el sistema de gestión farmacéutica usando los servicios del bundle ESB. Estos sistemas fueron simulados mediante la exposición de servicios web que recogen la información del bus y una aplicación web que mostraba los diferentes mensajes de alarma y actividad, permitiendo evaluar el correcto funcionamiento de la plataforma. Por otro lado, las alarmas detectadas dentro de la plataforma eran enviadas a su vez a un agente SIP externo a través de los servicios ofrecidos por el bundle SIP. La tasa de etiquetas no leídas de forma automática por la red de antenas ha sido inferior al 2.5%. Los principales factores identificados de esta tasa son:

• •

Registro erróneo por parte del personal farmacéutico al adherir las etiquetas a los envases. Velocidad de lectura. Durante la entrada masiva de medicamentos, el tiempo de paso por los arcos de antena no era suficiente para una lectura correcta de todas las etiquetas.

VII. C ONCLUSIONES Y F UTUROS T RABAJOS En este trabajo de investigación se ha presentado una plataforma basada en tecnologías OSGi, SIP y RFID para la localización e identificación de medicinas en un entorno hospitalario. El trabajo ha utilizado un framework OSGi que facilita el despliegue de los diferentes módulos utilizados y permite el despliegue de nuevos servicios. La plataforma expuesta, aunque se ha modelado para entornos hospitarios, puede fácilmente reutilizarse para otros entornos generando una nueva ontología para el nuevo entorno y definiendo nuevos servicios de empresa Finalmente se ha presentado un piloto desplegado en el servicio de farmacia del Hospital Gregorio Marañón durante el periodo de funcionamiento del piloto, los datos recogidos del sistema fueron muy satisfactorios tanto para el personal técnico encargado del despliegue y mantenimiento del sistema, cómo del personal sanitario involucrado. El uso de la plataforma permite la posibilidad de utilizar esta arquitectura para otros entornos, así como ofrecer nuevas líneas de investigación dentro del entorno hospitalario, como puede ser la optimización y mejora de la calidad de los servicios hospitalarios al personal sanitario, pacientes y familiares, así como otro tipo de activos del hospital AGRADECIMIENTOS Cardea ha sido cofinanciado por el Ministerio de Industria, Turismo y Comercio, dentro Subprograma Avanza I+D 2008 (TSI-020302-2008-78) R EFERENCIAS [1] Gu, T.; Wang, X. H.; Pung, H. K. and Zhang, D. Q. An ontology-based context model in intelligent environments, 2004. [2] O. Alliance. OSGi Service Platform Core Specification, 2007. Más información en http://www.osgi.org/. [3] V. Cabrera. Entreprise Service Bus, 2006. [4] H. Chen, T. Finin, and A. Joshi. An ontology for context-aware pervasive computing environments. In Workshop on Ontologies and Distributed Systems. IJCAI-2003, August 2003. [5] H. Chen, F. Perich, T. W. Finin, and A. Joshi. Soupa: Standard ontology for ubiquitous and pervasive applications. In MobiQuitous, pages 258– 267. IEEE Computer Society, 2004. [6] I. Informática. Sitio Web Cardea. Disponible en http://cardea.germinus.com/. [7] JENA. Jena semantic web framework. Disponible en http://jena.sourceforge.net/. [8] M. Klein, A. Schmidt, and R. Lauer. Ontology-centred design of an ambient middleware for assisted living: The case of soprano. In T. Kirste, B. König-Ries, and R. Salomon, editors, Towards Ambient Intelligence: Methods for Cooperating Ensembles in Ubiquitous Environments (AIMCU), 30th Annual German Conference on Artificial Intelligence (KI 2007), Osnabrück, September 10, 2007, 2007. [9] Knopflerfish. Knopflerfish OSGi Framework. Disponible en http://www.knopflerfish.org/. [10] M. Meints. D3.7 A Structured Collection on Information and Literature on Technological and Usability Aspects of Radio Frequency Identification (RFID). FIDIS deliverable, Junio 2007. [11] M. Source. The open source choice for integration and SOA. Disponible en http://www.mulesource.com/. [12] J. Wu, D. Wang, and H. Sheng. Design an OSGi Extension Service for Mobile RFID Applications. E-Business Engineering, IEEE International Conference on, 0:323–326, 2007.