D5/D7 Sistema multi-agente de gestión de actividades

Transcripción

1 PLAN NACIONAL DE I+D+I PROGRAMA NACIONAL DE TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES PalliaSys TIC Uso de las nuevas tecnologías de la información y las comunicaciones para facilitar el tratamiento de pacientes paliativos D5/D7 Sistema multi-agente de gestión de actividades Tareas: Versión: Autor(es): Organización(es): T5. Diseño de un sistema inteligente de gestión de actividades de la UCP T7. Implementación del sistema informático integral 1.0, Definitiva A.Moreno, D.Riaño, A.Valls URV Última modificación: 31/07/2005 Confidencialidad: Tipo de documento: Documento de libre acceso Deliverable de las tareas T5 y T7 Copyright PalliaSys En el proyecto PalliaSys participan: Universidad Rovira i Virgili (URV, Tarragona) Personal investigador, Grupo de Investigación en Inteligencia Artificial Hospital de la Santa Creu i Sant Pau (HSCSP, Barcelona) Personal médico, Unidad de Curas Paliativas

2 RESUMEN Este documento es el resultado de las tareas T5 y T7: Diseño de un sistema inteligente de gestión de actividades de la UCP, e implementación del sistema informático integral. En este documento se detalla el sistema multi-agente que se encarga de gestionar las diferentes actividades de una UCP (tipos de agentes, funcionalidades de cada agente, flujo de información entre ellos). Se ha incorporado el sistema multi-agente de control de la actividad de la UCP, al prototipo implementado en la tarea T4, que ya incluye la base de datos de la UCP y los métodos de comunicación con la misma. El sistema multi-agente incluye un agente encargado del análisis inteligente de los datos aplicando los algoritmos desarrollados en la tarea T6. Este documento se apoya en las tareas comentadas en los documentos D2: Descripción de la Base de Datos, D3: Mecanismos de acceso a la información de cada tipo de usuario y D4: Diseño e implementación del prototipo, donde se explican de forma detallada aspectos referenciados en este documento. TIC PalliaSys, Julio 2005 Página 2

3 1. INTRODUCCIÓN Algunos autores ([6]) han argumentado en los últimos años que las características principales de los agentes y de los sistemas multi-agente (MAS) les hacen una tecnología apropiada en la solución de problemas en el área del cuidado médico. Hay muchos trabajos recientes que sugieren el uso de agentes en este dominio (véase e.g. las colecciones de artículos disponibles en [2], [3], [4] y [7]). Estos trabajos exploran el uso de agentes y de sistemas multi-agente en una amplia gama de problemas, tales como la coordinación del trasplante de órganos y tejidos, el acceso personalizado a la información médica, los sistemas de ayuda a la toma de decisiones o la supervisión automatizada del paciente. Una tendencia científica reciente sugiere que sería muy útil ensamblar el funcionamiento inteligente de los sistemas multi-agente con el acceso flexible a la información con nuevas tecnologías de la información y las comunicaciones. Según esta tendencia es posible predecir un panorama futuro dominado por la inteligencia ambiental, en la cual agentes ubicuos se comunicarán mediante redes inalámbricas para proporcionar servicios inteligentes a los usuarios ([1]). 2. PROYECTO PALIASYS El objetivo principal del proyecto PalliaSys es diseñar, construir y desplegar un sistema automatizado para mejorar la gestión de los datos almacenados en la unidad de cuidados paliativas (UCP) de un gran hospital. Esta unidad se especializa en tratar a gente con enfermedades terminales, y su objetivo es aliviar su dolor en la fase final de sus vidas. Dependiendo de la diagnosis médica inicial, el paciente puede ser tratado en la UCP, en otra unidad del hospital, en un centro socio sanitario asociado al hospital, o en su casa. Debido al carácter altamente distribuido del cuidado paliativo, es particularmente interesante tener un sistema informático que permita el intercambio de la información entre el personal que participa en el tratamiento de un paciente (doctores de la UCP, doctores asociados a otras unidades o a un centro socio sanitario, los equipos médicos que hacen visitas en los hogares de los pacientes, los cuidadores de la persona). El sistema PalliaSys está especialmente dirigido a los pacientes que permanecen en sus hogares, de modo que tengan la posibilidad de tener acceso a algunos servicios sin tener que desplazarse al hospital. 2.1 LAS METAS BÁSICAS DEL PROYECTO Una primera meta del sistema PalliaSys es mejorar el proceso de recopilar y de recoger la información de los pacientes paliativos. Los datos se almacenan en una base de datos central situada en la UCP del centro médico. El sistema proporciona a los usuarios que participan en el cuidado de un paciente paliativo un acceso seguro y autenticado a los datos de los pacientes (Ver D3: Mecanismos de acceso a la información de cada tipo de usuario). TIC PalliaSys, Julio 2005 Página 3

