En la actualidad, soluciones como puede ser el entorno Microsoft HealthVault [253] o el ya desaparecido Google Health, han realizado esfuerzos de integración en esta línea. En el caso de la herramienta de Microsoft, la aplicación proporciona un conjunto de drivers para poder recoger los datos de una lista de dispositivos compatibles asociados a un PC con el objetivo de automatizar el proceso de recolección de datos. Sin embargo, Microsoft HealthVault, pese a proporcionar una API con la cual trabajar, opera sobre un repositorio propietario alojado en la nube que funciona a modo de HCE intermediario a disposición de los diversos servicios sanitarios. Más allá de los mecanismos de automatización relacionados con la comunicación con los dispositivos médicos, se trata de una solución cerrada en la que el usuario tiene una capacidad de personalización y configuración mínima. La alternativa propuesta en este trabajo trata de, no sólo solucionar los problemas de compatibilidad de los dispositivos derivados de los protocolos y formatos de comunicación, sino además proporcionar un nivel adicional de homogeneización al desarrollar un modelado uniforme para los dispositivos basado en X73 [254]. Adicionalmente, el HCE sobre el que se soporta no es propietario, sino directamente un sistema interoperable basado en CEN/ISO EN13606 al igual que se implementó en 4.1.1. El resultado ha sido el desarrollo de la plataforma integrada de e‐Salud (denominada
Integrated Health Platform, IHP) centrada en la gestión de dispositivos heterogéneos para
telemonitorización personalizada. En el conjunto de dispositivos médicos incorporados, se incluyen especialmente aquellos que hayan podido quedar obsoletos (dentro de la categoría de “clásicos” con opciones de conectividad no estándar), pero que siguen presentes en la rutina médica diaria, de forma que esos equipos puedan seguir usándose, integrados en esta plataforma. IHP tiene el propósito de servir además como base para el desarrollo y prueba de diversos proyectos de integración sobre la cual se han incorporado nuevas tecnologías y mecanismos como se verá más adelante en este trabajo.
El modelo de información jerárquica sobre los equipos (Figura 29) se elabora a partir de las características básicas definidas en el DIM de X73PHD, siendo completada con algunas propiedades adicionales para cubrir un abanico más amplio de dispositivos según las funcionalidades de los mismos. De esta forma, se ofrece un soporte para el mayor conjunto posible de tipos de equipos comerciales aunque no se hayan contemplado todavía en las especializaciones desarrolladas por X73PHD. En su descripción se incluyen algunos parámetros como información relativa al dispositivo (especialización, fabricante, identificador y modelo), tecnología e interfaz de transporte, tipo de protocolo de comunicaciones y modo de funcionamiento (manual o automático). Todos los atributos están clasificados haciendo uso de la nomenclatura X73.
Figura 29. Ejemplo de modelado funcional de dispositivos en IHP.
Por otro lado, se ha introducido un mecanismo más sencillo de cara a conseguir mejorar la integración, para la gestión de los diferentes atributos que forman parte de los dispositivos médicos. Estos atributos, basados de igual forma en el DIM de X73, representan desde parámetros fisiológicos hasta datos técnicos y de estado del dispositivo en forma de componentes. En la Figura 30 se muestra un esquema de este mecanismo y su relación con el resto de parámetros.
Figura 30. Esquema de clasificación basada en componentes.
La plataforma IHP ha sido diseñada como una aplicación ejecutada sobre una arquitectura HW común (ordenador portátil o sobremesa con sistema operativo Windows). Para la implementación se ha usado el lenguaje de programación C# sobre el framework Microsoft.NET. En el contexto más crítico de IHP, los recursos de conectividad, este enfoque de desarrollo contempla la implementación de forma nativa de algunos interfaces de comunicación cableados como USB, RS‐232 o una mezcla de ambos gracias a conversores (por ejemplo USB ‐> RS‐232) así como inalámbricos, generalmente Wi‐Fi o BT. Mientras que los cableados ofrecen un canal de comunicación punto a punto sin suponer mayor dificultad para la gestión de la comunicación, las tecnologías inalámbricas sí que precisan de un nivel más complejo de gestión al ofrecer una cantidad mayor de canales de comunicación. Por ello es necesario desarrollar un gestor eficiente de conexiones que tenga en cuenta, como veremos más
adelante, los dispositivos aceptados por la plataforma y su integración intrínseca con el resto de las funcionalidades (Figura 31).
Figura 31. Esquema modular de IHP.
En esta implementación, se ha usado la tecnología BT por varios motivos: estar implementada de forma nativa en la mayoría de los ordenadores, disponibilidad de dispositivos médicos con esta tecnología y versatilidad a la hora de añadir módulos adicionales (hasta 8 dispositivos) o la posibilidad de trabajar con librerías disponibles (In The Hand’s 32feet). Finalmente, la gestión de la aplicación se realiza mediante un interfaz principal personalizable que ofrece al usuario varios controles. Este interfaz se ha ido adaptando a diferentes proyectos basados en IHP (Figura 32).
Figura 32. Interfaz original de ejemplo para IHP.
A continuación se detallan los módulos que conforman el sistema IHP:
Database (DDBB) Manager. La base de datos (DDBB) alberga un repositorio local de la información fisiológica relacionada con el usuario, estando debidamente protegidos mediante cifrado, control y registro de acceso. Permite realizar búsquedas detalladas, así como obtener informes o análisis, entre otras funcionalidades. Ofrece al mismo tiempo un repositorio de gestión de dispositivos para IHP donde almacenar las diferentes configuraciones y modelos obtenidos. Remote Connection Manager. Su propósito es el de proporcionar un sistema de suscripción a la
plataforma (servidor), de forma que uno o más usuarios autorizados (clientes) puedan estar recibiendo al mismo tiempo la información de la evolución de los valores fisiológicos del paciente u otros parámetros configurables, obtenidos a través de los dispositivos con el propósito de supervisión. La primera versión de la aplicación cliente remota ha sido diseñada para funcionar ubicuamente en un Smartphone sobre sistema operativo Windows Mobile (ver izqda. Figura 33), y ha sido exportada una aplicación Web. En el primer caso, se han realizado pruebas de transmisión a través de redes de área extendida WAN como 3rd Generation (3G) y General Packet Radio
System (GPRS) [255, 256]. Para la gestión de estas transacciones de datos, se ha diseñado como
primera aproximación un protocolo ligero que soporta las principales funciones básicas del proceso minimizando el payload, basándose en la característica de que la conexión puede ser interrumpida en cualquier momento, sin solicitud de desconexión previa. En cuanto a seguridad, el programa implementa un sistema de identificación basado en login y password para identificación del suscriptor, además de claves de cifrado públicas y privadas (public/private keys) para transferencia de datos (algoritmo Advanced Encryption Standard, AES) (ver dcha. Figura 33). Figura 33. Captura de cliente conectado a IHP y proceso de cifrado. Medical Device Configurator Manager. Este módulo permite gestionar los dispositivos médicos asignados a la plataforma, teniendo en cuenta que la aplicación establece como criterio de diseño que el usuario no dispone de más de un dispositivo orientado al mismo propósito (por ejemplo,
dos tensiómetros diferentes). La información relativa a los dispositivos se encuentra en dos ficheros XML que registrarán las posibles actualizaciones: SupportedDevices y ConfiguredDevices. Se muestra en Figura 34 el interfaz gráfico de la aplicación que incluye la lista de dispositivos soportados (Figura 34 izda.), otra lista conteniendo los configurados localmente (Figura 34 dcha.) y una serie de botones de control (ver zona inferior de Figura 34).
Figura 34. Captura de Medical Device Configuration Manager.
La información de clasificación correspondiente a un pulsioxímetro y báscula contenida en
ConfiguredDevices se muestra en la Figura 35. En ella se describen, además de datos específicos
del modelo y fabricante (<manufacturer>, <model>, <id>), parámetros relacionados con las características de comunicación (<protocol>, <transport>, <configuration>) y la especialización (<specialization>, <units>) haciendo uso de la nomenclatura X73. <configuredDevices> <device> <specialization>MDC_DEV_SPEC_PROFILE_PULS_OXIM</specialization> <protocol>propietary</protocol> <transport>rs232</transport> <manufacturer>nellcor</manufacturer> <model>n560</model> <id>382198392018</id> <type>automatic</type> <info>not provided</info> <configuration> <comPort>COM5</comPort> </configuration> </device> <device> <specialization>MDC_DEV_SPEC_PROFILE_SCALE</specialization>
<protocol>propietary</protocol> <transport>bluetooth</transport> <manufacturer>and</manufacturer> <model>uc321pbt</model> <id>00A09631D1CA</id> <type>automatic</type> <info>not provided</info> <unitsDefinition> <componentName>MDC_MASS_BODY_ACTUAL</componentName> <units>MDC_DIM_KILO_G</units> <componentName>MDC_LEN_BODY_ACTUAL</componentName> <units>MDC_DIM_CENTI_M</units> </unitsDefinition> </device> </configuredDevices> Figura 35. Ejemplo de ConfiguredDevices para pulsioxímetro y báscula.
Medical Device Generator Manager. Facilita la creación de dispositivos según parámetros introducidos manualmente. Si un nuevo dispositivo puede formar parte del ecosistema de la plataforma y no existe todavía un modelo XML disponible en DDBB, permite configurar uno (ver Figura 36). Quedaría incorporar su driver de funcionamiento que describe las características de los servicios, mensajes de señalización y eventos, composición de las tramas y formato de la información. Este proceso requiere de la introducción de una serie de parámetros relativos al dispositivo a nivel administrativo como, por ejemplo fabricante, identificador y modelo, así como las unidades de medida (importante ya que una vez los datos son enviados al HCE remoto, podría producir alertas por falsos positivos) e información relativa al funcionamiento del equipo. Figura 36. Captura de interfaz de Medical Device Generator Manager.
Device Connection Manager. Como ya se ha comentado al comienzo, este módulo se encarga de la gestión de las conexiones establecidas con los dispositivos médicos que hagan uso de diferentes tecnologías. Partiendo de los módulos generalmente disponibles de forma nativa en el equipo (RS‐232, USB, Wi‐Fi, BT), módulos adicionales pueden añadirse a la plataforma ampliando el rango de especializaciones de dispositivos (ANT/ANT+). Para la implementación actual de la plataforma, se diseñó el módulo de gestión BT (ver captura de tensiómetro real en Figura 37), USB y RS‐232 para poder integrar los dispositivos disponibles en el laboratorio de pruebas. Concretamente en BT han sido de especial importancia el uso de las librerías 32feet.NET que ofrecen una gran abstracción de la tecnología BT al tiempo que simplifican el proceso de implementación gracias a una completa colección de clases e interfaces. En la Figura 38 se muestra un esquema del proceso de gestión de una conexión BT con esta librería y las clases y servicios relacionados comparada con la librería de Microsoft. Figura 37. Ejemplo de dispositivo médico Bluetooth: tensiómetro A&D. 32feet Microsoft Figura 38. Librerías BT aplicables a IHP: 32feet vs Microsoft. La plataforma IHP se ha incorporado en diferentes proyectos mostrados en el apartado 5.1.