Download Contribuciones en el diseño, implementación e integración de

Universidad de Zaragoza
Centro Politécnico Superior
Contribuciones en el diseño, implementación e
integración de nuevas tecnologías y perfiles
médicos recomendados para entornos de e-Salud
basados en el estándar ISO/IEEE 11073
Programa de Postgrado en Ingenierías Transversales
Ingeniería Biomédica · Mención de Calidad
Autor
Antonio Aragüés Ruiz
Director
Dr. Ignacio Martínez Ruiz
DICIEMBRE 2010
Agradecimientos
A Nacho, mi director de TFM, por su constante apoyo y ayuda durante el
desarrollo de este trabajo. Gracias por confiar en mí.
A mis compañeros de trabajo y laboratorio: Pilar, Pili, Javi, Chus, Eva y
Nelia. Gracias por los buenos momentos que me hacéis pasar cada día y
vuestra ayuda constante.
A todo el equipo de Healthy Interoperability de la universidad vienesa
de ciencias aplicadas Fachhochschule Technikum Wien. En especial a
Ferenc y Matthias por su amabilidad y trato durante mi estancia en
Viena.
A todos los compañeros del Máster. Aunque comencé tarde el curso me
sentí integrado desde el primer día. Vanesa, Jose Antonio, Eli, Juan
Carlos, Fernando, Eduardo, Chus… y más que olvido. Sois geniales.
Y por supuesto a mi familia y amigos. Y especialmente a mis padres, que
me dan fuerza cada día, que siempre están ahí.
Hitos académicos y de
investigación
Como resultado de este trabajo se han llevado a consecución los siguientes hitos académicos y de investigación:
Dirección de proyectos fin de carrera
Análisis, diseño funcional y modelado UML de la Arquitectura Software de una pasarela o Compute Engine (CE) para
una plataforma de E-Salud basada en el estándar ISO/IEEE 11073. Autor: Javier Almingol. Fecha: -. Director: Antonio
Aragüés Ruiz. Ponente: Ignacio Martínez Ruiz
Publicación de los siguientes artículos en congresos, simposios y reuniones científicas:
Del Valle P, Aragüés A, Escayola J, Martínez I, and García J, “Propuesta de Diseño de un Entorno Gráfico e-Accesible
según la norma ISO 9241 e interoperable según la norma ISO/IEEE 11073 para soluciones de e-Salud” XXVIII Congreso
Anual de la Sociedad Española de Ingeniería Biomédica, CASEIB 2010.
Aragüés A, Funes P, Carot S, Del Valle P, Trigo J, Escayola J, Muñoz P, Martínez-Espronceda M, Martínez I, García J,
“Integración sobre una plataforma Android de las normas de interoperabilidad ISO/IEEE11073 y UNE-EN/ISO13606”
XXVIII Congreso Anual de la Sociedad Española de Ingeniería Biomédica, CASEIB 2010.
A. Aragüés, J. Almingol, J.D. Trigo, J. Escayola, M. Martínez-Espronceda, I. Martínez, J. García, “Análisis de tecnologías de
transporte con perfiles médicos especializados para el estándar ISO/IEEE11073” XXVIII Congreso Anual de la Sociedad
Española de Ingeniería Biomédica, CASEIB 2010
P. Muñoz, I. Martínez, A. Muñoz, A. Aragüés, J. Escayola, J. García, “Uso de arquetipos en la adquisición no supervisada
de medidas remotas para su incorporación a un servidor de HCE” ” XXVIII Congreso Anual de la Sociedad Española de
Ingeniería Biomédica, CASEIB 2010
Resumen
El núcleo central del trabajo llevado a cabo en los últimos años en el proyecto upHealth.ES dentro
del subgrupo de telemedicina perteneciente al Grupo Consolidado de Tecnologías de las
Comunicaciones del Instituto de Investigación en Ingeniería de Aragón (GTC/I3A) ha sido la
implementación de una plataforma de e-Salud personal basada en estándares extremo-a-extremo.
La arquitectura global está basada en una pasarela (Compute Engine, CE) que concentra la
información recogida por los dispositivos médicos (Medical Devices, MDs, y Personal Health Devices,
PHDs) conforme al estándar ISO/IEEE 11073 (X73PHD). Este CE se comunica a través de la red
externa con un servidor de monitorización que actualiza toda la información en el Historial Clínico
Electrónico (HCE) del paciente conforme al estándar UNE-EN/ISO 13606.
La versión actual del CE tiene una arquitectura monolítica, basada en C/C++, en la que todo el código
se estructura en grupos funcionales muy acoplados, lo que dificulta cualquier modificación,
ampliación o adaptación a las evoluciones del propio estándar X73. En este Trabajo Fin de Máster
(TFM) se ha realizado un re-diseño completo de la arquitectura software del CE migrándolo a C# y
estructurándolo como solución multi-capa para poder explotar las ventajas del paradigma de la
programación orientada a objetos y dotarlo en un futuro de nuevas funcionalidades de valor
añadido así como implementarlo en diferentes plataformas hardware fijas e inalámbricas/móviles.
A partir de este re-diseño e implementación del nuevo framework X73PHD, se ha estudiado el
estado del arte de los nuevos perfiles médicos propuestos para las tecnologías de transporte
recomendadas desde el grupo especial de trabajo de X73PHD (PHDWG): Bluetooth Health Device
Profile (BT HDP), USB Personal Healthcare Device Class (USB PHDC) y ZigBee HealthCare Profile (ZB
ZHC). A partir de este estado del arte, se ha propuesto el diseño e implementación del perfil médico
BT HDP para su integración con el framework X73PHD y el servidor de HCE con los más recientes
dispositivos médicos certificados desde la iniciativa Continua Health Alliance. Además, se ha
diseñado la capa de servicios a nivel superior según el paradigma cloud computing para poder
plantear un entorno de uso real. Por último, y a partir de este entorno de uso propuesto, se ha
realizado la evaluación completa de la nueva plataforma y el impacto de las nuevas tecnologías
inalámbricas percibido por los usuarios en el contexto del proyecto WiSo (Wiener Sozialdienste) en
colaboración con el grupo Healthy Interoperabilty de la universidad vienesa de ciencias aplicadas
Fachhochschule Technikum Wien y coordinado por el Dr. Em y las Dras. Kraus y Haslinger. Esta
evaluación, junto con la colaboración con el grupo del Dr. Pedro de las Heras de la Universidad Juan
Carlos I para el desarrollo del perfil médico BT HDP en entornos específicos de paciente, han
constituido las prácticas médicas asociadas a la TFM.
Como líneas futuras, se pretende extender las contribuciones propuestas al resto de perfiles
médicos recomendados (USB PHDC y ZHC) para su integración definitiva en la plataforma lo que
desembocará en un entorno de comunicación multi-tecnología completamente interoperable
conforme a X73PHD. A partir de aquí, habría que estudiar las tendencias en tecnologías inalámbricas
de última generación WiFi/WiMax, Ultra Wide Band (UWB) y Long Term Evolution (LTE) y su posible
aplicación a escenarios de e-Salud (analizando su adaptación y compatibilidad con el entorno
sanitario, su problemática de integración y su influencia en la mejora de la calidad de vida de las
personas), lo que constituirá la futura propuesta de tesis doctoral del alumno.
Índice
1. Introducción……………………………………………………………………………………………………………………
2. Estado del arte.…………………………………………………………………………………………………..............
2.1. e-Salud, telemonitorización y estandarización………………………………………………..………..
2.2. Iniciativas de estandarización e integración en e-Salud..……………………..……………….….
2.3. Tecnologías de transporte y perfiles médicos.……………………………..…………………………..
3. Análisis, diseño e implementación.………………………………………………………………………………..
3.1. Plataformas previas.…………………………………………………………………………………………………
3.2. Análisis y diseño. Arquitectura propuesta …………………………..…………………………………..
3.3. Implementación.………………………………………………………………………………………………………
3.4. Integración de Bluetooth HDP.…………………………………………………………………………………
3.5. Integración de servicios en la nube.…………………………………………………………………………
3.6. Integración con el servidor de HCE………………………………….……………………………………….
3.7. Integración con el nivel de aplicación……………………………………………………………………….
4. Evaluación y resultados……………………..…………………………………………………………………………..
4.1. Evaluación de la implementación……………………………………………………………………………..
4.2. Proyecto WiSo.…………………………………………………………………………………………………………
5. Conclusiones y líneas futuras………………………………………………………………………………………….
5.1. Conclusiones.……………………………………………………………………………………………………………
5.2. Líneas futuras.………………………………………………………………………………………………………….
Pág
1
5
5
8
10
15
15
16
23
25
28
34
36
39
39
42
43
43
44
Acrónimos…………………………………………………………………………………………………………………………….
Tabla de figuras…………………………………………………………………………………………………………………….
Referencias…………………………………………………………………………………………………………………………..
45
46
47
Anexos
I. El estándar ISO/IEEE 11073………………………………………………………………………………………..
II.
Plataformas previas. upHealth.ES………………………………………………………………………………
III.
Detalles de implementación del framework X73PHD y el perfil médico BT HDP…………
49
55
67
Introducción
Los avances en el campo de la Ingeniería Biomédica han dado lugar al desarrollo de equipos de adquisición y medición
de parámetros vitales cada vez más precisos y manejables a la vez que accesibles para el paciente y completamente
integrados en su vida cotidiana. De la mano de la inteligencia ambiental (Ambient Intelligence, AmI) y el auge del hogar
digital, la monitorización de pacientes en modo local (domiciliario) o remoto (hospitalario) se presenta como un
importante servicio de supervisión del usuario mediante la incorporación de sistemas formados por uno o varios de
estos equipos médicos. Sin embargo, la mayoría de prototipos y soluciones de e-Salud que han venido desarrollándose
en los últimos años, aunque válidas, arrastran una cierta heterogeneidad que no las hacen extensibles e integrables con
otras aplicaciones similares y en el contexto sanitario global. Para ello, en la actualidad, un aspecto clave a tener en
cuenta en estos sistemas es el diseño basado en estándares que definan completamente las reglas con las que los
dispositivos médicos se interconectan y comunican dentro de la solución de e-Salud.
El estándar internacional asumido para la comunicación interoperable de dispositivos médicos es la familia de normas
ISO/IEEE 11073 (X73). X73 abarca los siete niveles de la pila de protocolos y proporciona la versatilidad suficiente para
convertir la información en un formato interoperable de manera que pueda ser intercambiada entre un dispositivo de
salud personal (agente) y un sistema central de registro (manager). Los datos pueden ser enviados posteriormente a un
centro remoto de control o almacenamiento de Historia Clínica Electrónica (HCE), así se permite construir sistemas más
completos que constituyan soluciones globales. X73 nace centrado en el Punto de Cuidado (Point of Care, PoC) del
paciente para implantación en Unidades de Cuidados Intensivos (UCIs) y evoluciona en los últimos años hacia nuevos
casos de uso, tecnologías de interconexión y perfiles médicos orientados a dispositivos de salud personal (Personal
Health Devices, PHD). De la misma forma, para lograr niveles óptimos en la calidad asistencial y continuidad de cuidado
de un paciente, es necesario incluir a todas las partes implicadas en el seguimiento/control de la enfermedad. Para ello,
hay que contemplar también la interoperabilidad en el intercambio de HCE entre sistemas sanitarios a través de la
norma internacional UNE-EN/ISO13606. Sin embargo, la existencia de normas médicas no garantiza la correcta
implementación de una solución homogénea de e-Salud dado que la integración de las diferentes normas en soluciones
extremo a extremo todavía sigue siendo una tarea compleja e intrincada. Este es uno de los principales retos en la
investigación de estándares para su posterior implementación, en forma de soluciones reales, en el sistema sanitario.
Contexto
Este Trabajo Fin de Máster (TFM) se integra en el contexto de diseño e implementación de una plataforma de
telemonitorización de pacientes basada en estándares extremo a extremo [1] desarrollada por el grupo de
telemedicina de GTC/I3A. La arquitectura de la plataforma (ver Figura 1.1), está basada en una pasarela (Compute
Engine, CE) que concentra toda la información recogida por los distintos dispositivos médicos (Medical Devices, MDs).
Este CE se comunica a través de la red externa de acceso y transporte, con un servidor de monitorización que gestiona
distintos CEs y reúne toda la información proveniente de cada escenario para actualizar la HCE del paciente. Las
características de cada elemento que conforma la arquitectura del sistema son:
• Medical Devices (MDs). La adquisición de datos médicos sigue un formato propietario. Estos adaptadores crean la
especialización para el MD que genera su modelo de información específico y establece una máquina de estados
permitiendo a los MDs no compatibles con X73PHD actuar como agentes nativos de una comunicación X73PHD.
• Compute Engine (CE). El dispositivo de pasarela está diseñado como un manager nativo X73PHD que recoge toda
la información médica proveniente de MDs. La información es almacenada en un fichero de datos que, junto con
el perfil de configuración específico (Config Profile), sirve como entrada de datos para el proceso de creación de
tramas para un protocolo de armonización entre estándares extremo a extremo (End-to-End Standard
Harmonization Protocol, E2ESHP). Este protocolo permite integrar la información adquirida por los MDs en la HCE
de forma transparente y posibilita, a partir de una consulta en la base de datos o de modificaciones del Config
Profile, administrar y gestionar remotamente los CEs y las especificaciones de cada MD.
• Monitoring Server (MS). Está compuesto por dos entidades. La primera actúa como servidor E2ESHP puesto que
se encarga de recibir los datos X73PHD, decodificando tramas E2ESHP y extrayendo los datos X73PHD apropiados
(clasificando información por usuario asociado) para almacenarlos en la base de datos. El segundo implementa
una doble función cliente/servidor UNE-EN/ISO 13606 aceptando peticiones UNE-EN/ISO 13606 de información
almacenada en la base de datos, y generando extractos UNE-EN/ISO 13606 siguiendo sus arquetipos.
Página | 1
Figura 1.1. Plataforma de telemonitorización basada en estándares extremo a extremo
Objetivos
La versión actual del CE desarrollado en la plataforma de telemonitorización de pacientes tiene una arquitectura
monolítica, basada en C/C++ en la que todo el código se estructura en grupos funcionales muy acoplados, lo que
dificulta cualquier modificación, ampliación o adaptación a las evoluciones del propio estándar X73. El objetivo principal
de este TFM es proponer un re-diseño completo de la arquitectura software del CE migrándolo a C# y estructurándolo
como solución multi-capa para poder explotar las ventajas del paradigma de la programación orientada a objetos. Este
re-diseño permitirá dotar en un futuro al CE de nuevas funcionalidades de valor añadido así como implementarlo en
nuevas plataformas portables, inalámbricas y móviles integrando ambas normas de interoperabilidad, ISO/IEEE11073 y
UNE-EN/ISO 13606, en un entorno open source sobre Linux.
A partir de este re-diseño, se desarrollará la implementación completa del nuevo framework sobre X73PHD y se
integrarán la interoperabilidad de área extendida (Wide Area Network, WAN) con el servidor de HCE según UNE-EN/ISO
13606 y mediante tecnologías Web Services (WS) a través de lenguaje eXtensible Markup Language (XML). Además, se
estudiará el estado del arte de los nuevos perfiles médicos propuestos para las tecnologías de transporte
recomendadas desde el grupo especial de trabajo de X73PHD (PHDWG): Bluetooth Health Device Profile (BT HDP), USB
Persona Healthcare Device Class (USB PHDC) y ZigBee HealthCare Profile (ZB HCP). A partir de este estado del arte, se
propondrá el diseño e implementación del perfil médico BT HDP para su integración con el framework X73PHD y el
servidor de HCE con los más recientes dispositivos médicos certificados desde la iniciativa Continua Health Alliance.
Además, se diseñará la capa de servicios a nivel superior según el paradigma cloud computing para poder plantear un
entorno de uso real que pretende ser una prueba de concepto incorporando servicios de valor añadido como
calendario de citas médicas, recordatorio de tareas, mensajes privados o soporte a través de chat apoyándose en los
paradigmas del diseño en la nube.
Como líneas futuras, se pretende extender las contribuciones propuestas al resto de perfiles médicos recomendados
(USB HDCP y ZHC) para su integración definitiva en la plataforma lo que desembocará en un entorno de comunicación
multi-tecnología completamente interoperable conforme a X73PHD y UNE-EN/ISO 13606. A partir de aquí, habría que
estudiar las tendencias en tecnologías inalámbricas de última generación (WiFi/WiMax, Ultra Wide Band (UWB) y Long
Term Evolution (LTE)) y su posible aplicación a escenarios de e-Salud (analizando su adaptación y compatibilidad con el
entorno sanitario, su problemática de integración y su influencia en la mejora de la calidad de vida de las personas), lo
que constituirá una futura propuesta de tesis doctoral.
Prácticas médicas
Para la consecución de este TFM se han realizado prácticas médicas en tres ámbitos diferentes:
 el académico, en colaboración con el grupo Morfeo (proyecto OpenHealth) del Dr. Pedro de las Heras de la
Universidad Juan Carlos I para el desarrollo e integración del perfil médico de Bluetooth y con el grupo Healthy
Interoperabilty del Dr. Stefan Sauermann de la universidad vienesa de ciencias aplicadas Fachhochschule
Technikum Wien (en la que se ha realizado una estancia de investigación de tres meses), para el desarrollo y
ejecución de pruebas sobre la nueva plataforma propuesta;
 el empresarial, en colaboración con Técnicas Competitivas S.A. (TCSA), una empresa canaria que, entre otros
productos, ofrece servicios de gestión de HCE en el ámbito de la salud y con la que se participa en la actualidad en
el proyecto TSI-020302-2009-89 dentro del Plan Avanza I+D del Ministerio de Industria, Turismo y Comercio;
Página | 2
 y el sanitario, mediante la colaboración en el proyecto WiSo (Wiener Sozialdienste), en el contexto de la citada
estancia, para los servicios sociales de Viena que consiste en la adaptación de hogares y residencias de mayores
para que estos puedan ser monitorizados por sus familiares más cercanos ofreciéndoles una mejora en su calidad
de vida. En este proyecto se realizaron entrevistas con profesionales médicos para determinar los datos que,
además de la propia medida, resultan fundamentales y deben ser asociados a ésta como el dispositivo utilizado o
la hora en la que se realizó la medida.
Estructura de la memoria
Capítulo 1
Este primer capítulo introduce el contexto en el que se desarrolla este TFM y desglosa los objetivos generales y
particulares, detallando el contenido de las distintas secciones y apartados del TFM.
Capítulo 2
El segundo capítulo desarrolla el Estado del Arte acerca de algunos de los conceptos más importantes de este TFM: eSalud, telemonitorización y estandarización. Presenta las iniciativas existentes en la actualidad en lo referente a
estandarización e integración en e-Salud y detalla un análisis exhaustivo de las tecnologías de transporte que han
desarrollado un perfil médico para X73PHD.
Capítulo 3
En este capítulo se presenta la nueva plataforma desarrollada. Se inicia el capítulo recordando las plataformas previas
cuyo trabajo acumulado ha desembocado en la nueva plataforma y se completa analizando detalladamente el diseño,
arquitectura, implementación e integración de todos los componentes que conforman la nueva plataforma.
Capítulo 4
En el capítulo 4 se plantea la metodología de evaluación de los resultados obtenidos por la nueva plataforma y se
describe el proyecto WiSo en el cual se ha desarrollado una parte de las prácticas médicas que propone este TFM.
Capítulo 5
Para finalizar el TFM, se presenta en este capítulo las conclusiones obtenidas tras la labor de investigación donde,
después de adquirir un conocimiento, se ponen de manifiesto unas pautas a tener en cuenta para el futuro. Por último,
se constatan los puntos abiertos que deja este TFM que servirán de líneas futuras a desarrollar en la Tesis Doctoral.
Página | 3
Página | 4
Estado del arte
2.1. e-Salud, telemonitorización y estandarización
Los sistemas de provisión de servicios sanitarios y de asistencia social son claves en una sociedad europea cada vez más
envejecida, con unos ciudadanos que demandan más y mejores servicios incluso en sus desplazamientos, y con unas
Administraciones Públicas que requieren mayor eficiencia en la provisión de los mismos. En este contexto, las
Tecnologías de la Información y las Comunicaciones (TIC) jugarán un papel fundamental en generar un marco sostenible
y en facilitar su desarrollo. Por consiguiente, tanto en España como en la Unión Europea, se suceden diversas iniciativas
para establecer un marco de impulso a las acciones relativas a e-Salud y la e-inclusión como medio para conseguir
sistemas de salud y de asistencia social capaces de ser proactivos y reaccionar de manera inteligente a las necesidades
individuales de los ciudadanos.
En este contexto, la telemonitorización de pacientes es uno de los principales campos de aplicación de los servicios de
e-Salud, ya que abarca el conjunto de sistemas técnicos y servicios médicos que permite realizar un control a distancia
de parámetros y señales biológicas de enfermos que lo necesitan. La telemonitorización de pacientes es una de las
prácticas más habituales en telemedicina, puesto que, empleada adecuadamente, permite incrementar la calidad de la
atención prestada y aumentar la eficiencia de los servicios, fundamentalmente gracias a que facilita un seguimiento
continuado de pacientes crónicos, ancianos, cuidados paliativos o intervenidos quirúrgicamente, sin que éstos ocupen
las camas que serían necesarias para su seguimiento in-situ y permite destinarlas a usos más críticos. Además, los
pacientes telemonitorizados pueden continuar viviendo en sus propios domicilios con las ventajas que ello conlleva:
comodidad, contexto favorable, ausencia de desplazamientos, etc. Incluso, en los últimos años, el espectro de
aplicación y casos de uso se ha ampliado a autocontrol de la salud, fitness, control de atletas, etc. Todo ello justifica la
elección de la telemonitorización como el campo de aplicación de innovaciones en TIC aplicadas a la e-Salud.
Los dispositivos médicos más usados en e-Salud para medir parámetros y señales biológicas suelen ser (ver Figura 2.1):
monitores de ECG, medidores de presión arterial y frecuencia cardiaca, básculas digitales, pulsioxímetros, incluso
monitorizadores portables para control del ejercicio, fitness, etc. En función del ámbito de aplicación y el caso de uso,
pueden ser fijos, inalámbricos, o llevables (wearables), incorporados en prendas de vestir, pulseras, etc. mediante
sensores. Estos conjuntos de sensores alrededor del paciente conforman lo que se suele denominar red corporal (Body
Area Network, BAN) o red personal (Personal Area Network, PAN). Habitualmente, para seguimiento de pacientes
ancianos o de escasa movilidad, estas redes PAN o BAN se completan con detectores de presencia, sensores de
movimiento, o dispositivos similares, formando la red domiciliaria (Home Area Network, HAN). En los últimos años, la
evolución de los sensores, dispositivos y equipos asociados al paciente ha sido vertiginosa como se pone de manifiesto
en siguientes apartados de este trabajo, en los que se analizará esta problemática más en detalle. La evolución de los
dispositivos, lleva asociado un cambio en el punto de atención al paciente. Esta última década ha estado marcada por
las continuas evoluciones desde los servicios tradicionales de e-Salud centrados en el paciente, hacia el uso de nuevos
dispositivos médicos personales o llevables (wearables) que aprovechan las ventajas de las tecnologías wireless. Esta
evolución tecnológica, ha venido inducida por el avance en las nuevas tecnologías como USB, Bluetooth o ZigBee, entre
otras.
Figura 2.1. Dispositivos médicos
Esta evolución ha llevado a trasladar el ámbito de aplicación de la soluciones de e-Salud del entorno hospitalario
centrado en el punto de cuidado (PoC) hacia el entorno personal del paciente (PHD). Esta transformación implica
cambios en el concepto de la comunicación de los datos médicos, de la autonomía, peso, tamaño, etc. de los
Página | 5
dispositivos, así como de los procedimientos funcionales globales de la solución. Todo ello hace que la implantación de
nuevas soluciones de salud personal requieran de un estudio detallado de los entornos de aplicación,
usuarios/pacientes a los que se dirigen y, en definitiva, evaluar los nuevos entornos de uso. Es, por tanto,
imprescindible a la hora de diseñar las características específicas de una solución de e-Salud, evaluar sus entornos de
uso de manera que quede convenientemente definido el rango de propiedades soportadas por la solución y sus
correspondientes dispositivos médicos. Una lista de los casos de uso contemplados para el desarrollo de soluciones de
e-Salud personal se proporciona desde el grupo especial de trabajo de X73PHD (PHDWG) destacando los siguientes
entornos de uso:
 Salud y bienestar
 Fitness cardiovascular y monitorización de actividad
 Fitness de esfuerzo
 Gestión de enfermedades de alto riesgo: obesidad e hipertensión
 Assisted Ambient Living (AAL)
 Cuidado de pacientes de avanzada edad
 Diabetes
 Monitorización de pacientes con problemas cardiacos
Sin embargo, algunos de los problemas no resueltos en e-Salud son:
 La heterogeneidad de sistemas de información sanitarios, que redunda en dificultades de integración de
dispositivos médicos. Abundan los formatos propietarios (no publicados) de fabricante, que implican
comunicaciones no universales, ni transparentes e incompatibles entre sí.
 Problemas de reemplazos y actualizaciones de sistemas, con sus correspondientes costes. Errores concretos o
nuevas versiones implican modificaciones completas de hardware/software y sustitución del sistema.
 La necesidad de integrar historia clínica electrónica basada en estándares aceptados.
 Los estrictos requisitos de seguridad que garanticen la privacidad y confidencialidad del paciente.
Además, existen barreras de interoperabilidad en el escenario actual de expansión de servicios de telemonitorización,
relacionadas con la interoperabilidad, y que dificultan gravemente la implantación en rutina clínica:
 No se logra integrar la información de telemonitorización con los sistemas de información sanitaria usados en la
rutina clínica, lo que limita la expansión de las soluciones.
 Se encuentra gran dificultad para que dispositivos de monitorización heterogéneos (de formatos y modelos de
comunicación propietarios de fabricante, no universales ni transparentes) convivan en una red homogénea según
un funcionamiento plug&play.
 No se han resuelto los amplios problemas que ocasionan los reemplazos y actualizaciones de los sistemas, con sus
correspondientes costes.
Estas barreras están muy relacionadas con los diferentes ámbitos de integración identificados en un diseño de e-Salud.
En el ámbito local (red BAN/PAN/HAN), conviven dispositivos de monitorización heterogéneos (por ej. báscula,
esfigmomanómetro, y pulsioxímetro). En el ámbito global del sistema de telemedicina, los datos médicos del paciente
deben ser integrados con su HCE, y accesibles por los profesionales correspondientes. Cualquiera de estas situaciones,
implica grandes cambios en el software de la aplicación, no sólo por la diferencia de formatos, sino porque el
paradigma de funcionamiento suele resultar muy diferente. Para superar estas barreras y dotar de homogeneidad a las
soluciones propuestas, es esencial el uso de estándares internacionales a seguir por fabricantes.
Este es un largo proceso que ha venido impulsado en las últimas décadas desde los organismos de normalización y las
asociaciones de integración. Estas evoluciones buscan arquitecturas integradas que no sólo posibiliten la
interoperabilidad en el punto de cuidado, sino que garanticen portabilidad a otros entornos y casos de uso, faciliten la
gestión remota (alarmas, patrones de comportamiento), e incorporen nuevas funcionalidades (plug&play, HotSwap),
tecnologías (USB, Bluetooth, ZigBee), y dispositivos (PDAs, SmartPhones, micro-controladores). En este contexto, las
principales organizaciones encargadas de la Informática Médica y las TICs para la salud son el Comité Europeo de
Normalización (CEN), a través de su Comité Técnico CEN/TC251, como principal organización europea con competencia
en este campo y la, Asociación Española de NORmalización (AENOR), mediante su Comité Técnico AEN/CTN139, como
el organismo de estándares en España, y espejo del CEN a nivel nacional. Nuestro grupo de investigación pertenece a
ambos comités y ha venido participando activamente en el desarrollo y redacción de las normas objeto de este TFM:
X73 para interoperabilidad de dispositivos médicos y UNE-EN/ISO 13606, para comunicaciones interoperables de HCE.
Página | 6
Sin embargo, el consenso e integración en la utilización de estándares y su implantación a gran escala, es un camino
complejo. Por eso, quizá sea más importante el papel que juegan otras asociaciones que no las organizaciones de
normalización. Integrating the Healthcare Enterprise (IHE) es una de esas asociaciones: se trata de un organismo
formado por fabricantes de todo el mundo (americanos, europeos y asiáticos) cuyo propósito no es elaborar nuevas
normas, sino la adopción coordinada de los estándares existentes más adecuados para cada aplicación concreta. En
este camino, un hito importante en este proceso se da en junio de 2006 cuando 22 industrias líderes en tecnología y
compañías de salud unen sus esfuerzos para formar una alianza abierta y sin ánimo de lucro: Continua Health Alliance.
Desde sus inicios, esta alianza ha crecido continuamente hasta alcanzar, en la actualidad, 36 compañías promotoras y
otras 32 colaboradoras. Siguiendo su objetivo de “establecer un ecosistema de sistemas de salud personal
interoperables para permitir a personas y organizaciones una mejor gestión de su salud y bienestar”, la alianza no busca
desarrollar nuevas normas sino consolidar al máximo e integrar las existentes; así como cerrar ciertos debates abiertos
sobre middleware, al promover reglas comunes y estándares de interoperabilidad. Continua Health Alliance abarca
desde los dispositivos médicos en el entorno del paciente hasta servicios end-to-end definiendo interfaces
interoperables. Actualmente, varias tecnologías fijas y móviles están en fase de investigación para estandarizar su
conectividad sobre diferentes perfiles médicos propuestos desde el grupo especial de trabajo de X73PHD (PHDWG) y
comentados en la introducción: Bluetooth HDP, USB PHDC y ZigBee HCP. Además de los aspectos técnicos, uno de los
objetivos claves de Continua Health Alliance es establecer un programa de certificación con su correspondiente
logotipo oficial para el etiquetado de los dispositivos.
Por último y según los objetivos planteados para este TFM, merece especial consideración la familia de normas X73 y su
reciente evolución hacia una versión optimizada y adecuada a estas nuevas tecnologías y dispositivos médicos
personales (X73PHD), como muestra la Figura 2.2. Esta evolución optimiza la arquitectura del protocolo, el modelo de
comunicaciones agente-manager, define una nueva máquina de estados finita (Finite State Machine, FSM), así como un
nuevo modelado del transporte y de nivel físico que conforman la pila de protocolos X73PHD. En este apartado no se
busca desarrollar todo el contenido técnico del protocolo X73PHD ya que su estudio requiere de una lectura en
profundidad y preferentemente acompañado de una implementación real, por lo que toda la información disponible
sobre su estructura y características técnicas se incluye en el Anexo I.
Figura 2.2. Evolución de la pila de protocolos de X73PoC a X73PHD
Página | 7
2.2. Iniciativas de estandarización e integración en e-Salud
Continua Health Alliance [2] nace en junio del 2006 como una coalición de industria
abierta sin ánimo de lucro de 22 de las mejores compañías de asistencia sanitaria y
tecnología para colaborar en la mejora de la calidad de la asistencia sanitaria
personal. Con más de 180 compañías socias en todo el mundo, Continua se dedica a
establecer un sistema de soluciones interoperables de soluciones de salud personal
con el conocimiento de que la ampliación de esas soluciones en el hogar promueve
la independencia, capacita a los individuos y ofrece la oportunidad para una
verdadera gestión personalizada de la salud y del bienestar. De acuerdo con su
misión “establecer un sistema de soluciones de e-Salud personal interoperable que promueva la independencia y que
capacite a las personas y organizaciones a gestionar mejor la salud y el bienestar”, son objetivos de Continua:
 Desarrollar directrices de diseño que permitan a los proveedores fabricar sensores interoperables, redes en el
hogar, plataformas de e-Salud y servicios de salud y bienestar.
 Establecer un programa de certificación de productos con un logo reconocible para el consumidor, que indique la
promesa de interoperabilidad en los productos certificados.
 Colaborar con las agencias reguladoras gubernamentales para proporcionar métodos para la gestión segura y
eficaz de diversas soluciones de proveedores.
 Trabajar con los líderes del sector de la asistencia sanitaria para desarrollar nuevas maneras de tratar los costes de
proporcionar sistemas de e-Salud personal.
Es importante resaltar que Continua no es un organismo de estandarización. La alianza ha seleccionado estándares de
conectividad y trabaja para identificar y resolver vacíos en algunos organismos estándares de modo que las soluciones
de e-Salud personal sean interoperables y colaboren en la gestión sanitaria mejorada. Además, la alianza está
redactando directrices sobre cómo utilizar específicamente los estándares para lograr una auténtica interoperabilidad
en muchas compañías y en muchos dispositivos. En definitiva, Continua aparece como un mecanismo potenciador de
los estándares de interoperabilidad e intentando que éstos se vean reflejados en el mundo real a través de las
empresas colaboradoras.
Morfeo OpenHealth [3] es un proyecto de investigación para el desarrollo de soluciones de eSalud en entornos móviles. Estas soluciones están basadas en la gestión de dispositivos
biomédicos inalámbricos en redes de área corporal BAN bajo estándares IEEE y Open Mobile
Terminal Platform. Este proyecto implementa los principales componentes del estándar X7320601 como son el Modelo de Servicio, Modelo de Comunicación y Modelo de Información de
Dominio (Domain Information Model, DIM). El objetivo es el de transformar la información en un
formato interoperable que permite el intercambio de información y comunicación entre agentes
y managers. Hasta ahora, las principales características implementadas son:
 Soporte para Abstract Syntax Notation One (ASN.1) a través de una versión modificada del framework Binary
Notes que contiene:
o Librería de codificación y decodificación. Esta librería implementa la reglas de codificación (Encoding Rules, ER)
básicas (Basic, BER), de paquete (Packet, PER) y específicas (Distinguished, DER).
o BCN Compiler (basado en eXchange Sheet Language, XSL). Compilador ASN.1 el cual es capaz de generar clases
Java o C# para un fichero de entrada ASN.1. El código generado tiene anotaciones y atributos que usa el
compilador durante la ejecución. Binary Notes permite personalizar los ficheros generados modificando las
plantillas XSL originales o creando nuestras propias plantillas.
 Colas de mensajes. Implementación de colas de mensajes simples y de alto rendimiento.
 Soporte para Medical Device Encoding Rules (MDER), codificación usada en el intercambio de información X73.