4 Una segunda meta del proyecto es mejorar la información de la que disponen los doctores sobre los pacientes. Usando un SMA es posible supervisar continuamente el estado de cada uno de los pacientes y proactivamente proporcionar información personalizada, detallada y actualizada a los doctores de la UCP. Éste es uno de los aspectos principales de este documento. Finalmente, otra meta importante de PalliaSys es hacer un análisis inteligente de los datos históricos recopilados en la UCP, aplicando técnicas novedosas de minería de datos y técnicas de aprendizaje. Por ejemplo, es factible definir modelos de pacientes, analizar la evolución médica y los flujos de diversos tipos de pacientes, y crear los modelos de estas evoluciones que permitan hacer predicciones de los estados futuros de pacientes. Uno de los agenets del sistema multi-agente, el agente analizador, se ocupa de realizar esta tarea. 3. ARQUITECTURA DEL SISTEMA MULTI-AGENTE En esta sección describimos el sistema PalliaSys y sus diversos componentes. La arquitectura básica del sistema PalliaSys se muestra (en una forma simplificada) en la figura 1. Figura 1. Arquitectura Multi-Agente del proyecto Palliasys. TIC PalliaSys, Julio 2005 Página 4

5 Dos partes principales pueden ser distinguidas dentro del sistema: 1. Tecnologías de la información y las comunicaciones, usadas por los pacientes en sus hogares para proporcionar o consultar sus datos médicos personales, para enviar autoevaluaciones o para recibir la información de los doctores. (Ver D4: Diseño e implementación del prototipo). 2. Un sistema multi-agente, usado para manejar con seguridad los datos clínicos, sin perder de vista el estado de los pacientes paliativos y analizando su evolución. En el sistema, podemos encontrar seis tipos de agentes: Agente Wrapper de la Base de datos. Este agente controla el acceso a la base de datos de la UCP. Incluye los mecanismos de autentificación que aseguran que solamente los agentes correctamente autorizados puedan solicitar los datos clínicos para leerlos o modificarlos (en la línea del sistema HeCaSe, [5]). En este agente se aplican algunos mecanismos de seguridad, tales como la definición de diversas clases de usuarios, la asignación de diversos permisos a cada uno de ellos, el uso de contraseñas y el cifrado de mensajes usando SSL (véase D3: Mecanismos de acceso a la información de cada tipo de usuario y D4: Diseño e implementación del prototipo). Este agente se comenta con más detalle en la sección 4. Un agente doctor para cada doctor de la UCP. Este agente funciona en el ordenador personal del doctor. Proporciona una interfaz gráfica que permite que el doctor obtenga fácilmente la información de sus pacientes, controle el horario de visitas, o compruebe, como será detallado más abajo, si el sistema ha activado alguna alarma con respecto al deterioro de la salud de un paciente. Un agente paciente para cada paciente. Cada uno de estos agentes es responsable de controlar la evolución del paciente. Estos agentes deben comprobar si los pacientes envían los informes periódicos referentes a su estado de salud o no. Una característica interesante es que si el agente paciente detecta cualquier problema (e.g. el grado de dolor ha aumentado desde la auto-evaluación pasada), puede enviar una advertencia al agente doctor responsable de ese paciente, para tomar las medidas apropiadas (e.g. una llamada telefónica o una visita a domicilio del paciente). Una explicación detallada del sistema de gestión de alarmas diseñado y puesto en ejecución en el proyecto PalliaSys se da en la sección 5 del documento. El sistema multi-agente también incluye un agente, el analizador de los datos, especializado en la minería de datos, el descubrimiento del conocimiento y técnicas de aprendizaje automático. Su tarea principal es realizar un análisis inteligente de la evolución de los pacientes y descubrir conocimiento médico interesante y útil, como se ha comentado arriba. Por otra parte, el jefe de la UCP tiene el deber administrativo de escribir un informe anual que detalla toda la actividad de la unidad en el plazo de los 12 meses pasados. Para facilitar esta tarea, el agente analizador también proporciona una serie de estadísticas básicas sobre los datos de la BD de la UCP. Se comentan algunos aspectos de este agente en la sección 6. Un agente Socket descrito en al sección 7 que permite la comunicación entre las dos partes de la arquitectura del sistema Palliasys. Este agente será el encargado de avisar a los agentes pacientes para que realicen la tarea de chequeo de alarmas con la consiguiente activación si es necesario. TIC PalliaSys, Julio 2005 Página 5

