"Implementación de un software de tipo - e-IMRT

"Implementación de un software de tipo middleware para la integración de dispositivos biomédicos
de bajo coste en sistemas de tele asistencia"
J. Otero, A. Gómez, F.J. González Castaño, F. Gil-Castiñeira
Abstract
Dos de los problemas principales que se pueden encontrar al implementar la tele-monitorización de
parámetros biomédicos en un proyecto de e-health son la diversidad de los interfaces utilizados por
los dispositivos de monitorización y la ausencia de homogeneidad en los protocolos manejados por
los sistemas encargados de la gestión de esa información. Para solucionar ambos problemas, se
propone un middleware entre las aplicaciones y los dispositivos de medida que permite minimizar
el impacto de estos problemas y disminuir la complejidad del desarrollo de estas aplicaciones. Se
describen sus principios de diseño y arquitectura, incluyendo los esquemas de datos utilizados y los
flujos de los mismos, así como su implementación e integración dentro de un proyecto de telemedicina.
Introducción
Uno de los aspectos clave en la teleasistencia es el seguimiento remoto de los signos vitales de los
pacientes. Poder disponer de estos datos de forma remota permite evitar molestias al paciente
(desplazamientos a centro de salud, comodidad en la toma de las mediciones... ), reducir costes en
los sistemas de sanidad (menos citas y uso de materiales), y hacer un uso más eficiente de los
recursos humanos (médicos, enfermeras, cuidadores..) y técnicos (sistemas de monitorización, salas
de medición...). Dado el envejecimiento progresivo de la población en los países más desarrollados,
el seguimiento de los pacientes en su domicilio de forma continua será cada vez más importante,
por lo que se han desarrollado en los últimos años muchos entornos para facilitar tecnológicamente
dicho servicio (véase por ejemplo [WANG-06] o [DIAZ-06]).
Idealmente, existirían una serie de dispositivos que permitirían realizar la tele-monitorización de
estos signos vitales de forma no invasiva, continua, inalámbrica y transparente. Estos dispositivos
serían interrogados desde un sistema central que procesaría y almacenaría los datos obtenidos. En
este sistema central los datos estarían a disposición del personal cualificado. Además, si los valores
de las mediciones recogidas estuviesen fuera de rangos establecidos como normales, podrían
generarse alertas automáticas. En la actualidad todavía esto no es completamente posible, aunque
se están desarrollando investigaciones en el campo de las redes inalámbricas de dispositivos de
monitorización continua para que realicen su función de forma transparente sin intervención por
parte del usuario. Líneas de trabajo en este sentido son, por ejemplo, los trabajos para obtener
métodos de medición no invasivos para mediciones como la blood glucose [LIU05][LILIENFELD-05] [PICKUP-05] o la blood pressure [KIRSTEIN-05]. También existen
trabajos destinados a producir sensores discretos para alguna parte del cuerpo en concreto
[EDMISON-02] o todo el cuerpo [JOVANOV-05][OTTO-06], o los que proponen la integración de
los dispositivos dentro de elementos textiles ([PARK-03] [COTTET-03] [KALLMAYER-03]
[KLEMM-04] [TRÖSTER-04] [PARADISO-03] [SERGIO-03] ) que ya han dado lugar a alguna
solución comercial [WSENSATEX] [WVIVOMETRIX-HOWWORKS]. Para obtener una
perspectiva general de esta familia de líneas de investigación y su evolución esperada, puede
consultarse [STEPANIAN-04] y [ROBERT-04]. A review of opportunities, constraints and user
cases of wareable computing for medical applications is [RASKOVIC-03]
Dado el estado de la tecnología, en el momento actual no es viable construir dispositivos con las
características comentadas a precios que los hagan viables comercialmente y de uso masivo. Esto
no impide que actualmente se estén comercializando sistema de teleasistencia que incorporen
monitorización de signos vitales. Lo que hacen es utilizar dispositivos domésticos de medición que
incorporan capacidades de comunicación. Estos dispositivos están disponibles comercialmente, y el
usuario puede adquirirlos fácilmente en cualquier tienda o farmacia, a un precio bastante asequible.
Además, aunque no siempre proporcionan una precisión clínica en las mediciones, sí proporcionan
una aproximación a la evolución en el tiempo del parámetro medido, que es lo que generalmente se
busca en algunas áreas de tele-asistencia como la gerontología. El problema para la utilización de
estos dispositivos es que ninguno de sus fabricantes utiliza soluciones estándar y todos ellos optan
por implementar sus propias soluciones. Esto supone un handicap añadido, puesto que se ha de
desarrollar el soporte a bajo nivel para cada dispositivo que queramos incluir en el sistema de teleasistencia.
Otro problema es la no uniformidad existente en las arquitecturas y protocolos de comunicación que
manejan los sistemas centrales que recogen, manejan y almacenan los datos. Estos sistemas suelen
soportar distintos sabores de los estándares, o distintos estándares, o incluso no soportar estándares
en absoluto (utilizar soluciones propietarias). Esto es un problema al intentar construir un desarrollo
que permita que los dispositivos proporcionen datos a distintos sistemas centrales. Es necesario
incluir, para cada sistema central, un “adaptador” para acceder al dispositivo correspondiente, y esto
para cada dispositivo y para cada sistema gestor de información. Las posibilidades son muchas, y
con ellas aumenta el grado de complejidad para mantener el sistema limpio, global y accesible. Es
necesario integrar tanto los dispositivos como las bases de datos de los centros de asistencia, como
se ha puesto en relevancia en [AMATO-06]
Para paliar este tipo de situaciones en donde no existen estándares claros, habitualmente se recurre a
la utilización de middlewares que permiten conectar las diferentes aplicaciones o dispositivos de
forma correcta y simplificada. Así, se han propuesto middlewares para el soporte de redes
inalámbricas de sensores con necesidades especiales como QoS o conservación de la energía
[HEINZELMAN-04]
or the OSA+ middleware for systems with real time needs
[BRINKSCHULTE]. A nivel de aplicación dentro del área de e-Health también se han propuesto
diferentes middlewares sobre todo para el intercambio de información clínica como HL7, DHE o
CORBAmed. Para una comparativa de los mismos véase [BLOBEL-97].
Este paper presenta una solución para los problemas descritos anteriormente en la conexión de
dispositivos médicos a través de la utilización de un nuevo middleware. Primeramente se
presentarán los principios perseguidos en su desarrollo (modularidad, estanquidad,
estandarización...). A continuación se hará una exposición de la arquitectura utilizada para la
implementación, a nivel estático y a nivel dinámico. También se expondrá el caso de uso en el que
se ha probado el middleware, y se repasarán otros entornos en los que el middleware desarrollado
podría ser explotado. Por último se comentarán posibles líneas futuras de trabajo, para la mejora y
utilización del middleware.
Requisitos del sistema
La idea es desarrollar una solución que permita dar soporte a la mayor cantidad posible de
dispositivos y de sistemas de gestión de la información. Además, hacerlo mediante un sistema
abierto y ampliable, en el que se pueda añadir soporte para nuevas funcionalidades, dispositivos y
sistemas de información. La utilización de una arquitectura software tipo “middleware” construida
de forma modular y escalable es una buena alternativa para construir este sistema.
Fig.1 El uso del middleware evita que cada aplicación tenga que soportar directamente cada dispositivo concreto
La utilización de este middleware permitirá un desarrollo controlado del sistema, facilitando la
introducción de modificaciones y la realización de adaptaciones a situaciones no previstas
inicialmente. Asimismo, esta solución permitirá dividir el desarrollo de la arquitectura en una serie
de componentes independientes. Estos componentes tendrán asignadas unas tareas bien definidas,
usarán un conjunto de datos claramente identificados y podrán ser añadidos a la arquitectura según
se necesiten.
El sistema propuesto puede verse como una especie de API que proporciona funcionalidades para
que los sistemas de información accedan a los dispositivos médicos. Desde este punto de vista, lo
que se busca es hacer lo mas transparente posible las características físicas del dispositivo al sistema
de información. Sin embargo, los datos servidos por cada dispositivo serán de distinta naturaleza
(presiones, frecuencias de pulso, temperaturas, niveles de glucosa...), y el sistema de gestión de la
información correspondiente deberá tener cierto nivel de conocimiento de la naturaleza de las
medidas que está intentando consultar (aunque no de las características físicas del dispositivo que
toma dichas medidas). La idea es proveer un interface lo más genérico posible que permita acceder
a la mayor cantidad posible de dispositivos, independientemente de la naturaleza de los datos
médicos. La utilización de una solución basada en un software de middleware permite también
satisfacer este requisito.
Otro argumento a tener en cuenta es la utilización de estándares, que esta solución middleware
permitiría incorporar de una forma mucho más flexible que mediante una aproximación más
tradicional. Tanto a nivel interno como a nivel externo. Gracias a la arquitectura modular del
middleware, se podrían incluir diferentes interfaces compatibles con distintos estándares de la
industria (XML, HL7[HL7V2-03] [HL7V3-07], IEEE 1073 [IEEE1073-96],... ) y, al mismo tiempo,
permitir la implementación de módulos de interface específicos optimizados para sistemas de
gestión de la información concretos.
Además, utilizando este diseño middleware puede construirse el sistema de tal manera que puede
ser ampliado con funcionalidades no previstas inicialmente. Para ello, se buscaría definir una
modularidad lo mas estanca posible, a la vez que funcional y operativa. También los interfaces
serían lo suficientemente genéricos como para permitir la interoperabilidad entre módulos y el
añadir funcionalidades en un futuro que puediesen ser implementadas dentro del marco definido por
esos interfaces y módulos.
Arquitectura
El enfoque middleware proporciona a los sistemas de gestión de la información consultantes un
interface que les permite conocer cuales son los dispositivos que se encuentran conectados y cual es
la naturaleza de las mediciones que proporcionan. Además, proporciona capacidades para manipular
los datos en un determinado dispositivo, y recuperarlos. También permite el envío de comandos de
control genérico (apertura, cierre, encendido, apagado...) . Toda la información transmitida, tanto de
datos como de órdenes o comandos, se envía codificada en el protocolo seleccionado por el sistema
de gestión de la información para interactuar con el middleware.
Fig.2. La arquitectura middleware amplia las capacidades de comunicación dispositivo-aplicación
De esta manera, será suficiente con que un sistema de gestión de la información implemente un
conjunto mínimo de operaciones común a todos los dispositivos para trabajar con todos los
dispositivos soportados por el middleware. El sistema de gestión de la información podrá
comunicarse con ellos utilizando cualquiera de los protocolos soportados por el sistema. Incluso
podrían desarrollarse módulos específicos para soportar protocolos propietarios. Para cada
dispositivo que se quisiera incluir en el sistema habría que desarrollar soporte para él. Este
desarrollo habría que hacerlo solamente una vez. Una vez hecho el desarrollo, el dispositivo estaría
automática soportado en todos los sistemas de gestión de la información que utilizasen el
middleware. Este soporte incluiría, entre otras, la implementación de operaciones de obtención de
estado de dispositivos, su selección y deselección, su inicialización, la obtención de datos
almacenados en ellos.... The full list of op's supported over a device, among the technical
specification of the whole system, can be found in [CESGA-06-II].
Internamente, el sistema se estructura en 3 capas (fig. 3), perfectamente definidas y limitadas: la
capa de interface, la de servicios y la de acceso a los dispositivos.
La capa de interface es la que comunica el middleware con los sistemas de gestión de información
que quieren acceder a los dispositivos. Recibe directamente las peticiones de servicios y
proporciona los datos pedidos en un determinado formato. Está compuesta por dos tipos de
módulos: de lenguaje y de interpretación. Los módulos de lenguaje traducen los datos desde y
hacia un determinado lenguaje. Hacia abajo tienen una salida en el formato interno del sistema.
Hacia arriba tienen salida en el formato del y hacia el cual traducen. A través de ellos circulan tanto
los datos de trabajo como las ordenes de trabajo. (p.e. Una orden de OPEN puede llegar desde una
aplicación codificada en XML: <operacion> <orden> OPEN </orden> <parametro> HGD
</parametro> </operacion> ). Hay un módulo de lenguaje por cada protocolo soportado. El Módulo
de interpretación se encarga de gestionar la comunicación entre la capa de interface y la capa de
servicios, proporciona el enlace entre el módulo de lenguaje que se esté utilizando para la
comunicación y la capa de servicios. Traduce entre términos como “datos” (lenguaje interno del
middleware) a términos con sentido externo como “medidas”, “fechas”, “horas”... (i.e. en el resto
del middleware una “medida”, una “fecha”, una “hora”... es simplemente un “dato”, son tratados de
la misma manera).
Fig. 3 Estructura interna en capas del middleware
Un nivel más abajo, la capa de servicios se encarga de todas aquellas tareas destinadas al
mantenimiento de las estructuras internas de datos necesarias para poder dar servicio a las
peticiones de obtención de medidas (disponibilidad de dispositivos, capacidades de los mismos,...).
También se encarga de gestionar los mensajes de interface relacionados con el acceso a los datos y,
en general, de las tareas de inicialización y descarga de todo el software del middleware.
En el nivel más bajo, la capa de acceso a los dispositivos biomédicos se encarga de manejar el
acceso a los dispositivos físicos que realizan las mediciones. La idea aquí es dividir la capa en
tantos módulos como dispositivos vayan a ser soportados por el sistema, e incluir un modulo de
dispatcher de acceso que enrute la comunicación al módulo de dispositivo correspondiente. Todos
los módulos de dispositivo producen una salida común de acuerdo a un interface de comunicación
con la capa de servicios. Ese interface es lo suficientemente genérico como para poder adaptarse a
las necesidades especificas de cada uno de los módulos de dispositivo.
La capa de acceso a los dispositivos está compuesta por dos tipos de módulos: de dispatcher de
acceso y de acceso al dispositivo. El módulo de dispatcher se encarga de mantener unas listas con
información sobre los dispositivos soportados por el sistema y los dispositivos conectados al
sistema. Tambien se encarga de enviar las peticiones de apertura y cierre de un dispositivo al
módulo correspondiente, haciendo el mapeado de los descriptores lógicos utilizados por las capas
superiores del middleware a los descriptores de bajo nivel utilizados para acceder físicamente a los
dispositivos. Los módulos de acceso a dispositivo se encargan de gestionar los accesos a los
dispositivos físicos correspondientes.
En cuanto a la naturaleza de los datos manejados por el middleware, hay que distinguir entre los
datos de interface a los sistemas de gestión, los datos de los dispositivos y los datos internos del
middleware. Los primeros se utilizan para recibir y proporcionar información y comandos de
control desde y hacia los sistemas de gestión que interactuan con el middleware. Los segundos
(datos de dispositivos) son los que se utilizan para almacenar la información que proporcionan los
dispositivos físicos. En tercer lugar, los datos internos son aquellos que utiliza el middleware para
almacenar la información necesaria para realizar las tareas que le son propias. Los datos de interface
incluyen soporte para obtener información sobre dispositivos, identificarlos y accederlos. Tambien
incluye soporte para los datos que proporcionan los dispositivos (mediciones, info de gestión de las
mismas...), ademas de soporte para información de gestión de errores, en caso de producirse estos.
La arquitectura de estos datos de interface es común a todos los módulos de lenguaje, de tal forma
que tanto un módulo de HL7 como un módulo de IEEE1073 van a interactuar con el resto de
componentes de sistemas utilizando las mismas estructuras de datos. Lo mismo ocurre para los
módulos de acceso a los dispositivos médicos. Por otro lado, los datos de los dispositivos se
transmiten codificados en cadenas XML. Estas cadenas XML son parseadas por los módulos de
capas superiores para construir estructuras de datos con información relativa a estos dispositivos.
De esta manera se modulariza la información de descripción de un dispositivo con respecto al resto
de componentes del sistema. Cada módulo de dispositivo proporciona datos acerca del lenguaje de
datos manejado por ese dispositivo, datos de identificación del dispositivo y datos de las mediciones
que contiene. Los datos internos contienen información que es accesible desde cualquier módulo del
middleware. Esta información incluye dispositivos físicos soportados/conectados, datos que maneja
un determinado dispositivo y valores de las mediciones almacenadas. También se incluyen
información para manejar situaciones de error, y para enrutar las comunicaciones entre los distintos
componentes del middleware.
En lo que se refiere a la circulación de la información a través del middleware, el sistema basa su
funcionamiento en el intercambio de mensajes. El modelo de trabajo utilizado siguiendo este
esquema es similar al utilizado en los SSOO tipo UNIX. Desde su arranque, el middleware espera
la llegada de algún mensaje para él a través de algún módulo de lenguaje. Una vez recibido se
procesa y devuelve el resultado correspondiente al peticionario. Cada vez que un cliente solicite
acceso a un dispositivo, se le devolverá un identificador de dispositivo que el cliente deberá utilizar
para cualquier operación posterior que realice sobre dicho dispositivo. Una vez finalizadas las
operaciones con el dispositivo, el cliente solicitará la desconexión del dispositivo correspondiente.
La utilización de mensajes permite parametrizar y modularizar el sistema. Esto es así por que los
mensajes pueden estar codificados en el protocolo de comunicación que el cliente haya
seleccionado a la hora de solicitar la conexión. Existen implementados mensajes para la apertura y
cierre de conexiones, para la conexión y desconexión a dispositivos, para obtener la lista de
dispositivos conectados, y para acceder a los datos almacenados en el dispositivo. Están pendientes
de implementación mensajes para la gestión de conexiones o la gestión de datos de usuario o de
fechas a nivel de dispositivos.
La circulación de mensajes a través del middleware es similar para todos los mensajes. A modo de
ejemplo, se muestra a continuación la circulación de un mensaje de solicitud de acceso a
mediciones:
OUTSIDE
ACK_GET
(ITEM_COUNT,
ITEM_ARRAY)
GET(FD,DATA_NAME,MEMO_NUM)
LENGUAGE MODULE
ACK_EXEC
(ITEM_COUNT,
ITEM_ARRAY)
EXEC(GET_FD_DATA*NAME_MEMO_NUM)
INTERPRETATION
MODULE
ACK_GET
(ITEM_COUNT,
ITEM_ARRAY)
GET(FD,DATA_NAME,MEMO_NUM)
SERVICES LAYER
ACK_GET
(ITEM_COUNT,
ITEM_ARRAY)
GET(FD,DATA_NAME,MEMO_NUM)
DISPATCHER MODULE
ACK_GET
(ITEM_COUNT,
ITEM_ARRAY)
GET(FD_SYSTEM,DATA_NAME,MEMO_NUM)
DEVICE MODULE
FIG. 4 – Diagrama de flujo para un mensaje de obtención de datos
El lector puede observar como el mensaje generado por el sistema peticionario entra en el sistema
por un módulo de lenguaje y circula a través del middleware pasando de módulo a módulo hasta
llegar al módulo encargado de atender ese tipo de petición (en este caso el módulo de acceso al
dispositivo del que se solicita la información). Este devuelve los datos solicitados, y nuevamente los
mensajes circulan de vuelta por el sistema hacia el módulo de interface que devolverá la respuesta
al sistema peticionario.
Pruebas realizadas
El middleware propuesto ha sido integrado en el entorno de un proyecto de investigación sobre
teleasistencia específicamente diseñado para personas mayores [DIAZ-06]. En las pruebas de
laboratorio realizadas, el middleware demostró un comportamiento correcto a la hora de
proporcionar acceso a los dispositivos desde el sistema gestor de la información de la aplicación de
prueba. En una primera fase se implementó, en paralelo con todo el resto de componentes del
middleware, un módulo de dispositivo para un esfingomanómetro digital doméstico de mano y un
módulo de interface para un protocolo propietario basado en XML. Se comprobó que el sistema se
comportaba correctamente con las funcionalidades implementadas, y que los datos de las
mediciones eran recogidos correctamente en el sistema remoto. Después de eso, se procedió a
implementar otro módulo de acceso para un segundo dispositivo (un medidor de glucosa del tipo
LifeScan OneTouch), y comprobar así las capacidades de modularidad del sistema. El desarrollo de
este segundo módulo fue sencillo y rápido, no hubo que hacer ningún re-diseño del sistema en
general, y se integró perfectamente con el resto del middleware. También se han implementado
versiones dummy de módulos de dispositivo que dan acceso a dispositivos ficticios que toman
mediciones de frecuencia respiratoria, saturación de oxigeno en sangre y temperatura corporal.
Estos módulos simplemente simulan el comportamiento en cuanto a las mediciones que se
esperarían recibir de un dispositivo que tomase ese tipo de mediciones. Igual que en el caso del
dispositivo físico medidor de glucosa, los módulos para estos dispositivos dummy se integraron
perfectamente en el middleware sin tener que hacer ningún tipo de rediseño en el sistema.
Otros Proyectos
La utilización de dispositivos de bajo coste para la tele-monitorización de parámetros vitales no es
una idea nueva, existen toda una serie de soluciones disponibles comercialmente que usan esta
aproximación, como el proyecto i-Living citado anteriormente. Hay también soluciones comerciales
de fabricantes como Metrikus que en su producto Metriklink [WMetrikLink] incorpora soporte para
un gran grupo de medidores de glucosa y de presión y pulso arterial. Otros sistemas como el Health
buddy [WHealthBuddy] incorporan soporte para, además de glucosimetros y de medidores de
presión sanguínea, basculas y medidores de capacidad respiratoria. CareVital [WCareVital] es otro
sistema que utiliza dispositivos domésticos para el monitorado de presión sanguínea, peso corporal
y niveles de glucosa en sangre. El fabricante Honeywell HomMed [WhomMed] incorpora en su
solución la monitorización de temperatura corporal, y la saturación de oxigeno en sangre. Otro
sistema que utiliza esta aproximación es el remote nurse de Virtual Medical Care [WremoteNurse],
sistema que permite, entre otros, el monitorado de fluidos y electrocardigramas. El fabricante RTX
comercializa una solución [WRTX] que incorpora dispositivos para la medición de glucosa, presión
sanguínea, pulso cardiaco, espirometría y peso corporal. Todos estos sistemas tienen en común que
soportan los dispositivos de forma nativa. Incorporar el middleware propuesto en dichos sistemas
permitiría facilitar la incorporación de nuevos dispositivos, pues no habría que desarrollar el soporte
para un mismo dispositivo en cada solución. Una vez incluido soporte para ese dispositivo en el
middleware ya estaría soportado en el resto de sistemas que utilizasen el middleware, simplemente
habría que actualizarlo en las estaciones de los pacientes.
En cuanto a proyectos que estén trabajando con dispositivos para la telemonitorización de signos
vitales, podemos mencionar CHRONIC en donde se implementó soporte para un espirómetro de la
casa sibel y para una solución comercial de card-guard [de Toledo–02]. El proyecto TOPCARE para
la creación de “cooperative health care provider networks” incluye estaciones de paciente que
incorporan dispositivos para monitorizar nivel de glucosa en sangre, peso, coagulación de sangre,
presión sanguínea, pulso, oximetrías, analizadores de orina y dispensadores de partillas
[WTopCare]. Codeblue es otro proyecto en donde se utilizan dispositivos de monitorización de
pequeño tamaño. Estos dispositivos mediante una terminal (generalmente PDA's) se integran dentro
de un sistema de respuesta en situaciones de emergencia [Konrad-04]. El middleware propuesto
podría incorporarse en este sistema incluyéndolo en las terminales para soportar un mayor número
de dispositivos.
Otros trabajos incluyen los desarrollados por los laboratorios de investigación de IBM en lo
referente a la integración de dispositivos de medición de niveles de tensión [WIBM-Blood] o de
niveles de glucosa. Especial atención merece también el desarrollo del sistema PCC (Personal Care
Connection) para la creación de un sistema de “remote health-care monitoring” basado en
estándares y diseñado de forma abierta independientemente de los dispositivos y sistemas
considerados[Blount-07] .
Yao et al. proponen un sistema que utilice el estándar de la industria IEEE1073 para la recogida de
los datos de una red de dispositivos domesticos[Yao-05]. Su aportación es la utilización de un
protocolo estándar de la industria para la comunicación con los dispositivos domesticos. El
middleware propuesto permitiría incluir en la solución de Yao soporte para todos los dispositivos a
los que el middleware fuese capaz de acceder simplemento añadiendo un módulo de lenguaje para
el IEEE 1073. Lo mismo ocurriría para el trabajo de leback en donde, desde el mismo grupo de
trabajo, se propone la utilización del estándar HL7 para la misma función. [Lebak-04]
Discusión y conclusiones
Para un futuro, líneas de trabajo podrían ser la incorporación de módulos de lenguaje para otros
protocolos, tanto propietarios como basados en estándares, para comprobar si las funcionalidades
definidas son suficientes para cubrir los objetivos marcados o habría que ampliarlas. Otra hipotética
línea de trabajo sería la de la implementación de los flujos de circulación para los mensajes
pendientes de implementar (mantenimiento de conexión, estado de conexión, obtención de
definición de lenguaje de dispositivo, obtención de sintaxis de datos, gestión de ID's de usuarios,
gestión de fechas de dispositivos). Estos flujos no son requeridos para un funcionamiento básico del
sistema, pero su incorporación permitiría incluir funcionalidades que pueden resultar útiles para una
gestión avanzada de los datos en los dispositivos por parte de los sistemas gestores de información
médica. El analisis de las características de nuevos dispositivos para identificar y caracterizar
hipotéticos nuevos flujos de circulación de mensajes no detectados inicialmente sería otro campo de
trabajo para la mejora del sistema.
Otra línea de trabajo con respecto a los dispositivos soportados por el middleware sería el estudiar
la inclusión de dispositivos no medicos. Por ejemplo de dispositivos domóticos, incluyendo algun
grado de control sobre los mismos, lo que permitiría a los cuidadores de forma remota “adaptar” el
entorno en el que se encuentra el paciente (p.e. Subir o bajar la temperatura de las habitaciones,
subir o bajar persianas, dar mas o menos luz, asegurar puertas y/o ventanas...). Otro posible tipo de
dispositivos a incluir sería sensores de actividad, que permitirían recoger y enviar información sobre
el estado de movimiento y grado de actividad de los pacientes.
Otra linea de trabajo sería el adaptar el sistema para permitir la monitorización continua de los
signos vitales (tal y como se describe por ejemplo en los trabajos de Cardenas [Cardenas-03] y
Chen [Chen-04] ). Actualmente, y dadas las limitaciones de los sistemas domésticos para los que
está pensado el middleware, este tipo de monitorización no está soportada. La inclusión de soporte
para mediciones de este tipo permitiría soportar sistemas que permitiesen hacer un monitorado
continuo de medidas (p.e. Sistemas de seguimiento del sueño, ECG's en tiempo real...)
En definitiva se ha desarrollado un middleware que permitiría el acceso a los datos de un amplio
abanico de dispositivos de consumo para la medición de parámetros médicos, por parte de sistemas
de gestión de la información que quisieran incluir la telemonitorización de pacientes. La utilización
de esta aproximación parece razonable dado que, si bien actualmente la investigación en este campo
está dirigiéndose hacia sistemas ubicuos, transparentes al usuario, inalámbricos y de tamaño
reducido, previsiblemente todavía queda un tramo hasta que se consiga un nivel de desarrollo que
haga utilizables en entornos reales alguna solución basada en esas tecnologías. Hasta entonces, la
utilización de dispositivos comerciales domésticos de medición de dichos parámetros vitales que
incorporen algún tipo de capacidad de comunicación se plantea como una de las altenativas más
viables a la hora de incluir el soporte para monitorización de signos vitales en un sistema de
teleasistencia.
Referencias
[LIU-05] Liu, R, Deng, B, Chen, WL, et al. “Next step of non-invasive glucose monitor by NIR technique from the well
controlled measuring condition and results” OPT QUANT ELECTRON 37 (13-15): 1305-1317 DEC 2005
[LILIENFELD-05] von Lilienfeld-Toal, H, Weidenmuller, M, Xhelaj, A, et al. A novel approach to non-invasive
glucose measurement by mid-infrared spectroscopy: The combination of quantum cascade lasers (QCL) and
photoacoustic detection VIB SPECTROSC 38 (1-2): 209-215 JUL 29 2005
[PICKUP-05] Pickup, JC, Hussain, F, Evans, ND, et al. "In vivo glucose monitoring: the clinical reality and the
promise" BIOSENS BIOELECTRON 20 (10): 1897-1902 APR 15 2005
[KIRSTEIN-05] Kirstein, KU, Sedivy, J, Salo, T, et al. "A CMOS-based tactile sensor for continuous blood pressure
monitoring" DESIGNERS' FORUM: DESIGN, AUTOMATION AND TEST IN EUROPE CONFERENCE AND
EXHIBITION : 210-214 2005
[EDMISON-02] Edmison, J, Jones, M, Nakad, Z, et al. "Using piezoelectric materials for wearable electronic textiles"
SIXTH INTERNATIONAL SYMPOSIUM ON WEARABLE COMPUTERS, PROCEEDINGS : 41-48 2002
[JOVANOV-05] E. Jovanov, A. Milenkovic, C. Otto, P.C. de Groen "A wireless body area network of intelligent motion
sensors for computer assisted physical rehabilitation" Journal of NeuroEngineering and Rehabilitation, March 2005
(disponible online en http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=552302 )
[OTTO-06] Otto,C, Milenković, A,Sanders, C, Jovanov, E. "System architecture of a wireless body area sensor network
for ubiquitous health monitoring" Journal of Mobile Multimedia, Vol. 1, No. 4 307-326, JAN 10 2006 (Dispoñible en
http://www.ece.uah.edu/~milenka/docs/coamej_jmm06.pdf )
[PARK-03] Park, S, Jayaraman, S "Enhancing the quality of life through wearable technology" IEEE ENG MED BIOL
22 (3): 41-48 MAY-JUN 2003
[COTTET-03] Cottet D, Grzyb J, Kirstein T, Tröster G. "Electrical Characterization of Textile Transmission Lines".
IEEE Transactions on Advanced Packaging 2003;26(2):182-90.
[KALLMAYER-03] Kallmayer C, Pisarek R, Cichos S, Gimpe S. "New Assembly Technologies for Textile
Transponder Systems". Proc. ECTC May 2003.
[KLEMM-04] Klemm M, Locher I, Tröster G. "A Novel Circularly Polarized Textile Antenna for Wearable
Applications". European Microwave Conference, Amsterdam, October 2004.
[TRÖSTER-04]G. Tröster, "The agenda of wearable Healthcare", IMIA Yearbook of Medical Informatics 2005:
Ubiquitous Health Care Systems. Haux R, Kulikowski C, editors. Stuttgart: Schattauer; 2004 p. 125-138 (
http://www.wearable.ethz.ch/fileadmin/pdf_files/pub/IMIA_05.pdf )
[PARADISO-03]Paradiso R. "Wearable Health Care System for Vital Signs Monitoring". Proc of the 4th Annual IEEE
Conf on Information Technology Applications in Biomedicine, UK, 2003. p. 283-6.
[SERGIO-03] Sergio M, Manaresi N, Campi F, Canegallo R, Tartagni M, Guerrieri R. "A Dynamically Reconfigurable
Monolithic CMOS Pressure Sensor for Smart Fabric". IEEE J Solid-State Circuit 2003;38(6):966-75.
[WSENSATEX] Página Web de sensatex: http://www.sensatex.com/
[WVIVOMETRIX-HOWWORKS] Página Web de presentación de la camiseta de vivometrics:
http://www.vivometrics.com/site/system_howitworks.html
[STEPANIAN-04]stepanian, RSH, Jovanov, E, Zhang, YT "Introduction to the special section on m-Health: Beyond
seamless mobility and global wireless health-care connectivity" IEEE T INF TECHNOL B 8 (4): 405-414 DEC 2004
(disponible gratuitamente en http://dx.doi.org/10.1109/TITB.2004.840019 )
[ROBERT-04] Robert S.H. Istepanian, Jovanov Emil, Zhang Y.T. “Introduction to the special section on M-Health:
Beyond Seamless mobility and global wireless Health-care Connectivity” IEEE transactions on information technology
in biomedicine, vol. 8, No. 4, december 2004
[CESGA-06-II] “Propuesta de arquitectura para el modulo de dispositivos biomédicos”, CESGA, 2006.
[WMetrikLink] Web de producto metriklink, http://www.imetrikus.com/prod_ML.asp, accedida Abril 2007
[WHealthBuddy] Web de producto de Health Buddy https://www.healthhero.com/, accedida Abril 2007
[WCareVital] Web de producto de Care Vital http://www.carelink1.com/index.php?file=carevital , accedida
Abril 2007
[WhomMed] Web de Hommed,
Http://wwww.hommed.com/products/index.htm , accedida Abril 2007
[WremoteNurse] Web del producto Remote Nurse,
http://www.webvmc.com/products%20&%20services.htm , accedida Abril 2007
[WRTX] RTX Healthcare solutions, http://www.rtx.dk/Healthcare/Products/Peripheral_Devices.aspx ,
accedida Abril 2007
[de Toledo – 02] de Toledo P., Jimenez S., Del Pozo F., “A telemedicine system to support a new model for care of
chronically ill patients.”, Journal of Telemedicine & Telecare 2002, 8 Suppl 2:17-9
[WTopCare] TOPCARE. Página web del proyecto, http://www.topcare-network.com, accedida abril 2007
Konrad Lorincz, David J. Malan, Thaddeus R.F. Fulford-Jones, Alan Nawoj, Antony Clavel, Victor Shnayder, Geoffrey
Mainland, Matt Welsh , Steve Moulton, “Sensor Networks for Emergency Response: Challenges and Opportunities ”,
IEEE pervasive computing, pp. 16-23, october-december 2004.
[WIBM-Blood] “ Remote monitoring of health conditions”, IBM newsletter,
http://www.zurich.ibm.com/news/03/mobilehealth.html , october 31, 2003.
[Blount-07] M. Blount , V. M. Batra , A. N. Capella , M. R. Ebling , W. F. Jerome , S. M. Martin , M. Nidd , M. R.
Niemi , S. P. Wright , “Remote health-care monitoring using Personal Care Connect”, IBM Systems Journal, Vol. 46,
No 1, 2007
[Yao-05] J. Yao, R. Schmitz, and S. Warren, ‘‘A Wearable Point-of- Care System for Home Use That Incorporates Plugand- Play and Wireless Standards,’’ IEEE Transactions on Information Technology in Biomedicine 9, No. 3, 363–371
(2005).
[Lebak-04]J. W. Lebak, J. Yao, and S. Warren, ‘‘HL7-Compliant Healthcare Information System for Home
Monitoring,’’ Proceedings of the 26th Annual International Conference of IEEE Engineering in Medicine and Biology
Society, San Francisco, CA (2004), pp. 3338–3341.
[Chen-04] W. Chen, D. Wei, M. Cohen, S. Ding, S. Tokinoya, and N. Takeda, ‘‘Development of a Scalable Healthcare
Monitoring Platform,’’ Proceedings of the 4th International Conference on Computer and Information Technology,
Wuhan, China (2004), pp. 912–915.
´
[Cardenas-03] A. F. Cardenas, R. K. Pon, and R. B. Cameron, ‘‘Management of Streaming Body Sensor Data for
Medical Information Systems,’’ Proceedings of the International Conference on Mathematics and Engineering
Techniques in Medicine and Biological Science, Las Vegas, Nevada (2003), pp. 168–191.
[HL7V3-07] Health Level Seven, Inc., "HL7 V3 last ballot", Health Level Seven®, Inc., 2006, [Online] Available on:
http://www.hl7.org/v3ballot/html/welcome/environment/index.htm [Accesed April 2007]
[HL7V2-03] ANSI/HL7, "Health Level Seven Standard Version 2.5 An Application Protocol for Electronic Data
Exchange in Healthcare Environments", ANSI/HL7 V2.5-2003.
[IEEE1073-96] The Institute of Electrical and Electronics Engineers, Inc., "IEEE 1073 Standard for Medical Device
Communications Overview and Framework", The Institute of Electrical and Electronics Engineers, Inc., Jan 1, 1996.
[RASKOVIC-03] Dejan Raskovic, Thomas Martin and Emil Jonanov: “Medical monitoring Applications for Wearable
Computing”, The Computer Journal 2004 47(4):495-504
[HEINZELMAN -04] WB Heinzelman, AL Murphy, HS Carvalho, and MA Perillo. Middleware to support sensor
network applications. IEEE Network Mag., 18(1):6--14, 2004.",
[BLOBEL-97] B. Blobel, and M. Holena, “Comparing Middleware concepts for advanced healthcare system
architectures”, International Journal of Medical Informatics, vol 46, pp. 69-85, 1997
[WANG-06] Qixin Wang, Wook Shin, Xue Liu, Zheng Zeng, Cham Oh, Bedoor K. Alsheb li, Marco Caccamo, Carl A.
Gunter, Elsa Gunter, Jennifer Hou, Karrie Karahalios, and Lui Sha, "I-Living: An Open System Architecture for
Assisted Living", in Proc. of IEEE SMC 2006.
[DIAZ-06] Fernando Díaz, Matías A. Villanueva, Aránzazu Balo, Ana López, Ana I. Pedreira, J.C.
Millán-Calenti :“Telegerontología: un nuevo recurso de apoyo gerontológico a domicilio”, Polytechnical Studies
Review.2006.vol III nº 5/6. 57-71
[AMATO-06] Giuseppe Amato, Stefano Chessa, Fabrizio Conforti, Alberto Macerata and Carlo Marche:” Health Care
Monitoring of Mobile Patients”, ERCIM News No. 60, January 2005
[BRINKSCHEULTE-] ¿???