o Nuevo codificador y decodificador para MDER.
o Tipos de datos ASN.1
 Soporte para el Modelo de Comunicación.
o Características de las comunicaciones
o Máquina de estados del manager
 Implementación libre de Health Device Profile (HDP) y Multi-Channel Adaptation Protocol (MCAP) para la pila de
protocolos BlueZ (para tecnología Bluetooth sobre sistema operativo Linux).
Página | 8
A día de hoy, ya se ha conseguido realizar una comunicación satisfactoria entre un pulsioxímetro Nonin, que cumple
con X73, y un teléfono móvil Nexus One a través de Bluetooth usando el motor X73-20601 desarrollado por el equipo
de Morfeo. La plataforma sobre la que se ha desarrollado este proyecto es Android, un sistema operativo orientado a
dispositivos móviles basado en una versión modificada del núcleo Linux. Este sistema fue inicialmente desarrollado por
Android Inc., compañía que fue comprada posteriormente por Google, y en la actualidad lo desarrollan los miembros de
la Open Handset Alliance (liderada por Google). El impulso de esta plataforma por parte de Google ha hecho que se esté
imponiendo como sistema operativo para dispositivos móviles rivalizando fuertemente con iOS, el sistema operativo de
Apple. Es importante destacar que este proyecto se distribuye bajo los términos de la licencia GPL versión 3 o posterior.
Healthy Interoperability [4] es un conglomerado de investigaciones y actividades de
desarrollo en los campos de: e-Salud, interoperabilidad, validación, integración técnica y
seguridad de dispositivos médicos e información. El proyecto, desarrollado por la
universidad de ciencias aplicadas Technikum de Viena, nace en el año 2008 a partir de un
grupo de estudiantes de postgrado en Ingeniería Biomédica. Estos estudiantes iniciaron un
proyecto: desarrollar una plataforma software modular para gestionar y visualizar señales
biomédicas. El objetivo de este primer proyecto dentro del marco de Healthy
Interoperability es construir un software que se capaz de manejar diferentes estándares y formatos de dispositivos
biomédicos. El proyecto es apoyado por la agencia austriaca para la promoción de la investigación (Austrian Research
Promotion Agency , FFG) dentro del programa "FHPlus in Coin" y por el departamento municipal de la ciudad de Viena
número 27, "EU-strategy and economic development" siguiendo las guías "Fachhochschulförderrichtlinie" del año 2005.
La finalidad del proyecto es analizar las diferentes propuestas internacionales para la comunicación consistente de
datos provenientes de sensores y otros instrumentos a sistemas de información de instalaciones de salud o historial
clínico electrónico. Se desarrollarán métodos a partir de los resultados obtenidos por proyectos de investigación
internacionales y normas internacionales como X73, HL7, UNE-EN/ISO13606 y otras iniciativas como IHE o Continua
Health Alliance. Esta iniciativa es, junto con el proyecto upHealth.ES del subgrupo de telemedicina de GTC/I3A de la
Universidad de Zaragoza, una de las primeras que ha comenzado a abordar la problemática extremo a extremo, desde
la medida con el dispositivo médico hasta la recepción de la misma en el centro hospitalario.
Google Health [5] es un servicio de historial médico personal desarrollado por Google. Este
servicio permite a los usuarios introducir información clínica como estados de salud,
medicaciones, alergias, resultados de análisis, entre otros. A través de esta información,
Google Health proporciona al usuario una historia clínica, información de su estado y
posibles interacciones entre medicamentos o alergias. En septiembre del 2010 Google
actualizó el servicio dotándolo de nuevas características como monitorización del ejercicio,
dieta y parámetros variados como niveles de colesterol, peso o presión arterial. Además, se
añadieron gráficas para visualizar y comprender mejor nuestra salud y efectos de nuestros
hábitos a diferentes niveles físicos.
Microsoft HealthVault [6] es un servicio gratuito que permite que los
pacientes almacenen todos los datos relacionados con temas de salud,
ofreciéndoles una plataforma de aplicaciones que trabajan con estos
datos. En HealthVault, los usuarios pueden permitir a las aplicaciones el
acceso a sus datos de salud personal, aunque estas aplicaciones no
podrán en ningún momento recopilar datos personales de los usuarios. HealthVault no es solo una plataforma
orientada a mejorar los sistemas de salud de los usuarios, sino que para Microsoft también será un negocio ya que lo
utilizará como soporte publicitario. Según Microsoft, de momento no existen planes de compartir la información de los
usuarios con el National Health Service (NHS), pero asegura que esta nueva plataforma de salud en la nube, será de
gran ayuda para el sistema sanitario público.
Página | 9
2.3. Tecnologías de transporte y perfiles médicos
A continuación se analiza las diferentes tecnologías de transporte que han desarrollado un perfil médico especializado
para X73PHD. Actualmente, dichas tecnologías son tres: para comunicaciones cableadas, el perfil USB PHDC y, para
comunicaciones inalámbricas, los perfiles Bluetooth HDP y ZigBee HCP. La estructura genérica de la pila de protocolos
X73PHD se muestra en la Figura 2.3. Las capas inferiores (1-4 del modelo OSI) corresponden a las diferentes tecnologías
de transporte existentes y las capas superiores (5-7 del modelo OSI) dan cabida a las funcionalidades propias de
X73PHD (que englobarían el protocolo de comunicación X73-20601 y las especializaciones X73-104zz) y a las de nivel de
aplicación fuera del alcance de X73PHD.
Application
Application Layers
Layers
(OSI
(OSI5-7
5-7Layers)
Layers)
ISO/IEEE PHD
Functionality
Non PHD
Supporting
Functionality
Transport Layers
(OSI 1-4 Layers)
Multiple Transport Technologies
Figura 2.3. Pila genérica de protocolos X73PHD
USB Personal Health Device Class (USB PHDC)
Universal Serial Bus (USB) es una especificación para establecer una comunicación cableada entre un host y toda una
gama de dispositivos cliente, por este motivo el sistema USB tiene un diseño asimétrico master-slave. USB 2.0, lanzada
en abril de 2000 y estandarizada a finales de 2001 por USB Implementers Forum (USB IF), es la especificación más
común en los equipos pudiendo alcanzar velocidades de transferencia de 480 Mbit/s. USB fue la primera tecnología que
publicó un perfil compatible con X73PHD, ya que antes los dispositivos de salud USB estaban obligados a implementar
métodos propietarios para transmitir información y usar algunas de las clases definidas. Típicamente se empleaba la
clase Human Interface Device (HID), definida para ratones y teclados, o bien la clase Vendor Specific, que requería de
drivers propietarios específicos para cada dispositivo. De esta necesidad se forma en abril del 2007 el USB Personal
Healthcare Working Group que publica el 8 de noviembre del mismo año la clase USB PHDC [7], que sigue vigente a día
de hoy sin revisión alguna. El objetivo de una especificación de clase es permitir la interoperabilidad sin fisuras entre el
USB host y aquellos dispositivos pertenecientes a la clase, en este caso dispositivos de salud personal (agentes
X73PHD). La especificación describe la arquitectura completa, como se detalla en la Figura 2.4 (a), y los descriptores y
comandos que un dispositivo de salud y un host deben poder soportar en virtud de intercambiar datos médicos sobre
un bus USB. Un descriptor es una estructura de datos que contiene, en una serie de campos, información sobre el
dispositivo y sus características. De este modo, el descriptor del dispositivo, por ejemplo, contiene información sobre la
clase del dispositivo (por ejemplo, PHDC) así como información sobre el fabricante, número de serie, etc. El estándar
USB PHDC define una jerarquía de descriptores que se pueden clasificar en descriptores estándar, de especificación de
clase y opcionales. La jerarquía de descriptores USB PHDC se detalla en la Figura 2.4 (b).
Página | 10
Personal Health Care
Application
-104zz Device
Specializations
Meta-Data
-20601 Optimized
Exchange Protocol
Device
Configuration
Interface
PHDC Class Funtion
PHDC Function Extension
Endpoint
PHDC QOS
USB Personal Health Device Class
Driver
PHDC Meta-Data
Endpoint
(PHDC Driver)
PHDC QOS
PHDC Meta-Data
Figura 2.4. (a) Pila de protocolos de X73PHD sobre USB PHDC y (b) Jerarquía de descriptores USB PHDC
Dentro de la jerarquía, se definen endpoints como una entidad lógica que se encuentra en el dispositivo y con el que el
host establece canales lógicos denominados tuberías o pipes. Cada uno de ellos tiene su propio descriptor de calidad de
servicio (Quality of Service, PHDC QoS) así como un descriptor opcional de meta-datos (PHDC meta-data). La
transmisión de metadatos se realiza mediante el envío de una transacción inicial antes de enviar los datos que
proporciona separación entre ambos. Dicha transacción se denomina preámbulo y es una característica opcional por lo
que implementarla o no es potestad del fabricante. Sin embargo un host está obligado a soportar siempre ésta
característica. Además, USB PHDC define un conjunto de endpoints (tres obligatorios y un cuarto opcional) que
implementan los requerimientos de QoS mencionados:
 Control endpoint: requerido por USB PHDC para la tubería por defecto de control bidireccional. Dichos endpoints
están siempre accesibles mientras que los demás sólo lo estarán una vez hayan sido configurados por el host.
 Bulk Out endpoint: proporciona un camino para las transferencias desde el host al dispositivo.
 Bulk In endpoint: proporciona un camino para las transferencias desde el dispositivo al host.
 Interrupt In endpoint (opcional): proporciona un camino hacia el host cuando sea necesario enviar datos de un
modo continuo (sólo se usa para el tipo de QoS Low Good).
Por último, el procedimiento de comunicación USB PHDC es el siguiente: cuando un dispositivo se conecta al bus USB,
el host inicia el proceso de enumeración, lee el descriptor de dispositivo, asigna al dispositivo un número único de 0 a
127 y, si el dispositivo es soportado por el host, se cargan los drivers de comunicación apropiados en función de la clase
a la que pertenezca el dispositivo.
Bluetooth Health Device Profile (BT HDP)
Bluetooth es una especificación para redes inalámbricas de área personal (Wireless PAN, WPAN) que posibilita la
transferencia de datos entre dispositivos mediante un enlace de radiofrecuencia en la banda reservada para uso no
comercial (2.4-2.5GHz) sin necesidad de licencia siempre que se respete el límite de potencia. La especificación define
una pila de protocolos y una serie de perfiles. Los perfiles son guías que indican los procedimientos por los que los
dispositivos Bluetooth se comunican entre sí para los diferentes tipos de uso. Existe un amplio abanico de perfiles
(perfil de dispositivo de interfaz humana, perfil de telefonía inalámbrica, perfil de puerto serie, etc.). Cada perfil incluye,
como mínimo, información sobre las características concretas de la pila Bluetooth utilizada por el perfil, así como las
posibles dependencias de otros perfiles y propuestas del formato de nivel de aplicación. Al seguir las directrices
proporcionadas por los perfiles los desarrolladores pueden crear aplicaciones compatibles con todos los dispositivos
Página | 11
que se ajusten al perfil. Típicamente los dispositivos médicos comerciales con tecnología Bluetooth hacían uso de
formatos propietarios no publicados sobre el perfil de puerto serie (Serial Port Profile, SPP).
Para resolver estas cuestiones, Bluetooth Special Interest Group (SIG) crea en 2006 un grupo de trabajo (Medical
Working Group, MedWG) con objeto de diseñar un perfil específico para dispositivos de salud personal. El resultado de
este trabajo fue la publicación en Junio de 2008 del perfil Bluetooth HDP [8] junto con un nuevo protocolo específico
Multi-Channel Adaptation Protocol (MCAP). HDP define los requisitos que deben implementar los dispositivos
certificados como Bluetooth Healthcare & Fitness. Así, el perfil es dependiente de los protocolos MCAP, Logical Link
Control and Adaptation Protocol (L2CAP) y Service Discovery Protocol (SDP) junto con el perfil Device ID (DI) y algunos
procesos del perfil Generic Access Profile (GAP). MCAP coordina la creación de un canal de control y uno o más canales
de datos. SDP se utiliza para descubrir otros dispositivos Bluetooth y sus servicios a través de un registro que se anuncia
a través del perfil DI. El perfil GAP se encarga de procesos comunes a todos los perfiles, tales como autentificación y
cifrado. L2CAP se encarga de la multiplexación de todos los protocolos superiores, del control de flujo y QoS, y de la
retransmisión, segmentación y re-ensamblado de todos los paquetes. Finalmente, Host Controller Interface (HCI)
describe comandos y eventos compatibles con todas las implementaciones hardware de un módulo Bluetooth. A nivel
de aplicación, HDP define como obligatorio el uso del X73-20601 como único protocolo para el intercambio de datos
entre dispositivos. Además, establece las denominadas Device Data Specializations compatibles con este protocolo. La
pila completa de protocolos se muestra en la Figura 2.5.
Personal Health Care
Application
-104zz Device
Specializations
-20601 Optimized Exchange
Protocol
Health Device Profile (HDP)
GAP
MCAP
DI
SDP
L2CAP
Host Controller
ll Interface
f
(HCI)
( )
Bluetooth
Controller
Module
ll
Figura 2.5. Pila de protocolos de X73PHD sobre Bluetooth HDP
En el perfil médico BT HDP los términos agente y manager se sustituyen por source y sink respectivamente, dado que
los agentes que captan las medidas fisiológicas son las fuentes de datos y el manager el consumidor de dichos datos. El
procedimiento de comunicación se inicia cuando uno de los dos dispositivos (source o sink) establece un canal de
control. Este canal sólo se utiliza para tráfico MCAP y ambos dispositivos pueden utilizarlo para coordinar la creación de
uno o más canales de datos por el que se intercambia el tráfico X73PHD. Finalmente, uno de los extremos finaliza la
conexión; bien cerrando primero los canales de datos y después el canal de control, o cerrando directamente el canal
de control que produce el cierre automático de los canales de datos.
Página | 12
ZigBee Health Care Profile (ZHC)
ZigBee, al igual que Bluetooth, es una tecnología para redes inalámbricas de área personal WPAN. Se trata de un
conjunto de protocolos que operan sobre el estándar IEEE 802.15.4, ya que éste sólo define el nivel físico y el control de
acceso al medio. Se consigue así una solución completa enfocada a aplicaciones que requieran una baja tasa de
transmisión, bajo coste, larga duración de las baterías y cifrado de la información. Al igual que Bluetooth, opera en la
banda ISM de 2.4GHz, pudiendo hacerlo también en la de 868MHz en Europa. La tasa de transmisión máxima es de
250kbits/s frente a los 3Mbits/s de Bluetooth, pero el número máximo de nodos en la red es de 65535 frente a los 8 de
una piconet Bluetooth. El hardware es un 90% más sencillo y presenta un consumo mucho más reducido logrando
autonomías de varios años.
ZigBee ha sido, por el momento, la última de las tecnologías de transporte en publicar un perfil de salud que utiliza
X73PHD a nivel superior: ZigBee ZHC [9], aprobado por ZigBee Alliance Board of Directors en Marzo de 2010. Este perfil
ZHC proporciona una descripción de los dispositivos mediante clusters junto con el esquema de comunicación dentro
de la red y los protocolos utilizados. Los clusters contienen un conjunto de atributos que representan el estado del
dispositivo junto con los comandos que posibilitan la comunicación. Además, para crear un túnel de datos compatible
con X73PHD, se han desarrollado una serie comandos específicos agrupados en la denominada 11073 Protocol Tunnel
Cluster Library. La pila completa de protocolos se muestra en la Figura 2.6.
Personal Health Care
Application
-104zz Device
Specializations
-20601 Optimized Exchange
Protocol
ZigBee Health Care Profile(ZHC)
11073 Protocol tunnel Cluster
ZigBee Cluster Library
ZZigBee
igBee 2007 ZZigBee
igBee 2007 PRO
IEEE 802.15.4
Figura 2.6. Pila de protocolos de X73PHD sobre ZHC
En el procedimiento de comunicación ZHC se establecen dos túneles o X73PHD tunnels. En uno, el manager actúa de
servidor y el agente de cliente mientras que, en el otro, los roles son los recíprocos. Para iniciar la comunicación el
manager comprueba si un agente posee un servidor X73PHD establecido. En ese caso, generará una petición de
conexión y el agente contestará con una notificación de estado connected a partir de la cual podrán intercambiar
tramas X73PHD.
La adhesión al perfil permite a los fabricantes obtener la certificación ZigBee que garantiza interoperabilidad con los
dispositivos de otros fabricantes. Además el hecho de que todos los perfiles se definan usando clusters de la ZigBee
Cluster Library (ZCL) posibilita la reutilización de los clusters usados por varios perfiles.
Página | 13
Análisis de X73PHD sobre los perfiles médicos USB, Bluetooth y ZigBee
En primer lugar, para la comunicación interoperable entre USB PHDC en las capas inferiores con X73PHD en las capas
superiores, se asumen las siguientes suposiciones:
 Los datos se envían y reciben en tramas X73PHD (Application Protocol Data Units, APDU) no superiores a 63
kBytes.
 USB PHDC puede enviar y recibir datos de manera opaca. En caso de que se necesite conocimiento sobre los
datos enviados, esta información se facilita como metadatos junto con los datos reales.
 Dado que USB PHDC implementa una conexión cableada, se asume que la seguridad de los datos enviados está
garantizada en la capa física.
 En caso de existir diferentes canales en una misma asociación device/host, la información de QoS para cada uno
de los canales se especificará de manera independiente en forma de metadatos.
 Se usarán los siguientes tipos de calidad de servicio para describir latencia y fiabilidad (cada una con código
diferente en el descriptor de QoS): Low Good, Low Medium, Medium Better, Medium Better, High Best y Very High
Best.
En segundo lugar, las principales ventajas de utilizar BT HDP sobre otros perfiles genéricos que se han estado usando
en aplicaciones de e-Salud son las siguientes:
• Método inalámbrico estandarizado para descubrir dispositivos mediante la definición de un registro estándar
para SDP que contiene campos necesarios para definir un servicio conforme a BT HDP.
• Canal de control robusto que requiere del empleo de nuevas capacidades de L2CAP como son: modo de
retransmisión mejorado (Enhanced Retransmission Mode, ERTM) y secuencias de comprobación de trama (Frame
Check Sequence, FCS).
• Configuración flexible e independiente de cada uno de los canales de datos que pueden ser de tipo fiable
“reliable” (si utilizan el modo ERTM del protocolo L2CAP) o de tipo “stream” (si utilizan Streaming Mode (SM) del
protocolo L2CAP).
• Mecanismo de re-conexión optimizado. Permite retener el estado del sistema y elimina pasos redundantes en la
re-conexión. Este procedimiento reduce el consumo medio.
• Optimización para dispositivos médicos con pocos recursos, ya que posee un conjunto reducido de comandos
sencillos.
• Autentificación y cifrado.
• Sincronización precisa de reloj mediante el empleo de Clock Synchronization Protocol (CSP). No obstante, la
implementación de este protocolo es opcional y no está presente en todos los dispositivos. La sincronización
conseguida puede llegar a tener precisión de microsegundo.
Por último, ZHC presenta algunas particularidades con respecto a los dos perfiles anteriores:
• Permite indicar la ubicación en la que se instala un dispositivo mediante una serie de códigos predefinidos (baño,
cocina, dormitorio, etc.).
• Permite estimar la posición de un dispositivo en función de la señal recibida.
• Permite a los fabricantes incluir funcionalidades no estándar mediante clusters específicos.
• Permite a los dispositivos enviar voz mediante el empleo del Voice Over ZigBee Cluster.
• Dentro de una red ZigBee pueden existir hasta tres tipos de dispositivos: coordinador, router y dispositivo final. El
coordinador (ZigBee Coordinator, ZC) controla la red y los caminos que deben seguir los dispositivos para
conectarse entre ellos, y debe existir uno por red. El router (ZigBee Router, ZR) interconecta dispositivos separados
en la topología de la red. El dispositivo final (ZigBee End Device, ZED) puede comunicarse con su nodo padre (el
coordinador o un router), pero no puede transmitir información destinada a otros dispositivos. Este último tipo de
nodo puede estar dormido la mayor parte del tiempo aumentando la vida media de sus baterías.
Página | 14
Análisis, diseño e
implementación
3.1. Plataformas previas
Las evoluciones sufridas en los últimos años por los estándares X73 y UNE-EN/ISO13606 y sus implicaciones, tanto en la
arquitectura funcional del sistema como en las reglas de diseño del modelo de comunicaciones y sus protocolos, han
requerido varias evoluciones de implementación de la plataforma telemática de integración de estándares desarrollada
en el proyecto upHealth.ES que se detallan en las siguientes fases (ver Figura 3.1):
Fase 1 (plataforma1.0-alfa) [10]. Primera solución end-to-end dividida en dos subsistemas: el subsistema de adquisición
que permite la conexión (vía RS-232 e IrDA) entre los dispositivos médicos y un elemento central (gateway) conforme a
X73PoC, y el subsistema de almacenamiento que soporta el intercambio de la información médica en un servidor de
HCE conforme a ENV13606. Se basó en lenguajes C/C++ y Java, y operaba sobre SO Linux (permitiendo simular la
consola Linux en computadoras con SO Windows mediante CYGWIN-POSIX/ GNU.GCC). La arquitectura X73PoC se basó
en elementos de servicio (Service Element) ACSE, ROSE y CMISE definidos en librerías ASN1.C (ASNX en X73) mediante
sintaxis abstracta (MDDL) y sintaxis de transferencia (MDER, BER, y PER).
Fase 2 (plataforma1.5-beta) [11]. Segunda solución end-to-end que mantiene los dos subsistemas, pero evoluciona de
X73PoC a X73PHD: independizando la capa de transporte (mediante un handler compatible con TCP/IP sobre USB y
Bluetooth), incluyendo envío de datos episódico (al anterior periódico) mediante un sistema de buffers para las PDUs
de cada capa de la pila, y optimizando el gateway hacia el concepto de CE sobre una nueva máquina de estados finita.
La arquitectura integra tanto X73PoC como X73PHD, manteniendo las estructuras ACSE, ROSE y CMISE, pero
flexibilizando la sintaxis MDER/BER/PER.
lenguaje
Linux
Windows
ASN.1c
ASNX
C/C++
Java
Windows
ASN.1c
ASNX
C/C++
Java
Windows
Mobile
ASN.1c
ASNX
C/C++
Java
tecnologías
diseño
desarrollo
IrDA
RS-232
prototipo
PCs
consola
cygwin
IrDA/RS-232
RJ-45
testbed
PCs
consola
Windows
USB
Bluetooth
demo
PDAs
GUI
Windows
estándares médicos
dispositivos médicos
características
técnicas
puntos
abiertos
X73PoC – ENV13606
tensiómetro - pulsioxímetro
- Entorno fijo
- Gateway (fijo)
- Diseño ad-hoc
(IrDA/RS-232)
- MDER/BER/PER
- ACSE/ROSE/CMISE
- 1ª Implementación
end-to-end
- SO Windows
- Entornos wireless
- Funcionalidades
Plug-and-Play
- Diseño profesional
- Interfaz usuario
- Inteligencia y
gestión remota
X73PoC/X73PHD – ENV13606
tensiómetro - pulsioxímetro
- Entorno personal
- Compute Engine(fijo)
- Diseño multiacceso
(handler transporte)
- MDER/BER/PER
- ACSE/ROSE/CMISE
- Funcionalidades
Plug-and-Play
- SO Windows ME
- PDA/SmartPhones
microcontroladores
- Diseño completo
- Perfil configuración
- Interfaz usuario
- Inteligencia y
gestión remota
plataforma 2.0-release
librerías
plataforma 1.5-beta
sistema
operativo
plataforma 1.0-alfa
versión plataforma
Fase 3 (plataforma2.0-release) [12]. Evolución actual que integra los dos subsistemas mediante un nuevo protocolo
extremo a extremo, incluye todas las evoluciones tanto de X73PHD como de UNE- EN/ISO 13606, incorpora un nuevo
entorno gráfico y, sobre todo, migra la implementación de MDs y CEs hacia dispositivos móviles (PDAs, SmartPhones).
La arquitectura completa se basa en X73PHD, se optimiza el código C++/Java sobre Windows, y se implementa la
comunicación Bluetooth optimizando las funcionalidades ubicuas (plug-and-play y hot-swap) para permitir su
aplicación a soluciones de e-Salud.
X73PHD – EN13606
tensiómetro - pulsioxímetro - báscula
- Entorno ubicuo
- CE mutitarea (móvil)
- Diseño interoperable
(Máquina Estados)
- MDER/XER
- SE optimizados
- Integración protocolo
E2E (ConfigProfile)
- Multiplataforma
- Microcontroladores
- Interfaz usuario
multiconfigurable
- Inteligencia y
gestión remota
- Pruebas clínicas
- Implantación real
Figura 3.1. Esquema de evolución de migraciones de la plataforma telemática de e-Salud
Todas estas implementaciones son la base de la actual plataforma upHealth.ES que se describe con mayor detalle en el
Anexo II de esta memoria.
Página | 15
3.2. Análisis y diseño. Arquitectura propuesta
En el anterior apartado se han descrito las diferentes plataformas desarrolladas en el proyecto upHealth.ES, un trabajo
que se ha ido realizando desde el año 2005 y que ha atesorado una gran experiencia e influencia en el desarrollo del
estándar de interoperabilidad X73. Sin embargo, a lo largo de estos años, se ha producido también un proceso de auto
crítica intentando detectar las limitaciones de las soluciones implementadas y, sobre todo, conocer qué líneas de
trabajo e investigación se deberían seguir en un futuro. Estos análisis se han realizado a todos los niveles, aunque este
documento únicamente se centrará en las líneas estratégicas tomadas a nivel técnico y la decisión final de crear una
nueva plataforma de desarrollo.
El primero de los pasos fue el análisis de fallos y limitaciones de las anteriores plataformas:
 Escalabilidad. Definida como la propiedad deseable de un sistema, una red o un proceso, que indica su habilidad
para extender el margen de operaciones sin perder calidad, o bien manejar el crecimiento continuo de trabajo de
manera fluida, o bien para estar preparado para hacerse más grande sin perder calidad en los servicios ofrecidos.
Las anteriores plataformas carecían de esta propiedad: intentar añadir nuevas funcionalidades a cualquiera de
ellas requería un proceso muy complicado de modificación del código.
 Modularidad. Definida como la capacidad que tiene un sistema de ser estudiado, visto o entendido como la unión
de varias partes que interactúan entre sí y que trabajan para alcanzar un objetivo común, realizando cada una de
ellas una tarea necesaria para la consecución de dicho objetivo. De nuevo, se carecía de esta propiedad. El código
se mezclaba de tal forma que era imposible separar la parte donde se realizaban tareas de comunicación y
procesado de la información de la parte gráfica.
 Portabilidad. Definida como la característica que posee un software para ejecutarse en diferentes plataformas. En
todas las plataformas desarrolladas el resultado final tenía como objetivo una pareja arquitectura-sistema
operativo muy clara, siendo necesario pequeñas y, en muchas ocasiones, grandes modificaciones para usar una
solución entre diferentes entornos.
 Mantenibilidad. Definida como la facilidad con la que un sistema o componente software puede ser modificado
para corregir fallos, mejorar su funcionamiento u otros atributos o adaptarse a cambios en el entorno. Ligada con
las anteriores características, era imposible corregir un fallo sin tener que rehacer prácticamente todo el código.
 Robustez. Definida como la capacidad de un software de reaccionar apropiadamente ante condiciones
excepcionales. Las plataformas realizaban el trabajo para el que estaban preparadas pero, si se realizaba cualquier
cambio en el flujo de trabajo, las aplicaciones podían fallar.
 Usabilidad. Definida como la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para
el usuario, en condiciones específicas de uso. Es algo que no se tuvo en cuenta en las anteriores plataformas.
 e-Accesibilidad. Definida como el grado en el que todas las personas pueden utilizar un objeto, visitar un lugar o
acceder a un servicio, independientemente de sus capacidades técnicas, cognitivas o físicas. Al igual que la
usabilidad, es otro concepto que no se tuvo en cuenta en las anteriores soluciones. No se tenía en cuenta las
posibles discapacidades del usuario.
Ante la ausencia parcial, y en ocasiones total, de las características descritas en las anteriores plataformas, el siguiente
paso era el diseño de una nueva solución que tuviera en cuenta todas estas cualidades del desarrollo de un nuevo
software. Para ello, el segundo de los pasos era realizar una adecuada elección del lenguaje de programación. La
elección de la plataforma o framework de desarrollo y lenguaje de programación que se utilizan en un proyecto de
estas características es un punto crítico que puede afectar a la evolución del software en un futuro. El primer paso en
esta elección es decidir si se opta por un lenguaje de alto nivel, como Java o C#, o por uno de bajo nivel, como C++.
Elegir un tipo u otro de lenguaje de programación tiene sus ventajas y sus inconvenientes. La elección de C++ supone
una serie de ventajas:
 Los compiladores de C++ generan código nativo con un alto grado de optimización en memoria y velocidad, lo que
lo convierte en uno de los lenguajes más eficientes.
 Es un lenguaje que puede considerarse de nivel intermedio, pudiéndose utilizar tanto para escribir software de
bajo nivel, como drivers y componentes de sistemas operativos, como para el desarrollo de aplicaciones.
 Posibilidad de utilizar la solución en dispositivos embebidos con mínimos cambios, pues la mayoría suelen ser
programados en C o C++.
Sin embargo, existen una serie de inconvenientes:
 Portabilidad. Aunque en ocasiones pequeños, casi siempre es necesario realizar cambios en el código cuando se
intenta portar una solución de una a otra plataforma.
Página | 16
 La facilidad de desarrollo cae en picado respecto a lenguajes de más alto nivel como los anteriormente
comentados: hay que conocer cómo se realiza la gestión de la memoria, punteros, etc.
 Aunque es un lenguaje con el que prácticamente puede desarrollarse cualquier tipo de aplicación, no es un
lenguaje “moderno” orientado a plataformas web, algo muy importante y necesario para la solución propuesta en
un futuro.
La comparativa entre los diferentes lenguajes de programación podría suponer páginas o incluso libros enteros, algo
que no es objetivo de esta memoria. La plataforma que se pretendía construir no requiere una gran eficiencia y
velocidad. Por el contrario, sí que es necesario en un entorno como el académico donde los proyectistas fin de carrera
o becarios tienen poca experiencia programando, un lenguaje de programación fácil de entender, intuitivo, moderno,
que permita realizar desarrollos de una forma ágil y sencilla. Se pretendía, además, llegar con el mismo código a
diferentes arquitecturas sin que sea necesario realizar cambios. Y sobre todo, el futuro de los servicios web que tendrán
una gran importancia a la hora de transmitir datos desde el manager a servidores remotos, marca una clara inclinación
hacia lenguajes como C# o Java. Sin embargo, no hay que olvidar C++. Este lenguaje de programación, aunque como ya
se ha comentado puede considerarse de nivel intermedio, se desmarca un poco de las características deseadas ya
descritas. La complejidad del código aumenta, aunque también lo hace la eficiencia. No tiene detrás unas plataformas
(o frameworks) de desarrollo tan intuitivos y orientados a la web como C# o Java. Por todo ello, se descarta como
lenguaje principal de desarrollo, aunque será necesario en los niveles bajos de la pila de protocolos para implementar
ciertas capas de comunicación, como en el caso del perfil médico Bluetooth HDP.
La decisión entonces está entre Java o C#. Las similitudes son muchas: orientación a objetos, independencia de la
plataforma, sintaxis muy similar, recolector de basura, entre otras. Existen por supuesto diferencias, aunque son muy
escasas. Por ejemplo, en C# incluso los tipos básicos (como int) son objetos, lo que lo hace un lenguaje todavía más
orientado a objetos. Otra gran diferencia es que C# es un estándar ECMA, mientras que Java no es un lenguaje
estándar. Java fue desarrollado por Sun Microsystems en los años 90 y no fue hasta mayo del 2007 cuando Sun liberó la
mayor parte de sus tecnologías Java bajo la licencia GNU GPL, de acuerdo con las especificaciones del Java Community
Process, de tal forma que prácticamente todo el Java de Sun es ahora software libre (aunque la biblioteca de clases de
Sun que se requiere para ejecutar los programas Java aún no lo es).
En el caso de Java, se compila el código fuente escrito para generar un código conocido como bytecode. Esta pieza está
“a medio camino” entre el código fuente y el código máquina que entiende el dispositivo destino. El bytecode es
ejecutado entonces en la máquina virtual (Java Virtual Machine, JVM), un programa escrito en código nativo de la
plataforma destino (que es el que entiende su hardware), que interpreta y ejecuta el código.
El caso de C# es muy similar al anterior aunque presenta algunas peculiaridades. El Common Language Runtime (CLR)
ejecuta una forma de código intermedio (bytecode) llamada Common Intermediate Language (CIL). El CLR actúa como
una máquina virtual, encargándose de ejecutar las aplicaciones diseñadas en C#. Es decir, cualquier plataforma para la
que exista una versión del CLR podrá ejecutar cualquier aplicación escrita en este lenguaje. Existen versiones del CLR
para la mayoría de las versiones de Windows (.NET): Windows 95, Windows 98, Windows ME, Windows NT 4.0,
Windows 2000, Windows XP y Windows CE (que puede ser usado en CPUs que no sean de la familia x86). Existen
también versiones del CLR para otros sistemas operativos como Linux o Mac OS (Mono). Asimismo, dado que la
arquitectura del CLR está totalmente abierta, es posible que en el futuro se diseñen versiones del mismo para otros
sistemas operativos.
El CLR, y esto es una diferencia muy sustancial respecto a Java, funciona también como integrador de lenguajes. Desde
cualquier lenguaje para el que exista un compilador que genere código para la plataforma .NET/Mono es posible utilizar
código generado para la misma usando cualquier otro lenguaje tal y como si de código escrito usando el primero se
tratase. La integración de lenguajes es tal que es posible escribir una clase en C# que herede de otra escrita en Visual
Basic.NET que, a su vez, herede de otra escrita en C++.NET. El CLR ha sido, desde sus primeras versiones más eficiente y
funcionalmente completo que la JVM de Java. En la JVM no hay soporte para técnicas tan útiles como los tipos
enumerados o el traspaso de parámetros por referencia (especialmente de los tipos de datos primitivos). Esto se paga
en velocidad de ejecución y en menor productividad, al tener el programador que tratar con un lenguaje menos
expresivo. Por último, destacar que el bytecode de Java muchas veces termina por ser interpretado, en cambio el
código intermedio de C# nunca se interpreta, sino que siempre se transforma en eficiente código nativo como se
observa en la Figura 3.2.
Página | 17
Código Fuente C#
Compilador
Código CIL (Bytecode)
CLR (Compilador JIT)
Código Nativo
Figura 3.2. Esquema de funcionamiento de C#
La decisión de optar por uno u otro lenguaje no es sencilla. Por ello, hay que buscar la diferencia más allá de lo que es el
lenguaje de programación. Ambos lenguajes tienen plataformas de desarrollo construidas alrededor de ellos que
facilitan la programación ágil de multitud de aplicaciones. Java, por ejemplo, se apoya en las siguientes plataformas:
 J2SE: Plataforma Java 2, Standard Edition. Kit de desarrollo de software que se utiliza para escribir applets y