6 Y finalmente un agente que se ejecuta en entornos móviles. Este agente nos permite interactuar con el sistema mediante un aparato de telefonía móvil, pudiendo enviar una auto-evaluación desde cualquier lugar donde se encuentre el paciente. Los detalles de este agente se encuentran en la sección 8 de este documento. 4. AGENTE DB WRAPPER Este agente, como se ha comentado en el apartado anterior, es el encargado de controlar el acceso a la Base de Datos de la Unidad de Cuidados Paliativos. Este agente funciona como capa envolvente al acceso a la base de datos interactuando con ésta y el exterior, siendo su función principal la de servir las peticiones de inserción, modificación, eliminación y consulta de los datos referentes a los pacientes, por parte de los agentes o servicios (web o telefonía, ver posteriormente en este documento) destinados a estas tareas. A su vez, el agente Wrapper ejerce el papel de controlador de acceso a los datos del sistema pidiendo autentificacion a todo aquel que intente conectar con la base de datos. Para este cometido el sistema prevee la definición de una serie de usuarios con unos permisos de acceso explicitos. Por otro lado, las comunicaciones entre el agente Wrapper y otros agentes o servicios se realiza de forma cifrada mediante SSL, necesaria para la transmisión de datos criticos mediante canales de comunicación de carácter abierto (véase D3: Mecanismos de acceso a la información de cada tipo de usuario y D4: Diseño e implementación del prototipo). 5. GESTIÓN AUTOMATIZADA DE ALARMAS En la situación actual, todos los pacientes tienen que hacer visitas periódicas al hospital, para ser examinados por los doctores y controlar su evolución. En cada visita los pacientes tienen que completar un formulario de auto-evaluación. En este documento tienen que evaluar (con un valor entre 0 y 10) diez aspectos subjetivos relacionados con su salud: los grados de dolor, debilidad, depresión, ansiedad, vómito, insomnio, hambre, bienestar, problemas de respiración y sequedad de boca. Durante la visita, el doctor comprueba todos los valores y los puntúa según su criterio experto. Además, el doctor también evalúa los criterios de complejidad (características personales del paciente, problemas médicos especiales, estrategias terapéuticas). Finalmente, el doctor puede tomar algunas decisiones referentes al cuidado del paciente, tales como pruebas clínicas que posteriormente ordenan, modificar el tratamiento del paciente, o cambiar la ubicación del paciente (por ejemplo, hospitalizar a un paciente en un centro socio sanitario si su salud se ha deteriorado demasiado). Uno de los objetivos de PalliaSys es facilitar el proceso de recogida de información de las auto-evaluaciones de los pacientes, de modo que puedan enviar esta información periódicamente desde sus hogares (e.g. cada semana) sin tener que ir al hospital tan a menudo. La idea es poner a su disposición las diversas tecnologías de la información y las comunicaciones, tales como la web, teléfonos móviles o PDAs, de modo que cada paciente pueda elegir la manera de comunicación que le sea más cómoda o fácil de utilizar. Los mismos canales de comunicaciones se pueden utilizar también para recibir la información del sistema. Hay alrededor de 500 nuevos pacientes en la UCP del Hospital de la Santa Creu i Sant Pau cada año, así que la cantidad de datos generados por auto-evaluaciones semanales TIC PalliaSys, Julio 2005 Página 6

