Repositorio Institucional de Documentos

UNIVERSIDAD DE ZARAGOZA CENTRO POLITÉCNICO SUPERIOR PROYECTO FIN DE CARRERA Ingeniería de Telecomunicación I Im mp pl le em me en nt ta ac ci ió ón n d de e u un na a p pl la at ta af fo or rm ma a d de e t te el le em mo on ni it to or ri iz za ac ci ió ón n d de e p pa ac ci ie en nt te es s e es st tá án nd da ar r, , o op pe en n s so ou ur rc ce e y y u ub bi ic cu ua a b ba as sa ad da a e en n I IS SO O/ /I IE EE EE E 1 11 10 07 73 3- -P PH HD D s so ob br re e A An nd dr ro oi id d. . Julio, 2010 Pedro Funes Salas Director Pilar del Valle García Ponente Ignacio Martínez Ruiz Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 1 Resumen Resumen La telemedicina se entiende como el uso de las tecnologías de la información y las telecomunicaciones para el diagnóstico médico y cuidado de pacientes, ofreciendo un servicio cómodo y mejorando la calidad de vida de los usuarios. En ese ámbito se enmarca este PFC, que continúa con la línea de investigación llevada a cabo en los últimos años por el grupo X73Spain de la Universidad de Zaragoza, abriendo la plataforma de telemonitorización existente a nuevos entornos open source basados en el sistema operativo Android, y añadiendo soporte para nuevos dispositivos médicos. El software se ha desarrollado en Java, más concretamente en J2ME (Java Mobile Edition), por tratarse del lenguaje indicado para este sistema operativo, y ser además un entorno libre de trabajo (open source). Android ofrece un gran potencial para la implementación de nuevas funcionalidades y servicios. Al tratarse de un entorno libre, permite una rápida integración con otras plataformas, además de ofrecer una serie de herramientas que facilitan el desarrollo de aplicaciones. Por otro lado, los terminales existentes que cuentan con este sistema operativo, poseen unas prestaciones de muy alto nivel: pantallas de gran tamaño y calidad visual, cámaras con alta definición, procesadores eficientes, etc. Todas estas características hacen de Android un entorno más que apropiado para la elaboración de este proyecto. Para conseguir la interoperabilidad de esta plataforma con otros entornos de e-Salud existentes, es necesaria la aplicación de un estándar que proponga una serie de normas en cuanto a intercambio de datos, representación de la información y gestión de dispositivos médicos. Se establece entonces la norma ISO/IEEE 11073 (X73) como guía en el desarrollo de este PFC. Este proyecto proporciona un entorno ubicuo donde se facilita el intercambio de información médica entre los diferentes dispositivos médicos que pueda necesitar el paciente, y en diversos casos de uso. De esta forma, se dispone de un terminal Agente, que representa varios dispositivos médicos estándar (termómetro, tensiómetro, pulsioxímetro y báscula), y otro terminal haciendo las funciones de Manager, ambos simulados en teléfonos Android. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android Agradecimientos 2 Me gustaría agradecer especialmente a Pilar, a Nacho y al resto de compañeros, su disponibilidad y ayuda prestada en todo momento. Y como no, a las personas cercanas, mi familia y amigos, por su paciencia y comprensión, pero sobre todo, por estar ahí. "Ninguna fuerza doma, ningún tiempo consume, ningún mérito iguala, el nombre de la libertad." N. Machiavelli Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android Índice 3 Índice de contenidos Acrónimos y siglas ........................................................................................... 7 1. Introducción ............................................................................................ 8 1.1 Telemedicina y necesidad de cubrir nuevos estándares ....................................... 8 1.2 Norma ISO/IEEE 11073 .......................................................................................... 9 1.3 Android ................................................................................................................ 10 1.4 Antecedentes del proyecto ................................................................................. 10 1.5 Motivación ........................................................................................................... 12 1.6 Objetivos ............................................................................................................. 13 1.7 Estructura de la memoria .................................................................................... 13 2. Estado del arte ...................................................................................... 15 2.1 Organismos y normas para la salud .................................................................... 15 2.2 MDs y Android ..................................................................................................... 16 2.3 Dispositivos médicos con X73 ............................................................................. 18 2.4 Evolución de la plataforma de telemonitorización ............................................. 20 2.4.1 Plataforma 1.0 – alfa ................................................................................... 21 2.4.2 Plataforma 1.5 – beta .................................................................................. 21 2.4.3 Plataforma 2.0 – release ............................................................................. 22 2.4.4 Plataforma 2.1 – BT ..................................................................................... 22 3. Análisis y diseño .................................................................................... 24 3.1 Análisis de requisitos ........................................................................................... 24 3.2 Especificación ...................................................................................................... 28 3.3 Diseño y arquitectura .......................................................................................... 30 3.3.1 Binary Notes ................................................................................................ 31 3.3.2 IEEE 11073 ................................................................................................... 32 3.3.3 Utils, Messages y Events ............................................................................. 32 3.3.4 Manager ...................................................................................................... 32 3.3.5 Agent ........................................................................................................... 34 Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android Índice 4 4. Desarrollo e implementación ................................................................. 35 4.1 Estructura del código .......................................................................................... 35 4.2 Programación ...................................................................................................... 36 4.3 Funcionamiento del programa ............................................................................ 41 4.3.1 Sistema de ficheros XML ............................................................................. 45 5. Evaluación y resultados ......................................................................... 48 5.1 Prueba de software ............................................................................................. 48 5.2 Pruebas de interoperabilidad .............................................................................. 52 5.3 Pruebas de hardware .......................................................................................... 54 6. Cronograma de implantación ................................................................. 55 6.1 Cronograma de implantación .............................................................................. 55 6.2 Diagrama de Gantt .............................................................................................. 57 7. Conclusiones y líneas futuras ................................................................. 58 7.1 Conclusiones ........................................................................................................ 58 7.2 Líneas futuras ...................................................................................................... 59 Referencias .................................................................................................... 61 Anexo A – La norma ISO/IEEE 11073 .............................................................. 63 Anexo B – Android ......................................................................................... 67 B.1 Arquitectura ........................................................................................................ 67 B.2 Estructura de una aplicación Android ................................................................. 69 B.3 Dispositivos disponibles ...................................................................................... 70 B.4 Desarrollo de aplicaciones .................................................................................. 72 Anexo C – Definición de medidas ................................................................... 75 C.1 Temperatura ........................................................................................................ 75 C.2 Tensión ................................................................................................................ 76 C.3 Pulso .................................................................................................................... 77 C.4 Nivel de oxígeno .................................................................................................. 78 C.5 Peso ..................................................................................................................... 79 Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android Índice 5 Índice de figuras Figura 1.1 – Arquitectura de la norma IEEE 11073 y evolución de X73PoC a X73PHD ....... 9 Figura 1.2 – Plataforma de telemonitorización extremo a extremo ................................ 10 Figura 2.1 – Arquitectura del proyecto MOCA .................................................................. 18 Figura 2.2 – Modelo 2500 PalmSAT® ................................................................................ 19 Figura 2.3 – OMRON Blood Pressure Monitor .................................................................. 19 Figura 2.4 – OMRON Weighing Scale ................................................................................ 20 Figura 2.5 – Nonin Pulse Oximeter ................................................................................... 20 Figura 2.6 – Evolución de la plataforma de monitorización ............................................. 21 Figura 2.7 – Plataforma 1.0 – alfa ..................................................................................... 21 Figura 2.8 – Smartphone CE y MD .................................................................................... 23 Figura 3.1 – Máquina de estados FSM genérica ............................................................... 25 Figura 3.2 – Intercambio de tramas entre el MD y el CE .................................................. 26 Figura 3.3 – Esquema de la solución adoptada ................................................................ 27 Figura 3.4 – Termómetro, Domain Information Model .................................................... 28 Figura 3.5 – Diagrama del software implementado (Agente y Manager) ........................ 31 Figura 3.6 – a)Manager GUI y b)Received Data UI ............................................................ 33 Figura 3.7 – Formato ficheros XML ................................................................................... 33 Figura 3.8 – a)Agent GUI y b)Weighing Scale UI ............................................................... 34 Figura 4.1 – Estructura del código en Eclipse ................................................................... 36 Figura 4.2 – Código del proceso de asociación ................................................................. 37 Figura 4.3 – Código del envío de datos médicos .............................................................. 38 Figura 4.4 – Código del proceso de desasociación ........................................................... 38 Figura 4.5 – Código InternalEventManager en “Manager.java” ....................................... 39 Figura 4.6 – Código de la especialización del termómetro ............................................... 40 Figura 4.7 – Código del socket Bluetooth abierto por el manager ................................... 41 Figura 4.8 – Log del manager en la consola de Eclipse ..................................................... 42 Figura 4.9 – a) Pantalla del Scan y b) Bluetooth conectado ............................................. 42 Figura 4.10 – Proceso de asociación a)del manager y b)del agente ................................. 43 Figura 4.11 – Manager y Agente en modo Operating ...................................................... 43 Figura 4.12 – Mensaje de advertencia sobre el dato introducido .................................... 44 Figura 4.13 – Envío y recepción del dato médico a)Manager b)Agente ........................... 44 Figura 4.14 – Desconexión a)del manager y b)del agente ................................................ 45 Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android Índice 6 Figura 4.15 – a)Menú contextual para guardar la medida o salir, b)Pop-up para guardar varias medidas en un fichero ............................... 46 Figura 4.16 – Ficheros XML guardados en la carpeta x73spain ........................................ 46 Figura 4.17 – Mensaje de confirmación de envío del XML ............................................... 47 Figura 5.1 – Terminal telnet para redirigir puertos .......................................................... 49 Figura 5.2 – Tramas de datos del AssociationRequest ..................................................... 50 Figura 5.3 – Tramas de datos del ConfigReport ................................................................ 51 Figura 5.4 – Tramas de datos del DataReport .................................................................. 52 Figura 5.5 – Escenarios de pruebas de interoperabilidad ................................................. 52 Figura 5.6 – Captura manager plataforma .NET ............................................................... 53 Figura 6.1 – Diagrama de Gantt ........................................................................................ 57 Figura 7.1 – Gestión de alarmas con Google Calendar ..................................................... 60 Figura A.1 – Tipos de uso para X73-PHD ........................................................................... 65 Figura B.1 – Evolución del lanzamiento de Android ......................................................... 68 Figura B.2 – Distribución de las versiones de Android ...................................................... 71 Figura B.3 – Comparativa terminales comerciales Android .............................................. 71 Figura B.4 – Instalación del plugin ADT en Eclipse ............................................................ 72 Figura B.5 – Configuración del plugin y SDK de Android en Eclipse ................................. 73 Figura B.6 – Creación de un emulador de Android con Eclipse ........................................ 74 Índice de tablas Tabla 3.1 – Atributos del objeto MDS Thermometer ....................................................... 29 Tabla 3.2 – Atributos del objeto métrico Body Temperature ........................................... 30 Tabla C.1 – Clasificación Indice de Masa Corporal ............................................................ 79 Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android Acrónimos y siglas 7 Acrónimos y siglas AENOR ACR ANSI API ASL2 ASN1 AVD BER CEN CE DER DIM ECG EHR EDR FSM GPRS GUI HCE HDP HL7 IDE IEEE IHE IP IrDA ISCIII ISO J2ME MCAP MD MDS MIT OLPC NEMA ONG OSI PC PER PHD PFC PHDC PoC RFCOMM SCP – ECG SPP SDK SO TCP USB WiFi UCI XML UPNA URJC UZ Asociación Española de NORmalización Colegio Americano de Radiólogos American National Standards Institute Application Programming Interface Apache Software License 2 Abstract Syntax Notation One Android Virtual Device Basic Encoding Rules Comité Europeo de Normalización Compute Engine Distinguished Encoding Rules Domain Information Model ElectroCardioGrama Electronic Healthcare Record Enhanced Data Rate Finite State Machine General Packet Radio Service Graphic User Interface Historia Clínica Electrónica Health Device Profile Health Level 7 Integrated Development Environment Institute of Electrical and Electronics Engineers Integrating the Healthcare Enterprise Internet Protocol Infrared Data Association Instituto de Salud Carlos III International Organization for Standardization Java 2 Mobile Edition Multi-Channel Adaptation Protocol Medical Device Medical Device System Massachusetts Institute of Technology One Laptop Per Child Asociación Americana de Fabricantes Eléctricos Organización No Gubernamental Open Systems Interconnection Personal Computer Packed Encoding Rules Personal Health Device Proyecto Fin de Carrera Personal Health Device Class Point of Care Radio Frequency Communication Serial Port Profile Standard Communications Protocol for computer assisted Electrocardiography Software Development Kit Sistema Operativo Transmission Control Protocol Universal Serial Bus Wireless Fidelity Unidad de Cuidados Intensivos Extensible Markup Language Universidad Politécnica de Navarra Universidad Rey Juan Carlos Universidad de Zaragoza Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 8 Introducción 1. Introducción En esta sección se introduce el concepto de telemedicina y se justifica la necesidad de usar un estándar de interoperabilidad, la norma ISO/IEEE 11073, entre dispositivos médicos. También se hace una pequeña referencia al sistema operativo utilizado, Android, y a los antecedentes existentes relacionados con este proyecto. Finalmente se definen los objetivos y la estructura de la memoria. 1.1 Telemedicina y necesidad de cubrir nuevos estándares El término telemedicina [1]-[2] se puede definir, en un sentido amplio, como el uso de las tecnologías de la información y las telecomunicaciones para proporcionar servicios sanitarios, formación e información a profesionales de la salud y consumidores. Es decir, se trata de la La evolución más reciente de las nuevas tecnologías, y de las herramientas que proporciona la nueva Sociedad de la Información, permite aplicar este concepto de telemedicina o e-Salud a innumerables campos: aplicaciones asistenciales (teleconsulta, telediagnóstico, telemonitorización), administración y gestión de pacientes, o formación e información tanto de profesionales como usuarios [3]. utilización de la tecnología para el diagnóstico médico y el cuidado de pacientes. Debido a la relativa novedad de este sector, existe una carencia importante de estandarización de dispositivos médicos, tanto en la toma de medidas, como en la transmisión de éstas. Esto conlleva, por un lado, un importante aumento de los costes, ya que para cada marca y dispositivo, se tendría que utilizar un software propietario y, por otro lado y más importante todavía, una elevada incomodidad tanto para el personal médico como para los pacientes, que se verían obligados a comprar todos los equipos de la misma marca o, en caso de no hacerlo, aprender a manejar diferentes dispositivos, cada uno con un comportamiento particular establecido por el fabricante [4]. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 15 Estado del arte 2. Estado del arte En este apartado se presentan los distintos organismos de e-Salud que existen actualmente, así como las normas emitidas por éstos. Se muestran además diferentes modelos de dispositivos médicos utilizados en este campo, viéndose la escasa presencia de aquellos que cumplen con la norma X73. En esta dirección trabaja la Continua Alliance, la cual ha presentado varios dispositivos que sí cumplen este estándar. Y finalmente se explicará la evolución sufrida por la plataforma de telemonitorización desarrollada por este grupo. 2.1 Organismos y normas para la salud Las principales organizaciones encargadas de la Informática Médica y las TICs para la salud y que, entre otras actividades importantes, colaboran en el desarrollo de estándares y normas, objeto de estudio en este trabajo, son:  CEN, Comité Europeo de Normalización, a través de su Comité Técnico CEN/TC251, es la principal organización europea con competencia en este campo.  AENOR, Asociación Española de NORmalización, mediante su Comité Técnico AEN/CTN139, es el organismo de estándares en España, y espejo del CEN a nivel nacional.  ISO, International Standards Organization e IEEE, Institute of Electrical and Electronics Engineering, órganos de responsabilidad superior de los que dependen los comités internacionales y nacionales anteriores. Las normas y estándares más destacados para interoperabilidad de sistemas de información en medicina son: Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 16 Estado del arte  HL7, Health Level 7, fundada por fabricantes americanos de equipos médicos, y acreditada por American National Standards Institute (ANSI), es un estándar para intercambio de mensajes médicos. Desarrolla una sintaxis propia, en los siete niveles de la pila de protocolos, para representar la información en una estructura sencilla compuesta por segmentos, tipos de datos y campos etiquetados.  EN13606, especifica la arquitectura de información requerida para las comunicaciones interoperables entre sistemas y servicios que proveen o necesitan datos de la Historia Clínica Electrónica.  ISO/IEEE 11073 (X73), es una familia de normas, promovidas por IEEE, y adoptadas como estándar de ISO, y que agrupa diversas normas CEN anteriores para cubrir los diferentes niveles del modelo OSI. La incorporación de todos los estándares existentes en un mismo sistema es complicado y requiere de un gran esfuerzo de integración. Para ello, es imprescindible la coordinación entre instituciones, empresas y otras organizaciones tanto sanitarias como de investigación. Ante este panorama surgen otros dos organismos: Integrating the Healthcare Enterprise (IHE) [14] que trata de buscar, junto con los fabricantes de MDs, la mejor solución para cada servicio específico; y Continua Health Alliance [15], formada por 22 compañías del sector de tecnologías sanitarias, que persigue la incorporación de tecnologías interoperables en los dispositivos así como promover el uso de estos sistemas en las aplicaciones tanto a nivel profesional como cotidiano, planteando como reto la obtención de un certificado de normalización en forma de logotipo a incluir en los productos comerciales compatibles con los correspondientes estándares. OpenECG es otra de estas fundaciones, ligada estrechamente a la difusión del estándar de electrocardiografía, SCP-ECG. 2.2 MDs y Android Gracias a la telemedicina se han realizado muchos proyectos que permiten que una persona que se encuentra en un lugar remoto o sin el personal médico adecuado, pueda ser atendida en las mejores condiciones posibles por un especialista a distancia. Pero lejos de quedarse sólo en esos proyectos, los ingenieros que trabajan en esta rama han creado aplicaciones que permiten monitorizar el ritmo cardíaco de los pacientes e informar a los Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 17 Estado del arte médicos a través de un teléfono móvil, o crear cinturones que avisen cuando el paciente sufre una caída, o incluso controlar los niveles de glucosa en sangre de un enfermo de diabetes. Dando un paso adelante en la tecnología, un equipo de ingenieros del Masschusetts Institute of Technology (MIT) decidieron aprovechar el entorno de programación que ofrece Android para crear una aplicación que permita mejorar el diagnóstico remoto y los servicios terapéuticos en las áreas más alejadas de la población. Y así nació el programa "Moca", un proyecto open source que ahora mismo se está probando en Filipinas para el telediagnóstico [16]. Moca se basa en una aplicación para Android que se comunica con un servidor Linux del que obtiene información médica concerniente a los pacientes, previa introducción de una serie de datos a en un sencillo formulario a través de un HTC G1 (Google Dev Phone). Para poder llevar a cabo la comunicación entre el servidor Linux y Android, se ha desarrollado un plugin específico que permite la transmisión multimodal de la información aprovechando al máximo los recursos de red disponibles en cada momento. Así, por ejemplo para enviar pequeñas anotaciones de texto el teléfono utiliza el protocolo de mensajes cortos, mientras que para comunicar imágenes o informes de mayor tamaño el teléfono utiliza una conexión GPRS. Además, para evitar problemas de retransmisión con las pérdidas de paquetes que pueden retardar mucho las transmisiones, Moca incorpora un protocolo que divide la imagen en pequeños paquetes permitiendo retomar una transmisión en el momento en que se cortara. En numerosas zonas del planeta pueden pasar semanas hasta que un especialista pueda llevar a cabo un diagnóstico del paciente. Además, muchos pacientes deben realizar viajes extremadamente largos, de hasta medio día de duración, para llegar el centro médico más cercano, por lo cual no vuelven para hacer el seguimiento pertinente, o vuelven únicamente cuando sus condiciones son demasiado malas para tener solución. Utilizando esta aplicación sobre un HTC G1 o cualquier otro dispositivo basado en Android, el personal médico que se desplaza a las zonas mencionadas, puede realizar un diagnóstico insitu en el mismo momento. Permite tomar una foto, adjuntar un archivo de voz, o incluso una radiografía si está disponible. Los datos son enviados a través de WiFi o GPRS a un servidor Linux (Moca Dispatch Server), donde se almacenan en una base de datos (ver Figura 2.1). Los especialistas analizan el material recibido y realizan un diagnóstico, que envían inmediatamente de vuelta al personal clínico desplazado a la zona. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 18 Estado del arte Figura 2.1 – Arquitectura del proyecto MOCA El equipo de Moca eligió Android por tratarse de un sistema open source y multitarea con una cámara de calidad y que ofrece un avanzado entorno de desarrollo. Sin embargo, el elevado precio del HTC G1 suponía un problema en las áreas donde se iba a lanzar (Filipinas), ya que existían otros dispositivos open source pero las prestaciones que ofrecían no eran las requeridas. Finalmente, gracias a la colaboración y las ayudas recibidas por parte de la ONG One Laptop per Child (OLPC) el proyecto se ha podido llevar a la realidad [17]. Sin duda una pequeña muestra de las posibilidades que se abren para las telecomunicaciones gracias al uso de entornos abiertos para las aplicaciones. 2.3 Dispositivos médicos con X73 El intercambio de información y la interoperabilidad se puede entender como una serie de enormes beneficios para los sistemas sanitarios y los programas de telemedicina; los pacientes tendrán una mejor información sobre su estado de salud y los médicos tendrán la capacidad de controlar los signos vitales con mucha más facilidad. En Marzo de 2009, Continua Health Alliance publicó el primer producto Certificado Continua™ en el mercado mundial. Nonin Medical [18] dio a conocer a través de internet su Pulsioxímetro Portátil Continua Certificado con puerto USB, 2500 PalmSAT® (ver Figura 2.2). Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 19 Estado del arte Figura 2.2 – Modelo 2500 PalmSAT® Nonin Medical, Inc. es una empresa privada con sede en Minneapolis que está especializada en el diseño y fabricación de soluciones de monitorización fisiológica no invasiva. Es de las primeras empresas de la industria en capacidad de procesamiento de señales y diseño de sensores, además integra características no disponibles en los productos de otras empresas. Ha sido un factor clave en la arquitectura de normas de interoperabilidad, incluida la norma ISO/IEEE 11073, USB Personal Health Device Class (PHDC) y HDP. Hoy en día existen varios dispositivos médicos certificados por Continua, lo que pone de manifiesto el interés de la industria por este sector y, especialmente, por el desarrollo de equipos que cumplan con la norma X73. Excepto para la especialización del termómetro, existen dispositivos comerciales para el resto de implementaciones de este proyecto (tensiómetro, pulsioxímetro y báscula), todos ellos además con tecnología Bluetooth. A continuación se muestran algunos ejemplos de los equipos disponibles para las especializaciones desarrolladas, todos ellos certificados por Continua, y que podrían ponerse en funcionamiento con la plataforma desarrollada en este PFC. Los dos primeros han sido fabricados por OMRON [19], mientras que el último pertenece a Nonin. - OMRON Bluetooth® Home Blood Pressure Monitor: Se trata de un tensiómetro con tecnología Bluetooth que permite a los usuarios, además de tomar las medidas, transmitirlas fácilmente a otros sistemas electrónicos (ver Figura 2.3). Communication function: Bluetooth® Ver2.1+EDR Class2 (10m) Profile : SPP/HDP (conforming to Continua design guidelines) Data format standard : IEEE11073-10407 Pairing : Secure Simple Pairing/Passcode system Data transmission : Measurement date/time, measurement values, model, and serial number Figura 2.3 – OMRON Blood Pressure Monitor Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 20 Estado del arte - OMRON Weighing Scale: Báscula certificada por Continua con tecnología inalámbrica Bluetooth que ofrece a los usuarios una visión amigable de su nivel de salud a través de varios indicadores (ver Figura 2.4). Communication function : Bluetooth® Ver2.1+EDR Class2 (10m) Profile : SPP/HDP (conforming to Continua design guidelines) Data format standard : IEEE11073-10415 Pairing : Secure Simple Pairing/Passcode system Data transmission : Measurement date/time, measurement values, model, personal target values, serial number, and personal profile number Figura 2.4 – OMRON Weighing Scale - Nonin Onyx® II 9560 Wireless Fingertip Pulse Oximeter: Pulsioxímetro certificado por Continua con tecnología Bluetooth que ofrece un intercambio de información simple y seguro, y que permite monitorizar a los pacientes en su vida diaria (ver Figura 2.5). Communication function : Bluetooth® Ver2.0+EDR Class1 (100m) Profile : SPP/HDP (conforming to Continua design guidelines) Data format standard : IEEE11073-10404 Pairing : Secure Simple Pairing/Passcode system Data transmission : Measurement date/time, measurement values (SpO2 + pulse rate), model, serial number Figura 2.5 – Nonin Pulse Oximeter 2.4 Evolución de la plataforma de telemonitorización La evolución sufrida en los últimos años por la norma X73, así como el afán por llegar a un mayor número de personas a través de diferentes sistemas, ha hecho que la plataforma de telemonitorización original desarrollada en el grupo X73Spain [20], haya pasado por diversas migraciones, tal y como se expone a continuación (ver Figura 2.6). Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 21 Estado del arte Figura 2.6 – Evolución de la plataforma de monitorización 2.4.1 Plataforma 1.0 – alfa La plataforma 1.0-alfa es la 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 implementó una primera solución basada en leguajes C/C++ y Java para comunicar un pulsioxímetro DATEX-OHMEDA (no compatible con X73) con un gateway y un servidor de telemonitorización usando ordenadores personales operando sobre Linux (ver Figura 2.7). Figura 2.7 – Plataforma 1.0 – alfa Las comunicaciones adaptador-gateway y gateway-servidor se llevaban a cabo mediante X73, mientras que la comunicación entre el dispositivo y el adaptador no cumplía el estándar. Los datos médicos eran almacenados según las estructuras DIM (Domain Information Model) definidas en la norma X73. 2.4.2 Plataforma 1.5 – beta En esta plataforma se aborda el ámbito de la tele-asistencia sanitaria y la telemedicina; en concreto, la optimización de la norma X73 de interoperabilidad de dispositivos médicos. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 22 Estado del arte Se mantienen los dos subsistemas de la versión anterior, pero evoluciona de X73-PoC a X73-PHD: independizando la capa de transporte (mediante un handler compatible con TCP/IP sobre USB y Bluetooth), incluyendo envío de datos episódico (el anterior periódico) mediante un sistema de buffers, y optimizando el gateway hacia el concepto de Compute Engine (CE) sobre una nueva máquina de estados finita. Se migró del sistema operativo Linux a Windows, debido a su uso generalizado y a las mayores posibilidades y funcionalidades que ofrece en el desarrollo de sistemas end-to-end basados en la norma X73-PHD. Esta nueva versión 1.5-beta, implementa la parte de la comunicación entre un dispositivo médico (MD) y un PC actuando de gateway (CE). Para el desarrollo de esta plataforma se dispuso de un tensiómetro OMRON modelo 7051T BT. Es un modelo de brazo donde la medida se realiza de forma fácil e intuitiva igual que en otros dispositivos convencionales. La diferencia radica en que este modelo está equipado con un interfaz wireless que transfiere automáticamente el valor medido a un archivo central, y requiere la instalación de un software en el PC para recibir los datos de las medidas. 2.4.3 Plataforma 2.0 – release La segunda versión basada plenamente en X73-PHD, se encarga de solucionar los problemas de la anterior versión. Está orientada a entornos ubicuos y dispositivos llevables y a la aplicación de nuevas funcionalidades plug&play y de gestión remota. Implementa el protocolo de comunicación entre MD-CE, particularizado en X73-PHD. Esta plataforma integra los dos subsistemas mediante un nuevo protocolo extremo a extremo, incluye todas las evoluciones tanto de X73-PHD como de EN13606, e incorpora un nuevo GUI. El código está optimizado respecto a la versión anterior (Plataforma 1.5 – beta) e incorpora funcionalidades para permitir su aplicación en soluciones de e-Salud. Consiste, a grandes rasgos, en la implementación de la norma sobre un sistema compuesto por varios MD y un CE. 2.4.4 Plataforma 2.1 – BT Esta plataforma mantiene la estructura de la pila y los subsistemas de las anteriores versiones, y se basa en modificar el software heredado de la Plataforma 2.0 – release para adaptarlo a dispositivos móviles con tecnología Bluetooth, concretamente a smartphones con sistema operativo Windows Mobile 6 (ver Figura 2.8), optimizando las funcionalidades ubicuas Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 23 Estado del arte (plug-and-play y hot-swap). De este modo, fue necesario sustituir las librerías de las que se disponía en la anterior plataforma para poder realizar un software compatible. Figura 2.8 – Smartphone CE y MD Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 24 Análisis y diseño 3. Análisis y diseño En este capítulo se estudian los requisitos que debe cumplir el proyecto, que coinciden, principalmente, con las necesidades de los pacientes que en diferentes situaciones tendrán que tomarse una serie de medidas clínicas; se expondrá con detalle el diseño realizado y la arquitectura implementada. 3.1 Análisis de requisitos En este apartado se analizan las necesidades de los pacientes, usuarios potenciales del software, para determinar qué debe hacer el sistema a desarrollar. Existen tres tipos de escenarios en los que se puede situar al paciente que precisa de uno de los dispositivos médicos implementados: Domiciliario, Hospitalario y Fitness.  Domiciliario: Son pacientes individuales, con un número reducido de dispositivos médicos, todos ellos dentro de una red PAN (Personal Area Network). La configuración del sistema se compondrá de MDs con interfaz Bluetooth, un CE también Bluetooth y una conexión WiFi o 3G.  Hospitalario: En este caso el que hace uso del MD es personal sanitario experto, por lo tanto, asociado a cada usuario, habrá un número variable de pacientes. El sistema se configurará en este caso con MDs y CE wireless y una conexión WiFi.  Fitness: Este es un caso particular de los anteriores pero con una interfaz de usuario más atractiva y comercial. Tras haber detectado la necesidad de basarse en un estándar para dotar de interoperabilidad al proyecto, se establecerá como guía la norma X73 y se seguirán sus pautas para el diseño del software. Mediante una máquina de estados finitos (FSM) la norma describe cómo sincronizan su funcionamiento un sistema agente-manager. El diseño de la FSM (ver Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 31 Análisis y diseño Figura 3.5 – Diagrama del software implementado (Agente y Manager) A continuación se explican con mayor detalle cada uno de los bloques que componen la implementación, vistos en el diagrama anterior. 3.3.1 Binary Notes El paquete Binary Notes [21] ofrece un framework de ASN.1 (Abstract Syntax Notation One) [22] para entornos Java y .NET, que contiene: - Encoding/Decoding Library: Librería para la codificación/decodificación. Implementa las codificaciones BER (Basic Encoding Rules), DER (Distinguished Encoding Rules), y PER (Packed Encoding Rules). - BNCompiler: Compilador ASN.1 que genera el código Java / C# para un archivo ASN.1 de entrada determinado. - BinaryNotesMQ: Proporciona cadenas de mensajes basadas en la codificación ASN.1 que permiten la interoperabilidad de entornos Java y .NET. ASN.1 es una notación formal utilizada para describir la transmisión de datos que se lleva a cabo a través de los diferentes protocolos de comunicación existentes. Además establece una implementación del lenguaje y una representación física de estos datos, sea cual sea la aplicación y su complejidad. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 32 Análisis y diseño 3.3.2 IEEE 11073 Este bloque implementa la norma X73 (máquina de estados, definiciones, nomenclaturas…). Está dividido a su vez en tres partes: - Parte 10101: Aquí se definen todas las nomenclaturas utilizadas por la norma, es decir, todos los códigos que representan los diferentes atributos, tipos de medidas, de dispositivos, etc. - Parte 104xx: En esta parte se implementan las especializaciones desarrolladas, Thermometer (10404), Blood Pressure Monitor (10407), Pulse Oximeter (10408) y Weighing Scale (10415), tanto en su configuración estándar como en la extendida. - Parte 20601: En este bloque se establece el funcionamiento de la máquina de estados que rige el estándar, las definiciones ASN1 de todos los tipos de datos utilizados, y se define el PHD. Lógicamente, este paquete no será igual para el manager y para los agentes, si bien su estructura es idéntica y en ambos casos se utiliza de la misma forma. Por ejemplo, en el caso del manager, incluye también el código correspondiente al socket Bluetooth que escucha y recibe las conexiones entrantes procedentes del agente. 3.3.3 Utils, Messages y Events En estos paquetes se incluyen funciones útiles que sirven de gran ayuda a la hora de desarrollar el código principal: - Utils: Aquí aparecen utilidades para trabajar con los datos definidos por ASN1, con los objetos DIM, y con las colas de datos usadas en la transmisión. - Messages: Como su propio nombre indica, sirve para trabajar con los mensajes que se envían el agente y el manager. - Events: Bloque muy importante que permite el lanzamiento de eventos “hacia arriba” (hacia la interfaz gráfica) para actualizar los datos oportunos en la pantalla del terminal, por ejemplo, cuando llega una nueva medida o cuando se pasa de un estado a otro. 3.3.4 Manager Contiene la parte de más alto nivel del X73PHDManager, es decir, la interfaz gráfica principal y la pantalla donde se muestran los datos enviados por el agente (ver Figura 3.6). Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 33 Análisis y diseño Figura 3.6 – a)Manager GUI y b)Received Data UI Además, incluye la clase correspondiente al trabajo con los ficheros XML donde se almacenan, opcionalmente, los atributos correspondientes a las medidas recibidas. El formato de estos ficheros XML (ver Figura 3.7), se ha definido según lo establecido conjuntamente con otros miembros del grupo X73Spain, ya que, además de almacenarse de forma local, se pueden enviar a una base de datos de HCE, función incluida también en este bloque. Figura 3.7 – Formato ficheros XML Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 34 Análisis y diseño 3.3.5 Agent Al igual que en el caso del Manager (punto 3.3.4), en este apartado se encuentra la parte gráfica del X73PHDAgent, tanto de la pantalla principal, como de las especializaciones implementadas, donde se introducen las medidas que serán enviadas al manager. Como se ha explicado anteriormente, al no disponer de los dispositivos médicos reales, estas medidas no se toman físicamente, sino que se simulan con los terminales móviles, introduciéndolas manualmente en la pantalla de estos (ver Figura 3.8). Figura 3.8 – a)Agent GUI y b)Weighing Scale UI En la Figura 3.8 se muestra, además de la pantalla de inicio del X73PHDAgent, la correspondiente a la báscula, donde se ejecuta la conexión y se introduce la medida. Para el resto de especializaciones, la interfaz es equivalente, cambiando la(s) medida(s) a enviar y la imagen correspondiente. Además de la parte gráfica, se incluye también el código referente a cada uno de los dispositivos: generación de datos y mensajes a enviar, chequeo de las respuestas provenientes del manager, máquina de estados, etc. Por otro lado, cuenta con el código correspondiente a la conexión Bluetooth: descubrir dispositivos dentro de su alcance, parearse con ellos, y creación de los sockets de comunicación necesarios para el envío y recepción de datos entre agente y manager. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 35 Desarrollo e implementación 4. Desarrollo e implementación Una vez conocido el diseño que se ha llevado a cabo en este proyecto, se pasará a mostrar el desarrollo a más bajo nivel, detallando las partes fundamentales del código y presentando aspectos importantes de la programación realizada; se explicará también el funcionamiento de la plataforma a nivel de usuario. 4.1 Estructura del código Como ya se expuso en el capítulo 3.1, el código ha sido escrito en lenguaje Java, más concretamente en J2ME (Java Mobile Edition), a través del IDE (Integrated Development Enviroment) Eclipse, ya que éste cuenta con un plugin específico para el trabajo con Android, el cual proporciona herramientas de simulación a través de dispositivos virtuales (emulador), ayudas a la hora de diseñar las interfaces, consola para mostrar salidas por pantalla y controlar errores durante la depuración (modo debug), etc. Además del plugin comentado, se debe descargar el SDK de desarrollo de Android que proporciona el propio Google de forma gratuita (más información en el Anexo B). Cada uno de los proyectos realizados con Eclipse, agente y manager, se distribuye en varias carpetas de la siguiente manera (ver Figura 4.1): - bin: aquí se guardan los archivos binarios generados durante la compilación. - gen: donde se crean ficheros Java generados automáticamente. - res: contiene recursos como imágenes o diseños de las interfaces (layouts). - src: donde se encuentra el código fuente en cuestión, que a su vez está compuesta por las carpetas: es (código principal), ieee_11073 (norma X73), y org (Binary Notes). - Finalmente, existe además un archivo llamado AndroidManifest.xml que establece la información de la aplicación a tener en cuenta por el compilador (permisos, versión del SDK…). Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 36 Desarrollo e implementación Figura 4.1 – Estructura del código en Eclipse 4.2 Programación Se explica ahora de forma más detallada el código desarrollado, empezando por el X73PHDAgent, y particularizado al caso del termómetro, si bien la explicación es extensible al resto de especializaciones. La primera parte a destacar en el código del agente, es la correspondiente a la conexión Bluetooth, que se encuentra en las clases “BluetoothActivity.java” y “DeviceListActivity.java”, encargadas de descubrir los dispositivos dentro de su alcance y conectarse con el manager. Una vez realizada la conexión, se podrá crear un socket Bluetooth entre ambos dispositivos para llevar a cabo la comunicación. Este bloque se ejecuta pulsando el botón Scan que aparece en la pantalla principal del X73PHDAgent (ver Figura 3.8a). Al tratarse de un diseño modular, cada especialización está implementada por separado, lo que facilita futuras ampliaciones o modificaciones del programa. Así pues, para cada Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 37 Desarrollo e implementación dispositivo, se tiene una clase correspondiente al interfaz gráfico (“ThermometerGUI.java”, por ejemplo) y otra clase donde se gestionan los mensajes de la FSM enviados y recibidos (en el caso del termómetro sería “Thermometer.java”). De esta forma, cuando se pulsa el interruptor Connected/Disconnected (ver Figura 3.8b), en la clase “ThermometerGUI” se crea una instancia de la clase “Thermometer”, y se inicia automáticamente el proceso de asociación entre agente y manager. Para ello, el primer paso es enviar el AssociationRequest, para después evaluar el AssociationResponse enviado por el manager y pasar o no al estado Associated (ver Figura 4.2). Es importante destacar el cometido de la función “InternalEventReporter”, encargada de enviar eventos para la actualización del interfaz gráfico, que serán recibidos por un “InternalEventManager” de la clase “ThermometerGUI”. Figura 4.2 – Código del proceso de asociación Una vez que ambos dispositivos están asociados y en modo Operating se procede al envío de los datos médicos. Pulsando sobre el botón Send (ver Figura 3.8b) se toma la medida introducida en el interfaz gráfico y se inicia el envío de estos datos (ver Figura 4.3). Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 38 Desarrollo e implementación Figura 4.3 – Código del envío de datos médicos De la misma forma, cuando se pulse el botón Quit para finalizar la conexión, tendrá lugar el proceso de desasociación, volviendo de nuevo al estado Disconnected (ver Figura 4.4). Figura 4.4 – Código del proceso de desasociación Hasta aquí se han mostrado las partes principales del código del agente para el caso del termómetro. Para ver con más detalle las funciones que aparecen y el resto del código, ver el CD adjunto. Se pasa ahora a explicar el código desarrollado para el manager. En este caso, en lugar de los bloques de cada especialización que había para el agente, se tendrá solamente un bloque correspondiente al código principal del manager, donde se gestionan los interfaces y se recibirán las medidas enviadas por los dispositivos médicos. Habrá entonces un archivo “ManagerGUI.java” correspondiente a la pantalla principal, y otro “Manager.java” donde llegarán las medidas y se mostrarán en la interfaz. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 39 Desarrollo e implementación Al igual que antes, los eventos que puedan llegar desde el agente se recibirán en un “InternalEventManager”, lo que permitirá cambiar el estado, representar los datos médicos, etc. En la Figura 4.5 puede verse una parte de esta función. Figura 4.5 – Código InternalEventManager en “Manager.java” Otra parte destacada de esta clase “Manager” es la función “saveDataToXml”, encargada, como su propio nombre indica, de almacenar los datos médicos recibidos en un fichero XML. En esta función se creará el archivo con el nombre del agente y la fecha, y se creará una instancia de la clase “XML.java”, que se encuentra en el bloque Android, y que se ocupa de escribir los datos con el formato XML establecido en el fichero previamente creado. De la misma forma existe una función “sendData” que se ocupa de enviar el fichero XML generado a un servidor de HCE. Además de la parte de más alto nivel explicada, es importante también comentar la parte correspondiente a las especializaciones definidas por el estándar. Estas se encuentran en la carpeta “part_104zz”, dentro del bloque “ieee_11073”. Existe una clase llamada Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 40 Desarrollo e implementación “DeviceSpecializationFactory”, donde se crean las instancias de cada dispositivo, estableciendo los atributos requeridos para cada MD. Por otro lado, hay una clase para cada una de las especializaciones: “DS_10408.java” (termómetro), “DS_10407.java” (tensiómetro), “DS_10404.java” (pulsioxímetro), y “DS_10415.java” (báscula). En ellas se crean los objetos correspondientes a los datos médicos, con los atributos oportunos en cada caso según establece la norma X73 (ver Figura 4.6). Figura 4.6 – Código de la especialización del termómetro Por último, destacar también el código correspondiente a la creación del socket Bluetooth donde el manager recibirá las posibles conexiones de los agentes, y que se encuentra en la clase “BluetoothManagerChannel” (ver Figura 4.7). Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 47 Desarrollo e implementación disponible, o bien a través de una conexión 3G. Si el envío se ha realizado de forma correcta, aparecerá un mensaje en la pantalla con la indicación correspondiente (ver Figura 4.17). Figura 4.17 – Mensaje de confirmación de envío del XML El servidor HCE forma parte una de las líneas de trabajo del grupo X73Spain de la UZ. Por lo tanto, el formato del XML y la comunicación entre el manager HTC/Android y el servidor en cuestión, se ha desarrollado según lo establecido junto con las personas responsables de la investigación llevada a cabo sobre el HCE, tal y como dicta la norma EN13606. La integración con este servidor, permite disponer de una plataforma completa (end-to-end), dando soporte desde el inicio del proceso (toma de la medida por el paciente) hasta la parte final (almacenamiento de la medida en el HCE). Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 48 Evaluación y resultados 5. Evaluación y resultados En este apartado se explican las pruebas realizadas para comprobar que el proyecto funciona correctamente en escenarios de varios tipos. Se muestran además las tramas de datos enviadas entre agente y manager, viendo cómo siguen el comportamiento establecido por la norma X73. Se tratan además las diferentes pruebas de interoperabilidad e integración con otros entornos y plataformas. Por último se exponen los resultados obtenidos y los problemas encontrados. 5.1 Prueba de software Para llevar a cabo las pruebas y comprobar que el código desarrollado efectúa correctamente las operaciones para las cuales has sido diseñado, se utilizará el emulador que proporciona el plugin de Android para Eclipse, a través de su herramienta AVD (Android Virtual Device). Esta utilidad permite crear de forma rápida y sencilla unidades virtuales que simularán los terminales reales. En esta primera fase de pruebas, ambos dispositivos (agente y manager) se encontrarán en el mismo PC; se tendrán, por tanto, dos instancias del emulador sobre el mismo entorno Eclipse, trabajando en localhost y comunicándose a través de TCP. El procedimiento a seguir para hacer funcionar el proyecto es el siguiente. Una vez creadas las dos unidades virtuales que emularán tanto agente como manager, faltará únicamente instalar los dos proyectos, uno en cada emulador, y ejecutarlos. Antes de llevar a cabo la comunicación entre ambos, es necesario realizar una última operación; debido a que los mensajes que envía el agente se dirigen a un puerto concreto del manager, habrá que abrir un terminal telnet en el manager para redirigir todas las conexiones entrantes hacia el puerto especificado en el agente. Para ello, basta abrir un terminal de consola en Windows y escribir la siguiente instrucción: telnet localhost 5554 Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 49 Evaluación y resultados El número 5554, se refiere al puerto en el que se encuentra escuchando el emulador del manager (éste puede verse en la parte superior izquierda de la ventana donde se abre el emulador, y podría ser perfectamente otro número). Una vez ejecutado, se abrirá automáticamente el terminal telnet, donde se deberá escribir la instrucción de redirección, como puede verse en la Figura 5.1. En este caso, todas las conexiones que lleguen al manager, lo harán a través del puerto 9999, que es el puerto contra el que se crea el Socket TCP en el agente, y en el que escuchará, por tanto, el manager. Figura 5.1 – Terminal telnet para redirigir puertos Una vez ejecutada la redirección, ambas aplicaciones se encuentran listas para comenzar la comunicación. Después de haber visto en el punto 3.4 el funcionamiento del proyecto a nivel de usuario, la explicación se centra ahora en demostrar, a más bajo nivel, la correcta implementación del estándar X73, comprobando en todo momento las tramas de datos enviadas entre agente y manager y las transiciones entre los diferentes estados de la FSM definida por el estándar. El primer paso consiste en inicializar el manager pulsando el botón Start. De esta forma, se abrirá el socket mencionado en el puerto 9999, esperando las conexiones entrantes que le puedan llegar desde el 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, como se vio en el capítulo 3.1, por una petición de asociación del agente al manager (AssociationRequest), cuya trama de bytes puede verse en la imagen siguiente, separada según los atributos enviados (ver Figura 5.2). Se pasará entonces al estado de Associating. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 50 Evaluación y resultados Figura 5.2 – Tramas de datos del AssociationRequest 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. Estos códigos son: - 0: Association Request Accepted - 1: Association Request Rejected Permanent - 2: Association Request Rejected Transient - 3: Association Request Accepted Unknown Config - 4: Association Request Rejected No Common Protocol - 5: Association Request Rejected No Common Parameter - 6: Association Request Rejected Unknown - 7: Association Request Rejected Unauthorized - 8: Association Request Unsupported Association Version Según los códigos, si la respuesta tiene valor 0, la petición de asociación ha sido aceptada, mientras que si tiene valor 3, ésta ha sido aceptada pero sin 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 (ver Figura 5.3). Para el resto de códigos, la petición es rechazada y no se dará lugar a la asociación. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 51 Evaluación y resultados 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, el cual puede tomar los siguientes valores: - 0: Config Response OK - 1: Unsupported Config - 2: Standard Config Unknown Así pues, si este código tiene valor 0, el manager habrá aceptado 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. Figura 5.3 – Tramas de datos del ConfigReport 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 enviados. En la Figura 5.4, es importante destacar la línea que aparece remarcada (obs-scan-fixed), pues es la que contiene la información; los dos primeros bytes corresponden al propio dato clínico, mientras que el resto son los correspondientes a la fecha y la hora en la que éste ha sido tomado. Ahora se podrían seguir enviando nuevas medidas siguiendo el mismo proceso, es decir, creando nuevos mensajes DataReport con los datos clínicos; o bien finalizar la comunicación 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 Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 52 Evaluación y resultados finalización, que será ‘0’ para la desconexión normal (Normal Reason), mientras que el manager responderá con el mismo código para indicar que acepta la petición de desasociación. Figura 5.4 – Tramas de datos del DataReport 5.2 Pruebas de interoperabilidad Después de haber comprobado que el software desarrollado funciona correctamente cuando agente y manager se encuentran en el mismo equipo (ver Figura 5.5a), se procederá a probar el proyecto en diferentes escenarios. Figura 5.5 – Escenarios de pruebas de interoperabilidad Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 53 Evaluación y resultados Para ello, se pasará de un entorno localhost (agente y manager en el mismo PC) a otro con dos PCs. Ambos equipos seguirán conectados por IP a través de un hub o switch, por lo que la comunicación se realizará mediante TCP (ver Figura 5.5b). Ya que en las dos situaciones se trata de los mismos agente y manager sobre Android (emulados con Eclipse), el funcionamiento será exactamente el mismo que el explicado a lo largo de esta memoria, salvo que ahora, las peticiones del agente deberán dirigirse a la dirección IP del manager, y no a localhost como se hacía durante las primeras pruebas. Un reto importante llegado este punto, consiste en comprobar que la plataforma desarrollada es absolutamente compatible con otros entornos de desarrollo. Aprovechando que en el grupo X73Spain se está trabajando también en otra plataforma de telemedicina, equivalente a la que ocupa este proyecto, sobre tecnología .NET, una prueba importante sería comunicar las dos implementaciones. De esta forma, se procede a la comunicación de un agente Android sobre PC, con un manager .NET funcionando en otro PC distinto (ver Figura 5.5c). Como es lógico, el funcionamiento del agente Android será siempre el mismo, especificando la dirección IP del manager .NET al igual que en el caso anterior. Como ambos desarrollos están diseñados cumpliendo con las pautas establecidas por la norma X73, la comunicación se realiza sin ningún problema y los datos médicos son transmitidos correctamente (ver Figura 5.6). Figura 5.6 – Captura manager plataforma .NET Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 54 Evaluación y resultados 5.3 Pruebas de hardware Como ya se detalló anteriormente en el capítulo 3.1, al no disponer de dispositivos médicos reales que cumplan con la norma, ha sido imposible realizar las pruebas pertinentes en un escenario de trabajo real, por lo que se ha trabajado en todo momento con MDs simulados sobre un terminal Android. A pesar de todo, está previsto adquirir en las próximas semanas un dispositivo médico certificado por Continua para realizar este tipo de pruebas, y poder trasladar el trabajo a un entorno clínico real, como puede ser un centro médico, una residencia de ancianos, etc. Tanto en el punto 5.1 como el 5.2, las pruebas se han llevado a cabo mediante terminales emulados en un PC, a través de la herramienta que ofrece Eclipse para ello. Sin embargo, una prueba con los terminales reales a través de Bluetooth es completamente necesaria, ya que éste será el modo de trabajo de la plataforma. Por lo tanto, se ha instalado en los móviles HTC disponibles el X73PHDAgent y el X73PHDManager, y se ha repetido el proceso de conexión, asociación y envío de datos médicos, llevándose a cabo, como estaba previsto, de forma satisfactoria. Por último, otra prueba realizada ha sido la concerniente al sistema de ficheros XML. Al igual que ocurría con los emuladores, el fichero se crea correctamente y se almacena en el terminal móvil. Pero sin duda, el punto de mayor interés es el relativo al envío de este XML al servidor de HCE. Para ello, a través de un punto de conexión WiFi configurado en el laboratorio, el manager se conecta a la red y envía, a través de HTTP, el fichero en cuestión, recibiéndose en el servidor y finalizando así el proceso completo de la toma y transmisión de los datos médicos. La dirección donde se encuentra ubicado este servidor es: http://uzserver.no-ip.org/CE2EHR/ Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 55 Cronograma de implantación 6. Cronograma de implantación En este capítulo se explica cuál ha sido la cronología seguida durante la realización del PFC, y cómo se han desarrollado las diferentes fases que lo componen, representando para ello el diagrama de Gantt. 6.1 Cronograma de implantación A continuación se expone el tiempo de dedicación que ha sido empleado, aproximadamente, para cada una de las tareas que componen este proyecto. Las primeras semanas de trabajo se analizó la norma X73 y algunos documentos escritos por el grupo X73Spain de la Universidad de Zaragoza. Con una idea global sobre lo definido por la norma, se pasó a estudiar la anterior plataforma de telemonitorización que trabajaba sobre Windows Mobile (plataforma 2.1 – BT) [11], la cual se debía migrar al nuevo sistema operativo Android. Así se comprendió con mayor detalle cómo se implementaban las especificaciones definidas en el estándar. Durante este estudio, se descubrió la existencia de un proyecto que podría ser útil para la realización de este PFC, el proyecto OpenHealth desarrollado por la Universidad Rey Juan Carlos de Madrid a través de su programa Morfeo. Por lo tanto, se comenzó a analizar, llegando a la conclusión de que sería más conveniente partir de este nuevo diseño, que migrar la plataforma anterior al completo. Después de una reunión con los responsables de OpenHealth, se decidió utilizar su desarrollo como punto de partida del PFC. Además, y derivado de esta reunión, una nueva tarea llevada a cabo durante el transcurso del PFC ha sido la de mantener una línea de contacto con el grupo de Morfeo. Al mismo tiempo que se estudiaba el trabajo realizado por los compañeros de la URJC, se comenzó la familiarización con el entorno Android, haciendo pequeños programas e implementaciones guiadas para aprender a crear aplicaciones con Eclipse para este sistema operativo. A su vez, se tuvo que realizar un breve tutorial de Java, concretamente de J2ME, recordando los conceptos básicos de la programación en este lenguaje. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 56 Cronograma de implantación Una vez asimilado el funcionamiento del proyecto OpenHealth, se afrontó el diseño y arquitectura a implementar en este PFC, comenzando con la etapa de programación del código, que supone la tarea central del proyecto y ocupa la mayor parte del trabajo realizado. Cuando se había avanzado suficiente con el desarrollo del código, se comenzaron a realizar pruebas para comprobar que todo funcionaba según lo previsto, modificando pequeños detalles y añadiendo nuevos aspectos. Esta fase de pruebas y mejoras, junto con la redacción de la presente memoria, se extiende hasta la fecha de finalización y entrega del proyecto. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 63 Anexo A – La norma ISO/IEEE 11073 Anexo A – La norma ISO/IEEE 11073 En la actualidad, no existe ninguna norma que aborde oficialmente el problema de la integración de dispositivos en entornos de telemonitorización domiciliaria y ambulatoria, pero sí hay una familia de normas orientada a la interoperabilidad de dispositivos médicos en el punto de cuidado, que puede aplicarse en buena medida. Se trata de la familia ISO/IEEE 11073 (también nos referiremos a ella como X73), que está sufriendo modificaciones para cubrir ese campo. La norma ISO/IEEE 11073, como ya se comentó en la introducción, es un conjunto único de normas desarrolladas y adoptadas por todos los países para la conectividad completa de dispositivos médicos, que aporta interoperabilidad, plug&play, transparencia y facilidad de uso y configuración. Dicha norma está, a fecha de finalización de este documento, en fase de desarrollo. Para su desarrollo se han unido las organizaciones CEN, IEEE e ISO, entre otras, uniendo esfuerzos anteriores que absorben normas previas como PoCMDC (interconexión de dispositivos e intercambio datos entre ellos) o las normas ENV13734 (VITAL) para las capas superiores y ENV13735 (INTERMED) para las capas intermedias. 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 una única serie de estándares. 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 de una forma similar y trabajen de manera 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. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 64 Anexo A – La norma ISO/IEEE 11073 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. 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 MD-CE, 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. 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 X73-PoC para los sistemas sanitarios es una necesidad en la comunicación de los dispositivos médicos en e-Salud. A la hora de diseñar las características del protocolo, es necesario evaluar los entornos de uso o Use Cases de los dispositivos candidatos a implementar X73-PHD de manera que quede convenientemente definido el rango de propiedades soportadas por el protocolo. En general el sistema posee una topología tipo estrella donde el CE situado en el centro recopila los datos provenientes de los agentes. Una lista preliminar de los casos contemplados para el desarrollo se encuentra en el borrador “IEEE-11073-00013. Draft Guide for Health informatics - Personal Health Device communication. Technical report – Overview”. En él se destacan inicialmente los siguientes casos 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 - Cuidado de pacientes de avanzada edad Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 65 Anexo A – La norma ISO/IEEE 11073 - Diabetes - Monitorización de pacientes con problemas cardiacos Durante el desarrollo de la norma, se han reagrupado en torno a tres tipos de uso como puede verse en Figura A.1. Aquí se incluyen además los dispositivos médicos asociados para su estandarización conforme a X73-PHD. Figura A.1 – Tipos de uso para X73-PHD A la hora de seleccionar el conjunto inicial de dispositivos que van a trabajar con el X73- PHD, se realizó una encuesta a diversos fabricantes en la cual se valora, para cada tipo de dispositivo del mercado, la necesidad de aplicar X73-PHD a sus comunicaciones. La clasificación final se hace en base al interés de los expertos en desarrollar un estándar para el dispositivo tanto a largo como a corto plazo, su posible participación en el desarrollo y evidentemente la existencia de un grupo de trabajo. Las especializaciones que se encuentran en proceso de desarrollo actualmente son las siguientes: - 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 - 11073-10441 - Cardiovascular fitness and activity monitor - 11073-10442 - Strength fitness equipment - 11073-10471 - Independent living activity hub - 11073-10472 - Medication Monitor Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 66 Anexo A – La norma ISO/IEEE 11073 Esta lista inicial evoluciona y, conforme se obtienen versiones avanzadas de especializaciones en desarrollo, se van realizando nuevas propuestas que son llevadas a votación (Project Approval Request, PAR) para luego ser desarrolladas posteriormente si procede. 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 CE el identificar estas configuraciones para decidir si acepta la asociación con el dispositivo en cuestión en base a sus capacidades. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 67 Anexo B – Android Anexo B – Android Android es una solución completa de software de código libre para teléfonos y dispositivos móviles. Es un paquete que engloba un sistema operativo, un runtime de ejecución basado en Java, una serie de librerías de bajo y medio nivel y un conjunto inicial de aplicaciones destinadas al usuario final. Se distribuye bajo una licencia Apache versión 2 (ASL2), una licencia libre permisiva que permite la integración con soluciones de código propietario. Los primeros dispositivos con Android aparecieron en el último trimestre de 2008, aunque una versión preliminar del SDK, acompañado de un emulador y documentación de desarrollo, se encuentra disponible desde el 12 de noviembre de 2007 (ver Figura B.1). B.1 Android buscaba (y lo ha conseguido) causar impacto en la industria de la comunicación móvil, estableciendo una plataforma abierta que permita un acceso fácil a prácticamente todas las funcionalidades hardware de los dispositivos en los que esté instalado, así como proveyendo de serie a los desarrolladores con librerías que favorezcan la creación ágil y rápida de aplicaciones. Se ha hecho especial énfasis en que las aplicaciones creadas por terceros no tendrán ningún tipo de desventaja en cuanto a funcionalidad y acceso al dispositivo frente a las aplicaciones "nativas" que se distribuyen originalmente con Android. Android proporciona un paquete completo de software a todos los niveles [4]: Arquitectura - Un kernel Linux que sirve como base de la pila de software y se encarga de las funciones más básicas del sistema: gestión de drivers, seguridad, comunicaciones, etc. - Una capa de librerías de bajo nivel en C y C++, como SQLite para persistencia de datos; SGL, desarrollada por Skia (adquisición de Google); OpenGL ES para gestión de gráficos 3D, con aceleración 3D opcional y Webkit como navegador web embebido y motor de HTML. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 68 Anexo B – Android Figura B.1 – Evolución del lanzamiento de Android Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 69 Anexo B – Android - Un framework para el desarrollo de aplicaciones, dividido en subsistemas como el package manager, gestión del hardware del teléfono anfitrión (telephony manager) o acceso a APIs sofisticadas de geolocalización o mensajería - Una suite de aplicaciones (navegador, agenda, gestión del teléfono) XMPP. También incluye un sistema de vistas para manejar el interfaz de usuario de las aplicaciones, que ofrece posibilidad de visualización de mapas o renderizado HTML directamente en el interfaz gráfico de la aplicación. Las aplicaciones Android están programadas en Java, pero no corriendo sobre Java ME, sino sobre Dalvik, una máquina virtual Java desarrollada ex profeso por Google y optimizada para dispositivos empotrados y en la que los códigos fuente se compilan a ficheros de bytecode .dex. La creación de una virtual machine propia es un movimiento estratégico que permite a Google evitar conflictos con Sun por la licencia de la máquina virtual, así como asegurarse el poder innovar y modificar ésta sin tener que batallar dentro del B.2 Estructura de una aplicación Android Java Community Process. La estructura de una aplicación Android está definida por la interacción de distintos componentes, haciendo énfasis en la "agrupación débil" de distintas piezas. La aplicación hará uso de las distintas APIs expuestas por Android, de forma que los componentes encargados de realizar cada tarea puedan ser manipulados o reemplazados sin problemas, asegurando la máxima flexibilidad. Por ejemplo, una aplicación puede permitir al usuario elegir fotos mediante el componente "Galería" o, por ejemplo, reemplazar esa "Galería" por una selección de fotos a través de un servicio online. Los principales componentes de una aplicación serían:  Activity: Representa cada una de las principales tareas que el usuario puede llevar a cabo en la aplicación. Típica (aunque no necesariamente) corresponderá a una pantalla específica de la aplicación y, también normalmente, una Activity será el punto de entrada (pantalla inicial) de nuestra aplicación. Desde ella se invocarán las vistas específicas o layouts para la aplicación.  IntentReceiver: Permite a la aplicación declarar ciertos callbacks que responderán a cambios en el estado del terminal. Por ejemplo, llamada o email recibido, cambio en la geolocalización, etc. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 70 Anexo B – Android  Service: Una tarea que corre en el background y que puede y debe ejecutarse sin interacción con el usuario. Una aplicación puede mandar los mensajes necesarios a un determinado servicio activo.  ContentProvider: Establece una capa que permite a las distintas aplicaciones compartir datos. Con independencia del almacenamiento local que utilicen para sus propósitos, las aplicaciones necesitan declarar ContentProviders para poner a disposición de otros procesos los datos que consideren necesarios. Estas son algunas de las principales, pero no las únicas piezas de construcción B.3 Dispositivos disponibles de la aplicación. También es interesante que se defina como pieza de primer nivel, el sistema de notificaciones en pantalla, que se recomienda como principal vía de comunicación con el usuario. Android ha conseguido “explotar” en el último año, por lo que desde que se inició este proyecto hasta su finalización, han aparecido numerosos dispositivos basados en este sistema operativo. Ha dejado de ser fruto de cábalas y especulaciones, para convertirse en una realidad y ocupar una gran cuota de mercado, superando incluso, según las últimas estadísticas de ventas, al exitoso iPhone de Apple. De la mano de HTC, que apostó por él desde el principio y ha colaborado con Google en su lanzamiento y expansión (fabricando tanto los Dev Phones como el recién comercializado Nexus One), el resto de fabricantes se han subido al tren de Android y han desarrollado terminales con el nuevo sistema operativo. Como noticia de última hora en la fecha de redacción de este anexo, comentar que con la versión 2.2 (Froyo) que se lanzará próximamente (ya probada en un NexusOne), se espera un aumento del rendimiento del 450%, lo que situaría a este tipo de dispositivos a la cabeza del mercado en cuanto a prestaciones se refiere [23]. En el gráfico de la Figura B.2, puede verse la distribución de terminales comercializados según su versión de Android. Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 71 Anexo B – Android Figura B.2 – Distribución de las versiones de Android En la fase inicial de este PFC, se tuvo que realizar un pequeño estudio para decidir qué dispositivos eran más apropiados para implementar el proyecto. Se analizaron por tanto los terminales existentes, que por aquel entonces, no eran muchos, como puede verse en la siguiente tabla comparativa (ver Figura B.3) [24]. Figura B.3 – Comparativa terminales comerciales Android Además de estos terminales comerciales, Google ofrecía dos dispositivos para desarrolladores, el Google Dev Phone 1 ó HTC G1 (equivalente al HTC Dream) y el Dev Phone 2 ó HTC G2 (equivalente al HTC Magic). Tras analizar detalladamente las diferentes posibilidades, el HTC Hero convencía por su potente hardware y altas prestaciones, sin bien los Dev Phones eran equipos proporcionados especialmente para el desarrollo, por lo que finalmente se optó Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 72 Anexo B – Android por adquirir dos terminales HTC G2 a través del Android Market. El motivo principal de tomar esta decisión fue que, en los terminales comerciales, era muy posible que diversos aspectos del teléfono vinieran bloqueados por el fabricante, como accesos al hardware o algunas partes del API de desarrollo. B.4 Desarrollo de aplicaciones Para el desarrollo de aplicaciones de Android [25], Google proporciona un plugin para Eclipse que facilita el trabajo, ofreciendo herramientas como emuladores, acceso al sistema de archivos, gestión de hilos en ejecución, consola, etc. Por lo tanto, para comenzar a trabajar, lo primero que debe hacerse es descargar Elipse, un IDE gratuito que puede obtenerse en la sección downloads del sitio oficial: http://www.eclipse.org. El programa no necesita instalación, basta con ejecutar el fichero eclipse.exe una vez descomprimido el archivo .zip descargado. El siguiente paso será instalar el plugin de Android comentado. Para ello, hay que ir a la pestaña “Help > Install new software” (ver Figura B.4), y añadir la dirección web donde Eclipse deberá buscar y descargar el ADT (Android Development Tool), que puede encontrarse en la página para desarrolladores de Android, junto con los pasos detallados de la configuración: http://developer.android.com. Figura B.4 – Instalación del plugin ADT en Eclipse Implementación de una plataforma de telemonitorización de pacientes estándar, open source y ubicua basada en ISO/IEEE 11073-PHD sobre Android 79 Anexo C – Definición de medidas C.5 Peso El peso, según la OMS [29], es la medida de valoración nutricional más empleada, cuyo concepto se remonta a la antigua Grecia hace más de 2000 años. Por suerte, las balanzas que permiten su medición han evolucionado y hoy en día no representa ningún obstáculo el llevarlo a cabo, incluso en personas enfermas cuya movilidad sea dificultosa. El peso, no obstante, está en función del tipo morfológico y del esqueleto del individuo, por ello en ocasiones es preferible tomar otras medidas más representativas, como puede ser el Índice de Masa Corporal (IMC). Este índice es una medición indirecta de la composición corporal y tiene en cuenta tanto el peso como la estatura: 𝐼𝐼𝐼𝐼𝐼𝐼 = 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 2∗ 𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎 Según el valor del IMC, es posible clasificar a los individuos en varias categorías (Tabla C.1). La columna “Riesgo” indica el riesgo de sufrir otras enfermedades, a parte de la obesidad, como pueden ser: anorexia, bulimia, trastornos cardiovasculares, muerte prematura, hipertensión, etc. Tabla C.1 – Clasificación Indice de Masa Corporal Clasificación IMC (Kg/m2) Riesgo Peso bajo < 18.5 Alto Normal 18.5 – 24.9 Promedio Sobrepeso 25.0 – 29.9 Aumentando Obesidad 30.0 – 39.9 Severo Obesidad extrema > 39.9 Muy severo Por lo tanto, visto que el peso es un elemento determinante en la contracción de enfermedades, es importante mantenerlo bajo control, siguiendo las siguientes recomendaciones: - Llevar una dieta sana y equilibrada. - Compaginar la dieta con actividad física; el ejercicio aeróbico ayuda a incrementar el tejido muscular y a quemar calorías. - Evitar el alcohol o beber con moderación. - Recurrir a especialistas si no se consiguen cambiar los hábitos de alimentación.