aplicaciones con el lenguaje de programación Java
 J2EE: Plataforma Java 2, Enterprise Edition. Plataforma de para desarrollar y ejecutar software de aplicaciones en
Java con arquitectura de N niveles distribuida, basándose ampliamente en componentes de software modulares
ejecutándose sobre un servidor de aplicaciones
 J2ME: Plataforma Java 3, Micro Edition. Especificación de un subconjunto de la plataforma Java orientada a
proveer una colección certificada de Application Program Interfaces (API) de desarrollo de software para
dispositivos con recursos restringidos (PDAs, teléfonos móviles, etc.)
El caso de C# es algo más complicado. Al ser un estándar ECMA, no existe una única implementación, sino varias. Las
más conocidas son las de Microsoft, conocida como .NET, y Mono, implementación Open Source de .NET:
 NET. Desarrollada por Microsoft
o ASP.NET. Desarrollo web
o ADO.NET. Acceso datos
o .NET Compact. Desarrollo móvil (Windows Mobile)
 Mono. Implementación Open Source de .NET
o Moonlight. Implementación Open Source de Silverlight.
o MonoTouch. Posibilidad de utilizar C# para desarrollar en iPhone previo pago (versión Android en desarrollo).
o Incluye además librerías específicas de Mono: Posix, GTK, etc.
A la hora de analizar las soluciones que presentan ambos para el desarrollo de aplicaciones gráficas existen muchas
alternativas. Para Java:
 AWT. Librerías básicas de Java para la creación de interfaces gráficos
 Swing
 SWT
 JavaFX. Interfaces gráficos enriquecidos: Web, escritorio o móvil
Para C#:
 WinForms. Formularios Windows
 GTK#. Desarrollo de interfaces gráficos para Linux
 Windows Presentation Foundation (WPF). Interfaces gráficos enriquecidos. Web, escritorio o móvil. Incluye
Silverlight: subconjunto de WPF para crear aplicaciones estilo Flash y aplicaciones móviles
Si se analizan los entornos de desarrollo (Interface Development Environment, IDE), las diferencias tampoco son muy
críticas. Para Java, los principales IDEs son Eclipse (ver Figura 3.3) y Netbeans. Para C# existen Visual Studio de
Microsoft (ver Figura 3.4), SharpDevelop o MonoDevelop.
Página | 18
Figura 3.3. Entorno de desarrollo Eclipse
Figura 3.4. Entorno de desarrollo Visual Studio 2008
Como se ha comentado anteriormente, en ocasiones se necesitará usar lenguajes como C++ o C para acceder a
características del sistema operativo y construir librerías nativas a las que acceder a través de código. En este punto, el
acceso a librerías nativas, C# es mucho más rápido que Java. Este último necesita realizar una transformación de clases
y tipos, que se realiza mediante Java Native Interface (JNI) y que no es nada intuitiva. Mientras que el acceso a librerías
escritas en C++ o C desde C# es casi inmediato.
Y finalmente, se analiza el número de arquitecturas o plataformas a las que se podría llegar con uno u otro lenguaje.
Desarrollando la plataforma en Java, se podría usar en sistemas operativos como Windows, Linux o Mac Os. Podría
usarse también (quizás con algunos cambios mínimos) en dispositivos Android o móviles J2ME (ver Figura 3.5). Con C#
se puede acceder también a Windows, Linux o Mac Os. Con el mismo código se puede llegar a dispositivos Android en
un futuro no muy lejano, pues MonoTouch está siendo adaptado a estas plataformas. Además, los dispositivos con
Windows Mobile, los Zune (que todavía no han llegado a España) o Windows Phone 7 también serán accesibles.
MonoTouch dará la opción de llevar el código a móviles iPhone o la tablet de Apple: el iPad. La Xbox 360 también
admite aplicaciones desarrolladas en C#, aunque tendría que analizarse el nivel de acceso a los dispositivos que nos
ofrece este dispositivo (ver Figura 3.6).
Figura 3.5. Plataformas objetivo de Java
Figura 3.6. Plataformas objetivo de C#
Con todo lo expuesto, se analizaron los pros y los contras de cada uno de los lenguajes de programación y frameworks
de desarrollo y se tomó una decisión: la plataforma presentada en este TFM hace uso de C# como lenguaje de
programación y Mono, la implementación libre de C#, como plataforma de desarrollo multiplataforma
(Windows/Linux/Mac Os). Además, a este nuevo proyecto se le dio el nombre de uz.Health.
Página | 19
Diseño de la nueva arquitectura
Al igual que en los procesos de desarrollo de software empresarial donde se realiza una separación de la lógica de
negocios de la lógica de diseño, se pretendía construir una arquitectura basada en capas abstractas que definieran y
separaran claramente las diferentes funcionalidades de la solución (ver Figura 3.7). Con esta idea, se pretende que la
nueva solución, cumpla con las características definidas al comienzo de este capítulo. Esta arquitectura ofrece la
posibilidad de crear una o diferentes interfaces de usuario totalmente independientes del núcleo e incluso del lenguaje
de programación (con alguna capa de adaptación) lo que permitiría dotar al núcleo de capacidades de actualización
automática, sin necesidad de modificar el resto de capas. O incluso proporcionar conexión y desconexión de diferentes
tecnologías de transporte sin tener que modificar el núcleo de proceso principal, que en este caso sería X73-20601,
aunque se contempla que en un futuro se puedan introducir otros protocolos de comunicación como el antiguo
X73PoC, HL7, etc. En la Figura 3.8 se observa el diseño basado en capas de abstracción de la solución. Esta arquitectura
presenta tres capas principales:
 La capa tecnológica, donde se integrarán las tecnologías de transporte como Bluetooth, USB y ZigBee. Esta capa
presentará un interfaz homogéneo de comunicación hacia la capa superior a través de canales virtuales que
posteriormente se desarrollarán. Existirán casos excepcionales como Bluetooth donde en ocasiones es necesaria
la participación del usuario saltando la capa intermedia por ser innecesaria.
 La capa de comunicaciones que presenta los diferentes protocolos de comunicaciones como pueden ser X73PHD,
X73PoC o, en un futuro, otros como HL7 o protocolos propietarios.
 La capa de usuario donde se encuentra un interfaz gráfico web, o un interfaz gráfico de escritorio, o incluso otros
servicios de valor añadido al usuario.
Modelo Empresarial
Modelo Adaptado
Presentación
Usuario
Negocio
Protocolo de comunicaciones
Acceso a datos
Tecnologías de transporte
Base de datos
Figura 3.7. Modelo de separación en capas abstractas
Figura 3.8. Arquitectura de la solución según diseño basado en capas de abstracción
Página | 20
El núcleo central
En este tipo de arquitectura es crítico el diseño de la capa central, pues es el bloque que recibe los datos enviados por
uno o más sistemas agente y gestiona el proceso de comunicación para asegurar que el intercambio de datos sea de
acuerdo al protocolo elegido (en este caso el protocolo de intercambio de datos extendido X73-20601). A continuación,
se describe brevemente cómo se diseñó esta capa según la norma X73 pero teniendo presente que el diseño es
portable a cualquier otro protocolo de comunicaciones.
Todos los protocolos definidos por X73 utilizan sintaxis abstracta para facilitar la especificación de las estructuras de
datos sin hacer referencia a una tecnología de implementación concreta. ASN.1, junto con unas reglas de codificación
específicas de ASN.1, facilitan el intercambio de estructuras de datos describiendo esas estructuras de una forma que
es independiente de la arquitectura de la máquina y el lenguaje de implementación. La norma X73-20601 utiliza reglas
de codificación MDER optimizadas para ASN.1. MDER fue elaborada en X73-20101 para minimizar el ancho de banda
utilizado en las transferencias de datos médicos personales entre agentes y managers. La ausencia de
implementaciones open source de estas reglas de codificación motivó la utilización y modificación de BinaryNotes, un
framework ASN.1 para C#. Este framework presentaba las reglas de codificación más comunes como BER, PER o DER,
sin embargo MDER no era soportado y tuvo que implementarse un nuevo codificador y decodificador para reglas entre
dispositivos médicos. MDER es obligatorio tanto para agente como manager aunque los dispositivos pueden
opcionalmente establecer otras reglas de codificación como PER o XER. Este bloque central utiliza las librerías de
BinaryNotes para codificar las Applications Protocol Data Unit (APDUs) o tramas de datos, utilizando las reglas de
codificación anteriormente descritas además de las reglas MDER implementadas para este proyecto. La Figura 3.9
ilustra los componentes principales de la implementación:
 El Domain Information Model (DIM) constituye el núcleo principal de esta implementación. Este define un
conjunto de clases para modelar agentes según objetos que pueden contener fuentes de datos como señales
biológicas, eventos, informes de alertas, etc. Define así mismo su relación y los métodos que un manager puede
usar para controlar el comportamiento de un sistema agente.
 El modelo de servicio define el mecanismo de los servicios de intercambio de datos. Estos servicios están
mapeados en mensajes codificados usando ASN.1 que se intercambian agente y manager.
 Finalmente, el modelo de comunicación se ha implementado a través de una máquina de estados finitos FSM que
sincroniza los mensajes intercambiados en las conexiones punto a punto entre manager y agente.
Para mantener la independencia con la capa de transporte, se ha desarrollado un modelo abstracto de comunicación
basado en canales virtuales. Un canal virtual puede gestionar varios canales simultáneos al mismo tiempo en cada
conexión agente-manager. Además, cada uno de esos canales dentro de un canal virtual puede ser de una tecnología
diferente, como Bluetooth puerto serie (RFCOMM) o Bluetooth HDP. De esta forma se facilita un interfaz común de
comunicación al manager para enviar y recibir PDUs desde o hacia el sistema agente. Para facilitar las tareas de las
capas superiores, este núcleo central publica notificaciones sobre eventos internos recibidos desde los agentes además
de facilitar un interfaz para controlar el estado de los agentes conectados al manager. Las aplicaciones que usen este
núcleo central pueden suscribirse a eventos de la forma tradicional de C# pudiendo obtener notificaciones sobre
eventos genéricos en el manager como conexiones o desconexiones de un nuevo agente.
En un futuro cercano
Otro de los conceptos que se desean aplicar a este diseño en un futuro es el de arquitectura basada en plug-ins,
también conocidos como complementos o extensiones. Los plug-ins son módulos que se relacionan con una aplicación
para aportarle una función nueva y generalmente muy específica (ver Figura 3.10). Claro ejemplo de este tipo de
arquitectura es el navegador web de Mozilla Firefox, al que se le pueden ir añadiendo nuevas funcionalidades como
bloqueador de ventanas emergentes, gestor de descargas, mejora de gestión de pestañas, etc. Los complementos
permiten además:
 Que los desarrolladores externos colaboren con la aplicación principal extendiendo sus funciones
 Reducir el tamaño de la aplicación
 Separar el código fuente de la aplicación a causa de la incompatibilidad de las licencias de software
Página | 21
Sin embargo, también se pueden encontrar una serie de inconvenientes:
 Necesidad de un mayor control de errores
 Compromisos de seguridad.
 Incompatibilidades entre módulos
Este concepto de arquitectura es muy complejo, por ello es necesario la abstracción y estudio a fondo de toda la
solución. Se debe definir una interfaz de programación de aplicaciones (API) que permita a terceros crear
complementos que interactúen con el bloque principal propuesto. La necesidad de crear una API robusta hace que
aunque se tenga presente esta orientación a la hora del desarrollo, no se aplique de forma definitiva hasta bien
avanzado el desarrollo.
User Layer
DIM
Service Model
Communication Model
ISO/IEEE 11073-20601
BER
DER
PER
MDER
BinaryNotes Framework
Virtual Channel
HDP Channel
TCP Channel
RFCOMM Ch.
Figura 3.9. Arquitectura propuesta para el manager X73PHD
Figura 3.10. Esquema de conexión de módulos o plug-ins externos
Página | 22
3.3. Implementación
La implementación de la plataforma está pensada como si fuera un cubo de piezas donde cada usuario pueda construir
un manager o un agente pieza por pieza dándole un estilo personal si fuera necesario. Todas estas piezas se pueden
obtener de la librería principal (que se ha dado denominado UZ_ieee_11073, ver Figura 3.11). Esta librería,
desarrollada en C#, contiene todos los objetos necesarios para crear un manager compatible con X73PHD. Esta librería
depende únicamente de la librería BinaryNotes y es compatible con la versión 2.0 del framework .NET o superiores. De
esta forma, se asegura la total compatibilidad con la plataforma Mono. A continuación, se muestra en Figura 3.11 una
imagen de la solución UZ_ieee_11073 en el IDE de desarrollo Visual Studio 2010.
Figura 3.11. Solución propuesta UZ_ieee_11073 y lista de dependencias
BinaryNotes. Generando los objetos ASN.1
BinaryNotes es un framework ASN.1 completo Open Source para Java y para C# además de un compilador que
construye clases Java o C# a partir de un fichero de especificaciones ASN.1. Este framework contiene:
 Librería de codificación y decodificación. Esta librería implementa las reglas de codificación BER, PER y DER.
 BNCompiler. Compilador ASN.1 que puede ser ampliado y que es capaz de generar clases Java o C# a partir de un
fichero ASN.1 específico de entrada. Se pueden personalizar los ficheros generados cambiando las plantillas XSL o
creando plantillas propias.
 Colas de mensajes. Implementación de colas de mensajes de alto rendimiento basadas en codificación ASN.1
Sin embargo, BinaryNotes, como ya se comentó, no implementa las reglas de codificación MDER empleadas por
X73PHD para el intercambio de información. Para ello, ha sido necesario la modificación y creación de algunas clases
dentro del código de BinaryNotes. Las modificaciones de la librería se han realizado apoyándose en el documento de la
norma ISO/IEEE 11073-20101:2004 donde se define las reglas de codificación MDER y siguiendo el estilo de
programación del resto de clases de la librería BinaryNotes. En el documento de la norma se describen también tipos de
datos, atributos, objetos, etc. que utiliza el estándar X73PHD para representar datos. Toda esa información descrita en
formato ASN.1 debe ser traducida a objetos de C#. Para realizar esta tarea se utiliza el compilador BNCompiler. Los
pasos a seguir, así como todos los detalles del código de BinaryNotes, se describen en el Anexo III.
Librería UZ_ieee_11073
Con casi 4000 líneas de código, la librería UZ_ieee_11073.dll contiene el grueso de desarrollo de este TFM
implementando toda la arquitectura propuesta en el anterior capítulo. El proyecto se ha organizado intentando separar
las partes en las que se divide el estándar y todas aquellas clases de apoyo que tienen algo en común. A continuación se
describe el contenido y objetos de cada una de las carpetas. Los detalles de cada uno de estos módulos se detallan en
Anexo III.
Página | 23
 Config: Contiene las clases que gestionan la configuración de un dispositivo, como
tipo de codificación, versión de protocolo utilizada, etc.
 Core: Esta carpeta contiene los objetos a más alto nivel de la librería. Los objetos
agente y manager se construyen a partir de canales, objetos MDS, etc.
 Events: El núcleo X73PHD publica eventos para que otras clases u objetos los reciban
como nuevas medidas, conexiones y desconexiones de dispositivos. Esta carpeta
contiene las clases que se encargan del sistema de eventos de la implementación.
 Exceptions: No solo pueden generarse eventos sino también excepciones de muchos
tipos durante la ejecución del núcleo. En esta carpeta se encuentran los tipos de
excepciones utilizadas explícitamente para esta implementación.
 Gateway: Para comunicar el núcleo X73PHD con el mundo exterior en ocasiones se
necesita alguna capa de adaptación, contenida en esta carpeta.
 Logging: La implementación se ha construido utilizando un sistema de log de errores robusto, flexible y multi-hilo
permitiendo generar múltiples tipos de mensajes, ya sea por consola, mensajes remotos, etc.
 Part_10101: En esta carpeta se contiene en una única clase toda la nomenclatura del estándar.
 Part_104xx: Los dispositivos médicos se ven como especializaciones de X73PHD. En esta carpeta se contienen
todas las especializaciones soportadas por esta implementación. A día de hoy solo se soportan las
especializaciones 10408 (termómetro) y 10404 (pulsioxímetro). Sin embargo, gracias a la modularidad de la
solución, soportar más especializaciones es tan sencillo como crear una nueva clase similar a estas otras.
 Part_20601: Esta carpeta contiene el grueso de la implementación, máquina de estados finitos, canales, canales
virtuales, tipos de PDUs, etc.
 Utils: Esta carpeta contiene clases de apoyo al resto de clases para realizar operaciones determinadas u objetos
que no tienen una clasificación especial.
Se incluye de forma gráfica en la Figura 3.12 un esquema de implementación de la máquina de estados X73PHD:
Figura 3.12. Esquema de implementación de la máquina de estados X73PHD
Página | 24
3.4. Integración de Bluetooth HDP
Uno de los retos más importantes que afronta este TFM es la integración del perfil médico Bluetooth HDP en la nueva
plataforma. Los anteriores desarrollos de upHealth.ES hacían uso de TCP/IP o Bluetooth RFCOMM como tecnologías de
transporte por debajo de X73PHD. Por primera vez se utiliza el perfil médico Bluetooth HDP como tecnología de
transporte construyendo la primera solución totalmente compatible con el estándar X73PHD. Este logro se ha
conseguido en colaboración con la Universidad Juan Carlos I (especializada en estos últimos años en desarrollos a bajo
nivel de X73PHD) y en el contexto de la primera de las prácticas médicas realizadas en este TFM.
El perfil médico Bluetooth HDP en combinación con la especificación X73-20601 facilita un framework robusto y basado
en estándares que permite la interoperabilidad completa entre dispositivos de e-Salud sobre Bluetooth. Este nuevo
perfil médico Bluetooth HDP ha traído consigo el desarrollo de dos especificaciones en la pila de protocolos específicas
para dispositivos médicos como son MCAP y HDP. MCAP permite una conexión robusta incluyendo además soporte
para datos en streaming. El perfil Bluetooth HDP permite a los dispositivos agente (conocidos en Bluetooth como
source y asociados a tensiómetros, pulsioxímetros, etc.) intercambiar datos con los dispositivos manager (conocidos en
Bluetooth como sink y asociados a móviles, portátiles, SmartPhones, Tablet PCs específicos para e-Salud, etc.).
A día de hoy únicamente algunas pilas Bluetooth comerciales presentan compatibilidad con el nuevo perfil médico
Bluetooth HDP: Jungo BTware [13], diseñada para sistemas empotrados de bajo consumo; Stollmann BlueCode+ [14],
diseñada con una arquitectura independiente de la plataforma; Toshiba Bluetooth Stack [15], para Windows y
certificada por Continua; y Ethermind Bluetooth Stack [16], desarrollada por la empresa Mindtree para sistemas
empotrados y otras arquitecturas. Sin embargo, todas ellas se apartan del camino elegido por el proyecto upHealth.ES
pues se tratan de soluciones comerciales, cerradas, que no permiten evolucionar el desarrollo con nuevas
funcionalidades en un futuro y se alejan de los paradigmas de diseño que se quieren imponer en la nueva plataforma.
Desde la Universidad Juan Carlos I, en el año 2009, se inició el camino para integrar el nuevo perfil médico Bluetooth
HDP en la pila oficial BlueZ de Linux [17]. Esta iniciativa tenía como objetivo final la inclusión de HDP/MCAP en el núcleo
de Linux y de esta forma ofrecer las nuevas funcionalidades HDP a plataformas como Linux, Android o Meego. En la
Figura 3.13 se muestra un diagrama de bloques de la arquitectura BlueZ (en azul se muestran los bloques que no
estaban previamente implementados en BlueZ o que necesitaron ajustar parte de su código, como L2CAP):
 MCAP es un protocolo basado en L2CAP que facilita un mecanismo sencillo para manejar múltiples canales de
datos. Este protocolo soporta diferentes configuraciones de canal dependiendo de la aplicación o las necesidades
de la transmisión como por ejemplo los modos reliable o streaming.
 HDP es un perfil que simplifica el uso de MCAP y es el encargado de anunciar a otros dispositivos las
características soportadas así como los canales usados por cada perfil. Para estos anuncios hace uso del Service
Discovery Application Profile (SDP). De esta forma, los dispositivos pueden encontrar al manager y conectar con él
o viceversa, el manager puede iniciar una conexión a un dispositivo.
 DI especifica un método por el cual dispositivos Bluetooth comparten información que puede ser usada por otro
dispositivos para encontrar imágenes o software asociado, como por ejemplo controladores específicos. Toda esta
información también se publica en el registro SDP.
Health Device Profile (HDP)
GAP
MCAP
DI
SDP
L2CAP
Host Controller Interface (HCI)
Bluetooth Module
Figura 3.13. Pila de protocolos BlueZ
Página | 25
Implementando MCAP
La implementación de MCAP se ha realizado totalmente compatible con la especificación de Bluetooth SIG, soportando
todas las características obligatorias y algunas de las opcionales, como la re-conexión de canal. Como ya se ha
comentado, MCAP requiere los modos de streaming y retransmisión mejorada de L2CAP. Estos modos no existían al
comienzo del desarrollo del perfil Bluetooth HDP, se fueron construyendo paralelamente por otros miembros de BlueZ.
La arquitectura se diseñó para anunciar mediante callbacks, a las capas superiores, todos los eventos que ocurren
durante la ejecución del protocolo. Este diseño permite a la capa HDP recibir todos los eventos en tiempo real de forma
eficiente. Destacar que esta implementación de MCAP es multi-hilo por lo que, cuando se abre una sesión de MCAP, se
inicializa un nuevo hilo esperando nuevas conexiones. Este hilo controla todas las acciones que forman parte del
protocolo como conexión de nuevos canales de datos, desconexiones, re-conexiones, etc.
Implementando Bluetooth HDP
La implementación de Bluetooth HDP simplifica el uso de MCAP al usuario y registra toda la información necesaria en el
registro SDP. Aunque en la primera versión de la implementación se usaban también callbacks para notificar eventos al
usuario, la actual se ha re-escrito para adaptarse a las guías de estilo de BlueZ utilizando el sistema de mensajes de
sistema DBus. Esta implementación esconde por completo el mecanismo de control de los canales, facilitando un
modelo de abstracción basado en un servicio de notificación que notifica nuevos MCAP Communication Links (MCL)
tales como nuevos dispositivos remotos. Además, esta implementación gestiona la creación de nuevos canales de datos
y controla la correcta configuración de los mismos antes de ser notificados al usuario.
DBus
Antes de continuar con la integración de Bluetooth HDP en la plataforma, es imprescindible describir qué es DBus y
para qué es utilizado. DBus es un protocolo de comunicación entre procesos que emplea mensajes. Ha sido diseñado
para que sea ligero y fácilmente utilizado por cualquier programa. La arquitectura de DBus se compone de 2 partes
básicas: la librería libdbus, y un daemon que sirve como repetidor de los mensajes.
La librería libdbus crea conexiones o canales que conectan dos aplicaciones (ver Figura 3.14). Lo que hace es usar esa
única conexión para conectarse al daemon de DBus, que se comporta como un repetidor. De esta forma, todas las
aplicaciones que se conecten al daemon podrán contactar entre sí. La información se transmite en forma de mensajes
que los hay de dos tipos: métodos y señales. Los métodos sirven para decirle a un objeto que realice una operación.
Pueden requerir parámetros o no. Mientras, las señales sirven para notificar un suceso de interés general. DBus es
independiente del lenguaje que se use para acceder a él y hace que los objetos sean unas entidades no asociadas a
ningún lenguaje concreto. Como un objeto en DBus es una ruta, en DBus los objetos son direccionados a través de una
ruta que equivale a su nombre (un programa publica “objetos-rutas” (ObjectPath) a las que se puede acceder) y son
equivalentes a las que se emplean en el sistema de ficheros de Linux. Cada aplicación debe tener una ruta única y no es
complicado encontrar rutas como “/org/bluez/” ó “/org/freedesktop/DBus”.
A cada objeto le corresponden unos métodos. Estos métodos cambiarán el estado del objeto o nos permitirán recabar
información sobre él. Si se quiere ver métodos y señales en funcionamiento hay que ejecutar el comando dbus-monitor
en una consola de texto y ver cómo se suceden las acciones. Los interfaces son conjuntos de métodos con nombres
predefinidos y acciones acordadas que son conceptualmente cercanos. Un interfaz puede contener todo lo necesario
para reproducir música o buscar texto. Así, los interfaces pueden tener la misma ruta que los objetos y, para poder
diferenciarlos, se llegó al acuerdo de que los objetos tienen rutas con “/” como separador y los interfaces tienen rutas
con “.” como separador (por ejemplo, “/org/freedesktop/DBus” es un ruta y “org.freedesktop.DBus” es un interfaz).
Página | 26
Un programa que quiera trabajar con DBus debe seguir unos pasos. El primero consiste en conseguir un bus, un canal,
para comunicarse con el daemon de DBus. Si el daemon no está ejecutándose esto será imposible. Por tanto, hay que
asegurarse de que esté funcionando. Una vez que se tenga el bus se ha de conectar con el objeto. Para ello, se debe
usar su ruta. Sin embargo, este objeto no existe realmente: es un objeto DBus. Entonces, ¿cómo se puede trabajar con
él desde una aplicación? La solución a este problema consiste en emplear un objeto proxy o intermediario. Su misión
consiste en hacer de traductor o embajador del objeto DBus dentro de una sesión del programa. Este proxy es, en
realidad, una clase del lenguaje de programación que enmascara los detalles de la interacción con DBus. El proxy se
comporta como si fuese el objeto remoto, pero con sintaxis del lenguaje específico por lo que su uso será natural.
Todos los detalles de la implementación Bluetooth HDP utilizando DBus se incluyen en el Anexo III.
Void CreateApplication()
Dict GetProperties()
Call remote function
CreateApplication()
BlueZ
uz.Health
DBUS
Call remote function
GetProperties()
Bluetooth Gnome
Applet
Figura 3.14. Ejemplo de conexiones de DBus
Página | 27
3.5. Integración de servicios en la nube
Recordando la arquitectura de capas que se ha desarrollado para este TFM, en este apartado se analiza la capa superior
de usuario. Hasta ahora se ha descrito el núcleo de la plataforma, la capa de comunicaciones y en el anterior apartado
se analizó la integración del perfil médico Bluetooth HDP. Para esta última capa, esta plataforma propone una prueba
de concepto incluyendo servicios de valor añadido realizando un acercamiento al diseño en la nube. Además, aunque
no sea el objetivo prioritario de este TFM, se desarrolló un interfaz gráfico sencillo, que reúne todos estos servicios y
ofrece un acceso intuitivo a toda la plataforma de telemonitorización. Pero antes de presentar este desarrollo se
necesita entender qué es la nube.
La nube. Cloud computing
Son muchas las nuevas tendencias tecnológicas que están aparecido en el mercado en los últimos años, algunas de ellas
adoptadas de forma masiva y con mucho éxito como por ejemplo las redes sociales o de colaboración. Pero si hubiera
que destacar una de ellas, que ya hoy en día está comenzando a influir en el mundo de la empresa y que en un futuro
próximo será determinante en la forma de gestionar y hacer negocios, sería el cloud computing. El cloud computing ha
dado lugar a varias definiciones diferentes. Una comúnmente aceptada lo explica como un modelo de pago por uso que
permite un acceso cómodo y bajo demanda a un conjunto compartido de recursos informáticos configurable, como
redes, servidores, almacenamiento, aplicaciones y servicios, que se puede desplegar y utilizar de forma rápida y fácil. El
modelo de cloud computing ofrece cuatro tipos generales de servicios:
 Software como servicio: es el suministro de aplicaciones que se ofrece en una red y no precisa que los usuarios lo
instalen en sus propios ordenadores (ver Figura 3.15). Este es, sin duda, el servicio más frecuente en la nube.
 Infraestructura como servicio: es la disponibilidad de capacidad de almacenamiento, procesamiento y de red que
se factura según el consumo (ver Figura 3.16).
 Plataforma como servicio: se refiere a un entorno de desarrollo y herramientas y servicios asociados que se
ofrece a los clientes para crear sus propias aplicaciones (ver Figura 3.17).
 Proceso como servicio: es la extensión lógica del software como servicio, el suministro total de un proceso, como
los efectos a cobrar, en la nube.
Figura 3.15. Modelo de cloud computing según un esquema “software como servicio”
Página | 28
Figura 3.16. Modelo de cloud computing según un esquema “infraestructura como servicio”
Figura 3.17. Modelo de cloud computing según un esquema “plataforma como servicio”
Página | 29
En este contexto, es importante destacar qué niveles de valor ofrece el cloud computing:
 Nivel de utilidad. Menores costes y mayores niveles de servicio a través de recursos informáticos elásticos y
modelos de pago por uso.
 Nivel de transformación de procesos. Mejor integración y colaboración de los procesos de negocio aprovechando
los activos comunes en la nube.
 Nivel de innovación. Nuevos modelos de negocio y ecosistemas a través de vincular, compartir y combinar
recursos entre empresas que utilizan los activos escalables del cloud computing.
En este caso centrado en e-Salud, un ejemplo de los beneficios que se podrían obtener utilizando cloud computing sería
la capacidad para acceder a aplicaciones de gestión de datos y data mining en una plataforma abierta que conecte a las
compañías farmacéuticas y otras instituciones dedicadas a la investigación. En definitiva, una mayor disponibilidad de
herramientas de colaboración de seguridad, gestión de datos, diagnóstico de datos y análisis. El impacto estimado por
el Boston Consulting Group [18] sería de un ahorro de hasta 400 millones de dólares por fármaco y un aumento del 30%
en la rapidez de los ensayos. Los beneficios de cloud computing no solo son económicos. En un país como la India en el
cual el 72,2% de la población reside en zonas rurales y pueblos, cloud computing puede resolver los problemas de
infraestructuras permitiendo que esas zonas con un desarrollo menor puedan disfrutar de servicios de e-Salud sin
contar con equipos especializados [19]. Alguna aplicación que tendría cloud computing en estos escenarios sería:
 Base de datos de registro nacional de doctores. Existen muy pocos doctores y de esta forma sería posibile
localizarlos y consultarlos mediante telemedicina.
 Almacenamiento de imágenes. La interoperabilidad reduciría los costes drásticamente.
 Análisis farmaceúticos. Utilizando cientos de servidores de alta velocidad en la nube, el análisis llevaría un menor
tiempo de procesado.
 Bio-vigilancia. Localización temprana de enfermedades. Sería más sencillo lanzar programas de salud para areas