7 es muy grande, y es una tarea muy costosa en tiempo para los doctores estudiar toda esta información y analizar la evolución de cada paciente en las semanas o los meses pasados. Por ello los doctores sugirieron que podría ser muy útil tener una manera de analizar automáticamente toda esta información y ser alertados cuando ocurra una situación anómala. En los documentos D3: Mecanismos de acceso a la información de cada tipo de usuario y D4: Diseño e implementación del prototipo, se detalla el proceso de recogida de información mediante una página web. En el sistema PalliaSys, este proceso de recogida de información también es posible mediante un teléfono móvil. Esto es debido a que el sistema implementa un agente, capaz de ejecutarse en entornos móviles (véase sección 8). 5.1 DEFINICIÓN DE ALARMA PERSONALIZADA El hecho de tener un Agente doctor para cada doctor de la UCP permite que personalizemos el uso del sistema para cada uno de ellos. En detalle, cada doctor puede definir sus propias "situaciones de alarma", considerando sus preferencias y las características personales de los pacientes. Las alarmas se pueden definir en dos niveles: Las alarmas generales Son definidas por la gerencia de la UCP, a través de su Agente doctor personal, y tienen que ser aplicados a todos los pacientes de la unidad. Estas alarmas corresponden a las situaciones que exigen una respuesta inmediata, según la política de la UCP. Las alarmas específicas de cada Doctor Cada doctor puede definir situaciones personales de alarma, y puede decidir si aplicarlas a un solo paciente, a un grupo de pacientes, o a todos sus pacientes. Con esta clase de alarmas personalizadas, cada doctor define una supervisión muy detallada de la evolución del estado de salud de cada uno de los pacientes que están bajo su responsabilidad. El doctor puede ajustar de forma exacta las condiciones de cada paciente que activan una alarma, considerando las características personales de salud y su evolución en las semanas o los meses pasados. 5.2 TIPOS DE ALARMA Para cualquier alarma (general o específica de un doctor), debemos distinguir dos situaciones, dependiendo de si se analizan los datos de una sola auto-evaluación (alarmas básicas) o la evolución del estado de salud de un paciente en una secuencia de auto-evaluaciones (alarmas de evolución). Alarmas Básicas. En este tipo de alarmas, la única información que se considera es la proporcionada por el paciente en la última evaluación enviada al sistema. Por ejemplo, un doctor puede definir una alarma básica tal como la siguiente: ( Debilidad > 7) y ( Dolor > 8) => Debilidad_extrema TIC PalliaSys, Julio 2005 Página 7

8 El doctor puede considerar anormal una situación en la cual el grado de debilidad sea mayor de 7 y el grado de dolor sea mayor de 8, y puede definir una alarma básica, llamada "debilidad extrema", para detectar estas condiciones tan pronto como se presenten. Como se puede ver, el doctor indica las condiciones que algunos de los conceptos de la autoevaluación deben satisfacer (con los operadores booleanos y los operadores estándares de comparación). Además, debe asociar un identificador a cada alarma, de modo que cuando se active alguna de ellas, el doctor pueda notar inmediatamente cuál es la situación anormal que se ha detectado. Después de definir la situación extrema de debilidad mostrada arriba, un doctor puede definir otra alarma básica tal como la siguiente: (Hambre < 3) y Debilidad_extrema => Debilidad_peligrosa En este caso el doctor está definiendo una nueva situación de alarma, llamada Debilidad peligrosa, que será activada cuando un paciente envía una auto-evaluación con altos grados de debilidad y de dolor y un grado muy bajo de hambre. Este ejemplo demuestra cómo una alarma simple se puede utilizar en la definición de alarmas más complejas, permitiendo que los doctores definan una jerarquía completamente personalizada, muy precisa y concreta de las situaciones de alarma. Después de definir una alarma básica, el doctor puede decidir asociarla a un solo paciente o a un grupo de pacientes; así, los doctores pueden definir no sólo sus propias situaciones de alarma sino también personalizar la supervisión de cada paciente particular. Las alarmas básicas permitidas son las que se pueden generar con la gramática siguiente, descrita en BNF: AlarmaBásica Condiciones => IdAlarmaBasica Condiciones (Cond AND Cond) (Cond OR Cond) (NOT Cond) Cond Cond Item Comparación Valor IdAlarmaBasica IdAlarmaBasica Cadena de carácteres Item dolor debilidad depresión ansiedad vómitos somnolencia hambre bienestar problemas de respiración sequedad de boca Comparación < > Valor Las Alarmas de evolución. En muchos casos puede ser más interesante estudiar la evolución del estado de salud de un paciente que simplemente analizar los valores de una sola autoevaluación. Por ejemplo, si un paciente informa de un grado de dolor 6, puede no parecer muy alarmante; sin embargo, puede ser absolutamente anormal si la semana antes el grado de dolor era solamente 2. Una alarma de evolución comprueba el grado de cambio de cualesquiera de los diez aspectos descritos en una auto-evaluación, considerando las n auto-evaluaciones pasadas (alarmas TIC PalliaSys, Julio 2005 Página 8

9 específicas de evolución) o las auto-evaluaciones que se han enviado en los d días pasados (alarmas temporales de evolución). Un ejemplo de una alarma específica de evolución es la siguiente: (2 evals.) Debilidad > 3 = >Aumento rápido de la debilidad Esta alarma, llamada Aumento rápido de la debilidad, sería activada siempre que un paciente informara de un grado de debilidad que es por lo menos 4 unidades más grande que la que está anotada en la auto-evaluación pasada (e.g. el ejemplo descrito arriba con un salto repentino de 2 a 6 entre dos auto-evaluaciones consecutivas). En el caso de alarmas temporales de evolución, el sistema comprueba la evolución de un paciente en cierto período de tiempo. Un ejemplo de tal alarma es la siguiente: (28 dias) Dolor > 4 =>Aumento extremo del dolor La alarma Aumento Extremo del dolor se activaría cuando, después de recibir una autoevaluacion de un paciente y de analizar todas las evaluaciones enviadas por ese paciente en las 4 semanas anteriores, puede notarse que el grado de dolor ha aumentando continuamente, y hay una diferencia de más de 4 unidades entre la primera y la última de ese período (e.g. Si tuviéramos los valores con grado de dolor 2,3,5,7 en los informes recibidos en las 4 semanas pasadas). Las alarmas de evolución permitidas son las que se pueden generar con la gramática siguiente, descrita en BNF: AlarmaEvolucion (entero evals. ) Condiciones => IdAlarmaEspecificaEvolucion (entero dias ) Condiciones => IdAlarmaTemporalEvolucion Condiciones (Cond AND Cond) (Cond OR Cond) (NOT Cond) Cond Cond Item Comparación Valor IdAlarmaEspecificaEvolucion IdAlarmaTemporalEvolucion IdAlarmaEspecificaEvolucion Cadena de carácteres IdAlarmaTemporalEvolucion Cadena de carácteres Item dolor debilidad depresión ansiedad vómitos somnolencia hambre bienestar problemas de respiración sequedad de boca Comparación < > Valor En esta descripción formal se puede observar que, como en el caso de las alarmas básicas, los doctores pueden también combinar el análisis de diversos aspectos dentro de una alarma de evolución, y pueden también utilizar una alarma simple en la definición de una alarma más compleja. El doctor que define la alarma puede también elegir aplicarla a un solo paciente o a todos sus pacientes. TIC PalliaSys, Julio 2005 Página 9

10 Según lo explicado arriba, si una alarma básica o de evolución es definida por el jefe de la unidad de cuidados paliativos, se considera una alarma general y será aplicada automáticamente a todos los pacientes de la UCP. 5.3 PASOS EN LA GESTIÓN DE LAS ALARMAS Para permitir a los agentes supervisar a los pacientes y activar el procedimiento asociado a las alarmas, se deben seguir los siguientes pasos: Definición Cada Agente doctor (AD) proporciona una interfaz gráfica (ver figura 2), a través de la cual el doctor asociado a la UCP puede definir tanto alarmas de evolución (ver figura 3), como alarmas básicas (ver figura 4). Las alarmas generales pueden ser definidas solamente por la gerencia de la UCP, con su AD personal. La interfaz provee a los doctores un sistema con funcionalidades útiles: pueden utilizar alarmas simples existentes para definir alarmas más complejas, asignar alarmas a un paciente específico o a todos sus pacientes, desasignar las alarmas, y mirar las alarmas que se han activado y requieren una cierta atención (ver figura 5). Por otro lado, el sistema facilita a los doctores la posibilidad de crear agentes pacientes con los que se asociarán las distintas alarmas definidas. Almacenamiento Una vez que se ha definido y se ha asignado una alarma, el AD envía un mensaje con la definición de la alarma al Agente(s) paciente correspondiente (APs, que puede ser uno o varios, dependiendo de si la alarma se ha asignado individualmente o a todos los pacientes del doctor). El AP almacena internamente la alarma para su uso futuro. Las alarmas generales se almacenan en todos los APs, pues tienen que ser aplicadas a todos los pacientes. Comprobación Cuando un paciente envía una auto-evaluación, se almacena en la base de datos centralizada, y el AP asociado a esa persona recibe una señal (este procedimiento se describirá con más detalle en un posterior apartado referente al agente socket encargado de esta tarea). Dada la señal, este agente solicita los datos de la evaluación al agente wrapper de la DB, y comprueba todas las alarmas generales y específicas que tiene almacenadas. Si hay alarmas temporales de evolución, también tiene que solicitar los datos de las auto-evaluaciones anteriores necesarias para comprobar la evolución del paciente (por razones de seguridad, los APs no guardan las evaluaciones, éstas se almacenan solamente en la base de datos de la UCP). Activación Si un AP detecta que ha ocurrido una situación de alarma, envía un mensaje al AD que definió esa alarma con una explicación de la razón que ha causado la activación. El AD presenta al doctor una lista con todas las alarmas activadas, y después el doctor puede estudiar toda esta información y decidir la mejor conducta a seguir (e.g. telefonear al paciente, enviar a un equipo para examinar al paciente, o enviar un mensaje al paciente solicitando una visita en la UCP del hospital cuanto antes). TIC PalliaSys, Julio 2005 Página 10