específicas.
Las tendencias englobadas en el concepto de cloud computing se fundamentan en mantener una confianza sobre el
proveedor con el que se contratan los servicios. Esta confianza es considerada por diferentes sectores críticos (como el
de la salud) como un grave problema, puesto que en ningún momento existe la absoluta certeza de qué sucede con la
información, y se asume un riesgo “considerable” al no tener un completo control sobre los datos. El usuario se ve
obligado a hacer un acto de fe y depositar su confianza en aquellos proveedores que considera fiables y seguros
(empresas ampliamente consolidadas como Microsoft, Google, Amazon, etc.). En definitiva, la pérdida de control de la
información es el riesgo principal, pero también existen claros beneficios como la ubicuidad de las soluciones y la
posibilidad de trabajar con recursos remotos de forma eficiente. Desde el punto de vista de las aplicaciones móviles,
este concepto puede facilitar el desarrollo de aplicaciones multiplataforma, reduciendo los tiempos de desarrollo y
aumentando la diversidad.
Diseño en la nube
Este TFM no pretende diseñar una solución que cumpla todos los paradigmas del diseño en la nube pues es una tarea
muy compleja y que requiere de infraestructuras muy potentes y bien distribuidas, únicamente propone una primera
aproximación, una aplicación inicial del concepto de la nube a uno de los servicios de telemedicina como es la
telemonitorización de pacientes.
En este caso, el modelo que mejor se adapta a los intereses del proyecto dentro de los que propone cloud computing es
el de “software como servicio” (SaaS, Software as a Service). Este modelo de distribución de software proporciona a los
clientes el acceso a aplicaciones a través de internet. El software se suministra como servicio, de manera que el usuario
no tiene que preocuparse del mantenimiento de dichas aplicaciones. Para el usuario, este modelo permite optimizar
costes y recursos. Para el suministrador (el centro de salud, hospital…), este modelo permite implementar economías
de escala optimizando costes. Para ello, este proyecto utiliza Google Apps (ver Figura 3.18) para ofrecer servicios de
valor añadido como alertas, calendario de eventos, recordatorio de tareas o mensajería de apoyo. Google Apps es un
servicio de aplicaciones en la nube que ofrece multitud de soluciones para usuarios y empresas para tareas como
correo electrónico (Gmail), mensajería instantánea (Google Talk), calendario (Calendar), documentos compartidos
(Google Docs), gestión de información médica (Google Healht), etc. Algunas de estas aplicaciones se han integrado en la
implementación de la plataforma como se presentará más adelante.
Página | 30
Figura 3.18. Esquema del servicio de aplicaciones de Google Apps
La tenencia natural de las mayores compañías tecnológicas del mundo es mover todas sus soluciones hacia la nube, que
todo se encuentre en la web, incluso los datos, y que los usuarios accedan a todos los servicios a través de un
navegador web o software similar. Este tipo de solución es, a día de hoy, muy dificil de conseguir en la
telemonitorización de pacientes. Así, los pacientes deben utilizar un dispositivo médico para realizar las medidas de las
diferentes señales biomédicas. Esta información se comunica a un manager que gestiona la información para enviarla a
un centro de salud u otro servicio de telemonitorización. Por lo tanto, esa aplicación o proceso manager debe tener
acceso al hardware para poder recibir la información ya sea a través de USB, Bluetooth, ZigBee o cualquier otra
tecnología de transporte. Sin embargo, este acceso a bajo nivel no puede conseguirse desde un navegador web de
forma estándar para cualquier tipo de dispositivo. Android tiene su propia tecnología implementada en su navegador
web para acceder al hardware de los dispositivos. En otras plataformas esto es más complejo. Existen diferentes
propuestas de los diferentes navegadores web para conseguir ese tipo de acceso, pero no existe un consenso de todas
las partes y tampoco será facil llegar a él pues el acceso al equipo del usuario desde la web siempre ha estado muy
controlado.
Como una solución totalmente en la nube se presume muy compleja o imposible (al menos a día de hoy), el
acercamiento propuesto en este TFM consiste en ofrecer diferentes servicios de valor añadido dejando el proceso de
captura de señales biomédicas en manos de la aplicación manager en el equipo o dispositivo del paciente. Antes de
describir los servicios de valor añadido que la solución propone, es importante definir el concepto de Config Profile que
se ha utilizado en este TFM.
Config profile
El diseño del Config Profile ha sido un elemento clave en estudios previos [20]. Este archivo contiene toda la
información asociada a los procedimientos que deben seguir los pacientes que gestiona un mismo manager CE. En la
Figura 3.19 se muestra el concepto del Config Profile en el contexto de la plataforma de telemonitorización.
Agentes
Manager
x73
datos
x73
Config
Profile
Dispositivos Médicos
Compute Engine
idCE
Otra
info
Red
+
Datos de
paciente
Config
Profile
Servidor de Gestión
Base de
Datos
Datos de
paciente
Servidor de HCE
Figura 3.19. Situación y función del Config Profile en la plataforma de telemonitorización
Página | 31
Este elemento Config Profile es generado en el servidor de gestión (Management Server, MS). La información que
contiene procede de una base de datos que es completada a partir de dos fuentes de información distintas. Por un lado
se obtienen los datos necesarios de la HCE de cada paciente y, por otro lado, se introduce información adicional al caso
de uso de cada paciente manualmente. Una vez completa la información que debe contener el Config Profile se genera
un archivo XML que es el que se envía a CE para que el proceso de monitorización sea correcto. La información
necesaria para rellenar el Config Profile estaría contenida en una base de datos que almacenaría datos como
información genérica relativa a dispositivos médicos, registro de los CEs que se están utilizando para llevar a cabo la
monitorización de pacientes, información sobre los pacientes que están siendo controlados, médicos o enfermeros que
están realizando el seguimiento de pacientes, medidas realizadas, etc. En este TFM se ofrece una nueva perspectiva
para el Config Profile ya que, dada la complejidad que requiere el diseño, desarrollo e implementación de un servidor
de gestión que ofrezca seguridad y genere un Config Profile de forma eficiente, el objetivo de este TFM es trasladar
parte de esa información a la nube (especialmente las tareas a realizar por cada usuario), sirviendo como prueba de
concepto para un futuro donde toda la información sea almacenada de forma distribuida. El concepto del anterior
Config Profile, así como los detalles técnicos de su implementación y un ejemplo de funcionamiento además del
concepto del nuevo Config Profile puede verse en el Anexo III.
Flujo de ejecución
El nuevo concepto de Config Profile (ver Anexo III) utiliza Google Calendar para presentar eventos y tareas al usuario
pero, antes de conocer cómo ayudan al usuario el resto de servicios, es útil conocer el flujo de ejecución de los servicios
en nuestra plataforma que se representa gráficamente en la Figura 3.20:
Paso 1. Manager à Servidor telemonitorización
El usuario introduce su DNI o DNIe. Esta información viaja cifrada al servidor de telemonitorización. Y este le
devuelve un Config Profile con información básica.
Número de DNI + Clave ó
Información del DNIe
Config Profile
Conf
ig
Profil
e
Paso 2. Manager à Google Apps
En la información del Config Profile se transporta los datos necesarios para loguearse en los diferentes servicios
de Google Apps. Cada servicio devuelve el estado del login de forma separada.
Nombre de usuario de
Google Apps + Clave
Gmail in?
Gtalk in?
Calendar in?
Página | 32
Paso 3. Manager à Se Google Apps
Una vez se ha logueado correctamente en los servicios de Google, se procede a obtener la información de cada
uno de ellos de forma paralela.
Solicita correos de Gmail
Correos de usuario
Solicita los contactos disponibles para conversación
Contactos
Solicita tareas y eventos
Tareas y eventos
Paso 4. Usuario utiliza servicios
El usuario puede comenzar a utilizar los servicios: mandar y recibir correos, contactar mediante chat con
doctores y otros pacientes o consultar tareas y eventos en su calendario personal
Paso 4bis. El doctor utiliza servicios
Por otra parte, el doctor puede modificar eventos o tareas a realizar por el usuario que automáticamente se le
e
mostraran en su dispositivo, o enviar correos o recibir la consulta del paciente
Paso 5. Manager à Servidor telemonitorización
El usuario decide realizar una tarea de medida del calendario propuesto por su médico o realiza una medida
manual no prevista. Envia la información al servidor de telemonitorización.
Datos XML (TCP/IP)
X73
Confirmación datos recibidos
Figura 3.20. Flujo de ejecución de la plataforma
Página | 33
3.6. Integración con el servidor de HCE
Este TFM presenta el desarrollo de una plataforma de telemonitorización de pacientes sobre sistema operativo Linux y
que integra las normas de interoperabilidad X73PHD y UNE-EN/ISO13606. Es una solución estándar y ubicua para
entornos de salud personal que utiliza Bluetooth HDP para la comunicación entre los dispositivos médicos y el manager
X73PHD. Además, se homogeneíza la comunicación de área extendida (Wide Area Network, WAN) con el servidor de
HCE mediante tecnologías Web Services (WS) y comunicación interoperable según XML (ver Figura 3.21).
En las secciones anteriores se ha definido y analizado X73PHD como el estándar internacional para interoperabilidad de
dispositivos médicos. Este es el primer paso para llegar a una plataforma totalmente interoperable. No obstante, para
lograr niveles óptimos en la calidad asistencial y continuidad de cuidado de un paciente, es necesario que las partes
implicadas en el seguimiento/control de su enfermedad interactúen también de forma interoperable. El estándar
internacional para lograr interoperabilidad de HCE [21] entre sistemas sanitarios es UNE-EN/ISO13606 [22]. Esta norma
especifica cómo la información clínica debe ser transmitida basándose en un modelo dual: Modelo de Referencia y
Modelo de Arquetipos. Sin embargo, como ya se ha comentado a lo largo de este proyecto, la existencia de normas
médicas no garantiza la correcta implementación de una solución homogénea de salud personal dado que la
integración de las diferentes normas en soluciones extremo a extremo todavía sigue siendo una tarea compleja e
intrincada. Este es uno de los principales retos en la investigación de estándares: su posterior implementación, en
forma de soluciones reales, en el sistema sanitario. Algunas contribuciones anteriores han diseñado implementaciones
aisladas tanto de una plataforma de monitorización de pacientes basadas en X73 [23] como de un servidor de HCE
basado en UNE-EN/ISO13606 [24]. Estos desarrollos previos, si bien han servido como prueba de concepto del correcto
funcionamiento de ambas normas, también han constatado una ausencia de interoperabilidad en la comunicación
extremo a extremo. Algunas otras iniciativas como IHE y Continua o proyectos como Healthy Interoperability [25] ya
han abordado este problema. Sin embargo, hacen uso de mensajes HL7 y no del estándar europeo UNE-EN/ISO13606.
Interfaz PAN
(Bluetooth)
Dispositivos médicos
(Agentes X73PHD)
Interfaz WAN
(XML)
Computer Engine
(Manager X73PHD)
Servidor HCE
(ISO/EN13606)
Figura 3.21. Esquema conceptual de la plataforma de telemonitorización basada en estándares extremo a extremo
Así, X73PHD cubre la comunicación en el interfaz PAN y UNE-EN/ISO13606 define el intercambio interoperable de HCE.
Pero, hasta el momento, no se ha definido un estándar específico para el interfaz WAN entre el manager y el servidor
de HCE. Sin embargo, se han propuesto algunas iniciativas (lideradas por IHE y Continua Health Alliance) para suplir en
parte esta carencia. El Comité Técnico IHE-Patient Care Device (IHE-PCD) ha propuesto el perfil Device to Enterprise
Communication (DEC, llamado PCD-01) [26]. Este perfil emplea mensajes HL7 v2.6 para conectar el manager y el
servidor HCE. El perfil Subscribe to Patient Data (llamado PCD-02) [27] es una extensión de este perfil que divide este
interfaz para filtrar los datos generados en el entorno de e-Salud. Dentro de las directrices de Continua Health Alliance,
este interfaz se ha dividido en dos subinterfaces, incluyendo un nuevo elemento dirigido a servicios de back-end. El
primer subinterfaz está fuera del alcance de las denominadas guías de diseño (Continua Design Guidelines). Para el
segundo subinterfaz, se ha elegido el perfil IHE Cross-Enterprise Document Reliable Interchange (XDR) [28] y, sobre este,
el documento HL7 Personal Health Monitoring (PHM) [29].
Página | 34
Estas propuestas de IHE y Continua Health Alliance no implican la definición de nuevos estándares ad-hoc. Al contrario,
impulsan algunos perfiles y procedimientos de otros estándares, esencialmente HL7 (IHE-DEC impulsa mensajes HL7
v2.6 y Continua Health Alliance hace uso del perfil HL7-PHM). Debido a que la implementación propuesta está basada
en X73PHD y UNE-EN/ISO13606, estos enfoques basados en HL7 no es la opción más adecuada. Además, el detalle y
complejidad de HL7 ha llevado al diseño de una arquitectura WS apoyada por propuesta basada en XML. Este
documento XML satisface los particulares requerimientos de las implementaciones X73PHD y UNE-EN/ISO13606
previamente detalladas con elevada especificidad para mantener los requisitos de interoperabilidad, seguridad,
fiabilidad y privacidad al mismo tiempo que la simplicidad de aplicación. Un ejemplo de este XML se muestra a
continuación:
<collecter>
<idCollecter>12345678</idCollecter>
<soc>
<deviceInfo>
<extraDeviceInfo>
<attribute>
<id>MDC_ATTR_SYS_ID</id>
<value>123456</value>
</attribute>
<attribute>
<id>MDC_ATTR_ID_TYPE</id>
<value>MDC_MASS_BODY_ACTUAL</value>
</attribute>
<attribute>
<id>MDC_ATTR_VAL_BATT_CHARGE</id>
<value>60</value>
</attribute>
<attribute>
<id>MDC_ATTR_ID_MODEL</id>
<value>DeviceManufacturer</value>
<value>DeviceModel</value>
</attribute>
</extraDeviceInfo>
</deviceInfo>
<measurement>
<timeStamp>15/04/2010-18:10:15</timeStamp>
<attribute>
<id>MDC_ATTR_ID_TYPE</id>
<value>MDC_MASS_BODY_ACTUAL</value>
</attribute>
<attribute>
<id>MDC_ATTR_NU_VAL_OBS_SIMP</id>
<value>53.5</value>
</attribute>
<attribute>
<id>MDC_ATTR_UNIT_CODE</id>
<value>MDC_DIM_KILO_G</value>
</attribute>
</measurement>
<contextInfo>
<code/>
<value/>
</contextInfo>
</soc>
</collecter>
Desde el punto de vista del manager, el XML diseñado tiene en cuenta los datos disponibles que son relevantes para su
incorporación en la HCE para algunas especializaciones de dispositivos médicos, manteniendo una nomenclatura
homogénea. Desde el punto de vista del servidor de HCE, se incluye la información necesaria para integrar los datos en
la arquitectura UNE-EN/ISO13606. El contenido y estructura XML depende del fichero de configuración Config Profile
(explicado en la sección anterior), obtenido del servidor de HCE, y configurado en colaboración con especialistas
médicos y a partir de análisis previos de casos de uso [30]. Así, como se muestra en el ejemplo, el XML incluye
información específica de los pacientes (idCollecter), sus dispositivos asociados (deviceInfo), el procedimiento de
medida (timeStamp), y otra información técnica como tipo de dispositivo (mdc_ attr_id_type), modelo
(mdc_attr_id_model), niveles de batería (mdc_attr_val_batt_charge), etc.
Página | 35
3.7. Integración con el nivel de aplicación
Finalmente, la implementación de la plataforma uz.Health se completa con el desarrollo de un interfaz gráfico sencillo,
que permite al usuario utilizar todos los componentes y procesos descritos a lo largo del capítulo. Es imprescindible
aclarar que este interfaz se ha construido únicamente a modo demostración y se encuentra en fase de mejora y
optimización para incluir funcionalidades usabilidad, robustez y e-accesibilidad. El interfaz gráfico ha sido desarrollado
en GTK# y Mono y su utilización está orientada a plataformas Linux aunque la portabilidad a entornos Windows es casi
inmediata. En el Anexo III se describe con detalle el interfaz gráfico propuesto por este TFM.
En la Figura 3.22 se observa la pantalla principal del usuario, conocida como home. En ella se presentan las opciones
más habituales para el usuario. A la izquierda aparece la zona de notificaciones donde se avisará al usuario si tiene
algún correo electrónico, alguna tarea pendiente o un mensaje de chat. Debajo los botones para poder contactar con el
centro de salud, consultar la HCE o realizar una medida manual que no esté planificada. En pestañas se distribuyen los
servicios de usuario: tareas y eventos, correo, mensajes instantáneos y los contactos.
Figura 3.22. Pantalla principal de la plataforma uz.Health
Página | 36
Proceso de medida
La pantalla de medida manual propone realizar la medida siguiendo 4 pasos:
1. Seleccionar el tipo de dispositivo
2. Seleccionar el protocolo de comunicaciones del dispositivo
3. Seleccionar la tecnología de transporte usada por el dispositivo
4. En caso de que sea necesario, configurar los parámetros de la tecnología de transporte.
A continuación, se muestra un ejemplo de la medida con un pulsioxímetro X73PHD mediante Bluetooth HDP. En este
caso se ha seleccionado el adaptador Bluetooth y el dispositivo médico que se va a utilizar (ver Figura 3.23).
Finalmente, en la última pantalla se observa el proceso de medida (ver Figura 3.24). A la derecha, a modo de
depuración, se ha colocado un analizador de protocolo pudiendo observar los diferentes estados por los que pasa el
núcleo de comunicaciones. Una vez realizada la medida, haciendo clic en el botón “Enviar Medida” enviará la medida al
servidor de telemonitorización mediante el XML generado siguiendo la descripción del apartado 3.4 de esta memoria.
Si se inicia la medida desde la pestaña de “tareas y eventos” se llega directamente a esta pantalla ya que la
configuración del dispositivo es obtenida desde la propia tarea.
Figura 3.23. Pantalla de configuración de la medida
Página | 37
Figura 3.24. Pantalla de resultados de la medida
Página | 38
Evaluación y resultados
4.1. Evaluación de la implementación
En cualquier proyecto que contenga una parte de implementación, la necesidad de corroborar el correcto
comportamiento se convierte en imperiosa. En nuestro caso, tras la implementación se ha realizado un proceso de
depuración realizando pruebas tanto de “caja negra” como de “caja blanca” para asegurarnos del correcto
comportamiento de la aplicación implementada. La prueba de caja negra trata el software como una caja sin ninguna
comprensión del comportamiento interno. Esto ayuda a probar la funcionalidad de acuerdo a una serie de
requerimientos [31]. Así, la prueba introduce datos y únicamente ve la salida del objeto testeado. Este nivel de prueba
requiere por lo general definir perfectamente los casos de uso que se van a utilizar de tal forma que el probador
simplemente verificará la salida o comportamiento para una determinada entrada. La prueba de caja blanca, sin
embargo, se da cuando el probador tiene acceso a las estructuras de datos internas, código y algoritmos. Los métodos
de prueba de caja blanca incluyen pruebas creadas para satisfacer un criterio de cobertura del código. Por ejemplo, el
diseñador de las pruebas puede crear tests para causar que todos los métodos del programa sean ejecutados al menos
una vez. Este tipo de métodos puede ser utilizado también para evaluar la integridad de una prueba realizada con
métodos de caja negra. Esto permite al equipo de desarrollo examinar partes de un sistema que son raramente
probadas y asegura que los puntos más importantes han sido probados.
Evaluando el núcleo X73PHD
Las primeras pruebas que se realizaron sobre la plataforma fueron para analizar y corroborar el correcto
funcionamiento del núcleo X73PHD. Se crearon pruebas unitarias para probar cada uno de los módulos de la solución.
También se realizó un test de integración para exponer los defectos en los diferentes interfaces y la interacción entre
los diferentes módulos o componentes. Los test de integración van en progresión, comenzando con pequeños grupos
de componentes y creciendo hasta probar la integración de todos los componentes funcionando como un sistema
completo. Además de los test unitarios, se desarrolló un emulador de agente X73PHD funcionando sobre TCP/IP. Se
utilizaron diferentes especializaciones para comprobar el correcto funcionamiento del manager X73PHD:
 11073 - 10404 Pulse oximeter
 11073 - 10406 Heart rate monitor
 11073 - 10407 Blood pressure monitor
 11073 - 10408 Thermometer
 11073 - 10415 Weighing scale
 11073 - 10417 Glucose meter
En la Figura 4.1 se muestra una imagen del emulador de agente X73PHD simulando un termómetro X73PHD:
Figura 4.1. Emulador de agente X73 funcionando como termómetro
Página | 39
Para la evaluación se construyó un manager X73PHD básico en línea de comandos que funciona tanto en Linux como
Windows. Inicialmente se inicializa un canal TCP que escucha en el puerto 9999 del equipo las conexiones entrantes
que le pueden llegar desde un agente. En este momento, ambos dispositivos se encuentran en estado Unassociated. A
partir de aquí, comenzará el envío y recepción de tramas, empezando por una petición de asociación del agente al
manager (AssociationRequest). Se pasará entonces al estado de Associating. A continuación, el manager responderá a
la petición de asociación con un mensaje del tipo AssociationResponse, en el cuál informará de si la petición ha sido
aceptada, rechazada, o si necesita más datos de configuración para aceptarla, algo que ocurrirá siempre que el agente
no haya sido registrado previamente en el manager, es decir, que no se hayan asociado en anteriores ocasiones. Para
saber cuál ha sido la respuesta del manager, éste envía un código de asociación (AssociateResult), que permitirá
distinguir al agente entre los diferentes casos. La petición de asociación puede ser o no aceptada o ser aceptada pero
no conocer la configuración del agente, por lo que el agente deberá enviar un ConfigReport con sus parámetros de
configuración, pasando al estado Configuring. Una vez enviada la configuración, el agente esperará la confirmación de
ésta por parte del manager, que vendrá dada, al igual que ocurría con la petición de asociación, por un código
denominado ConfigResponse. Si el manager acepta la configuración del agente y ambos pasarán al estado Operating.
Llegados a este punto, ambos dispositivos se encuentran ya asociados y se podrá iniciar la transferencia de las medidas
tomadas por el agente. El agente mandará entonces un DataReport que contendrá los datos de la medida (el dato
médico y la fecha y la hora) y esperará, al igual que en casos anteriores, a que el manager confirme la recepción de los
datos enviado. Finalmente, la comunicación termina a través de una petición de desasociación por parte del agente
(AssociationReleaseRequest), y de la consiguiente confirmación del manager (AssociationReleaseResponse). Para ello,
el agente únicamente deberá indicar el motivo de la finalización. Todo este proceso de toma de medida se puede
observar en la Figura 4.2, la salida por la salida estándar del manager X73PHD.
Un reto importante llegado este punto, consiste en comprobar que la plataforma desarrollada es absolutamente
compatible con otras plataformas desarrolladas en lenguajes de programación diferentes para asegurar la
interoperabilidad de la solución. Paralelamente a este TFM, se desarrolló otra plataforma X73PHD basada en el trabajo
de Morfeo openHealth sobre Android. Una prueba importante sería comunicar las dos implementaciones (manager de
uz.Health con agente Android, ver Figura 4.3). Esta prueba resultó con un éxito y se muestra un log en Figura 4.3.
Figura 4.2. Eventos del proceso de toma de medida
Figura 4.3. Salida de depuración del agente X73PHD Android e interfaz gráfico
Página | 40
Evaluando la implementación de Bluetooth HDP
Una práctica muy común es que las pruebas y evaluación de un software sean realizadas por un equipo o un
desarrollador diferente al que ha realizado la implementación. De esta forma se asegura que el equipo probador no
tenga vicios adquiridos por el desarrollador y pruebe cosas diferentes. Intentando cumplir estas premisas, durante la
redacción de este TFM se realizó una estancia de investigación en Viena en la universidad de ciencias aplicadas
Fachhochschule Technikum Wien colaborando con el grupo de investigación Healthy Interoperability. Esta
colaboración, además de otras muchas cosas, tenía como objetivo realizar tests cruzados de las plataformas de
telemonitorización de ambas universidades. Estas pruebas realizadas se trataron de pruebas de caja blanca
entregándole al equipo de Viena la aplicación manager descrita en anteriores capítulos. Para las pruebas se utilizó uno
de los pocos dispositivos certificados por Continua, el tensiómetro A&D Medical UA-767PBT-C Blood Pressure Monitor.
Se realizaron diferentes pruebas entre los miembros del equipo de Viena obteniendo un alto porcentaje de éxito en la
obtención de las medidas. Los errores que se obtuvieron fueron debidos al estado experimental en el que todavía se
encuentra la implementación del perfil Bluetooth HDP en la pila BlueZ de Linux. Durante la depuración de estos errores
se observó que la fuente de fallo eran los bloqueos (no muy frecuentes) de la capa L2CAP del kernel que esperan
resolverse con futuras actualizaciones del kernel de Linux. Como sistema operativo para las pruebas se utilizó Ubuntu
10.10. En la Figura 4.4 se observa la medida obtenida por la aplicación uz.Health y la entregada por el tensiómetro
A&D.
Figura 4.4. Medida realizada con el tensiómetro A&D Medical UA-767PBT-C Blood Pressure Monitor
Página | 41
4.2. Proyecto WiSo
La última parte de las prácticas médicas de este TFM se realizó, aprovechando la estancia de investigación, en Viena, en
colaboración con el grupo Healthy Interoperabilty (miembro de Continua) de la universidad de ciencias aplicadas
Technikum Wien. El proyecto Wiener Sozialdienste (WiSo) [32] se trata de una ambiciosa iniciativa a partir de la cual se
pretende crear una red de telemedicina en hogares y residencias de ancianos y enfermos crónicos o con algún tipo de
discapacidad. Se trata de una prueba piloto impulsada por los servicios sociales y de asistencia de Viena. A través de
este proyecto, el grupo Healthy Interoperabilty distribuye dispositivos de medida como tensiómetros, pesos o
pulsioxímetros compatibles con X73. Junto a los dispositivos, se facilita la plataforma de telemedicina desarrollada por
este grupo de investigación de Viena y en la que se ha colaborado en las pruebas durante los meses de estancia. Esta
plataforma está desarrollada en Java sobre Windows. Aunque el grupo es miembro de Continua y tiene acceso a las
librerías de desarrollo oficiales de la alianza, ha preferido utilizar la pila de Bluetooth de Toshiba comentada
previamente para compatibilizar su plataforma con los dispositivos médicos que utilizan el perfil médico Bluetooth
HDP. En la Figura 4.5 se observa el interfaz gráfico de la plataforma. Su arquitectura basada en plug-ins permite añadir
los diferentes módulos, en forma de pestañas, de forma independiente. Además, incorpora características muy
interesantes como la seguridad e identificación a través de biometría o la generación de códigos de barras
bidimensionales (conocidos como bidis) que identifican a cada persona.
En esta prueba piloto no se pretende mejorar la salud o identificar potenciales problemas en las personas analizadas,
sino servir como evaluación de la plataforma Healthy Interoperability, así como extender los resultados de la evaluación
a la plataforma propuesta en este TFM. Para ello, todos los participantes del proyecto WiSo se comprometen a realizar
al menos tres medidas al día para tener un número suficiente de muestras sobre la que realizar pruebas. La seguridad,
muy importante en este tipo de pilotos, se asegura mediante transmisiones cifradas y la utilización de pseudónimos en
la base de datos en lugar de nombres reales. Aparte de la colaboración para el testeo de la plataforma Healthy
Interoperability y en el despliegue de los dispositivos a lo largo de toda la red de telemedicina, la participación en este
proyecto sirvió para tener un contacto más directo con la realidad médica de este tipo de iniciativas. La colaboración
directa durante estos meses con los doctores Dr. Em, Dra. Kraus y Dra. Haslinger ofrecieron una perspectiva diferente
que se aleja mucho de la meramente técnica y que hay que considerar antes de afrontar el despliegue de una red de
estas características. De estas colaboraciones se pueden extraer algunas premisas de interés. Por ejemplo, este tipo de
pacientes son muy dependientes y es necesaria, en la mayoría de los casos, la presencia de otra persona que les ayude
en el proceso de medida. Solo una minoría puede llegar a entender el procedimiento. A día de hoy se desconfía del preprocesado de los datos antes de enviarlos al centro médico. Los doctores prefieren los datos tal como se obtienen sin
ningún tipo de análisis previo o interpretación. Además, los interfaces gráficos necesitan de un estudio más profundo
para poder ser accesibles a cualquier tipo de discapacidad, ya sea visual, sonora o de otro tipo. En este aspecto el
proyecto upHealth.ES ya tiene una línea de investigación focalizada en esta problemática sobre e-Accesibilidad.
Figura 4.5. Interfaz gráfico de la plataforma Healthy Interoperability
Página | 42
Conclusiones y líneas futuras
5.1. Conclusiones
En este TFM se ha abordado desde los inicios de la e-Salud, la necesidad interoperabilidad y el estado del arte de
estandarización en varios niveles y en especial en el estándar X73 como propuesta para solucionar dichos problemas de
interoperabilidad. Actualmente, la e-Salud ha sido impulsada gracias a multitud de diferentes aplicaciones
desarrolladas en grupos de investigación en colaboración con hospitales, proveedores de servicios y empresas
fabricantes de dispositivos médicos. Así, el proceso de implantación de estándares se ha acelerado llegando ahora a
niveles de próxima ejecución. Los fabricantes de dispositivos médicos y sistemas informatizados para medicina no se
han preocupado de la problemática de la estandarización hasta el momento. Los productos iban destinados a un uso
concreto: mostrar los datos por el display y no a ser interconectados para almacenar los datos en un HCE o ser
gestionados por un CE centralizado. Si el usuario deseaba almacenar los datos en un PC era necesario el uso de un
software propietario que gestionara la comunicación con el dispositivo e interpretara los datos. Estas condiciones eran
comprensibles dado que las tecnologías de transmisión en conjunto con los sistemas operativos no contemplaban
nuevas funcionalidades como plug-and-play, calidad y seguridad necesarias para estos servicios en las conexiones a
distancia, o la adopción e integración del HCE como destino final de los datos médicos en los sistemas de e-Salud, que
ha sido y es muy lenta.
Es ahora cuando las empresas comienzan a aprovechar el hecho de que estos tres factores están resueltos
prácticamente y deciden apostar por la interoperabilidad de sus sistemas. Obviamente, seguirán ofreciendo soluciones
propietarias que, según ellos, permiten aprovechar el máximo de las prestaciones de sus productos al no tener que
depender de otros fabricantes. En este contexto, surgen X73PHD y UNE-EN/ISO13606 en una nueva etapa tecnológica
donde los dispositivos son más avanzados, asequibles, llevables, inalámbricos y dan cabida a nuevos servicios. Al mismo
tiempo cobran fuerza los conceptos de salud y entrenamiento personal (fitness). Todo esto hace que X73PHD
aproveche las posibilidades del momento y ofrezca un protocolo base tan preparado que su implementación al menos
no suponga un cambio significativo en los productos de las empresas y permita incluso mejorarlos. Precisamente una
de las razones por las cuales se ha alcanzado tal nivel de estabilidad es debido a la colaboración que han ejercido las
empresas del sector dentro de PHD Working Group.
En este escenario, este TFM ha propuesto una plataforma moderna de telemonitorización, completamente
interoperable y basada en estándares, construida a partir de la experiencia previa adquirida, y adaptada a los actuales
paradigmas de diseño y las nuevas tecnologías recomendadas por X73PHD. Se ha apostado, además, por la filosofía
open source en la que se fomenta la participación de otros desarrolladores, intentando crear una plataforma flexible,
robusta y de futuro que atraiga a las entidades relacionadas con e-Salud al uso de estándares. También se ha obtenido
una panorámica actual del problema de la interoperabilidad y estandarización, pues se ha tenido la oportunidad de
conocer de primera mano la situación real del proceso de normalización que el mundo sanitario está experimentando y
los mecanismos que se están siguiendo para derrumbar las barreras que previamente se habían levantado.
La posibilidad de la realización de prácticas médicas en ámbitos tan distintos, como lo son el comercial, el médico y el
académico, ha permitido comprender la visión tan dispar que se posee en todos ellos de la misma realidad, desde la
defensa acérrima del modelo completo hasta la adecuación de la norma a las necesidades específicas en cada ámbito.
Por esto, y por muchas otras razones, las conclusiones al trabajo realizado difícilmente pueden ser consideradas más
positivas, al menos para el autor y cubren las expectativas y objetivos planteados al comienzo del trabajo.
Página | 43
5.2. Líneas futuras
Con este TFM se coloca la primera piedra sobre la que girarán los futuros desarrollos relacionados con las tecnologías
de transporte y comunicaciones compatibles con X73PHD. Una vez definida una plataforma robusta, modular y
multiplataforma, los esfuerzos se centrarán en dos líneas: implementar y adaptar el resto de tecnologías que han
desarrollado un perfil médico específico para X73PHD (USB PHDC y ZigBee HC), y estudiar las tendencias en
tecnologías inalámbricas de última generación WiFi/WiMax, Ultra Wide Band (UWB) y Long Term Evolution (LTE) así
como su posible aplicación a escenarios de e-Salud, lo que constituirá la futura propuesta de tesis doctoral.
Respecto a USB PHDC, son todavía escasos los dispositivos reales que existen que sean compatibles con X73PHD y,
entre ellos, solo uno que utilice USB PHDC, aunque se esperan más a corto/medio plazo para complementar el
ecosistema de PHDs portátiles o móviles. Además, dada la ausencia de una implementación abierta de este perfil,
académicamente hablando, resulta interesante el estudio, desarrollo e integración de esta tecnología en la plataforma
desarrollada. A diferencia de BlueZ, que se dirige específicamente a entornos Linux, la base sobre la que podría
implementarse el perfil USB PHDC está disponible para varias plataformas e incluso varios lenguajes mediante la librería
libusb. Esta librería open-source está disponible para Linux, Mac OS y Windows. Además, paralelamente se ha ido
desarrollando la librería libusbdotnet, que presenta las mismas características que la original, pero que está
desarrollada en C#, permitiendo una integración directa en la plataforma propuesta.
El futuro de la tecnología ZigBee es quizás el más incierto. Todavía no existe ningún dispositivo real que utilice esta
tecnología inalámbrica y no existen indicios de posibles lanzamientos cercanos. Continua y los fabricantes han optado
por Bluetooth como tecnología inalámbrica. Las razones responden a la gran penetración que tiene en la actualidad
Bluetooth en el mercado de consumo. ZigBee, sin embargo, sitúa su nicho de mercado en entornos domiciliarios, por lo
que su futuro parece ligado al de la domótica. Además, académicamente es muy interesante pues supone grandes
retos de investigación y desarrollo no solo en la parte software sino en la parte hardware.
Por otra parte, además de las citadas tres tecnologías que han desarrollado un perfil médico específico en sus
arquitecturas de protocolos, existen multitud de escenarios donde estas tecnologías encuentran limitaciones y
carencias. Por ello, es necesario explorar nuevas tecnologías que sean capaces de resolver no solo estos problemas,
sino introducir nuevas características y mejoras en la telemonitorización de pacientes. Algunas de estas tecnologías se
encuentran en fase experimental, otras prácticamente están en su fase de nacimiento y otras no dejan de ser una
amalgama de ideas teóricas que necesitan fundirse en una tecnología futura. Previamente al estudio de esas
tecnologías, es importante comenzar con un profundo estudio y análisis de todos los escenarios y casos de uso posibles
que nos podemos encontrar entre los recomendados por los organismos internacionales: salud y bienestar,
seguimiento y autocontrol de la propia enfermedad, enfermedades crónicas y teleasistencia domiciliaria para la tercera
edad. IPv6 over LoW Power wireless Area Networks (6LowPAN), ANT+, Wireless USB (WUSB), IntraBody
Communications (IBC) o Ultra Wide Band (UWB) son algunas de las tecnologías inalámbricas más innovadoras que se
presentan en el panorama internacional y que presentan características y funcionalidades específicas que sería
interesante analizar en cada uno de los escenarios. La ausencia de un perfil médico específico para estas tecnologías
supone el principal reto para una futura tesis doctoral, analizar y proponer una nueva arquitectura de protocolos para
cada una de esas tecnologías para hacerlas compatibles con el estándar X73PHD.
Página | 44
Acrónimos
AAL
AmI
ACSE
APDU
API
ASN.1
BAN
BER
CE
CIL
CLR
CMISE
CSP
DEC
DER
DIM
E2ESHP
ER
ERTM
FC
FSM
GAP
HAN
HCE
HCI
HDP
HID
HL7
IBC
IDE
IHE
JNI
JVM
L2CAP
LTE
MCAP
MedWG
MD
MDER
MS
PAN
PCD
PER
PHD
PHDC
PHM
PoC
QoS
ROSE
SaaS
SDP
SIG
Assisted Ambient Livin
Ambient Intelligence
Association Control Service Element
Application Protocol Data Unit
Application Program Interfaces
Abstract Syntax Notation One
Body Area Network
Basic Encoding Rules
Compute Engine
Common Intermediate Language
Common Language Runtime
Common Management Information Service Element
Clock Synchronization Protocol
Device to Enterprise Communication
Distinguished Encoding Rules
Domain Information Model
End-to-End Standard Harmonization Protocol
Encoding Rules
Enhanced Retransmission Mode
Frame Check Sequence
Finite State Machine
Generic Access Profile
Home Area Network
Historial Clínico electrónico
Host Controller Interface
Health Device Profile
Human Interface Device
Health Level Seven
IntraBody Communications
Interface Development Environment
Integrating the Healthcare Enterprise
JAva Native Interface
Java Virtual Machine
Logical Link Control and Adaptation Protocol
Long Term Evolution
Multi-Channel Adaptation Protocol
Medical Working Group
Medical Device
Medical Device Encoding Rules
Monitoring Server
Personal Area Network
Patient Care Device
Packet Encoding Rules
Personal Health Devices
Personal Healthcare Device Class
Personal Health Monitoring
Point of care
Quality of Service
Remote operations service element protocol
Software as a Service
Service Discovery Protocol
Special Interest Group
SM
SPP
TIC
UCI
UWB
WAN
WG
WPAN
WPF
WS
WUSB
XER
XDR
XML
XSL
ZC
ZCL
ZED
ZHC
ZR
6LowPan
Streaming Moder
Serial Port Profile
Tecnologías de la Información y las Comunicaciones
Unidad de Cuidados Intensivos
Ultra Wide Band
Wide Area Network
Working Group
Wireless PAN
Windows Presentation Foundation
Web Services
Wireless USB
XML Encoding Rules
Cross-Enterprise Document Reliable Interchange
Extensible Markup Language
eXchange Sheet Language
ZigBee Coordinator
ZigBee Cluster Library
ZigBee End Device
ZigBee HealtCare Profile
ZigBee Router
IPv6 over LoW Power wireless Area Networks
Página | 45
Tabla de figuras
Capítulo 1
Figura 1.1. Plataforma de telemonitorización basada en estándares extremo a extremo. Página 2
Capítulo 2
Figura 2.1. Dispositivos médicos. Página 5
Figura 2.2. Evolución de la pila de protocolos de X73PoC a X73PHD. Página 7
Figura 2.3. Pila genérica de protocolos X73PHD. Página 10
Figura 2.4. (a) Pila de protocolos de X73PHD sobre USB PHDC y (b) Jerarquía de descriptores USB PHDC. Página 11
Figura 2.5. Pila de protocolos de X73PHD sobre Bluetooth HDP. Página 12
Figura 2.6. Pila de protocolos de X73PHD sobre ZHC. Página 13
Capítulo 3
Figura 3.1. Esquema de evolución de migraciones de la plataforma telemática de e-Salud. Página 15
Figura 3.2. Esquema de funcionamiento de C#. Página 18
Figura 3.3. Entorno de desarrollo Eclipse. Página 19
Figura 3.4. Entorno de desarrollo Visual Studio 2008. Página 19
Figura 3.5. Plataformas objetivo de Java. Página 19
Figura 3.6. Plataformas objetivo de C#. Página 19
Figura 3.7. Modelo de separación de capas abstractas. Página 20
Figura 3.8. Arquitectura de la solución según diseño basado en capas de abstracción. Página 20
Figura 3.9. Arquitectura propuesta para el manager X73PHD. Página 22
Figura 3.10. Esquema de conexión de módulos o plug-ins externos. Página 22
Figura 3.11. Solución propuesta UZ_ieee_11073 y lista de dependencias. Página 23
Figura 3.12. Esquema de implementación de la máquina de estados X73PHD. Página 24
Figura 3.13. Pila de protocolos BlueZ. Página 25
Figura 3.14. Ejemplo de conexiones de DBus. Página 27
Figura 3.15. Modelo de cloud computing según un esquema “software como servicio”. Página 28
Figura 3.16. Modelo de cloud computing según un esquema “infraestructura como servicio”. Página 29
Figura 3.17. Modelo de cloud computing según un esquema “plataforma como servicio”. Página 29
Figura 3.18. Esquema del servicio de aplicaciones de Google Apps. Página 31
Figura 3.19. Situación y función del Config Profile en la plataforma de telemonitorización. Página 31
Figura 3.20. Flujo de ejecución de la plataforma. Páginas 32 y 33
Figura 3.21. Esquema conceptual de la plataforma de telemonitorización basada en estándares extremo a extremo.
Página 34
Figura 3.22. Pantalla principal de la plataforma uz.Health. Página 36
Figura 3.23. Pantalla de configuración de la medida. Página 37
Figura 3.24. Pantalla de resultados de la medida. Página 38
Capítulo 4
Figura 4.1. Emulador de agente X73 funcionando como termómetro. Página 39
Figura 4.2. Eventos del proceso de toma de medida. Página 40
Figura 4.3. Salida de depuración del Agente Android e interfaz gráfico. Página 40
Figura 4.4. Medida realizada con el tensiómetro A&D Medical UA-767PBT-C Blood Pressure Monitor. Página 41
Figura 4.5. Interfaz gráfico de la plataforma Healthy Interoperability. Página 42
Página | 46
Referencias
Capítulo 1
[1] Martinez. I. et al. Integration Proposal through Standard-Based Design of an End-to-End Platform for p-Health Environments.
Minneapolis : IEEE Engineering in Medicine and Biology society, 2009.
Capítulo 2
[2] Continua Health Alliance. http://www.continuaalliance.org [11/10]
[3] Morfeo Openhealth. http://openhealth.morfeo-project.org/ [11/10]
[4] Healthy Interoperability. http://www.healthy-interoperability.at/ [11/10]
[5] Google Health. http://www.google.com/health [11/10]
[6] Microsoft HealthVault. http://www.healthvault.com [11/10]
[7] Universal Serial Bus Device Class Definition for Personal Healthcare Devices (USB PHDC) release 1.0. USB Implementers Forum
Inc. http://www.usb.org. 1st Ed. 2007. [11/10]
[8] Bluetooth Health Device Profile (BT HDP) version 1.0 revision 00 [Multi-Channel Adaptation Protocol (MCAP)] [Implementation
Guidance Whitepaper]. Bluetooth Special interest Group (SIG). http:// www.bluetooth.com. 1st Ed.2008. [11/10]
[9] ZigBee Health Care Profile (ZHC) specification version 1.0 revision 15. ZigBee Alliance. http://www.zigbee.org.1st Ed. 2010.
[11/10]
Capítulo 3
[10] I. Martínez et al. “Implementación integrada de plataforma telemática basada en estándares para monitorización de pacientes”.
Jornadas de Ingeniería Telemática, pp. 505-512, 2007.
[11] I. Martínez et al. “Optimización de una plataforma telemática para monitorización de pacientes orientada a u-Salud y basada en
estándares y Plug-and-Play”. Jornadas de Ingeniería Telemática, pp. 505-512, 2008.
[12] I. Martínez et al. “Plataforma Telemática de Integración de Estándares End-to-End para Salud Personal”. VIII Jornadas de
Ingeniería Telemática (JITEL), Septiembre 2009
[13] Jungo BTware. http://www.jungo.com. [07/10]
[14] Stollmann BlueCode+. http://www.stollmann.de. [07/10]
[15] Toshiba Bluetooth. http://aps2.toshiba-tro.de/bluetooth. [07/10]
[16] Ethermind Stack. http://www.mindtree.com. [07/10]
[17] BlueZ. http://www.bluez.org. [07/10]
[18] Boston Consulting Group “Capture the value of Cloud Computing”, 2009 http://www.bcg.com/documents/file34246.pdf [10/10]
[19] Shaily malik, Vineet Sinha - Cloud Computing - A Hope for the Rural India, 2010 International Journal of Computer Applications
(0975 - 8887) Volume 1 – No. 20
[20] M. Gil Lalaguna et al., “Configuración remota de perfiles de usuario y casos de uso para una solución ubicua de p-Salud”. Caseib
2009
[21] Historia Clínica Electrónica. Informes de la Sociedad Española de Informática y Salud (SEIS). www.seis.es [07/10].
[22] ISO/EN13606 - CEN/TC251. Electronic Healthcare Record (EHR) Communication Standard. Parts 1-5.
http://www.medicaltech.org. 1st Ed.: 2004. Last visit: 07/10.
[23] I. Martínez et al., "Implementation of an End-to-End Standards-based Patient Monitoring Solution", IET Comm. Special Issue on
Telemedicine e-Health Communication Systems 2:181-191, 2008.
[24] A. Muñoz et al., "Proof-of-concept Design and Development of an ISO/EN13606-based Electronic Healthcare Record Service", J
Am Med Inform Assoc 14:118-129, 2007.
[25] Mense, A et al., "Healthy interoperability": A standard based framework for integrating personal monitoring and personal health
device data into medical information systems”, Journal on Information Technology in Healthcare, 7 (4), pp. 214-221, 2010.
[26] Device to Enterprise Communication (DEC) Profile PCD-01. IHE-PCD Technical Committee.
http://wiki.ihe.net/index.php?title=PCD_Profile_ DEC_Overview. [07/10].
[27] Subscribe to Patient Data (SPD) Profile PCD-02. IHE-PCD Technical Committee. http://www.ihe.net/
Technical_Framework/upload/IHE_PCD_TF_Supplement_SPD_PC_2007-07-18.pdf [07/10].
[28] IHE-XDR. http://wiki.ihe.net/index.php?title=Cross-enterprise_Document_Reliable_Interchange [07/10].
[29] HL7 – PHM Reports. http://www.hl7.org/special/Committees/projman/ searchableProjectIndex.cfm?
action=edit&ProjectNumber=209. [07/10].
[30] I. Martínez et al., "Recent innovative advances in telemedicine: standard-based designs for personal health", Int J Biomedical
Engineering and Technology, 2010.
Capítulo 4
[31] Laycock, G. T. (1993). "The Theory and Practice of Specification Based Software Testing" (PostScript). . Dept of Computer
Science, Sheffield University, UK Retrieved on 2008-02-13.
[32] Wiener Sozialdienste. http://www.wiso.or.at/ [11/10]
Página | 47
Página | 48
Anexos
A.I. ISO/IEEE 11073
Inicios de la norma. VITAL, INTERMED, 1073…
La familia X73 es un conjunto de normas desarrolladas y adoptadas por todos los países para conectividad completa de
dispositivos médicos, que aporta interoperabilidad, plug-and-play, transparencia, y facilidad de uso y configuración.
Dicha norma está, a fecha de finalización de este documento, en fase de desarrollo. De hecho, muchas de sus partes
tienen todavía el status de drafts.
Haciendo cronología, el IEEE fue el primero que desarrolló estándares en esta área con la aparición de Medical
Information Bus (MIB) en 1984. Sin embargo, los principales fabricantes desarrollaron sus soluciones propietarias, que
no han tenido una aceptación general. El CEN creó en 1993 un conjunto de estándares (Point-of-Care Medical Device
Communication, PoC MDC) que fueron ratificados en 1999 para poder interconectar dispositivos e intercambiar datos.
En el año 2000/2001 las organizaciones de estandarización IEEE e ISO se pusieron de acuerdo y crearon el “Pilot
Project” para no competir y trabajar conjuntamente en un único conjunto de estándares. En dicho proyecto piloto, los
estándares IEEE empiezan a desarrollarse conjuntamente. Apelando al tratado de Viena esta organización conjunta se
extendió para incluir al CEN con el fin de llegar a una armonía internacional en los estándares. De hecho, estos acuerdos
han puesto la base para que otras organizaciones de estandarización avancen en una forma similar y trabajen de forma
coordinada con otras organizaciones como HL7, DICOM, IHE o Continua Alliance. A principios de 2004 se aprobaron los
cinco estándares existentes de la norma 11073 y, desde entonces, se han desarrollado con un alto nivel de participación
internacional. Están siendo adoptados como normas ISO a través de su comité técnico TC215, bajo la denominación de
norma 11073. También se consideran estándares europeos por medio del TC251 del CEN.
Este proceso de integración comienza uniendo esfuerzos realizados anteriormente por cada una de las partes, de modo
que se absorben normas previas de ISO e IEEE para poder llegar a cubrir todos los niveles/capas en la comunicación
entre los dispositivos. Entrando en detalle, X73-PoC MDC absorbe ENV13734 (VITAL) para las capas superiores,
ENV13735 (INTERMED) para las capas intermedias, y las antiguas normas 1073 (1073.3 para las capas inferiores y
1073.4 para el nivel físico). El conjunto se renombra como 11073-x-x (para CEN e ISO) y 1073.x.x (para IEEE), aunque
puede asumirse la nomenclatura general de X73-x-x (ver Figura AI.1).
Figura AI.1. Modelos de referencia X73
Modelo X73-PoC
La norma X73-PoC posibilita la comunicación entre dispositivos médicos (Medical Devices, MDs) y sistemas informáticos
externos. Asimismo proporcionan una captura de datos automática de los signos vitales del paciente y de la
información asociada al funcionamiento del dispositivo. La norma X73 se aplica sobre un dispositivo médico MD
seleccionado. Dicho MD establece una comunicación con el gateway central que al mismo tiempo se conecta con el
hospital. El modelo de comunicación es del tipo agente-manager y se posibilitan dos modos básicos de funcionamiento
Página | 49
o comunicación de medidas: store&forward y real-time, que se identifican con los dos perfiles de comunicación: polling
y baseline.
X73-PoC estaba inicialmente orientada a entornos de Unidades de Cuidados Intensivos, UCI (bedside) y dirigida a
equipamiento para el cuidado continuo del paciente (monitores, ventiladores, bombas de infusión, ECGs, etc.)
Comprende una familia de estándares que pueden usarse conjuntamente a distintos niveles para proporcionar
conectividad a los dispositivos implicados dando una solución completa desde bajo nivel (cable físico y conector) hasta
alto nivel (representación abstracta de información y servicios). La familia X73-PoC se divide en cuatro grupos:
 Transporte (por ej., wireless ó cableado).
 Servicios de aplicación (por ej., servicios por eventos o polling, servicios continuos o baseline).
 Datos del dispositivo (por ejemplo, modelo orientado a objetos y terminología para la representación de los
datos y especializaciones para cada tipo de dispositivo).
 Comunicación en red y gateway estándares (por ejemplo, gateway entre representación de datos y mensajes
basados en IEEE1073 y DICOM, HL7, etc.).
El esquema de la pila de protocolos X73-PoC se muestra en Figura AI.2.
Figura AI.2. Pila de protocolos X73-PoC
Pila de protocolos X73-PoC
A. Niveles superiores (1073.1.x.x).
Determinan la aplicación de X73-PoC a un MD determinado. Se debe conocer el conjunto de nombres y códigos
(Medical Device Data Language, MDDL) de que se dispone para crear posibles mensajes y realizar la comunicación.
MDDL establece la nomenclatura, como conjunto de códigos para nombrar los elementos en el Modelo de Información
de Dominio (DIM), y la sintaxis que establece la correspondencia entre códigos y formularios. Los códigos necesarios
son los genéricos de monitorización, y los específicos de cada escenario y MD. La nomenclatura en X73-PoC se usa
principalmente en las PDUs para identificar la información gestionada (medidas, partes del cuerpo, etc).
B. Niveles intermedios (1073.2.x.x).
Los niveles intermedios se definen mediante la generación del MD System (MDS) y sus mensajes que están asociados
con el paciente de forma no ambigua. Así, al realizar la conexión se inicia una secuencia automática de asociación.
El agente (MD, sensor, etc.) será el proveedor de datos y el manager será el sistema de información que recoge y
gestiona los datos que le envía el agente.
Los procesos de aplicación del agente son aquellos que gobiernan el sensor, levan a cabo procesado de las señales
obtenidas y sirven de fuente de datos para el MDS. Los procesos de aplicación del manager son procesos para recoger y
archivar señales que provee el agente. Como muestra Figura AI.2, el MDIB es el conjunto de instancias de objetos que
definen el agente. En este marco los protocolos ACSE y CMDISE se utilizan para asociación y para los servicios de
Página | 50
gestión y comunicación de los datos respectivamente. Los pasos a seguir en la aplicación de estas partes de X73-PoC
serían:
 Revisar el Modelo del Paquete de Comunicación del DIM.
 Identificar los controladores de comunicación, interfaces y sus características:
o DCC: es la interfaz para cada MDS que opera como agente; i.e. que provee información de signos
vitales.
o BCC: es el punto físico de conexión para los DCC cuyos MDS necesitan asociarse con un Entorno de
Paciente específico. Opera como manager que consume y actúa sobre la información de signos
vitales.
 Revisar el Modelo Dinámico del DIM y las formas de tratar con inicializaciones, estados de conexión, diagramas
de relación de objetos o acceso a datos.
 Revisar el Modelo de Servicio de los sistemas de comunicación para eventos, peticiones de datos, modificación
de atributos, invocación de métodos, creación/eliminación de instancias.
 Utilizar el Modelo de Comunicación y las definiciones de los distintos protocolos y servicios que se utilizan para
el intercambio de información.
 Conocer especializaciones de la Sintaxis Abstracta.
 Definir los campos y cabeceras de las PDUs a lo largo de toda la pila de protocolos (ACSE, ROSE,


CMDISE, presentación y sesión), así como su uso, aplicación, sintaxis, y reglas de codificación. El
proceso es análogo para los mensajes.
Sincronización. Actualmente X73-PoC no define un método para la sincronización temporal entre
dispositivos médicos, sino que establece que ha de ser consecuente con las definiciones relevantes
contenidas en
Reglas de codificación. Se define la especialización MDER para formato de red.
C. Niveles inferiores (1073.3.x.x y 1073.4.x.x)
Se definen los requisitos de nivel físico (wired y wireless), haciendo uso la sub-norma 1073.3.3.x que está basada en
conexión mediante cable RS-232 e infrarrojos (IrDA). Esta parte es la que presenta más limitaciones, por lo que sería
interesante incorporar nuevas tecnologías, como USB o Bluetooth a X73-PoC. Por todo ello, y tras diversos estudios y
propuestas del CEN, se ha constatado la necesidad de ampliar el ámbito de aplicación de la norma a este tipo de
tecnologías, incluso nuevas wireless, como Zigbee o WiBree. El grupo de trabajo de IEEE/ISO P1073.0.1.1 en Radio
Frecuencia (RF) ha venido desarrollando un informe sobre el uso de redes RF para comunicación de dispositivos
médicos. Este informe proporcionará un interesante análisis del uso de tecnologías wireless aplicado a MDs en el PoC,
que sentará las bases para la adopción de una nueva versión de X73.
A partir de estas premisas, en los últimos años el vertiginoso desarrollo de nuevos MDs wearables, con sensores de alta
calidad y sobre tecnologías wireless (como Bluetooth o ZigBee), y el incremento de accesos de banda ancha a redes
multimedia, está acelerando la evolución del estándar X73 hacia una versión optimizada y adecuada a estas nuevas
tecnologías y contextos ubicuos. Esta versión se denomina X73-PHD (Personal Health Devices). En esta ocasión cambia
la arquitectura del protocolo, el modelo de comunicaciones agente-manager, se define una nueva máquina de estados
finita (Finite State Machine, FSM), y el modelado del transporte y de nivel físico que conforman la pila de protocolos
X73-PHD, como se detalla en el siguiente apartado. Por todo ello, es evidente que este conjunto de estándares está
todavía en fase de desarrollo, en un proceso evolutivo en el que multitud de ingenieros han trabajado en paralelo con
universidades, instituciones y entidades internacionales. Esto desemboca en una situación transitoria en su progresiva
implantación dado que no está asegurada todavía al no existir garantías de que los principales diseñadores y
fabricantes de dispositivos médicos acepten el estándar. Sin embargo, la existencia de un estándar universal como X73PoC para los sistemas sanitarios es una necesidad en la comunicación de los dispositivos médicos en e-Salud.
Modelo X73-PHD
En este apartado no se busca desarrollar todo el contenido técnico del protocolo (su estudio requiere de una lectura en
profundidad y preferentemente acompañado de una implementación real). Sin embargo, se presenta una descripción
básica de su estructura y los aspectos más interesantes que afectan al uso de MDs del usuario.
Página | 51
PHD ha simplificado en gran medida la arquitectura del protocolo, delimitando perfectamente las funcionalidades que
ahora quedan separadas en tres modelos (ver Figura AI.3):



Modelo del Dominio de Información (Domain Information Model, DIM) caracteriza la información contenida en
un agente como un conjunto de objetos. Cada uno de los objetos contiene uno o más atributos. Los atributos
describen datos de medidas que son enviados al manager y elementos que controlan el comportamiento del
dispositivo.
Modelo de Servicio, proporciona métodos de acceso a los datos que son enviados entre los dos sistemas agente y
manager para establecer el intercambio de datos del DIM. Entre esos métodos se incluyen comandos como GET,
SET, ACTION y Event Report extraídos del protocolo ROSE.
Modelo de Comunicaciones, describe la arquitectura de red en la que uno o más agentes se comunican con un
solo manager mediante conexiones punto a punto. Para cada enlace, la FSM controla el comportamiento del
sistema. Otra función del modelo de comunicaciones es convertir los datos abstractos (abstract syntax) usados en
el DIM en una sintaxis de transferencia. Por ejemplo a mensajes binarios empleando las reglas de codificación
(MDER). Otro tipo de mensajes pueden ser empleados como XML.
Figura AI.3. Arquitectura genérica de X73-PHD
Las especializaciones de los dispositivos contienen a menudo definiciones de clases nuevas en el modelo de
comunicaciones para abarcar las funcionalidades particulares del mismo. Además, el fabricante puede crear
especializaciones propias o extendidas que contienen un esquema de objetos modificado, así como su lista de atributos
definidos. Es tarea del manager el identificar estas configuraciones para decidir si acepta la asociación con el dispositivo
en cuestión en base a sus capacidades.
Pila de protocolos X73-PHD
X73-PHD incorpora una nueva arquitectura para la pila de protocolos X73 que posibilita la conexión entre
MDs o agente y sistemas externos (Compute Engines, CE) o managers. Esta nueva pila X73-PHD se ha
dividido en tres niveles (ver Figura AI.4):



Device Specialization. Un conjunto de modelos descriptivos que aglutina el total de objetos y atributos
relacionados con los componentes de los dispositivos, como su diseño virtual (Virtual MD, VMD), la configuración
del sistema (MD System, MDS), o las especificaciones de la métrica persistente (PM-Store).
Optimized Exchange Protocol. La parte principal del estándar. Consiste en un marco de terminología médica y
técnica DIM que se encapsulará dentro de una trama PDU. X73-PoC definía esta parte como MDDL. Después el
Modelo de Servicio define el conjunto de mensajes e instrucciones para obtener datos de agente. Proporciona una
conversión de datos de Sintaxis de Notación Abstracta ASN.1 a una sintaxis de transferencia usando reglas de
codificación optimizadas (MDER) además de otras específicas (BER/PER/XER). Los elementos de servicio de X73PoC siguen siendo ROSE, ACSE y CMISE. Finalmente, el Modelo de Comunicación describe una conexión punto a
punto basada en una arquitectura agente-manager a través de una nueva máquina finita de estados FSM.
Transport Layer. La transmisión de datos es independiente de la tecnología de transporte debido a que X73-PHD
establece suposiciones que requieren un soporte directo por esta capa permitiendo que varios tipos de transporte
puedan ser implementados. Por tanto, las especificaciones del tipo de capa de transporte quedan fuera del
alcance de X73-PHD.
Página | 52
Figura AI.4. Evolución de la pila X73-PoC a X73-PHD
Entrando en detalle de IEEE 11073-20601 Application Profile-Optimized Exchange Protocol, si en algo destaca este
protocolo respecto al anterior, es que han sido capaces de reunir prácticamente los tres modelos en un documento
único y compacto. Sus características más destacadas son:






Ahora, conociendo las especificaciones estándar, un agente no tiene que transmitir su configuración a no ser que
haga uso de una diferente. En tal caso, el Manager pedirá dicha configuración para poder trabajar con dicho agente
y almacenarla para futuras ocasiones evitando de esta forma el proceso de asociación que, en el caso de
dispositivos multi-especializados (implementan varios equipos al mismo tiempo, como tensiómetro y glucómetro),
puede requerir un tiempo considerable.
Es independiente de la capa de transporte. Esto reduce enormemente la problemática de implementación, y
simplemente asume una serie de funcionalidades que ha de reunir la tecnología seleccionada. Si no fuera el caso,
admite la adición de éstas mediante una capa de acondicionamiento (shim layer).
Define diferentes perfiles de transporte, teniendo en cuenta las condiciones del canal de comunicación (entorno de
aplicación) y clasificándolos según éstas en tipos:
o Tipo1: Perfiles de transporte que contienen ambos servicios de transporte fiable y no fiable, donde deberá
de haber 1 o más canales virtuales para transporte fiable y 0 o más canales no fiables.
o Tipo 2: Contienen únicamente un servicio de transporte unidireccional.
o Tipo 3: Sólo contienen un servicio de transporte no fiable, donde deberá de haber 1 o más canales de
dicho tipo.
Reduce la complejidad del árbol de objetos del DIM eliminando clases redundantes al tiempo que agrega nuevas
como la Permanent Metric (PM) que permite almacenar medidas para su posterior envío a petición del manager.
Se simplifica enormemente la implementación de dispositivos multi-especializados. En X73-PoC, esta característica
exigía la definición de un tipo de MDS específico (Hydra-MDS) que junto con la complejidad de la estructura de
objetos era difícil de implementar correctamente.
Una Máquina de Estados Finitos FSM mucho más completa, descrita en profundidad y testeada para evitar
cualquier posible error durante el funcionamiento del protocolo. La FSM diseñada para PHD es más completa que
la utilizada en la versión X73-PoC, al haber incorporado nuevas funcionalidades como disponer de la configuración
del agente por parte del manager. Dado que este es un aspecto clave en la nueva versión X73-PHD, se detalla en el
apartado siguiente un esquema de FSM genérico para la comunicación entre agente y manager.
Página | 53
Nueva máquina de estados finitos FSM
El diseño de la FSM (ver Figura AI.5) es la clave de cualquier solución basada en X73-PHD dado que define mecanismo
principal de comportamiento. Para el diseño se han de tener en cuenta los estados definidos en X73-PHD:
DISCONNECTED, CONNECTED, UNASSOCIATED, ASSOCIATED, CONFIGURING y OPERATING. El proceso de funcionamiento sería:





Ambos equipos son encendidos, desencadenando el proceso de inicialización local (MDIB y otros parámetros
de estado).
A partir de esta inicialización, se establece una conexión a través de la capa de transporte; si tiene éxito,
ambos pasan al estado CONNECTED, pero UNASSOCIATED. Para asociarse, MD envía una petición de asociación
[AARQ] al manager.
Si el manager conoce la configuración del agente ya porque es estándar o la tiene almacenada de operaciones
pasadas, pasan a ASSOCIATED y podrán operar. Si no, el manager solicitará la configuración del agente
(CONFIGURING) previamente y la podrá almacenar para futuras ocasiones (esto facilita las funcionalidades Plugand-Play).
En el estado OPERATING, se inicia el envio de muestras. Puede ser el agente quien las mande directamente o
previa demanda del manager. Bajo este modo, el agente puede realizar un solo envío, o sucesivos durante un
periodo de tiempo limitado o ilimitado.
En cualquier momento se pueden desasociar tanto agente como manager en situaciones de error, por
finalización del envío de medidas o por otras circunstancias. Para ello se dispone de una solicitud de
desasociación [RLRQ] seguida de la confirmación del otro extremo [RLQE] o una desasociación directa [ABRT].
DISCONNECTED
transport connection
indication
transport disconnection
indication
CONNECTED
disassociating
procedure
associated
operating
configuring
unassociated
associating
procedure
OK waiting (MD)
config check (CE)
send config (MD)
wait config (CE)
Figura AI.5. Máquina de estados finitos
Página | 54
AII. Plataformas previas. upHealth.ES
La plataforma upHealth.ES ha pasado, en los últimos años, por diferentes versiones para adecuarla a las evoluciones de
los estándares en los que se basaba, la evolución de los distintos dispositivos médicos y tecnologías que la soportaban
(de fijos a móviles), incluso la integración entre los distintos estándares en los que se basaba. Este anexo recoge la
documentación asociada a todas ellas, así como el detalle de su puesta en marcha.
El comienzo
El comienzo del grupo X73 Spain Group, que se ha dado a inicio del segundo semestre de 2009, ha sido fruto del
esfuerzo de muchas personas y de una muy buena idea: “Conseguir poner en funcionamiento real la plataforma
upHealth.ES”. Este proyecto se enmarca en la línea de investigación de telemedicina del Grupo de Tecnologías de
Comunicación (GTC) adscrito al Instituto de Investigación en Ingeniería de Aragón (I3A). A principios de 2000, el grupo
se une a la Red de Telemedicina a nivel nacional, y por tanto comienza como nodo de la red a participar en proyectos
enmarcados en distintos nuevos servicios de telemonitorización en vehículos de emergencias médicas.
Progresivamente van apareciendo más proyectos y se comienza a constituir la base de los antecedentes de este
proyecto.
Alguno de estos proyectos se basa en la interoperabilidad de dispositivos biomédicos de monitorización en aplicaciones
de telemedicina. Se aportan ideas, se escriben documentos técnicos, se realizan charlas y conferencias. A raíz de estos
hechos, se oyen voces de pasar del mero análisis en reuniones entre distintos grupos de distintas universidades a
establecer una estrecha colaboración entre varios nodos de la Red de Telemedicina. Así pasamos de un middleware de
ideas a ver signos que apelan a una estandarización para conseguir los objetivos. La colaboración con la Universidad
Pública de Navarra (UPNA) y el Instituto de Salud Carlos III (ISCIII) para decidir elegir las normas ISO11073/IEEE1073
(X73) consolidada como referencia europea para lograr la interoperabilidad.
A partir de este momento el grupo de Zaragoza, se da cuenta que debería hacer una aportación científica en este marco
de estandarizar los dispositivos médicos. Por ello se decide que una buena aportación sería crear un sistema completo
(end-to-end) basado en la norma X73, que implica el diseño e implantación, para múltiples servicios, de todos los
elementos necesarios para transmitir las mediciones efectuadas a un paciente, desde su domicilio (donde se sitúan
dispositivos médicos y gateway X73) hasta el hospital de seguimiento, centro de salud o consulta médica (donde se
encuentra el servidor de telemonitorización) sin que este hecho conlleve un esfuerzo adicional por parte del usuario.
Para lograr este objetivo, se otorgan becas de colaboración, y se desarrollan proyectos fin de carrera, enmarcados en
este propósito. Así, la colaboración entre las tres universidades, cuyos grupos han destinado un esfuerzo importante
por impulsar ese proyecto, da sus frutos y finalmente en la Universidad Zaragoza se implementa el mencionado sistema
end-to-end.
Ya en 2009, es necesario hacer inventario de lo que hay hecho hasta ahora y sobre todo para futuros compañeros que
se unan a la plataforma, es necesario recopilar y organizar todo lo que hemos desarrollado.
Este documento contiene los códigos de las plataformas desarrolladas hasta ahora y pretende poner al lector en
antecedentes para poder entender qué es lo que se ha hecho hasta ahora en el laboratorio y qué es lo queda por hacer.
Podrá entender cómo funcionan los códigos elaborados para las distintas plataformas del estándar y cómo se usan los
dispositivos médicos disponibles en el laboratorio. Además incluye en un capítulo final una presentación resumida de la
nueva página web del grupo, www.x73Spain.com o también www.uphealth.es.
X73 Spain Group posee una serie de versiones previas de la plataforma denominada upHealth.ES de acuerdo a la
evolución que ha experimentado estos últimos años, y la relación de personal que ha llevado a cabo cada una de estas
plataformas es la siguiente
Plataforma upHealth.ES. Evolución, librerías y funciones
Para que en el laboratorio quede una constancia organizada y clara de la evolución de la plataforma de monitorización,
se ha elaborado una entrada al servidor del laboratorio, donde el personal puede acceder a los códigos desarrollados,
así como a los artículos científicos escritos sobre el estándar o a memorias de proyectos o tesis anteriores. Como se ve
en dicha figura, cada versión de la plataforma contiene una carpeta (Código Fuente o Códigos C++) donde se
Página | 55
encuentran los códigos en el lenguaje de programación correspondiente, y otra carpeta Ejecutables, que contiene los
archivos ejecutables que genera Microsoft Visual Studio cuando compilas la solución, para poder hacer uso directo de la
plataforma lanzando directamente las aplicaciones.
La plataforma 1.0 se centra en PoC y está compuesta de un adapter y un gateway implementados en Linux con IrDA y
RS-232. Además se apoya en las librerías propias del estándar X73, que están recogidas en la carpeta x73srv-lib. La
plataforma 1.5 recoge la migración a sistema operativo de Windows del par agent-manager, similar a los anteriores
adapter-gateway. Se encuentra en esta carpeta además un resumen explicativo del debug de X73. La plataforma 2.0 se
centra en PHD y está claramente organizada en la carpeta Código C++, que está subdivida en otras subcarpetas (agent,
agent_network, agent_P2P, manager) que contienen el código del agente (en sus tres versiones) y del manager,
respect. La plataforma 2.1 hace la versión de PHD en Windows Mobile y contiene en su carpeta Códigos C++ las mismas
dos subcarpetas (agent, manager) para diferenciar ambos códigos.
upHealth.ES – Plataforma 1.0-alfa
El diseño e implementación de soluciones de telemedicina basadas en estándares es una tarea ardua y compleja.
Existen contribuciones previas, desarrolladas en EE.UU. por el grupo de investigación del Dr. Warren, que estudian la
viabilidad de implantar estándares en entornos sanitarios e implementan plataformas de monitorización de pacientes
en el PoC. Sin embargo, no existen antecedentes europeos en este campo ni tampoco propuestas de soluciones
telemáticas globales extremo a extremo que alcancen nuevos casos de uso como se plantean con esta plataforma.
Así, y a partir de trabajos preliminares surgidos desde los grupos tecnológicos que conformaron la Red Nacional de
Investigación Cooperativa en Telemedicina en los que se avanzaba las primeras aportaciones iniciales, surge una
implementación integrada completa: platform1.0-alfa. Esta plataforma aporta una solución global basada en
estándares (X73 y EN13606) extremo a extremo, y que permite la investigación y experimentación de las normas más
recientes de tecnología médica. Esta solución facilitaría la gestión y aprovechamiento de los recursos de los
proveedores, promoviendo la implantación de dispositivos interoperables ubicuos y plug-and-play.
El esquema genérico de platform1.0-alfa se presenta en Figura AII.1. Se basa en un elemento concentrador
(Gateway/CE) que recopila toda la información adquirida por los MDs del paciente. Este gateway se comunica, a través
de la red de acceso, con un servidor remoto que gestiona los diferentes gateway y que centraliza la información
proveniente de cada escenario de monitorización de paciente (de ahí su nombre: servidor de telemonitorización). Por
último, el servidor de telemonitorización se conecta, a través de la red de comunicaciones, con el servidor de HCE del
hospital para almacenar la información asociada a cada paciente en su correspondiente base de datos.
A partir de este esquema genérico, se detalla su implementación en la figura Figura AII.2. Esta implementación
consigue que el diseño propuesto no dependa de los MDs propietarios de los fabricantes, ni de los interfaces de
conexión, ni del formato de las diferentes bases de datos ya que toda la comunicación sigue protocolos estándares.
Además, esta arquitectura incluye:



Interfaces personalizados a cada UC y/o tipo de paciente/usuario y a su interacción activa.
Métodos P&P para gestión de múltiples dispositivos según algoritmos de Inteligencia Ambiental (AmI).
Módulos de selección de las tecnologías de acceso de banda ancha óptimas usando algoritmos avanzados de
estimación de calidad de servicio (Quality of Service, QoS).
Página | 56
X73
EN13606
home
hospital
Telemonitoring
server
Communications
network
Gateway
server
Communications
network
interface
EHR
medical devices
Figura AII.1. Esquema genérico de la solución platform1.0-alfa basada en estándares extremo a extremo
VMD no X73
prop
USB
X73 adapter
X73 data
IrDA-RS232
X73 gateway
X73 data
TCP/IP
Ethernet
Monitoring Server
X73 / EN13606 EN13606
TCP/IP
Ethernet
EHR Server
EN13606
EHR
Electronic
Healthcare
Record
X73srv-adapter-v1.1
X73 communication
X73srv-gateway-v1.1
X73srv-telemon-v1.1
X73 communication
EN13606
client
EN13606
server
EN13606
communication
Figura AII.2. Arquitectura completa de platform1.0-alfa con las especificaciones tecnológicas de cada elemento
Implementación sobre X73 y EN13606
Se detallan a continuación las características técnicas de cada uno de los elementos que componen la arquitectura del
sistema, así como las especificaciones de diseño que se han seguido en su implementación (ver Figura AII.2):
MDs y adaptadores X73. A día de hoy resulta difícil encontrar MDs que cumplan la norma X73-PoC. Muchos de ellos
tienen interfaces físicos Bluetooth, USB, etc. que no están incluidos en la norma (X73-PoC actualmente sólo contempla
RS-232 e IrDA). Por ello, en el desarrollo presentado se utilizan dispositivos médicos propietarios sin salida X73-PoC. Los
dispositivos utilizados en la implementación son: un tensiómetro (OMRON 705IT), y un pulsioxímetro (DATEX-Ohmeda
3900). A estos dispositivos hay que añadir su correspondiente adaptador a la norma X73-PoC, tanto a nivel físico como
a nivel de información, que es el que realmente permite la intercomunicación X73 extremo a extremo con el gateway.
Gateway X73. El gateway se diseña como un dispositivo X73 o manager, beneficiándose de todas aquellas
funcionalidades propias del estándar: interoperabilidad, sistema de alertas, supervisión y control remoto. Existen
riesgos derivados del hecho de que el gateway X73 esté situado en el entorno personal del paciente, donde las
condiciones escapan al control del proveedor del servicio. Algunas cuestiones que se han considerado en la solución
propuesta han sido:


La inteligencia del sistema no puede depender de un equipo externo al hogar; por tanto, el gateway necesita
un módulo de inteligencia local (por ej., a control remoto).
El paciente tiene derecho a la privacidad de su información médica debiendo ser esta transmitida empleando
métodos de cifrado.
Página | 57
Servidor de telemonitorización X73/EN13606. El servidor de telemonitorización desempeña un doble papel: De
servidor (manager) para la comunicación X73-PoC con el gateway (agente), y de cliente para la comunicación con el
servidor de HCE. Crea un extracto EN13606 a partir de los datos X73 proporcionados por el dispositivo médico y es
transmitido con el acorde a los arquetipos contemplados por la norma EN13606.
Servidor de HCE EN13606. Es un contenedor de información clínica, donde se encuentran las bases de datos con las
HCE de los pacientes. Los datos provenientes de cada MD (extractos de HCE generados según un “arquetipo” diseñado
ad-hoc) son incorporados al HCE como datos asociados a diferentes asistencias médicas, siguiendo el formato EN13606.
De esta manera, este servidor recibe los extractos “arquetipo”, los valida según la norma EN13606, los almacena en la
base de datos, y envía el correspondiente reconocimiento al cliente.
El objetivo de desarrollar las diversas capas y elementos de servicio por separado es facilitar un desarrollo progresivo y
directamente guiado por las especificaciones de los estándares X73 y OSI (X73 sigue una pila de protocolos que
contempla los 7 niveles del modelo OSI). Los lenguajes de programación utilizados han sido Java y C/C++ junto con otras
herramientas de desarrollo (ANTLR 2.7, Java SDK 5.0 y el compilador de ASN.1 ASN.1c 0.9.22). ASN.1 es un lenguaje
orientado a la definición de protocolos en el cual se diseñan los tipos de datos a gestionar así como las estructuras de
los mensajes de una manera abstracta. Para obtener elementos en formato de computación o de red, estas
definiciones son procesadas por el compilador ASN.1c obteniendo como resultado un conjunto de estructuras de C
(definición de tipos de datos estándar y funciones de codificación. Para incorporar la codificación específica de X73-PoC
MDER, se ha optado por modificar el árbol sintáctico del compilador haciendo uso de ANTLR2 manteniendo la
automatización dl proceso.
A continuación Se describen down-up, las características específicas de cada capa:



La capa de transporte se ha implementado como adaptación a la pila de transporte que corresponda usar: la
del sistema operativo en caso de TCP/IP (net socket), o una diseñada de forma específica en el caso de
IrDA/RS-232.
La capa de sesión en el estándar X73 queda minimizada, desapareciendo todos los servicios de sincronización y
control de diálogo.
La capa de presentación queda principalmente como un mecanismo de negociación de las sintaxis a usar por
las capas superiores, definido en X73.
Para representar las definiciones de clases, atributos y mensajes gestionados por X73-PoC se hace uso de la sintaxis
abstracta (MDDL). Éstas son posteriormente mapeadas a sintaxis de transferencia (cómo se traducen a cadenas de bits)
acorde a MDER. Esta codificación, desarrollada exclusivamente para X73, simplifica en gran medida la lectura y
transmisión de datos si se hace uso de plantillas de tramas (conociendo la posición de los bytes en el mensaje
transmitido). Se detallan a continuación los servicios de gestión de asociación y envío de datos implementados:



ACSE (Association Control SE). Se encarga de gestionar el estado de asociación entre el manager y el agente.
Define un conjunto de comandos
CMDISE (Common Medical Device Information SE). Este protocolo implementa las operaciones de transmisión
de datos entre los equipos. Se usa junto a ROSE/CMISE.
ROSE/CMISE (Remote Operation SE/Common Management Information SE). Para la comunicación se utiliza
sintaxis MDER, que adopta un conjunto reducido de tipos de datos ASN.1. Implementa la comunicación de
eventos o notificaciones y la solicitud de ejecución de acciones o funciones del dispositivo.
Evolución de la plataforma
La primera de las actualizaciones, consistió en la incorporación de equipo de pulsioximetría a la plataforma. Mientras
que el proyecto anterior estaba orientado al uso de un solo equipo dispositivo médico, la extensión de su aplicación
como un simple demostrador a un sistema de mayor utilidad práctica era inevitable. El manager de este modo no
queda relegado a un simple gateway monopuesto sino que tendría bajo su gestión más de un dispositivo, ampliando la
red personal PAN. Al mismo tiempo, el protocolo X73-PoC contempla varias formas de implementar varios dispositivos
en la red:
Página | 58


Como un dispositivo multifuncional (HydraMDS): Funciona como varios equipos médicos de naturaleza
diferente al mismo tiempo, transmitiendo sobre un mismo enlace con el Manager.
Como múltiples dispositivos: para cada uno se establece un enlace punto a punto y el Manager debe de
gestionar las diversas comunicaciones X73.
El equipo a incorporar es un Pulsioxímetro del fabricante Datex-Ohmeda modelo 3900 (Figura AII.3). Este dispositivo
permite visualizar en todo momento el valor de SpO2 y de las pulsaciones cardiacas, así como muestra el gráfico de la
forma de onda pletismográfica. Las lecturas de SpO2, frecuencia cardiaca y valor pulsátil PIr, junto con la marca horaria,
la etiqueta personalizada del paciente y las condiciones de alarma respectivas, se transmiten a intervalos de 2 segundos
en el modo de salida automático y cada 6 segundos en el modo de salida de tendencia.
Figura AII.3. Imagen del pulsioxímetro
Las diferencias con respecto al otro dispositivo a la hora de desarrollar la implementación de la solución son
principalmente la presencia de diferentes tipos de datos (curva pletismográfica , nivel de saturación de oxígeno en
sangre y ritmo cardíaco) que precisan de nuevos formatos como el Real Time Sample Array (RT-SA) y modos de
transmisión adicionales como Baseline o periódico.
Manteniendo la estructura del núcleo de X73-PoC, se añaden las funcionalidades necesarias para conseguir, al igual que
con el dispositivo inicial, capturar y enviar los datos del paciente a un servidor remoto (ver Figura AII.4):
Las mejoras obtenidas al finalizar el trabajo se había se resumen a continuación:
 Recopilación y organización del código original creado por los desarrolladores previos.
 Depuración del proyecto para su correcto funcionamiento tanto en Windows (mediante Cygwin) como Linux.
 Clasificación de todas las herramientas necesarias para la compilación del código junto con la redacción de una
guía de compilación e instalación para futuros proyectos
 Creación, a partir del punto anterior, de un autoinstalable para la ejecución del sistema en otros equipos.
Figura AII.4. Esquema de aplicación
Página | 59
La segunda de las actualizaciones consiste en el desarrollo de un actualizador de adaptadores. El protocolo X73-PoC
podría haber sido implementado en un sistema sin necesidad de hacer uso de dispositivos reales. Precisamente esto
conlleva el problema de tener que diseñar un adaptador que interprete los datos del dispositivo en concreto. Esta es
una cuestión que siempre se ha mantenido presente, sin embargo, los buenos resultados que se estaban obteniendo
junto el futuro prometedor de la norma sugería que el proyecto no quedara en un simple demostrador, sino que
tuviera una verdadera aplicación práctica. El objetivo: adaptar dispositivos médicos de uso prácticamente nulo en los
centros de salud para su funcionamiento con el protocolo X73 y añadir nuevas funcionalidades a los mismos.
Muchos son los dispositivos que se encuentran en el mercado, para los cuales cada fabricante otorga características
exclusivas a cada modelo, sin tener en cuenta la incorporación de los mismos en sistemas globales de eSalud. Cada
dispositivo necesita, al menos de momento, de un adaptador que incluye un intérprete de datos en formato propietario
y un agente X73 (ver Figura AII.5).
Dispositivo
Médico
Intérprete
Protocolo
Propietario
Agente X73
Figura AII.5. Proceso de adaptación de MD a X73
La implementación consiste en el desarrollo de una aplicación que permita la configuración manual del Intérprete de
Protocolo Propietario del adaptador y configurar los parámetros del Agente X73 acorde con el tipo de dispositivo y
modo de funcionamiento. Dicha aplicación se ejecutará desde un computador externo conectado al adaptador X73 por
medio de un puerto USB o un puerto RS-232 (puertos de salida más comunes). Mediante un interfaz gráfico sencillo
(hay que tener en cuenta que la persona que realiza la configuración del adaptador no tiene porque saber el
funcionamiento del mismo) podrá realizarse una búsqueda del modelo de dispositivo en concreto en una base de datos
local o localizada en un servidor remoto a través de Internet y descargar en el adaptador el controlador necesario. El
controlador puede contener, además de información técnica del dispositivo, parámetros relacionados con el paciente.
Las diferentes partes que componen el sistema son:
 Aplicación Servidor. Permanece a la escucha de conexiones entrantes, ejecuta funciones de autenticación de
usuarios mediante password, realiza búsquedas en la base de datos de dispositivos y transfiere el fichero de
configuración solicitado.
 Aplicación Cliente. Se encuentra almacenada en el servidor en forma de applet, de esta forma se puede
acceder a ella por medio un navegador de un equipo conectado a Internet y una vez descargada ejecutarla en
la misma ventana del navegador (sin instalaciones). Esta aplicación se ha creado con una interfaz gráfica simple
e intuitiva tanto para facilitar su manejo al encargado de llevar a cabo la instalación del adaptador X73 (que no
tiene necesariamente que tener muchos conocimientos de informática) como para que un exceso de imágenes
y datos hagan que la carga del applet sea excesivamente lenta.
 Aplicación Adaptador. Alojada en el equipo conectado al dispositivo, se encarga de establecer un diálogo con
la aplicación Cliente para recibir el software de adaptación apropiado y una vez almacenado ejecutarlo para
iniciar el funcionamiento del Adaptador.
A continuación se muestra en Figura AII.6 un esquema general de la aplicación:
DISPOSITIVO
ADAPTADOR
GATEWAY
X73
VENDOR
APLICACIÓN
ADAPTADOR
RS-232
APLICACIÓN
CLIENTE
SERVIDOR DE
TELEMONITORIZACIÓN
TCP/IP
APLICACIÓN
SERVIDOR
TCP/IP
EQUIPO
EXTERNO
Figura AII.6. Esquema del sistema actualizador
Página | 60
Plataforma 1.5-beta
La principal motivación para la implementación de esta actualización de la plataforma es la complejidad en el desarrollo
con la platform1.0-alfa. Esto se debe al hecho de haber diseñado un código basado en librerías orientadas a Linux,
implementar un traductor de tipos de datos ASN.1 a estructuras MDER demasiado limitado a los primeros dispositivos
implementados y disponer de una elevada cantidad de llamadas a funciones para representar el total de las
especificaciones en cada uno de los niveles OSI que define la norma. En Figura AII.7 se representa un esquema del
diseño de la plataforma.
Con estos problemas cualquier cambio en el sistema requiere demasiado tiempo en programación y depuración de
errores. Con el desarrollo de X73-PHD a la vista, la solución es reutilizar la plataforma encapsulándola para poder
hacerla funcionar en un entorno Windows y simplificar el código para facilitar el trabajo sobre el mismo. Al mismo
tiempo, implementar algunas de las características que trae consigo X73-PHD como la máquina de estados (FSM) y
agregar una interfaz de usuario.
Especificación de
objetos ASN.1
Archivos ASN.1
IMPLEMENTACIÓN DE LA PILA
DEL PROTOCOLO X73
CAPA DE APLICACIÓN
[application_l.cc]
ACSE
[acse-se.cc]
CMISE/ROSE
[rose_cmip_se.cc]
CAPA DE PRESENTACIÓN
[presentation_l.cc]
Compilador
ASN1.C
IrDA
[transport_l.cc]
Clases de utilidad de
Objetos
MDER
Procesador
JAVA
Generado por
ANTLR
Enlace en
tiempo de
ejecución
INTERFAZ FÍSICO
(socket API)
AARE-apdu(.h/.c)
AARQ-apdu(.h/.c)
AttributeList(.h/.c)
Etc...
Librería ASNX
java
CAPA DE SESIÓN
[session_l.cc]
TCP/IP
[transport_l.cc]
[server.cc]
Clases de utilidad de
Objetos
BER/DER
asn_cmise.h
asn_cmip.h
asn_common.h
asn_mdse.h
asn_rose.h
Especificación de
objetos ASN.1
Archivos ASN.1
Figura AII.7. Esquema de diseño y herramientas empleadas en las plataformas X73
La implementación de esta nueva plataforma comprende el proceso de adaptación de todas las librerías de modo que
el nuevo proyecto pueda ser compilable en un único entorno de desarrollo (Microsoft Visual C++). Uno de los objetivos
es conseguir un sistema que requiera un mínimo tiempo de aprendizaje y de puesta en marcha de nuevas
modificaciones. Al mismo tiempo, se tiene como objetivo a largo plazo la conversión del proyecto para su ejecución en
sistemas móviles (PDA, Smartphone, UltraMoblePC) que hagan uso del sistema operativo Windows CE (Windows
Mobile). El uso de managers móviles o en sistemas de mediana/baja capacidad es uno de los puntos de aplicación de
X73-PHD.
Esta solución mantiene la filosofía de comunicación entre MD (adaptador) y CE (gateway): CE pide asociación a MD, lo
que desencadena la creación de un objeto MDIB actualizado con los datos adquiridos del tensiómetro (según perfil
periódico o episódico). MD envía la estructura del objeto a CE, que copia en una base de datos actualizable y, en su
caso, envía al servidor de telemonitorización. Desde esta base se van a analizar los requisitos que establecerán las
reglas de diseño para realizar la nueva implementación (ver Figura AII.8).
Primero, buscar un diseño funcional y conforme a X73. Para ello, se ha de eliminar la dependencia con la tecnología de
transporte buscando una solución genérica y configurable (denominada gestor de capa de transporte o handler). Así,
los datos adquiridos, primero se transforman a X73 actualizándose cada vez que hay una nueva medida (pero en modo
episódico, no periódico como en la anterior plataforma1.0) para, después, iniciar el envío de datos (ya conforme a X73)
del adaptador X73 al CE a petición del usuario. Por tanto, se deja al desarrollador la inclusión de los archivos que den
soporte a la tecnología de transporte que estime oportuno para cada MD.
Página | 61
Segundo, el diseño de pila genérica X73 debe mantenerse. Sin embargo, se ha de optimizar el código e introducir la
librería de definiciones ASN1.C, llamada ASNX en X73, para que enlace correctamente en la vinculación que se realiza
desde el entorno de desarrollo para todos los recursos. Las clases que son una abstracción de los previos adaptador y
gateway también han de modificarse para implementar la nueva máquina de estados definida por CEN para X73-PHD.
Por último, al no incorporar una tecnología de transporte concreta, los datos que se encapsulan a través de las distintas
capas llegan a una disposición en estructuras de buffers, que recogen el conjunto de PDUs de las distintas capas de la
pila. Estos buffers han de ser correctamente gestionados para que responda al protocolo de comunicaciones que marca
la norma.
PLATAFORMA 1.0 - alfa
(X73-PoC / SO Linux)
Código pila
X73
C/ C++
BER
ASN1.C
GNU
GCC
Librería
ASNX
C/ C++
GNU
GCC
MDER
ANTLR
JAVA
spec.h
GNU
GCC
Librería X73
C/ C++
Spec ASN1.C
diseño
Código
migrado
puntos
abiertos
implementación
Migración
asn_common.h
asn_cmip.h
asn_cmdise.h
asn_mdse.h
asn_rose.h
PLATAFORMA 1.5 - beta
(X73-PHD / SO Windows)
PLATAFORMA 2.0 - release
Figura AII.8. Esquema de migración
Plataforma 2.0-Release
Consiste en la implementación del estándar X73-PHD sobre un sistema compuesto por varios MD/agente y un
CE/manager. Además se tienen en cuenta los siguientes objetivos para el desarrollo del proyecto:
 Capacidad de incorporación al sistema de un número de dispositivos mucho mayor que en la plataforma
anterior haciendo uso de una combinación de tecnologías de transporte tanto cableadas (USB, Ethernet) como
inalámbricas (Bluetooth, Wi-Fi, Zigbee).
 Diseño de un manager con posibilidad de ser ejecutado sobre una plataforma móvil (PDA, Smartphone) para la
gestión inalámbrica de un rango de dispositivos médicos.
 Monitorización y estudio estadístico del tráfico, contemplando la incorporación de posibles modificaciones en
las definiciones de tipos de datos ASN.1 para optimizar el intercambio de información en términos de tiempo y
coste.
 Diseño de un interfaz gráfico (GUI) multimodal para la gestión de dispositivos y muestras del usuario y otro
para la gestión del protocolo a nivel de depuración y evaluación.
En el planteamiento de la solución se tiene en cuenta que la norma X73-PHD va orientada a dispositivos de uso
personal que, como ya ha sido comentado anteriormente, poseen unas características muy restrictivas en cuanto a
capacidad de procesado (velocidad y memoria) y especialmente autonomía. Uno de los desafíos del proyecto es
conseguir programar el agente X73-PHD en un sistema basado en microcontrolador. La reducción de complejidad a
conseguir, teniendo como referencia la plataforma anterior basada en el X73-PoC es drástica al mismo tiempo que se
ha de optimizar el uso de memoria. Posteriormente, hay que incorporar una tecnología de transporte teniendo en
cuenta varios aspectos. El tipo de la señal a transmitir queda caracterizado por la estructura de los datos (muestras
simples o vectores), su tamaño y la frecuencia de transmisión requerida, pueden ser gestionados de manera más
eficiente en unas tecnologías que en otras (proceso de asociación y autenticación, tamaño de cabeceras y velocidades
de transmisión). Por otro lado es determinante el entorno de aplicación del dispositivo dado que, el uso de tecnologías
inalámbricas puede estar prohibido en algunos escenarios por poder interferir con otros equipos electrónicos. Al mismo
tiempo, la distancia al manager y su ubicación requerirán enlaces cableados o inalámbricos con diferente tecnología en
cada caso. Por último se tienen en cuenta las posibilidades de implementación debido a que para cada tecnología se
precisan unos módulos que incluyen básicamente el interfaz físico (radio o cable) y un controlador de protocolo que
gobierna la transmisión y las comunicaciones con el resto de dispositivos. Precio, disponibilidad, consumo, tamaño y
complejidad de desarrollo sobre el sistema global son los aspectos a analizar
Página | 62
Para el desarrollo del proyecto se ha hecho uso del mismo lenguaje de programación que en las dos plataformas
previas: C++. Los criterios que se han tenido en cuenta para su selección son:
 Uso de punteros para la gestión de árboles de objetos, gestión eficiente de memoria y tramas de datos.
 Experiencia de desarrollo con el lenguaje C/C++.
 Acceso a bajo nivel hardware.
 Posibilidad de desarrollo en sistemas empotrados.
 Integración con entornos de diseño de aplicaciones de ventanas para Windows (MFC).
El entorno de desarrollo de la solución ha sido básicamente Microsoft Visual Studio C++ y su versión para sistemas
empotrados Microsoft eMbedded Visual C++. Mientras que todo el código perteneciente al propio protocolo como la
gestión de los modelos del X73-PHD (Información, servicios y comunicaciones) se desarrolla únicamente con las
librerías estándar de C++, los interfaces visuales (GUI) se han implementado haciendo uso de las librerías Microsoft
Foundation Class (MFC). Estas librerías permiten encapsular tanto el código perteneciente al protocolo como las
funcionalidades requeridas en clases más sencillas. Además proporciona las herramientas necesarias (botones, campos
de información, listados, etc.) para la creación de aplicaciones tanto de ventana como de consola de una manera más
sencilla tanto para plataforma Win32 como sistemas empotrados basados en Windows CE.
Para la implementación del estándar se ha seguido el borrador de la norma ISO/IEEE P11073-20601/D20 Draft Standard
for Health informatics - Personal health device communication - Application profile - Optimized exchange protocol en su
versión 20 lanzada en mayo del 2008. Esta versión ha sufrido muy pocos cambios desde entonces, estando localizados
en aquellos apartados relacionados con determinadas especializaciones de dispositivos para incrementar su
compatibilidad.
Dado que son muchas las características que ofrece el protocolo y algunas de ellas no tienen sentido dependiendo del
tipo de dispositivo que se emplea en el sistema, es importante hacer una selección de dichas propiedades. Aún así,
mientras que en la plataforma anterior se buscaba poder desarrollar un demostrador que contuviera la mínima parte
de las características del X73-PoC para poder funcionar con una configuración determinada, en esta ocasión el sistema
ha de ser capaz de reconocer la mayor parte de los mensajes y la máquina de estados por completo. Entre las
características aplazadas destaca la Métrica Permanente (Permanent Metric) al estar orientadas nuestras aplicaciones a
la adquisición y transmisión en tiempo real y el tipo Enumeración (enumeration) al ser empleado solamente en
configuraciones extendidas de algunos dispositivos.
El modelado de la pila de protocolos o modelos de X73-PHD ha sido modificado en esta ocasión para reducir la
complejidad del programa. Mientras que en la plataforma anterior estaban implementadas todas las capas del modelo
OSI como funciones o clases con sus correspondientes variables locales y vinculaciones con otras clases, ahora
simplemente se procesa la cabecera de los mensajes y se sigue un esquema de interpretación determinado según el
tipo de servicio al que pertenece la cabecera. De esta manera es posible acceder a la información contenida en la trama
desde la aplicación central en algunos casos, como se verá más adelante. En la Figura AII.9 se puede ver un ejemplo de
los dos modelos:
X73-PoC PROTOCOL
MANAGEMENT
X73-PHD PROTOCOL
MANAGEMENT
Application PDU
Application Layer
PRST
ACSE
CMDISE
-ROSE
PHD PROTOCOL
AARQ
AARE
RLRQ
RLRE
ABRT
Protocol
& Device
Info
Reply
Info
Release
Reason
Release
Confirma
tion
Abort
Reason
RORJ
ROER
Reject
Reason
Error
Reason
RORS
Event Report
ROIV
ACSE
PROTOCOL
CMDISE-ROSE
PROTOCOL
Get
Set
Action
Atribute
Value
Atribute
Value
Activate
Method
Presentation Layer
Device
Configuration
Information
Measurements
Session Layer
Figura AII.9. Comparativa de modelos
Página | 63
Los tipos de datos definidos en ASN.1 son codificados a MDER de manera más simple en esta ocasión para reducir la
complejidad de la solución. Se ha prescindido de librerías adicionales y los mensajes, objetos y datos son codificados y
agregados a la trama “on-the-fly”. Esta estrategia descarga la complejidad de la etapa de ejecución del protocolo al
tiempo que la desplaza hacia la etapa de desarrollo. Esto es debido a que el uso de punteros en C++ y la manipulación
de arrays de bytes (tramas de transmisión) han de realizarse con extrema precaución para no provocar errores en
tiempo de ejecución (desbordamiento de memoria, punteros a zonas restringidas, etc.)
El procesado de las tramas se hace de manera bastante similar a las dos plataformas anteriores aunque ahora se hace
tratamiento más atomizado aprovechando las características de la codificación MDER. Este tipo de codificación explota
el hecho de que los paquetes intercambiados contienen campos que se repiten constantemente, como cabeceras de
tipo de protocolo, longitud o indicadores de segmento mientras que los campos contenedores de datos de medidas son
actualizados. Así surge la propuesta de uso de patrones de tramas, almacenados previamente en memoria que agilicen
el procesado y eviten la necesidad de implementar demasiadas funciones. El esquema final de la solución que
implementa el módulo de comunicaciones X73-PHD puede verse en la Figura AII.10 (a).
Todas las características del protocolo como los modelos, definición de tipos de datos, máquina de estados, gestión de
tramas se encuentran encapsulados en varias clases siendo las más representativas las clases PHDAppAgente y
PHDAppManager, las cuales implementan el nivel de aplicación del protocolo. Es importante remarcar que se cumplen
restricciones de diseño en al haber reducido el uso de memoria de unos 8450KB con X73-PoC a 1880KB con X73-PHD
además de rebajar el número de librerías y clases en un factor de casi 20, sin contar librerías de transmisión.
GRAPHIC USER INTERFACE
MFC LIBRARIES
FINITE STATE MACHINE
X73PHDAPPLICATION
DATA TYPE
ASN.1
CLASSES
DATA TYPE
C++
CLASSES
MDER-CODED
FRAME MANAGEMENT
X73-PROTOCOL STACK MANAGER
CODEC X73
TRANSPORT MODULE
BLUETOOTH
ETHERNET
USB
IRDA
RS-232
OTHERS
Figura AII.10. (a) Esquema de la solución, (b) Aplicación agente genérica
Finalmente se diseña el interfaz de usuario haciendo uso de las librerías MFC como se ha comentado al comienzo. Esta
aplicación implementa por un lado un agente que puede representar cualquiera de las especificaciones estándar o
extendida definidas en la norma y simula un dispositivo médico. Por otro lado implementa un manager que recibe
conexiones de agentes y gestiona la transmisión de datos desde el dispositivo. Ambos interfaces ofrecen información y
controles útiles para la depuración del programa como visor de buffers de transmisión, control del estado del sistema,
información de procesos, bytes enviados y recibidos entre otros y por otro lado controles orientados al
usuario/paciente como por ejemplo inicio o detención del sistema y envío de medidas. Se puede ver una captura de la
aplicación agente en la Figura AII.10 (b).
Plataforma 2.0-BT
Por último se ha desarrollado la plataforma 2.0-BT, para cubrir los puntos abiertos de la plataforma anterior. Esta
plataforma mantiene la estructura de la pila y los subsistemas de las anteriores plataformas, y se basa en modificar el
software heredado de la plataforma 2.0 para que se pueda aplicar dispositivos móviles a través de la capa de transporte
con tecnología Bluetooth.
Para ello, se trabaja con Windows Mobile, por ser el más extendido de los que ofrece la tecnología actual en este país.
De este modo, ha sido necesario sustituir las librerías de las que se disponía en la anterior plataforma para poder
realizar un software compatible.
Página | 64
Otro de los cambios ha sido la separación de la especificación del dispositivo médico. Se ha elaborado un archivo de
código fuente distinto para cada MD con librerías comunes. De esta forma, cuando se requiera integrar un dispositivo
nuevo, sólo será necesario integrar un nuevo archivo en la solución con los drivers adecuados para su funcionamiento.
Finalmente, la máquina de estados se ha vinculado, de forma que la llamada a la función se realiza desde otro archivo
haciendo uso de la programación orientada a objetos. De esta forma se consigue fragmentar el código, dejando por un
lado la parte básica inamovible y por otro la plataforma susceptible de evolución.
Para el diseño se han de tener en cuenta los estados definidos en X73-PHD: DISCONNECTED, CONNECTED,
UNASSOCIATED, ASSOCIATED, CONFIGURING y OPERATING. El proceso de funcionamiento, sería:
 Ambos equipos son encendidos, desencadenando el proceso de inicialización local.
 A partir de esta inicialización, se establece una conexión a través de la capa de transporte; si tiene éxito,
ambos pasan al estado CONNECTED, pero UNASSOCIATED. Para asociarse, el MD envía una petición de
asociación al CE.
 Si el CE conoce la configuración del MD ya porque es estándar o la tiene almacenada de operaciones pasadas,
pasan a ASSOCIATED y podrán operar. Si no, el CE solicitará la configuración del MD (CONFIGURING)
previamente y la podrá almacenar para futuras ocasiones (esto facilita las funcionalidades plug&play).
 En el estado OPERATING, se inicia el envío de muestras. Puede ser el MD quien las mande directamente o
previa demanda del CE. Bajo este modo, el MD puede realizar un solo envío, o sucesivos durante un periodo
de tiempo limitado o ilimitado.
 En cualquier momento se pueden desasociar tanto MD como CE en situaciones de error, por finalización del
envío de medidas o por otras circunstancias. Para ello se dispone de una solicitud de desasociación seguida de
la confirmación del otro extremo o una desasociación directa.
En primer lugar, la solución del proyecto se puede dividir en dos partes muy diferenciadas; cada uno de estos dos
códigos fuentes se encarga de funciones distintas y a la vez complementarias.
 El código fuente BthConnect.cpp, Figura AII.11, se encarga de realizar la comunicación mediante sockets
Bluetooth, y es aquí donde se encuentran las funciones de búsqueda de dispositivos (Function:
DiscoverDevices), conseguir la información del dispositivo Bluetooth (Function: GetDeviceInfo) y establecer la
comunicación BT (Function: OpenClientConnection y Function: OpenServerConnection). Además este código
fuente posee la descripción de las instrucciones que realiza cada uno de los botones.
 En el otro código fuente, StandardX73.cpp, está definido el estándar X73 propiamente, la relación de cada una
de las tramas que se han de intercambiar entre el MD y el CE para cumplir con el estándar. También están
definidas las clases y estructuras para que a través de la definición de un objeto en el BthConnect.cpp se
puedan hacer llamadas a las funciones definidas en StandardX73.cpp con tan sólo una llamada a través del
objeto.
Cuando se establece con el médico cuál ha de ser la periodicidad de las medidas, la historia clínica del paciente se
actualizará para establecer una serie de alarmas que se activarán en su CE. Así, cuando el paciente reciba una alarma
sonora y con mensaje en la pantalla de su CE, deberá ejecutar su programa Manager X73 y seleccionar START y así de
este modo el CE permanecerá a la escucha, buscando dispositivos Bluetooth activados en su zona de actuación. Figura
AII.12.
Después mediante CONEXIÓN_X73 se realizará una petición de asociación con el CE. Cuando éste recibe la petición
solamente buscará la dirección Bluetooth asociado a ese dispositivo médico.
Para finalizar la fase de conexión se ha elaborado dentro del código C++ el envío de datos de prueba de la medida de
tensión sistólica y diastólica. Cuando el CE recibe la medida de la tensión, puede ya desconectar el MD de la
comunicación X73 establecida presionando el botón DESCONEXIÓN_X73 y entonces aparecerá en la pantalla del CE del
paciente un aviso advirtiendo que el tensiómetro se ha desconectado. Como a veces la búsqueda de dispositivos
Bluetooth no resulta satisfactoria a la primera, se ha diseñado un botón dentro del entorno gráfico denominado
SEARCH (en el MD) y SEARCH AGAIN (en el CE) que permite al paciente y al dispositivo médico realizar una nueva
búsqueda de dispositivos Bluetooth activos en la zona.
Como mejora del software, se ha fragmentado el código fuente StandardX73.cpp, creando un nuevo elemento en la
solución denominado Tension.cpp que contiene las líneas de código relacionadas con la actuación por parte del
estándar cuando el dispositivo médico elegido es un tensiómetro.
Página | 65
INICIO
PROGRAMA
Busca los
dispositivos
Bluetooth en la
zona
SHOW
DEVICES
Discover
Devices
Muestra los
dispositivos
bluetooth
activos en la
zona de
actuación
Get Number
Device
Devuelve un
entero con el
número de
dispositivos
encontrados
Get Device
Information
Crea un hilo de
ejecución
CREATE
THREAD
Devuelve el
nombre y
dirección de
todos los
dispositivos en
la lista de
enlaces en
DeviceInfo. Es
usado por el
interfaz de
usuario para
mostrar los
nombres y
direcciones de
los dispositivos
encontrados
Get Local
Device Name
Devuelve el
nombre del
titular
establecido en
el Registro
Open Server
Connection
Abre un socket
servidor para
escuchar.
Registros del
servicio. Crea un
hilo de ejecución,
ReadThread,
para leer los
mensajes
entrantes.
Figura AII.11. Esquema de funcionamiento de la conexión Bluetooth
Del mismo modo, se ha creado un nuevo código fuente .cpp para la báscula y el pulsioxímetro, para permitir introducir
nuevos dispositivos. Esto mejora la escalabilidad y la modularidad. El código se ha estructurado de manera tal que, si en
un futuro se quisiera introducir un nuevo dispositivo médico emergente en el mercado en el que se haya incluido
puerto Bluetooth, bastará con incluir un nuevo código fuente .cpp para el dispositivo e incluir la librería diseñada
devices.h donde se ha definido la clase Bthdevices para asociar los dispositivos médicos con el código StandardX73.cpp
a través de un objeto creado en éste último código fuente.
Figura AII.12. Interfaz gráfica del manager Bluetooth
Página | 66
A.III. Detalles de implementación de framework X73PHD y perfil médico BT HDP
La implementación de la plataforma está pensada como si fuera un cubo de piezas donde cada usuario pueda construir
un manager o un agente pieza por pieza dándole un estilo personal si fuera necesario. Todas estas piezas se pueden
obtener de la librería principal (que se ha dado denominado UZ_ieee_11073, ver Figura AIII.1). Esta librería,
desarrollada en C#, contiene todos los objetos necesarios para crear un manager compatible con X73PHD. Esta librería
depende únicamente de la librería BinaryNotes y es compatible con la versión 2.0 del framework .NET o superiores. De
esta forma, se asegura la total compatibilidad con la plataforma Mono. A continuación, se muestra en Figura AIII.1 una
imagen de la solución UZ_ieee_11073 en el IDE de desarrollo Visual Studio 2010.
Figura AIII.1. Solución propuesta UZ_ieee_11073 y lista de dependencias
BinaryNotes. Generando los objetos ASN.1
BinaryNotes es un framework ASN.1 completo Open Source para Java y para C# además de un compilador que
construye clases Java o C# a partir de un fichero de especificaciones ASN.1. Este framework contiene:
 Librería de codificación y decodificación. Esta librería implementa las reglas de codificación BER, PER y DER.
 BNCompiler. Compilador ASN.1 que puede ser ampliado y que es capaz de generar clases Java o C# a partir de un
fichero ASN.1 específico de entrada. Se pueden personalizar los ficheros generados cambiando las plantillas XSL o
creando plantillas propias.
 Colas de mensajes. Implementación de colas de mensajes de alto rendimiento basadas en codificación ASN.1
Sin embargo, BinaryNotes, como ya se comenta a lo largo de la memoria, no implementa MDER, las reglas de
codificación empleadas por ISO/IEEE 11073 para el intercambio de información. Fue necesario la modificación y
creación de algunas clases dentro del código de BinaryNotes (Ver Figura AIII.2).
Figura AIII.2. Nuevas clases MDER implementadas para codificar y decodificar reglas médicas
Las modificaciones de la librería se han realizado apoyándose en el documento de la norma ISO/IEEE 11073-20101:2004
donde se define las reglas de codificación MDER y siguiendo el estilo de programación del resto de clases de la librería
Página | 67
BinaryNotes. En el documento de la norma se describen también tipos de datos, atributos, objetos… etc. que utiliza el
estándar X73 para representar datos. Toda esa información descrita en formato ASN.1 debe ser traducida a objetos de
C#. Para realizar esta tarea se utiliza el compilador de BinaryNotes (BNCompiler).
Los pasos a seguir son los siguientes:
1. Generamos un archivo ASN.1 que contenga todas las definiciones del estándar. En nuestro caso al fichero generado
le hemos dado el nombre de UZ_IEEE_20601_defs.asn1.
…
-- ***************************************************
-- A.2.14 Operational state data type
-- ***************************************************
--The operational state data type defines if a certain object or other property is enabled or
disabled.
OperationalState ::= INTEGER {
disabled(0),
enabled(1),
notAvailable(2) }(0..65535)
…
Ejemplo de parte del fichero con la especificación ASN.1 del estándar
2. Desde la consola (Ejecutar > cmd si estamos en Windows), nos movemos al directorio Dist/bin, donde reside el
compilador de BinaryNotes.
3. Ejecutamos el compilador indicando el path del fichero ASN.1 que hemos creado (En nuestro caso, el fichero lo
hemos movido al mismo directorio que el compilador)
C:\BinaryNotes\Dist\bin\bncompiler.cmd –m cs –f UZ_IEEE_20601.asn
4. Si no hemos especificado directorio de salida (mediante el parámetro “–o directorio”), si todo ha ido bien,
obtendremos nuestros ficheros de C# (Ver Figura AIII.3) en el directorio “Output”.
Figura AIII.3. Clases C# generadas por el compilador de BinaryNotes
Librería UZ_ieee_11073
Con casi 4000 líneas de código, la librería UZ_ieee_11073.dll contiene el grueso de desarrollo de este TFM
implementando toda la arquitectura propuesta en el anterior capítulo. El proyecto se ha organizado intentando separar
las partes en las que se divide el estándar y todas aquellas clases de apoyo que tienen algo en común. La estructura de
carpetas es la siguiente:
A continuación se describe el contenido y objetos de cada una de las carpetas:
Página | 68
 Config: Contiene las clases que gestionan la configuración de un dispositivo, como
tipo de codificación, versión de protocolo utilizada, etc.
 Core: Esta carpeta contiene los objetos a más alto nivel de la librería. Los objetos
agente y manager se construyen a partir de canales, objetos MDS, etc.
 Events: El núcleo X73PHD publica eventos para que otras clases u objetos los reciban
como nuevas medidas, conexiones y desconexiones de dispositivos. Esta carpeta
contiene las clases que se encargan del sistema de eventos de la implementación.
 Exceptions: No solo pueden generarse eventos sino también excepciones de muchos
tipos durante la ejecución del núcleo. En esta carpeta se encuentran los tipos de
excepciones utilizadas explícitamente para esta implementación.
 Gateway: Para comunicar el núcleo X73PHD con el mundo exterior en ocasiones se
necesita alguna capa de adaptación, contenida en esta carpeta.
 Logging: La implementación se ha construido utilizando un sistema de log de errores robusto, flexible y multi-hilo
permitiendo generar múltiples tipos de mensajes, ya sea por consola, mensajes remotos, etc.
 Part_10101: En esta carpeta se contiene en una única clase toda la nomenclatura del estándar.
 Part_104xx: Los dispositivos médicos se ven como especializaciones de X73PHD. En esta carpeta se contienen
todas las especializaciones soportadas por esta implementación. A día de hoy solo se soportan las
especializaciones 10408 (termómetro) y 10404 (pulsioxímetro). Sin embargo, gracias a la modularidad de la
solución, soportar más especializaciones es tan sencillo como crear una nueva clase similar a estas otras.
 Part_20601: Esta carpeta contiene el grueso de la implementación, máquina de estados finitos, canales, canales
virtuales, tipos de PDUs, etc.
 Utils: Esta carpeta contiene clases de apoyo al resto de clases para realizar operaciones determinadas u objetos
que no tienen una clasificación especial.
A continuación se describen los principales espacios de nombres (namespaces) de la librería.
UZ_ieee_11073. Part_10101
En este namespace se definen los códigos de nomenclatura, los cuales ofrecen la posibilidad de identificar cláramente
objetos y atributos en relación a su código OID. Esta nomenclatura está dividida en particiones, para organizar los
código dependiendo de su contenido y función. Estos códigos son definidos en el código mediante constantes.
Este namespace únicamente contiene clase llamada Nomenclature. La clase contiene constantes estáticas que
representan los atributos y objetos mediante un código OID entero.
Para acceder a estas constantes desde cualquier parte del código tendremos dos opciones:
1.
Usar el namespace en la cabecera del fichero:
using UZ_ieee_11073.Part_10101;
mandatoryAttributes.Add(Nomenclature.MDC_ATTR_ID_HANDLE,
new Attribute(Nomenclature.MDC_ATTR_ID_HANDLE, handle));
2. No usar el namespace y usar todo el nombre de la variable.
Página | 69
mandatoryAttributes.Add(UZ_ieee_11073.Part_10101.Nomenclature.MDC_ATTR_ID_HANDLE,
new Attribute(UZ_ieee_11073.Part_10101.Nomenclature.MDC_ATTR_ID_HANDLE, handle));
UZ_ieee_11073. Part_20601
En este namespace se encuentran todos los objetos que definen el comportamiento del protocolo de
intercambio optimizado o ISO/IEEE 11073-20601. Es sin duda el núcleo de la implementación. Este namespace
se compone de otros 4 namespaces (o sub-namespaces) que engloban clases homogéneas.




ASN1. En este namespace aparecen los objetos ASN.1 generados mediante el compilador BNCompiler.
FSM. Clases relacionadas con la máquina de estados (Finite State Machine) y que forma parte del modelo
de comunicación de ISO/IEEE 11073.
Messages. En este namespace se definen las APDU que se utilizan para el intercambio de información en
ISO/IEEE 11073.
PHD. Aquí se definen las diferentes clases que conforman el DIM (Domain Information Model) y que
caracterizan un dispositivo.
UZ_ieee_11073. Part_20601.FSM
Como ya se ha comentado, en este namespace aparecen las clases relacionadas con
la máquina de estados FSM (Finite State Machine) y que forma parte del modelo de
comunicación de ISO/IEEE 11073.
En un primer nivel, se definen los interfaces y clases abstractas necesarias para la
implementación de la máquina de estados. La implementación de los estados será
diferente si el dispositivo es manager o agente. En este caso, en la figura adjunta
aparece la implementación de los diferentes estados únicamente del manager.
Todos los estados derivan de una clase base denominada State, una clase abstracta y
que es la siguiente:
public abstract class State
{
protected IStateHandler StateHandler;
protected State (IStateHandler handler) {
this.StateHandler = handler;
}
/**
* Process an APDU that has arrived on the input data stream
* @param apdu
*/
public abstract void Process(ApduType apdu);
/**
* Process an outer event
* @param apdu
*/
public abstract void ProcessEvent(Event newEvent);
public abstract string Name { get; }
}
Todo estado tendrá un manejador de estados o IStateHandler, un nombre identificador del estado y dos métodos,
Process para procesar las APDU provenientes de otro dispositivo y ProcessEvent para procesar diferentes eventos que
puedan producirse como desconexión de otro dispositivo, problemas en la red… etc.
El interface IStateHandler es un elemento clave para manejar los estados de la máquina de estados y que además nos
permitirá enviar la información hacia el exterior desde cada uno de los estados:
Página | 70
public interface IStateHandler
{
State State
{
get; set;
}
MDS MDS
{
get; set;
}
void Send(ApduType apdu);
void SendEvent(Event evnt);
}
Visualiizando de forma gráfica la creación de la máquina de estados quedaría una figura como la siguiente:
Figura AIII.4. Implementación de la máquina de estados
Estas clases son clases abstractas por lo que no se pueden instanciar. En nuestro código a día de hoy únicamente
tenemos implementadas las clases de la máquina de estados para el Manager.
Analizamos a continuación la implementación de dos estados del manager: Desconectado y No asociado. En el caso de
estado desconectado o ManagerDisconnected, tenemos el siguiente código:
class ManagerDisconnected : Disconected
{
public ManagerDisconnected(IStateHandler handler) : base(handler)
{
Logger.LogDebug("Current State: Disconnected");
}
public override void Process(ApduType apdu)
{
//Do not Process anything in Disconnected state.
}
public override void ProcessEvent(Event newEvent)
{
if (newEvent.Type == Event.Connection)
StateHandler.State = new ManagerUnassociated(StateHandler);
else
Logger.LogWarning("Unexpected event (" + newEvent.Type + ") arrived in disconnected state.");
}
Página | 71
En este caso, el manager está en estado desconectado. En este estado no procesa ninguna APDU, únicamente los
eventos de conexión o desconexión. En el método ProcessEvent, cuando llega un Evento de Conexión
(Event.Connection) modificamos la propiedad State del IStateHandler indicándole el siguiente estado, que sería
ManagerUnassociated.
El estado ManagerUnassociated, al que llegamos desde ManagerDisconnected a través de un evento de conexión, es
más complicado. A continuación presentamos el código más signiticativo de este estado:
class ManagerUnassociated : Unassociated
{
public ManagerUnassociated(IStateHandler handler) : base(handler){}
public override void Process(ApduType apdu)
{
if (apdu.isAarqSelected())
{
Logger.LogDebug("[Agent: " + StateHandler.Agent + "][State: "+ Name + "] AssociationRequest
received. Starting association process.");
Associating(apdu.Aarq);
}
else if (apdu.isAareSelected() || apdu.isRlrqSelected() || apdu.isPrstSelected())
{
Logger.LogDebug("[Agent: " + StateHandler.Agent + "][State: " + Name + "] Aare or Rlrq or Prst
received. Sending Tx abrt (reason undefined).");
StateHandler.Send(new AbrtApduUndefined());
}
}
public override void ProcessEvent(Event evnt)
{
if (evnt.Type == Event.Desconnection)
{
Logger.LogInfo("[Agent: " + StateHandler.Agent + "][State: "+ Name + "] Transport
disconnection.");
StateHandler.State = new ManagerDisconnected(StateHandler);
//TODO Indicar desconexion a capas superiores
}
}
En este caso se procesan tanto eventos como APDU. Si estamos en estado no asociado y recivimos un evento de
desconexión, movemos el IStateHandler a estado Desconectado. En el caso del procesado de la APDU, si se recibe una
AARQ, se inicializa el proceso de asociación, en otro caso se envía una APDU de abort por causas no definidas
(AbrtApdeuUndefined) tal como se define en el documento de la norma.
UZ_ieee_11073. Part_20601.Messages
En este namespace se construyen las APDU que se utilizan para el intercambio de información en ISO/IEEE 1107320601. Todas estas APDU derivan de una clase base ApduType a la que se añade información. Veamos algunos
ejemplos.
AbrtApdu. APDU para abortar conexión.
public class AbrtApdu : ApduType
{
public AbrtApdu(int reason)
{
UZ_ieee_11073.Part_20601.ASN1.AbrtApdu abrt = new
UZ_ieee_11073.Part_20601.ASN1.AbrtApdu();
Abort_reason abrtReason = new Abort_reason(reason);
abrt.Reason = abrtReason;
selectAbrt(abrt);
}
}
A través del constructor se pasa la razón del aborto de conexión y se construye una APDU específica para esta situación.
Página | 72
AbrtApduBufferOverFlow. APDU para abortar la conexión por desbordamiento de buffer. Es un caso específico del
anterior, y por ello esta clase deriva de la anterior.
public class AbrtApduBufferOverflow : AbrtApdu {
public AbrtApduBufferOverflow() : base(ASNValues.ABRT_RE_BUFFER_OVERFLOW) { }
}
AareRejectApdu. Esta es un poco más compleja que las otras e indica el rechazo a la asociación.
public class AareRejectApdu : ApduType
{
public AareRejectApdu(int assocResult)
{
byte[] empty = {};
AareApdu aare = new AareApdu();
AssociateResult ar = new AssociateResult(assocResult);
DataProto dp = new DataProto();
DataProtoId dpi = new DataProtoId(ASNValues.DATA_PROTO_ID_EMPTY);
dp.Data_proto_id = dpi;
dp.Data_proto_info = empty;
aare.Result = ar;
aare.Selected_data_proto = dp;
selectAare(aare);
}
}
UZ_ieee_11073. Part_20601.PHD
En este namespace aparece la implementación del modelo de información de dominio, el DIM. El DIM caracteriza la
información de un agente como un conjunto de objetos. Cada objeto tiene uno o más atributos. Los atributos describen
medidas que son comunicadas a un manager así como también elementos que controlan el comportamiento e
información del estado del agente.
Por ejemplo, veamos la implementación de Metric. Esta es la clase base de todos los objetos que representan medida,
estado y datos de contexto. Tal como impone la norma, esta clase no puede ser instanciada, por ello se trata de una
clase abstracta.
public abstract class Metric : DIM
{
private static readonly int[] MandatoryIds = {Nomenclature.MDC_ATTR_ID_HANDLE,
Nomenclature.MDC_ATTR_ID_TYPE,
Nomenclature.MDC_ATTR_METRIC_SPEC_SMALL};
public override int Code
{
get { return Nomenclature.MDC_MOC_VMO_METRIC; }
}
protected Metric(Dictionary<int, Attribute> attributes) : base(attributes) { }
protected override void CheckAttributes(Dictionary<int,Attribute> attributes)
{
for( int i=0; i<MandatoryIds.Length; i++)
{
if(!attributes.ContainsKey(MandatoryIds[i]))
throw new InvalidAttributeException("Attribute id " + MandatoryIds[i] + " is not assigned in
Metric Object.");
}
}
}
También podemos encontrar en este namespace la implementación del MDS, una de las clases más importante de toda
Página | 73
la librería puesto que cada agente es instanciado directamente desde una clase MDS. El objeto MDS representa la
identificación y el estado de un agente a través de sus atributos.
Además, este namespace contiene la implementación del canal virtual y
los diferentes tipos de canales para cada una de las tecnologías.
Actualmente se han implementado dos tipos de canales, para TCP y para
HDP. Este último únicamente es compatible con la plataforma Mono pues
utiliza la pila de Bluetooth open source de Linux BlueZ, no compatible con
Windows.
Toda esta información puede resultar muy abstracta, por lo que a
continuación se propone un ejemplo de la implementación de un
manager básico utilizando la librería ISO/IEEE 11073.
Un ejemplo de Manager
A continuación se desarrolla y se describe el código básico necesario para crear un Manager X73 con la librería
implementada.
using
using
using
using
using
System;
System.Collections.Generic;
UZ_ieee_11073.Core;
UZ_ieee_11073.Events;
UZ_ieee_11073.Part_20601.PHD.Channel.TCP;
namespace UZ_ieee_11073_Manager
{
public class Manager : IEventListener
{
private TCPManagerChannel _tcpManagerChannel;
private List<Agent> _agentsList;
public Manager()
{
_agentsList = new List<Agent>();
InitializeChannels();
}
private void InitializeChannels()
{
_tcpManagerChannel = new TCPManagerChannel();
_tcpManagerChannel.AgentAttached += AgentAttached;
}
void AgentAttached(Agent agent)
{
agent.EventManager.AddEventListener(this);
}
public void Start()
{
_tcpManagerChannel.Start();
}
public void Stop()
{
Console.WriteLine("Parando Manager");
_tcpManagerChannel.Finish();
foreach (Agent agent in _agentsList)
{
agent.SendEvent(new Event(Event.AssociationAbortRequest));
agent.FreeResources();
}
_agentsList.Clear();
}
Página | 74
#region IEventListener implementation
public void StateChanged(Agent agent, StateChange stateChange)
{
Console.WriteLine("El estado del agente " + agent.SystemId + "ha cambiado. " + stateChange);
}
public void NewMeasure(Agent agent, List<Measure> measure)
{
Console.WriteLine("El agente " + agent.SystemId + "ha generado nuevas medidas:");
foreach(Measure ms in measure)
Console.WriteLine(ms.ToString());
}
public void AgentDisconnected(Agent agent)
{
agent.FreeResources();
_agentsList.Remove(agent);
}
public string Name
{
get { return "UZ_ieee11073_Manager"; }
}
public void AgentConnected(Agent agent)
{
if (_agentsList.Contains(agent))
{
Console.WriteLine("Agente ya conectado");
return;
}
_agentsList.Add(agent);
}
#endregion
}
}
En el código propuesto, nuestra clase Manager implementa el interfaz IEventListener que debe ser obligatoriamente
implementado por cualquier clase que quiera escuchar los eventos de un agente. En el constructor de nuestra clase
inicializamos los canales que deseemos, en este caso únicamente se ha inicializado el gestor de canales de TCP, aunque
podríamos haber inicializado el de Bluetooth HDP o RFCOMM. En el momento que el manager del canal TCP dispara el
evento de AgentAttached, ya tenemos un agente conectado y comenzamos a escuchar todos sus eventos. Actualmente
se soportan los eventos de conexión, desconexión, cambio de estado y recepción de medidas, pero es posible que en
un futuro los eventos soporten más acciones que se van produciendo en el núcleo.
De esta forma tan sencilla y rápida se ha creado un manager ISO/IEEE 11073. La modularidad de la solución permite
que añadamos nuevos canales a la librería o incluso nuevos protocolos de comunicaciones sin afectar al resto del
código. El usuario final será el encargado de colocar las piezas finales de tal forma que se obtenga un manager a la
medida.
Página | 75
Integración de Bluetooth HDP
Uno de los retos más importantes que afronta este TFM es la integración del perfil médico Bluetooth HDP en la nueva
plataforma. Los anteriores desarrollos de upHealth.ES hacían uso de TCP/IP o Bluetooth RFCOMM como tecnologías de
transporte por debajo de X73PHD. Por primera vez se utiliza el perfil médico Bluetooth HDP como tecnología de
transporte construyendo la primera solución totalmente compatible con el estándar X73PHD. Este logro se ha
conseguido en colaboración con la Universidad Juan Carlos I (especializada en estos últimos años en desarrollos a bajo
nivel de X73PHD) y en el contexto de la primera de las prácticas médicas realizadas en este TFM.
El perfil médico Bluetooth HDP en combinación con la especificación X73-20601 facilita un framework robusto y basado
en estándares que permite la interoperabilidad completa entre dispositivos de e-Salud sobre Bluetooth. Este nuevo
perfil médico Bluetooth HDP ha traído consigo el desarrollo de dos especificaciones en la pila de protocolos específicas
para dispositivos médicos como son MCAP y HDP. MCAP permite una conexión robusta incluyendo además soporte
para datos en streaming. El perfil Bluetooth HDP permite a los dispositivos agente (conocidos en Bluetooth como
source y asociados a tensiómetros, pulsioxímetros, etc.) intercambiar datos con los dispositivos manager (conocidos en
Bluetooth como sink y asociados a móviles, portátiles, SmartPhones, Tablet PCs específicos para e-Salud, etc.).
A día de hoy únicamente algunas pilas Bluetooth comerciales presentan compatibilidad con el nuevo perfil médico
Bluetooth HDP: Jungo BTware [13], diseñada para sistemas empotrados de bajo consumo; Stollmann BlueCode+ [14],
diseñada con una arquitectura independiente de la plataforma; Toshiba Bluetooth Stack [15], para Windows y
certificada por Continua; y Ethermind Bluetooth Stack [16], desarrollada por la empresa Mindtree para sistemas
empotrados y otras arquitecturas. Sin embargo, todas ellas se apartan del camino elegido por el proyecto upHealth.ES
pues se tratan de soluciones comerciales, cerradas, que no permiten evolucionar el desarrollo con nuevas
funcionalidades en un futuro y se alejan de los paradigmas de diseño que se quieren imponer en la nueva plataforma.
Desde la Universidad Juan Carlos I, en el año 2009, se inició el camino para integrar el nuevo perfil médico Bluetooth
HDP en la pila oficial BlueZ de Linux [17]. Esta iniciativa tenía como objetivo final la inclusión de HDP/MCAP en el núcleo
de Linux y de esta forma ofrecer las nuevas funcionalidades HDP a plataformas como Linux, Android o Meego. En la
Figura 3.13 se muestra un diagrama de bloques de la arquitectura BlueZ (en azul se muestran los bloques que no
estaban previamente implementados en BlueZ o que necesitaron ajustar parte de su código, como L2CAP):
 MCAP es un protocolo basado en L2CAP que facilita un mecanismo sencillo para manejar múltiples canales de
datos. Este protocolo soporta diferentes configuraciones de canal dependiendo de la aplicación o las necesidades
de la transmisión como por ejemplo los modos reliable o streaming.
 HDP es un perfil que simplifica el uso de MCAP y es el encargado de anunciar a otros dispositivos las
características soportadas así como los canales usados por cada perfil. Para estos anuncios hace uso del Service
Discovery Application Profile (SDP). De esta forma, los dispositivos pueden encontrar al manager y conectar con él
o viceversa, el manager puede iniciar una conexión a un dispositivo.
 DI especifica un método por el cual dispositivos Bluetooth comparten información que puede ser usada por otro
dispositivos para encontrar imágenes o software asociado, como por ejemplo controladores específicos. Toda esta
información también se publica en el registro SDP.
Health Device Profile (HDP)
GAP
MCAP
DI
SDP
L2CAP
Host Controller Interface (HCI)
Bluetooth Module
Figura AIII.5. Pila de protocolos BlueZ.
Página | 76
Implementando MCAP
La implementación de MCAP se ha realizado totalmente compatible con la especificación de Bluetooth SIG, soportando
todas las características obligatorias y algunas de las opcionales, como la re-conexión de canal. Como ya se ha
comentado, MCAP requiere los modos de streaming y retransmisión mejorada de L2CAP. Estos modos no existían al
comienzo del desarrollo del perfil Bluetooth HDP, se fueron construyendo paralelamente por otros miembros de BlueZ.
La arquitectura se diseñó para anunciar mediante callbacks, a las capas superiores, todos los eventos que ocurren
durante la ejecución del protocolo. Este diseño permite a la capa HDP recibir todos los eventos en tiempo real de forma
eficiente. Destacar que esta implementación de MCAP es multi-hilo por lo que, cuando se abre una sesión de MCAP, se
inicializa un nuevo hilo esperando nuevas conexiones. Este hilo controla todas las acciones que forman parte del
protocolo como conexión de nuevos canales de datos, desconexiones, re-conexiones, etc.
Implementando HDP
La implementación de Bluetooth HDP simplifica el uso de MCAP al usuario y registra toda la información necesaria en el
registro SDP. Aunque en la primera versión de la implementación se usaban también callbacks para notificar eventos al
usuario, la actual se ha re-escrito para adaptarse a las guías de estilo de BlueZ utilizando el sistema de mensajes de
sistema DBus. Esta implementación esconde por completo el mecanismo de control de los canales, facilitando un
modelo de abstracción basado en un servicio de notificación que notifica nuevos MCAP Communication Links (MCL)
tales como nuevos dispositivos remotos. Además, esta implementación gestiona la creación de nuevos canales de datos
y controla la correcta configuración de los mismos antes de ser notificados al usuario.
DBus
Antes de continuar con la integración de Bluetooth HDP en la plataforma, es imprescindible describir qué es DBus y
para qué es utilizado. DBus es un protocolo de comunicación entre procesos que emplea mensajes. Ha sido diseñado
para que sea ligero y fácilmente utilizado por cualquier programa. La arquitectura de DBus se compone de 2 partes
básicas: la librería libdbus, y un daemon que sirve como repetidor de los mensajes.
La librería libdbus crea conexiones o canales que conectan dos aplicaciones (ver Figura AIII.6). Lo que hace es usar esa
única conexión para conectarse al daemon de DBus, que se comporta como un repetidor. De esta forma, todas las
aplicaciones que se conecten al daemon podrán contactar entre sí. La información se transmite en forma de mensajes
que los hay de dos tipos: métodos y señales. Los métodos sirven para decirle a un objeto que realice una operación.
Pueden requerir parámetros o no. Mientras, las señales sirven para notificar un suceso de interés general. DBus es
independiente del lenguaje que se use para acceder a él y hace que los objetos sean unas entidades no asociadas a
ningún lenguaje concreto. Como un objeto en DBus es una ruta, en DBus los objetos son direccionados a través de una
ruta que equivale a su nombre (un programa publica “objetos-rutas” (ObjectPath) a las que se puede acceder) y son
equivalentes a las que se emplean en el sistema de ficheros de Linux. Cada aplicación debe tener una ruta única y no es
complicado encontrar rutas como “/org/bluez/” ó “/org/freedesktop/DBus”.
A cada objeto le corresponden unos métodos. Estos métodos cambiarán el estado del objeto o nos permitirán recabar
información sobre él. Si se quiere ver métodos y señales en funcionamiento hay que ejecutar el comando dbus-monitor
en una consola de texto y ver cómo se suceden las acciones. Los interfaces son conjuntos de métodos con nombres
predefinidos y acciones acordadas que son conceptualmente cercanos. Un interfaz puede contener todo lo necesario
para reproducir música o buscar texto. Así, los interfaces pueden tener la misma ruta que los objetos y, para poder
diferenciarlos, se llegó al acuerdo de que los objetos tienen rutas con “/” como separador y los interfaces tienen rutas
con “.” como separador (por ejemplo, “/org/freedesktop/DBus” es un ruta y “org.freedesktop.DBus” es un interfaz).
Página | 77
Figura AIII.6. Ejemplo de conexiones de DBus
Un programa que quiera trabajar con DBus debe seguir unos pasos. El primero consiste en conseguir un bus, un canal,
para comunicarse con el daemon de DBus. Si el daemon no está ejecutándose esto será imposible. Por tanto, hay que
asegurarse de que esté funcionando. Una vez que se tenga el bus se ha de conectar con el objeto. Para ello, se debe
usar su ruta. Sin embargo, este objeto no existe realmente: es un objeto DBus. Entonces, ¿cómo se puede trabajar con
él desde una aplicación? La solución a este problema consiste en emplear un objeto proxy o intermediario. Su misión
consiste en hacer de traductor o embajador del objeto DBus dentro de una sesión del programa. Este proxy es, en
realidad, una clase del lenguaje de programación que enmascara los detalles de la interacción con DBus. El proxy se
comporta como si fuese el objeto remoto, pero con sintaxis del lenguaje específico por lo que su uso será natural.
HDP utilizando DBus
La nueva implementación de HDP hace uso de DBus para interactuar con la pila de Bluetooth de forma estándar. Se
compone de 3 interfaces principales:



org.bluez.HealthManager
org.bluez.HealthDevice
org.bluez.HealthChannel
A continuación se describe los métodos y eventos principales de estos interfaces.
El interfaz org.bluez.HealthManager presenta dos métodos principales:


ObjectPath CreateApplication(dictionary config)
void DestroyApplication(ObjectPath application)
Este es el interfaz principal a través del cual registraremos nuestra aplicación gestora de HDP. El método
CreateApplication registra la nueva aplicación aceptando un objeto de tipo Dictionary como parámetro. Este
Dictionary puede contener las siguientes parejas de parámetros:




DataType de tipo uint16 (obligatorio)
Role que puede tomar los valores "Source" o "Sink" (obligatorio)
Description de tipo string (opcional)
ChannelType que puede tomar los valores "Reliable" o "Streaming" (opcional)
Mediante estos parámetros podemos configurar nuestra aplicación que será cerrada cuando se llame al método
DestroyApplication o salgamos del DBus.
Página | 78
El interfaz org.bluez.HealthDevice representa al dispositivo médico remoto y presenta cuatro métodos:




Dictionary GetProperties(). Este método devuelve todas las propiedades del interfaz.
Boolean Echo(). Este método envía una petición de eco al servicio remoto. Devuelve True si la respuesta se
ajusta al bufer enviado o False si ocurre cualquier error.
ObjectPath CreateChannel(ObjectPath application, string configuration). Crea un Nuevo canal de datos. El
string de configuracion indica la calidad del servicio que se va a utilizar tomando los valores “Reliable”,
“Streaming” o “Any”.
Void DestroyChannel(ObjectPath channel). Destruye el canal de datos.
Además de estos métodos, este interfaz está compuesto por tres señales o eventos:



Void ChannelConnecte(ObjectPath channel). Esta señal se dispara cuando se crea un nuevo canal de datos o
cuando un canal ya conocido es reconectado.
Void ChannelDeleted(ObjectPath channel). Esta señal se dispara cuando se elimina un canal de datos.
Void PropertyChanged(string name, variant value). Esta señal indica que una propiedad ha cambiado de valor.
El interfaz org.bluez.HealthChannel representa un canal de datos y presenta tres métodos principales:



Dictionary GetProperties(). Este método devuelve todas las propiedades del interfaz.
Fd Acquire(). Este método devuelve el descriptor de fichero asignado a este canal de datos.
Void Release(). Libera el descriptor de fichero.
En la plataforma desarrollada en este TFM se ha utilizado una implementación de DBus sobre Mono. Sin embargo, dado
el estado experimental en el que todavía se encuentra la implementación de HDP en BlueZ es importante describir
todos los componentes necesarios para que todo funcione correctamente:



Kernel de Linux 2.6.36 o superior. Es necesaria esta versión del kernel de Linux para que no se produzcan
cuelgues en la capa L2CAP, aunque los componentes de BlueZ están trabajando para resolver este problema.
DBus 1.4.0 o superior. El interfaz org.bluez.HealthChannel hace uso de una característica recientemente
implementada en DBus conocida como “Unix Fd passing”. Mediante esta característica, es posible enviar un
descriptor de fichero desde una aplicación a otra.
BlueZ 4.77 o superior. La implementación de HDP apareció a partir de la versión 4.71 de BlueZ de forma muy
experimental. Y aunque todavía sigue teniendo ese estado de desarrollo, las últimas versiones ya presentan la
suficiente estabilidad para trabajar con ellas. Es imprescindible que en la configuración de la compilación se
utilice el flag para hdp: “configure –enable-health”.
El wrapper de Mono para Dbus conocido como dbus-sharp no implementa esta última y más reciente característica de
DBus por lo que se ha tenido que crear una librería compartida en C (hdpbushelper.so) para recuperar el descriptor de
archivo de forma nativa y pasárselo a nuestro código de C# a través de técnicas de marshalling. A continuación se
muestra el código de dicha librería nativa:
gboolean acquire_unix_fd(char *path, int *fd)
{
DBusMessage *message, *reply;
DBusConnection* conn;
DBusError err;
gboolean ret;
dbus_error_init(&err);
conn = dbus_bus_get(DBUS_BUS_SYSTEM, &err);
if (dbus_error_is_set(&err)) {
fprintf(stderr, "Connection Error (%s)\n", err.message);
dbus_error_free(&err);
ret = FALSE;
Página | 79
goto end;
}
message = dbus_message_new_method_call("org.bluez", path,
"org.bluez.HealthChannel",
"Acquire");
if (NULL == message) {
fprintf(stderr, "Message Null\n");
ret = FALSE;
goto end;
}
reply = dbus_connection_send_with_reply_and_block(conn, message,
-1, &err); //-1 is the default timeout
if (dbus_error_is_set(&err)) {
fprintf(stderr, "Error sending dbus message: %s\n", err.message);
dbus_error_free(&err);
ret = FALSE;
goto end;
}
dbus_message_get_args(reply, &err, DBUS_TYPE_UNIX_FD, fd,
DBUS_TYPE_INVALID);
if (dbus_error_is_set(&err)) {
fprintf(stderr, "Error getting arguments from reply: %s\n", err.message);
dbus_error_free(&err);
ret = FALSE;
goto end;
}
ret = TRUE;
end:
if (reply)
dbus_message_unref(reply);
if (message)
dbus_message_unref(message);
return ret;
}
Otra cosa importante observada durante los test con algunos dispositivos es que utilizando adaptadores Bluetooth 2.1
+ EDR se activa la protección “Man in the Middle” y algunos dispositivos no la soportan si no son 2.1. Para observar este
comportamiento se puede configurar udev para que arranque el demonio con el flag “-d” cuando arranque el sistema o
se conecte un dispositivo Bluetooth. Otra posibilidad es arrancar el demonio manualmente. Si se han compilado el
código fuente de BlueZ, en la carpeta “src” aparecerá un binario llamado “bluetoothd”. Nos aseguramos de parar el
demonio que posiblemente tengamos ejecutando mediante “/etc/init.d/bluetooth stop” y posteriormente ejecutamos
como root el binario “bluetoothd –dn”
A continuación analizamos algunos fragmentos de código que interactúan con DBus para utilizar el perfil médico de
Bluetooth HDP. Inicialmente es imprescindible definir las interfaces que expone HDP en C#.
public
public
public
public
public
public
public
public
delegate
delegate
delegate
delegate
delegate
delegate
delegate
delegate
void
void
void
void
void
void
void
void
DeviceDisappearedHandler(string address);
DeviceFoundHandler(string address, IDictionary<string, object> values);
DeviceCreatedHandler(ObjectPath device);
DeviceRemovedHandler(ObjectPath device);
DisconnectedRequestedHandler();
ChannelConnectedHandler (ObjectPath channel);
ChannelDeletedHandler (ObjectPath channel);
PropertyChangedHandler(string name, object val);
[Interface ("org.bluez.HealthManager")]
Página | 80
public interface HealthManager
{
ObjectPath CreateApplication(IDictionary<string, object> config);
void DestroyApplication(ObjectPath application);
}
[Interface ("org.bluez.HealthDevice")]
public interface HealthDevice
{
ObjectPath CreateChannel(ObjectPath application, string configuration);
void DestroyChannel(ObjectPath channel);
bool Echo();
IDictionary<string, object> GetProperties();
event ChannelConnectedHandler ChannelConnected;
event ChannelDeletedHandler ChannelDeleted;
event PropertyChangedHandler PropertyChanged;
}
[Interface ("org.bluez.HealthChannel")]
public interface HealthChannel
{
IDictionary<string, object> GetProperties();
uint Acquire();
void Release();
}
Además de estos interfaces específicos de HDP, se implementan otros de Bluetooth más generales y que nos servirán
para conocer los adaptadores de Bluetooth instalados en nuestro equipo y los dispositivos remotos conectados a ellos.
También se ha de implementar el acceso a la librería nativa desarrollada para obtener el descriptor de Unix.
[DllImport("libhdpdbushelper.so")]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool acquire_unix_fd(string path, ref int fd);
Se ha creado una librería que contiene todo este código relacionado con HDP llamada UZ_ieee_11073_HDPHelper
que facilita el trabajo con este perfil abstrayéndonos de las tareas más complejas. La clase principal de esta librería es
HDPManager.
private Bus _systemBus;
private HealthDevice _healthDevice;
public HDPManager ()
{
_systemBus = Bus.System;
_healthManager = _systemBus.GetObject<HealthManager>("org.bluez", new
ObjectPath("/org/bluez"));
}
En el constructor se obtiene el bus de sistema y el objeto HealthManager que será el punto de entrada para gestionar
el perfil médico de Bluetooth. Esta clase propone como públicos dos métodos que se expondrán al usuario
directamente y que le permitirá conocer los adaptadores de Bluetooth instalados y los dispositivos conectados a ellos:
public ObjectPath[] ListAdapters()
{
_manager = _systemBus.GetObject<Manager>("org.bluez", new ObjectPath("/"));
return _manager.ListAdapters();
}
public ObjectPath[] ListDevices(ObjectPath adapter)
{
_adapter = _systemBus.GetObject<Adapter>("org.bluez", adapter);
Página | 81
return _adapter.ListDevices();
}
Previamente a escuchar el dispositivo médico, desde el gestor de canales se inicializará la aplicación manager:
public void CreateApplication(ushort deviceType)
{
IDictionary<string, object> dict = new Dictionary<string, object>();
dict.Add("DataType", deviceType);
dict.Add("Role", "Sink");
_appPath = _healthManager.CreateApplication(dict);
}
Para esta acción será imprescindible determinar qué tipo de dispositivo médico se va a escuchar. Y
finalmente, cuando ya se ha elegido adaptador, dispositivo y tipo de dispositivo a escuchar, se comenzará a
escuchar el dbus.
public void ListenHealthDevice(ObjectPath device)
{
_healthDevice = _systemBus.GetObject<HealthDevice>("org.bluez", device);
_healthDevice.ChannelConnected += delegate(ObjectPath vchannel) {
Console.WriteLine("Se creó un canal: ");
};
_healthDevice.ChannelDeleted += delegate(ObjectPath channel) {
Console.WriteLine("Se borró un canal");
};
_healthDevice.PropertyChanged += delegate(string name, object val)
{
Console.WriteLine("Una propiedad cambió: " + name + " Value: " + val);
if(name.Equals("MainChannel"))
{
HealthChannel channel = _systemBus.GetObject<HealthChannel>("org.bluez",
(ObjectPath)val);
ObjectPath cc = (ObjectPath)val;
int descriptor = -1;
bool ret = NativeMethods.acquire_unix_fd(cc.ToString(), ref descriptor);
if(ret)
{
UnixStream stream = new UnixStream(descriptor, true);
if(StreamConnected != null)
StreamConnected(stream);
}
}
};
}
En este caso de ejemplo se han utilizado métodos anónimos para compactar el código. En el momento que
la propiedad MainChannel cambia, se obtiene el descriptor llamando a la librería nativa y se lanza un evento
con el stream ya creado. En ese momento, el proceso continúa de forma similar a cualquier otro canal
gracias a la abstracción de capas descrita en anteriores capítulos.
Página | 82
Integración de los servicios en la nube
Config profile
El diseño del Config Profile ha sido un elemento clave en estudios previos [20]. Este archivo contiene toda la
información asociada a los procedimientos que deben seguir los pacientes que gestiona un mismo manager CE. En la
Figura AIII.7 se muestra el concepto del Config Profile en el contexto de la plataforma de telemonitorización.
Agentes
Manager
datos
x73
x73
Config
Profile
Dispositivos Médicos
Compute Engine
idCE
Otra
info
Red
+
Datos de
paciente
Base de
Datos
Datos de
paciente
Config
Profile
Servidor de Gestión
Servidor de HCE
Figura AIII.7.Situación y función del Config Profile en la plataforma de telemonitorización
Este elemento Config Profile es generado en el servidor de gestión (Management Server, MS). La información que
contiene procede de una base de datos que es completada a partir de dos fuentes de información distintas. Por un lado
se obtienen los datos necesarios de la HCE de cada paciente y, por otro lado, se introduce información adicional al caso
de uso de cada paciente manualmente. Una vez completa la información que debe contener el Config Profile se genera
un archivo XML que es el que se envía a CE para que el proceso de monitorización sea correcto. La información
necesaria para rellenar el Config Profile estaría contenida en una base de datos que almacenaría datos como
información genérica relativa a dispositivos médicos, registro de los CEs que se están utilizando para llevar a cabo la
monitorización de pacientes, información sobre los pacientes que están siendo controlados, médicos o enfermeros que
están realizando el seguimiento de pacientes, medidas realizadas, etc. En este TFM se ofrece una nueva perspectiva
para el Config Profile ya que, dada la complejidad que requiere el diseño, desarrollo e implementación de un servidor
de gestión que ofrezca seguridad y genere un Config Profile de forma eficiente, el objetivo de este TFM es trasladar
parte de esa información a la nube (especialmente las tareas a realizar por cada usuario), sirviendo como prueba de
concepto para un futuro donde toda la información sea almacenada de forma distribuida.
Diseño del antiguo Config Profile
La información necesaria para rellenar Config.Profile estaría contenida en una base de datos que sigue el modelo de la
Figura AIII.8. Para su diseño nos hemos servido de los análisis explicados en los apartados previos a este capítulo.
La base de datos consta de las siguientes tablas de relaciones:
 MD Table: contiene información muy genérica relativa a los dispositivos médicos. Cada dispositivo de un tipo,
marca y modelo tendrá un identificador único por lo que en esta tabla se recogen todos los dispositivos
distintos que pueden utilizarse en la monitorización de pacientes. Como se ha dicho, esta tabla contendrá el
identificador de MD, idMD, el tipo, MDType, la marca, trademark, y el modelo, model.
 CE Table: en esta tabla quedarán registrados todos los CEs que se están utilizando para llevar a cabo la
monitorización de pacientes. Para cada CE se almacenará su identificador único, idCE, la marca y modelo del
dispositivo, trademark y model, y otro parámetro muy importante, idUSER, que indicará qué tipo de uso se da
al CE, es decir si lo utiliza un paciente en un entorno domiciliario, un enfermero o médico en uno hospitalario o
finalmente un monitor o un deportista en un entorno fitness.
Página | 83
Figura AIII.8. Modelo de la base de datos




Patient Table: aquí estarán recogidos todos los pacientes que de una forma u otra están siendo controlados y
que tendrán un único identificador, idPAC. La información que se ha considerado necesaria para el
Config.Profile es nombre, name, y apellido, surname, para que el entorno que vea el usuario sea dirigido y
personalizado. La edad, birthday, y el sexo, sex, puesto que son factores que influyen en los dispositivos
médicos que pueden tener asociados, en las enfermedades y en las prescripciones médicas. Además, se está
considerando que estos dos factores influyan en la apariencia que tendrá el GUI de la aplicación que se está
diseñando e implementando paralelamente. Todo lo expuesto hasta ahora justifica el caso domiciliario pero
también son los parámetros que se han considerado importantes para el caso hospitalario.
Doctor Table: en la presente tabla quedarán registrados todos los médicos o enfermeros que estén realizando
el seguimiento de algún paciente. Cada uno de ellos tendrá su propio identificador como en los casos
anteriores, idDOC. También será necesario conocer el nombre y apellido, name y surname, del personal
médico así como el cargo que desempeñan. Esta última característica vendrá indicada por idROL por lo que
con este campo se podrá conocer si la persona que realiza el seguimiento es un médico, un enfermero o un
monitor para el escenario de fitness. Este parámetro es muy importante porque dependiendo del tipo de
cargo que desempeñe el usuario este tendrá unos permisos en la aplicación u otros. Además, como en el caso
de los pacientes, estos factores son los que se han considerado importantes porque para el caso hospitalario
estos influirán en la apariencia del GUI. Para el escenario domiciliario en el que el usuario es un paciente es
importante para este que sepa quién es el que está vigilando su salud.
Measure Table: debido a que con cada MD pueden tomarse diferentes tipos de medidas (p. ej. con un
tensiómetro pueden tomarse la presión sistólica, la diastólica y el ritmo cardiaco) esta tabla se ha diseñado de
forma que tenga listadas todas las medidas distintas que pueden tomarse con los diferentes dispositivos
médicos aunque sean del mismo tipo (p. ej. el ritmo cardiaco medido con el tensiómetro 705 IT-BT de OMRON
tendrá un identificador distinto al medido con el tensiómetro UA-787 de A&D). Por lo tanto los campos que
existirán en esta tabla serán el identificador de medida, idMeasure, el tipo de medida, MeasureType, el
identificador del dispositivo al que está asociada dicha medida, idMD, y los umbrales técnicos para esa medida,
tanto superior como inferior, que dicho MD puede medir, MaxFuncThres y MinFuncThres.
Interpers Table: en esta tabla se recogen las relaciones que conciernen a algunas de las tablas ya explicadas. Es
aquí donde queda indicado quienes son los usuarios de cada CE así como los pacientes que tiene asociados
cada doctor/ enfermero. El identificador clave será idREL y en cada fila se asociará a cada CE, idCE, los
pacientes y médicos, idPAC e idDOC, que están asociados a este.
Página | 84

Procedure Table: esta es la tabla final en la quedarán asociados todos los procedimientos a llevar a cabo para
cada paciente. A cada paciente, que estará representado en esta tabla por idREL, se le asociarán todas las
medidas que debe realizarse, idMeasure, con la fecha y hora a las que debe realizarse cada toma, date.
Dependiendo de la gravedad de cada paciente, PATType, cada medida tendrá asociados unos umbrales
médicos superior e inferior, MaxMedThres y MinMedThres, impuestos por el especialista.
El relleno de esta base de datos se realizará en el centro de Salud por personal experto. Cada paciente al que se decida
realizarle un seguimiento debe quedar registrado en la base de datos en la que deben quedar reflejadas las dolencias
por las que se trata a cada paciente, los dispositivos asociados al mismo, así como las pautas prescritas por el
especialista para que el seguimiento sea óptimo.
Implementación del Config Profile
Como se ha citado anteriormente el Config Profile será un archivo XML que se implementará en el servidor de gestión,
MS, y se enviará a CE. Puede sufrir cambios y es importante que en el CE siempre esté la versión actualizada.
Se ha considerado el usar XML como forma de envío de la información ya que propone un estándar para el intercambio
de información estructurada entre diferentes plataformas. XML es una tecnología sencilla que tiene a su alrededor
otras que la complementan y la hacen mucho más grande y con unas posibilidades mucho mayores. Tiene un papel
muy importante en la actualidad ya que permite la compatibilidad entre sistemas para compartir la información de una
manera segura, fiable y fácil.
Para implementar el archivo XML se partirá de un esquema XML y se utilizará la herramienta JAXB puesto que permite
crear clases Java a partir de un esquema XML. En el Anexo E se detallada un poco más el por qué se han elegido estas
tecnologías. El Config Profile responde al esquema indicado en la Figura AIII.9.
El parámetro de entrada que es necesario para generar el Config Profile es idCE, puesto que cada Config Profile es único
por CE. La forma de interpretar el archivo XML es la que se detalla a continuación.
La información que puede encontrarse a primer nivel es el listado con todos los pacientes asociados a un CE concreto.
Para el caso domiciliario posteriormente aparece un listado con el personal médico asociado a cada paciente. La
correspondencia será uno a uno, es decir, al primer paciente lo controla el primer doctor, al segundo el segundo y así
sucesivamente. En el caso hospitalario solo aparecerá un único doctor o enfermero pues es él quien lleva el control de
todos los pacientes. A este mismo nivel se obtendrá también la información dada por idUSER que indica quién hace uso
del CE así como qué CE es el que se está utilizando.
De las distintas partes diferenciadas que componen el archivo XML la que nos va a ofrecer una mayor cantidad de
información es la parte relativa a los pacientes. Es aquí donde vienen indicados los procedimientos a llevar a cabo para
tratar a cada paciente.
Dentro de la información asociada a los pacientes, en segundo nivel se encuentra su nombre, apellido, fecha de
nacimiento, sexo así como una lista de los diferentes dispositivos médicos que ese paciente tiene asociados. De cada
MD se obtiene información, en un tercer nivel, del tipo de dispositivo que se trata, el modelo, la marca así como una
lista con todas las medidas que el paciente ha de tomarse con ese determinado MD. Ya por último, en un cuarto nivel
se tiene la información asociada a cada medida. El tipo, los umbrales funcionales que vienen determinados por cada
dispositivo, los umbrales médicos que vienen prescritos por el especialista y una lista con los instantes en los que deben
efectuarse las tomas.
La información asociada al personal experto es más breve. Se obtiene el nombre y el apellido del usuario así como su
rol que será un aspecto importante a la hora de otorgar al usuario ciertos permisos sobre la aplicación.
Página | 85
Figura AIII.9. Esquema XML del Config Profile
Moviendo el Config Profile a la nube
Este proyecto ofrece una nueva perspectiva para el Config Profile. Dada la complejidad que requiere el diseño,
desarrollo e implementación de un servidor de gestión que ofrezca seguridad y genere Config Profiles de forma
eficiente, nuestro objetivo es trasladar parte de esa información a la nube (especialmente las tareas a realizar por cada
usuario), sirviendo como prueba de concepto para un futuro donde toda la información sea almacenada de forma
distribuida.
A continuación se puede observar un ejemplo de Config Profile como se consideraba anteriormente:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Users xmlns ="http://www.example.org/configProfile">
<patient>
<name>Juan</name>
<surname>Español</surname>
<birthday>1984-06-09 00:00:00.0</birthday>
<sex>Hombre</sex>
<MD>
<measure>
<MeasureType>Presión Diastólica</MeasureType>
<Date>2009-06-25 09:00:00.0</Date>
<Date>2009-06-25 09:05:00.0</Date>
<Date>2009-06-25 21:00:00.0</Date>
<Date>2009-06-25 21:05:00.0</Date>
<MaxFuncThres>299.0</MaxFuncThres>
<MinFuncThres>0.0</MinFuncThres>
Página | 86
<MaxMedThres>60.0</MaxMedThres>
<MinMedThres>40.0</MinMedThres>
</measure>
<measure>
<MeasureType>Presión Sistólica</MeasureType>
<Date>2009-06-25 09:00:00.0</Date>
<Date>2009-06-25 09:05:00.0</Date>
<Date>2009-06-25 21:00:00.0</Date>
<Date>2009-06-25 21:05:00.0</Date>
<MaxFuncThres>299.0</MaxFuncThres>
<MinFuncThres>0.0</MinFuncThres>
<MaxMedThres>120.0</MaxMedThres>
<MinMedThres>90.0</MinMedThres>
</measure>
<measure>
<MeasureType>Pulso</MeasureType>
<Date>2009-05-28 09:00:00.0</Date>
<Date>2009-05-08 21:00:00.0</Date>
<MaxFuncThres>180.0</MaxFuncThres>
<MinFuncThres>40.0</MinFuncThres>
<MaxMedThres>0.0</MaxMedThres>
<MinMedThres>0.0</MinMedThres>
</measure>
<MDtype>Tensiómetro</MDtype>
<trademark>OMRON</trademark>
<model>705IT BT</model>
</MD>
</patient>
<doctor>
<name>Jesús</name>
<surname>Rodríguez</surname>
<rol>médico</rol>
</doctor>
<doctor>
<name>Borja</name>
<surname>Calvo</surname>
<rol>enfermero</rol>
</doctor>
<user>paciente</user>
<PDA>1</PDA>
</Users>
Mediante la utilización de los servicios en la nube, el contenido del Config Profile es más sencillo. Aunque únicamente
es una primera aproximación, para esta prueba de concepto se considera un Config Profile como el siguiente:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Users xmlns ="http://www.example.org/configProfile">
<patient>
<name>Juan</name>
<surname>Español</surname>
<birthday>1984-06-09 00:00:00.0</birthday>
<sex>Hombre</sex>
<gappsuser>uz.juanespanol</gappsuser>
<gappspass>#2e/@98ksp=q&l</gappspass>
</patient>
</Users>
El nuevo Config Profile se hace más sencillo moviendo la información sobre las medidas y los dispositivos a los servicios
en la nube, en este caso Google Calendar. Se ha añadido sin embargo dos nuevos campos definiendo el nombre de
usuario del paciente y la contraseña (cifrada) que identifican al paciente en Google Apps. Pero, ¿cómo se define la
anterior información en los servicios en la nube? Utilizando la misma estrategia que utilizan compañías como HTC para
introducir información propia en las Google Apps, nuestra plataforma utiliza los campos vacíos que ofrecen las
diferentes aplicaciones de Google para almacenar la información asociada a cada usuario en forma de XML. Analicemos
como se introduce la información sobre las tareas y eventos a realizar o asistir por el paciente. En este caso utilizamos
Google Calendar, un servicio online de calendario que nos permite introducir recordatorios, tareas o cualquier otro tipo
de evento. Si añadimos un evento, inicialmente veremos la siguiente figura:
Página | 87
Figura AIII.10.Evento de Google Calendar
Un evento de Google nos permite introducir el título y fecha del evento, en nuestro caso una medida, con lo cual esa
información ya no la necesitaremos en el XML. El resto de información necesaria, la colocaremos en el campo de
descripción con el siguiente formato:
<uzHealthData>
<measure>
<MeasureType>2677</MeasureType>
<MaxFuncThres>299.0</MaxFuncThres>
<MinFuncThres>0.0</MinFuncThres>
<MaxMedThres>60.0</MaxMedThres>
<MinMedThres>40.0</MinMedThres>
</measure>
<Device>
<trademark>OMRON</trademark>
<model>705IT BT</model>
<protocol>X73PHD</protocol>
<technology>BTPHD</technology>
<deviceconfig>
<PIN>3921334</PIN>
</deviceconfig>
</Device>
<doctor>
<name>Gregory</name>
<surname>House</surname>
<rol>Especialista</rol>
<email>[email protected]</email>
</doctor>
</uzHealthData>
Es decir, un evento está asociado a una medida de un usuario y contiene la siguiente información:



Medida. Se define el tipo de medida (que puede ser pulso, sistólica, diastólica… etc) y los umbrales en los que
se espera esa medida.
Dispositivo. Información del dispositivo de medida que se espera utilizar por parte del paciente. Entre la
información se define el protocolo y tecnología del dispositivo. Y en caso de que sea necesario, se define la
configuración necesaria para trabajar con ese dispositivo. Por ejemplo, en este caso que es un dispositivo
Bluetooth, se envía el PIN para realizar el emparejamiento con el dispositivo de forma automática.
Doctor. Información del doctor que controlará esta medida.
Con todo esto, la pantalla de Google Calendar quedaría como:
Página | 88
Figura AIII.11.Evento de Google Calendar con información de uzHealth
Esta información es totalmente transparente al usuario, que únicamente verá los eventos y tareas en la plataforma de
telemonitorización. Cuando el nuevo evento aparezca, el usuario simplemente puede hacer clic en el botón “Realizar
Medida” para que esta comience de forma automática, configurando el dispositivo sin necesidad de la participación del
usuario y enviando la medida al servidor de telemonitorización.
El objetivo principal es hacer el uso de la aplicación más sencilla al usuario de tal forma que el proceso de medida sea
tan fácil como sea posible. Hay que recordar que este tipo de aplicaciones estará orientado en mayor parte a personas
mayores, sin conocimientos informáticos, y una complejidad de la aplicación puede llevar a un mal uso de la misma o
incluso a no utilizarla nunca.
3.6. Integración con el servidor de HCE
Este TFM presenta el desarrollo de una plataforma de telemonitorización de pacientes sobre sistema operativo Linux y
que integra las normas de interoperabilidad X73PHD y UNE-EN/ISO13606. Es una solución estándar y ubicua para
entornos de salud personal que utiliza Bluetooth HDP para la comunicación entre los dispositivos médicos y el manager
X73PHD. Además, se homogeneíza la comunicación de área extendida (Wide Area Network, WAN) con el servidor de
HCE mediante tecnologías Web Services (WS) y comunicación interoperable según XML (ver Figura AIII.12).
En las secciones anteriores se ha definido y analizado X73PHD como el estándar internacional para interoperabilidad de
dispositivos médicos. Este es el primer paso para llegar a una plataforma totalmente interoperable. No obstante, para
lograr niveles óptimos en la calidad asistencial y continuidad de cuidado de un paciente, es necesario que las partes
implicadas en el seguimiento/control de su enfermedad interactúen también de forma interoperable. El estándar
internacional para lograr interoperabilidad de HCE [21] entre sistemas sanitarios es UNE-EN/ISO13606 [22]. Esta norma
especifica cómo la información clínica debe ser transmitida basándose en un modelo dual: Modelo de Referencia y
Modelo de Arquetipos. Sin embargo, como ya se ha comentado a lo largo de este proyecto, la existencia de normas
médicas no garantiza la correcta implementación de una solución homogénea de salud personal dado que la
integración de las diferentes normas en soluciones extremo a extremo todavía sigue siendo una tarea compleja e
intrincada. Este es uno de los principales retos en la investigación de estándares: su posterior implementación, en
forma de soluciones reales, en el sistema sanitario. Algunas contribuciones anteriores han diseñado implementaciones
aisladas tanto de una plataforma de monitorización de pacientes basadas en X73 [23] como de un servidor de HCE
basado en UNE-EN/ISO13606 [24]. Estos desarrollos previos, si bien han servido como prueba de concepto del correcto
funcionamiento de ambas normas, también han constatado una ausencia de interoperabilidad en la comunicación
Página | 89
extremo a extremo. Algunas otras iniciativas como IHE y Continua o proyectos como Healthy Interoperability [25] ya
han abordado este problema. Sin embargo, hacen uso de mensajes HL7 y no del estándar europeo UNE-EN/ISO13606.
Interfaz PAN
(Bluetooth)
Dispositivos médicos
(Agentes X73PHD)
Interfaz WAN
(XML)
Computer Engine
(Manager X73PHD)
Servidor HCE
(ISO/EN13606)
Figura AIII.12. Esquema conceptual de la plataforma de telemonitorización basada en estándares extremo a extremo
Así, X73PHD cubre la comunicación en el interfaz PAN y UNE-EN/ISO13606 define el intercambio interoperable de HCE.
Pero, hasta el momento, no se ha definido un estándar específico para el interfaz WAN entre el manager y el servidor
de HCE. Sin embargo, se han propuesto algunas iniciativas (lideradas por IHE y Continua Health Alliance) para suplir en
parte esta carencia. El Comité Técnico IHE-Patient Care Device (IHE-PCD) ha propuesto el perfil Device to Enterprise
Communication (DEC, llamado PCD-01) [26]. Este perfil emplea mensajes HL7 v2.6 para conectar el manager y el
servidor HCE. El perfil Subscribe to Patient Data (llamado PCD-02) [27] es una extensión de este perfil que divide este
interfaz para filtrar los datos generados en el entorno de e-Salud. Dentro de las directrices de Continua Health Alliance,
este interfaz se ha dividido en dos subinterfaces, incluyendo un nuevo elemento dirigido a servicios de back-end. El
primer subinterfaz está fuera del alcance de las denominadas guías de diseño (Continua Design Guidelines). Para el
segundo subinterfaz, se ha elegido el perfil IHE Cross-Enterprise Document Reliable Interchange (XDR) [28] y, sobre este,
el documento HL7 Personal Health Monitoring (PHM) [29].
Estas propuestas de IHE y Continua Health Alliance no implican la definición de nuevos estándares ad-hoc. Al contrario,
impulsan algunos perfiles y procedimientos de otros estándares, esencialmente HL7 (IHE-DEC impulsa mensajes HL7
v2.6 y Continua Health Alliance hace uso del perfil HL7-PHM). Debido a que la implementación propuesta está basada
en X73PHD y UNE-EN/ISO13606, estos enfoques basados en HL7 no es la opción más adecuada. Además, el detalle y
complejidad de HL7 ha llevado al diseño de una arquitectura WS apoyada por propuesta basada en XML. Este
documento XML satisface los particulares requerimientos de las implementaciones X73PHD y UNE-EN/ISO13606
previamente detalladas con elevada especificidad para mantener los requisitos de interoperabilidad, seguridad,
fiabilidad y privacidad al mismo tiempo que la simplicidad de aplicación. Un ejemplo de este XML se muestra a
continuación:
<collecter>
<idCollecter>12345678</idCollecter>
<soc>
<deviceInfo>
<extraDeviceInfo>
<attribute>
<id>MDC_ATTR_SYS_ID</id>
<value>123456</value>
</attribute>
<attribute>
<id>MDC_ATTR_ID_TYPE</id>
<value>MDC_MASS_BODY_ACTUAL</value>
</attribute>
<attribute>
<id>MDC_ATTR_VAL_BATT_CHARGE</id>
<value>60</value>
</attribute>
<attribute>
<id>MDC_ATTR_ID_MODEL</id>
<value>DeviceManufacturer</value>
Página | 90
<value>DeviceModel</value>
</attribute>
</extraDeviceInfo>
</deviceInfo>
<measurement>
<timeStamp>15/04/2010-18:10:15</timeStamp>
<attribute>
<id>MDC_ATTR_ID_TYPE</id>
<value>MDC_MASS_BODY_ACTUAL</value>
</attribute>
<attribute>
<id>MDC_ATTR_NU_VAL_OBS_SIMP</id>
<value>53.5</value>
</attribute>
<attribute>
<id>MDC_ATTR_UNIT_CODE</id>
<value>MDC_DIM_KILO_G</value>
</attribute>
</measurement>
<contextInfo>
<code/>
<value/>
</contextInfo>
</soc>
</collecter>
Desde el punto de vista del manager, el XML diseñado tiene en cuenta los datos disponibles que son relevantes para su
incorporación en la HCE para algunas especializaciones de dispositivos médicos, manteniendo una nomenclatura
homogénea. Desde el punto de vista del servidor de HCE, se incluye la información necesaria para integrar los datos en
la arquitectura UNE-EN/ISO13606. El contenido y estructura XML depende del fichero de configuración Config Profile
(explicado en la sección anterior), obtenido del servidor de HCE, y configurado en colaboración con especialistas
médicos y a partir de análisis previos de casos de uso [30]. Así, como se muestra en el ejemplo, el XML incluye
información específica de los pacientes (idCollecter), sus dispositivos asociados (deviceInfo), el procedimiento de
medida (timeStamp), y otra información técnica como tipo de dispositivo (mdc_ attr_id_type), modelo
(mdc_attr_id_model), niveles de batería (mdc_attr_val_batt_charge), etc.
Integración con el nivel de aplicación
Finalmente, la implementación de la plataforma uz.Health se completa con el desarrollo de un interfaz gráfico sencillo,
que permite al usuario utilizar todos los componentes y procesos descritos a lo largo del capítulo. Es imprescindible
aclarar que este interfaz se ha construido únicamente a modo demostración y que presenta grandes carencias de
usabilidad, robustez y accesibilidad, carencias que serán corregidas con la elaboración del futuro interfaz gráfico
totalmente accesible que prepara el grupo de investigación.
El interfaz gráfico ha sido desarrollado en GTK# y Mono y su utilización está orientada a plataformas Linux aunque la
portabilidad a entornos Windows es casi inmediata.
Pantalla de bienvenida
La pantalla de bienvenida de uz.Health nos presenta un breve mensaje que indica los pasos que debe seguir el usuario
para identificarse con el servidor de telemonitorización. Aunque todavía no está implementado, en un futuro se espera
que se integre la identificación mediante DNI electrónico o biometría.
Página | 91
Figura AIII.13. Pantalla de bienvenida
Pantalla de inicialización de servicios
Introducidos el DNI o número de identificación de usuario y contraseña, se produce la inicialización de los servicios:
Figura AIII.14.Pantalla de inicialización de servicios
Si la inicialización de cada uno de los servicios es correcta aparecerá una imagen verde al lado del servicio. Si se produce
un error, aparece un símbolo rojo como el de la siguiente figura:
Página | 92
Figura AIII.15.Pantalla de inicialización de servicios donde uno ha fallado
Una vez terminada la inicialización de servicios se presenta al usuario la opción de volver al inicio (si algún servicio no se
ha inicializado correctamente) o la opción se ir a la siguiente pantalla.
Home de usuario
Esta es la pantalla principal del usuario, conocido como Home. En ella se presentan las opciones más habituales para el
usuario. A la izquierda aparece la zona de notificaciones donde se avisará al usuario si tiene algún correo electrónico,
alguna tarea pendiente o un mensaje de chat. Debajo los botones para poder contactar con el centro de salud,
consultar la historia clínica electrónica o realizar una medida manual que no esté planificada.
En pestañas se distribuyen los servicios de usuario: Tareas y eventos, correo, mensajes instantáneos y los contactos.
Figura AIII.16. Pantalla principal de usuario
Página | 93
Tareas y eventos
En la pestaña de tareas y eventos encontraremos las tareas programadas por el doctor para el usuario y las diferentes
citas planificadas por el centro de salud. Seleccionando una tarea aparecerá la información extendida a la derecha junto
con el botón “Realizar Tarea”. Haciendo clic sobre ese botón llegaremos a la pantalla del proceso de medida con todos
los parámetros configurados como se describió en el anterior apartado.
Figura AIII.17. Pantalla de Tareas y eventos
Correo
En la pestaña de correo se presenta un mini cliente de correo donde podremos consultar los correos enviados por los
doctores u otros pacientes de nuestro centro de salud. También podremos responder a los correos o crear uno nuevo.
Este servicio es aportado por Gmail.
Figura AIII.18. Pantalla de Correo
Página | 94
Mensajes instantáneos
Esta pestaña funciona a modo de chat para realizar consultas a los doctores o chatear con otros pacientes. Este servicio
es facilitado por Google Talk.
Figura AIII.19. Pantalla de mensajes instantáneos
Contactos
En la pestaña de contactos encontraremos el contacto de doctores y otros usuarios con la información para escribirles
un email o contactar con ellos de forma tradicional.
Figura AIII.20. Pantalla de Contactos
Página | 95
Una medida se puede realizar de forma planificada seleccionando la tarea desde la pestaña de “Tareas y Eventos” o
puede realizarse la medida de forma manual. A continuación observamos el proceso de medida manual.
Proceso de medida
La pantalla de medida manual propone realizar la medida siguiendo 4 pasos:
1.
2.
3.
4.
Seleccionar el tipo de dispositivo
Seleccionar el protocolo de comunicaciones del dispositivo
Seleccionar la tecnología de transporte usada por el dispositivo
En caso de que sea necesario, configurar los parámetros de la tecnología de transporte.
Figura AIII.21. Pantalla de configuración de medida
En la Figura AIII.22 vemos un ejemplo de la medida con un pulsioxímetro X73 mediante HDP. En este caso hay que
seleccionar el adaptador Bluetooth y el dispositivo médico que se va a utilizar.
Página | 96
Figura AIII.22. Pantalla de configuración de medida llena de datos
Finalmente, en la última pantalla observamos el proceso de medida.
Figura AIII.23. Pantalla de medida final
A la derecha, a modo de depuración, se ha colocado un analizador de protocolo pudiendo observar los diferentes
estados por los que pasa el núcleo de comunicaciones. Una vez realizada la medida, haciendo clic en el botón “Enviar
Medida” enviará la medida al servidor de telemonitorización mediante el XML generado siguiendo la descripción del
apartado 3.4 de esta memoria. Si se inicia la medida desde la pestaña de “Tareas y eventos” se llega directamente a
esta pantalla ya que la configuración del dispositivo es obtenida desde la propia tarea.
Página | 97
Página | 98