11 Figura 2. Agente Doctor Figura 3. Alarmas de Evolución TIC PalliaSys, Julio 2005 Página 11

12 Figura 4. Alarmas Básicas TIC PalliaSys, Julio 2005 Página 12

13 Figura 5 Asignación de Reglas Para poder almacenar, comprobar y activar alarmas, un Agente Paciente debe ser creado en primera instancia por un doctor. Esta tarea se realiza a través de un menú situado en la interfaz gráfica del Agente Doctor. El sistema se encargará de comprobar que el Agente Paciente que se quiere crear no se encuentre ya activo en el sistema (porque otro doctor lo creara con anterioridad). Puede notarse que todo el proceso de gestión de las alarmas está hecho de una manera autónoma, sin que los doctores tengan que preocuparse de comprobar continuamente si los pacientes han enviado sus informes. Los APs envían las alarmas apropiadas a los ADs proactivamente, sin esperar peticiones explícitas de los doctores. En cualquier caso, los doctores pueden comprobar siempre todos los datos de todas las auto-evaluaciones enviadas por sus pacientes. TIC PalliaSys, Julio 2005 Página 13

14 6. AGENTE ANALIZADOR DE DATOS El agente analizador de datos que se presenta en este documento, dentro del contexto del proyecto PalliaSys, trata de dar una solución a la problemática siguiente: Detectar los estados de un paciente y cambios de estado de los pacientes. Detectar los patrones de circuitos seguidos por los pacientes. Construir estructuras de decisión (árboles, reglas, tablas) que ayuden a la toma de decisiones del personal medico. Detectar la evolución de los pacientes, a partir de los estados en que se clasifican los pacientes ya tratados. La figura 3 nos muestra el agente Analizador de datos dentro del contexto del proyecto PalliaSys. Figura 6. Agente Analizador de Datos. El funcionamiento de este sistema se basa en cuatro fases bien diferenciadas: Fase 1: Recogida de datos provenientes de la Base de Datos Hospitalarios. Fase 2: Generación de circuitos de pacientes y de circuitos de cambios de estado. En esta fase se incluye la detección de estados de paciente. Fase 3: Generación de Estructuras de decisión (árboles, reglas y tablas de decisión). Fase 4: Previsión de evoluciones de nuevos pacientes. En el presente documento se describe la Fase 1. Las Fases 2, 3 y 4 se describen de forma más extensa en el documento D6: Técnicas de mineria de datos aplicadas. El acceso a los datos de la Base de Datos Hospitalarios tiene varias entidades en juego. Por un lado esta la PCU Database que es la Base de Datos física; por otro lado tenemos el agente DB Wrapper que es quien interactúa directamente con la Base de Datos, y finalmente tenemos al agente Analizador de Datos que es quien realiza la petición de datos al DB Wrapper para que éste a su vez acceda a los datos físicos y se los devuelva en un formato establecido previamente. TIC PalliaSys, Julio 2005 Página 14

15 El agente analizador de datos proporciona una interfaz gráfica al usuario doctor, con la que puede acceder a las opciones necesarias para completar las 4 fases anteriormente descritas. Las figuras 7, 8, 9, 10 y 11 muestran las principales herramientas disponibles que ofrece esta agente. Figura 7. Circuito de Servicios. Figura 8. Arbol de decisión. TIC PalliaSys, Julio 2005 Página 15

16 Figura 9. Reglas de producción Figura 10. Tablas de decisión TIC PalliaSys, Julio 2005 Página 16

17 Figura 11. Nuevo Paciente TIC PalliaSys, Julio 2005 Página 17

18 7. AGENTE SOCKET El agente Socket permite la comunicación entre las dos partes de la arquitectura del sistema Palliasys, por un lado las tecnologías de la información (servidor web y telefonía movil), y por otro el sistema multi-agente. Mediante las tecnologías de la información los pacientes pueden realizar sus autoevaluaciones allí donde les sea más comodo, y el sistema debe saber que éstas se han producido en un instante concreto del tiempo y actuar en consecuencia (e.g. activando una alarma). Este conocimiento por parte del sistema es gracias al agente socket, que espera este tipo de situaciones. Una vez que se realiza una auto-evaluación por parte de un paciente, se envia al agente socket el número de historial clinico de este paciente. El agente socket se comunica con el agente paciente correspondiente al número de historial clinico recibido. Este último hecho desencadena un comportamiento en el agente paciente correspondiente al chequeo de sus alarmas, cogiendo como valores base los introducidos en la reciente autoevaluación (o auto-evaluaciones pasadas si se trata de alarmas de evolución). El agente socket recibe información tanto desde entornos web como entornos de telefonía móvil, actuando de igual forma en los dos servicios (véase D4: Diseño e implementación del prototipo). 8. AGENTES NECESARIOS PARA ENTORNOS MÓVILES A continuación haremos una breve descripción del funcionamiento de los agentes que se ocupan del manejo del sistema en entornos móviles. Dentro de esta categoría aparecen dos tipos de agentes: Agente Servidor o Servidor Móvil. Este agente se ubica en la misma máquina donde se alberga el agente Wrapper, ya que tiene una misión similar a éste último. El agente servidor está a la espera de las peticiones que provienen de los agentes clientes o agentes móviles. Estas peticiones hacen referencia a datos de pacientes que se encuentran en la base de datos, y por tanto la misión del agente servidor es servir esta información a los agentes que la pidan. Agente Cliente o Clente Móvil. Este agente representa un paciente paliativo, el cual puede enviar al sistema una auto-evaluación mediante su agente personal, que en el caso del sistema PalliaSys se está ejecutando en un teléfono móvil. El Agente cliente muestra, en primera instancia, una pantalla que representa un control de acceso para poder realizar una auto-evaluación. En ella se le pide información acerca de su número de historial clínico, así como una contraseña. Posteriormente, y una vez la información ha sido validada por el agente servidor, se presenta una pantalla donde el paciente puede rellenar los datos de la auto-evaluación. Seguidamente se pondrá en contacto con el agente servidor, que a su vez accederá a la base de datos de la UCP, registrando la información introducida. TIC PalliaSys, Julio 2005 Página 18

19 Figura 12. Agente Cliente o Móvil Como se puede observar la interacción de las diferentes partes del sistema con la base de datos, se produce a través de dos agentes: Wrapper y Servidor Móvil. Esto es debido a que los agentes, aunque conviven en una misma plataforma, el software que los implementa es incompatible, en otras palabras, la información que envia un agente cliente o móvil no es interpretada correctamente por el agente Wrapper y se hace necesaria la participación de un agente similar que entienda los mensajes enviados por el paciente mediante su teléfono móvil. Esta cuestión se presenta con mayor detalle en el siguiente apartado. 9. PLATAFORMA JADE Y JADE-LEAP La administración de agentes establece el modelo lógico para la creación, registro, comunicación, movilidad y destrucción de agentes. En el proyecto PalliaSys se han seguido los estándares establecidos por la FIPA (Foundation for Intelligent Physical Agents, organización que promueve el desarrollo de aplicaciones basadas en agentes). Los agentes individualmente proporcionan una funcionalidad interesante, pero lo que les hace tan adecuados para ciertos sistemas es su capacidad de cooperar para resolver problemas. Para poder hacerlo, los agentes deben comunicarse entre sí, utilizando un lenguaje común: ACL (Agent Comunication Language). Para garantizar la homogeneidad y compatibilidad entre los diversos agentes, la FIPA determina qué forma ha de tener un mensaje y su utilización; para ello esta organización elaboró las FIPA Specifications [8]. Todo mensaje esta compuesto por una serie de campos (o slots) que son los siguientes: TIC PalliaSys, Julio 2005 Página 19

20 Figura 13. Elementos de un mensaje Como se observa en la figura 13, existe un campo que identifica el protocolo utilizado y que define una serie de reglas o pasos que se ha de seguir para desarrollar una conversación. Existen diferentes tipos dependiendo de su finalidad: FIPA Request: permite pedir la realización de acciones y devolver los resultados FIPA Query: se utiliza para hacer preguntas. FIPA Contract Net: es un protocolo de negociación (se proponen y se evalúan propuestas). FIPA Iterated Contract Net: variante de la anterior que permite la renegociación. FIPA Brokering: gestiona los servicios disponibles para los agentes. FIPA Recruiting: variante de la anterior. FIPA Subscribe: permite la notificación de hechos importantes. FIPA Propose: simplificación del contract net. En el proyecto PalliaSys se ha usado el protocolo REQUEST, y se utiliza para pedir la realización de una acción. El comportamiento que tienen los agentes que utilizan este protocolo es el siguiente: El agente iniciador envía un mensaje de tipo request al agente receptor para que realice una acción en concreto. TIC PalliaSys, Julio 2005 Página 20

21 El receptor del mensaje lee el contenido del mensaje y obtiene la acción. El agente estudiará la petición y determinará si la puede hacer o no. Si la puede hacer, enviará un mensaje de agree al iniciador y empezará a hacer la acción. Si por alguna razón no puede realizarla, enviará un mensaje de refuse. En cualquier caso, si el iniciador no ha formulado bien el mensaje y, por tanto, no se puede descifrar correctamente, se enviará un mensaje de not-understood. Figura 14. Protocolo FIPA Request En el caso de haber enviado un mensaje de agree, el receptor habrá comenzado a realizar la acción. Cuando acabe, enviará un mensaje del tipo inform. Este puede ser de dos tipos: inform-done que sólo notifica que la acción ha sido finalizada e inform-ref, que devuelve un resultado. Si la acción no se ha finalizado correctamente, se enviará un mensaje de failure indicando la razón. JADE (Java Agent Developement Enviroment) es una herramienta de programación que contiene un conjunto de librerías escritas en JAVA [9] para el desarrollo de Sistemas Multiagente. Además de proporcionar las funciones de manejo de agentes a bajo nivel y las interficies que facilitan la programación, también nos presenta un entorno de ejecución donde los agentes podrán ejecutarse e interactuar. Para JADE, los agentes residen en un entorno predefinido llamado plataforma. Cada plataforma está dividida en contenedores y cada uno de ellos contendrá agentes. Los contenedores podrían asemejarse al dominio de los agentes. La plataforma se enciende en una máquina determinada, mientras que los agentes podrían ejecutarse en cualquier estación. Esto nos ofrece un comportamiento distribuido del SMA que será la base para la incorporación del LEAP. LEAP (Lightweight Extensible Agent Platform) es un addon para JADE, que nos permite obtener un entorno de ejecución para agentes que cumplan las especificaciones FIPA y se ejecuten en dispositivos de recursos limitados, que soporten Java. La necesidad de LEAP, viene dada por la incapacidad de JADE de ejecutarse correctamente en condiciones extremas de recursos, situación que nos encontramos claramente al trabajar en TIC PalliaSys, Julio 2005 Página 21

22 móviles o PDAs. Hay que destacar la naturaleza de las conexiones de estos dispositivos: bajo ancho de banda, conexión intermitente, IPs dinámicas... Todo esto debe ser tratado de forma especial, es por ello que LEAP nació. Su base principal es crear un contenedor para cada dispositivo, donde sus agentes se ejecuten. Estos contenedores, supeditados al contenedor principal (main container), formarán parte de una misma plataforma, que permitirá a todos los agentes trabajar conjuntamente. Desde el punto de vista del desarrollador de aplicaciones, JADE-LEAP es prácticamente igual a JADE, tanto en términos de APIs, como de ejecución, solo teniendo en mente unas ligeras diferencias, que en nada afectan al código de la aplicación. 10. RESUMEN Como se ha podido observar este documento describe como el sistema multi-agente se encarga de gestionar las diferentes actividades de una UCP, mediante diferentes tipos de agentes (Agente doctor, Agente paciente, Agente Wrapper para acceder a la base de datos, Agente analizador). Se han descrito las funcionalidades de cada agente, así como el flujo de información que existe entre ellos. Por otro lado, se detalla con mayor precisión el agente encargado del análisis inteligente de los datos, aunque solamente en la parte de comunicación con otros agentes, ya que los algoritmos aplicados para el analisis de los datos en sí se describen en el deliverable D6: Técnicas de mineria de datos aplicadas. REFERENCIAS [1]. U. Cortés and al. Assistive technologies for the disabled and for the new generation of senior citizens: the e-tools architecture. AI Communications, 16: , [2]. A. Moreno. Special issue of AI Communications on Agents Applied in Health Care, volume 16. IOS Press, [3]. A. Moreno and C. Garbay. Special issue of Artificial Intelligence in Medicine on Software Agents in Health Care, volume 27. Elsevier, [4]. A. Moreno and J. Nealon. Applications of software agent technology in the health care domain. Whitestein series on Agent Technology. Birkhauser, [5]. A. Moreno, D. Sánchez, and D. Isern. Security measures in a medical multi-agent system, volume 100 of Frontiers in AI and Applications, pages IOS Press, [6]. J. Nealon and A. Moreno. Agent-based health care systems, pages Whitestein series on Agent Technology. Birkhauser, [7]. V. Shankararaman, editor. Workshop on Agents in Health Care at the 4th International Conference on Autonomous Agents, Agents-2000, Barcelona, Spain, [8]. Especificaciones de la FIPA. [9]. Lenguaje programación orientado a objetos de Sun TIC PalliaSys, Julio 2005 Página 22