I. INTRODUCCIÓN

La telemedicina es un recurso tecnológico que ha permitido grandes avances al área de la salud. Uno de ellos es el seguimiento médico a un paciente con una enfermedad crónica como la diabetes o alguna enfermedad cardiovascular (ECV). Estos dos padecimientos pertenecen a un grupo denominado enfermedades no transmisibles, que requieren análisis periódicos de exámenes como el electrocardiograma y signos vitales asociados, los cuales se realizan en un espacio provisto de los elementos médicos de medición, ya sea en un hospital o llevando los equipos a los hogares de los pacientes, acarreando grandes costos de las entidades prestadoras de servicio, además de esfuerzos y costos del paciente al desplazarse y pagar transporte.

Es importante invertir en estos costos ya que se está hablando de la vida de muchas personas, puesto que las enfermedades no transmisibles son la mayor causa de mortalidad de la población mundial ^[1]. Datos tomados por el observatorio nacional de salud del Instituto Nacional de Salud de Colombia, quien se encarga de recopilar toda esta información y mostrar los análisis ^[1], revelan tasas de mortalidad de hasta 25,4% en 2011 ocasionadas por ECV. Teniendo esto en cuenta, los desarrollos tecnológicos buscan disminuir los costos incurridos en el seguimiento de este tipo de enfermedades.

En este sentido, los primeros desarrollos que se han implementado para atender las enfermedades mencionadas han sido aplicativos para computadores de escritorio de los pacientes, los cuales, utilizaban un puerto con interfaz serial para comunicarse con una red de sensores-microcontrolador externa y recibir información de los signos vitales de una persona, siendo esta almacenada en bases de datos ^[2]. El inconveniente de esta propuesta redunda en que los computadores no son elementos fáciles y/o cómodos de transportar a todas partes y menos para un enfermo.

Sin embargo hay otras posibilidades, los teléfonos inteligentes (Smartphone), dispositivos con sistemas operativos como Android, iOS, Windows Phone ó BlackBerry OS, son computadores portátiles con altas capacidades de procesamiento, que realizan las funciones básicas de un teléfono; por ejemplo, hacer llamadas o envíos de mensajes de texto, y adicionalmente, incluyen funciones de un computador como el procesamiento de texto o navegación en la Internet; todo esto en un dispositivo que es fácil de llevar a cualquier lugar, gracias a su peso y tamaño.

El desarrollo de software para los Smartphone tiene en particular un área dedicada a la implementación de aplicativos móviles denominada mHealth, término que hace referencia a la informática que usa dispositivos móviles, sensores médicos y tecnologías de la comunicación para promover la salud ^[3]. Esta área abarca una amplia gama de aplicativos que van desde recomendaciones para dietas, registros manuales de actividades físicas y signos vitales, consejos médicos, hasta aplicativos para solicitar citas médicas con especialistas. En los últimos años se han realizado estudios que registran el incremento de aplicaciones mHealth en las tiendas virtuales de los Smartphone ^[4-6]. Algunos de estos estudios realizan clasificaciones de las aplicaciones basándose en criterios de funcionalidad ^[4, ^5], teniendo en cuenta el personal que manipula la aplicación ^[5] -ya que la información de interés para un paciente es diferente a los datos que necesita un médico-, o con base en los costos de la aplicación ^[4]. El caso particular que nos interesa es el de las aplicaciones mHealth que realizan análisis de información suministrada directamente desde sensores médicos, es decir sin que la persona tenga que ingresar los datos manualmente.

Estos datos y el incremento del uso de Smartphone en la población colombiana ^[7,8], nos da la oportunidad de desarrollar un aplicativo mHealth para el monitoreo de pacientes con ECV, permitiendo adquirir, desde cualquier lugar, ya sea en el trabajo o en la casa, los datos de signos vitales de un paciente con una red de sensores conectada a su cuerpo en un extremo y comunicada al dispositivo móvil mediante la interfaz USB, eliminando los costos de transporte del paciente, y almacenando la información en una base de datos para que los médicos revisen el historial y programen las citas que permitan análisis más detallados, en caso que sea necesario.

La propuesta del presente artículo nace del centro de excelencia ARTICA (Alianza regional en TICs aplicadas), que, buscando desarrollar tecnologías que fortalezcan el sector de la salud desde diferentes ejes¹, plantea en un proyecto el desarrollo de un sistema de vigilancia y seguimiento a los pacientes que permitan su monitorización permanente por fuera del ambiente hospitalario.

El presente artículo muestra el desarrollo, desde el entorno QT con lenguaje C++, de un aplicativo prototipo para Smartphone con sistema operativo Android (debido a la preferencia de los colombianos en el año 2014 por este sistema operativo ^[9]), que se comunica con una red de sensores, realizando peticiones periódicamente de señales ECG y signos vitales para ser almacenados y posteriormente procesados.

II. MATERIALES Y MÉTODOS

El aplicativo tiene como objetivo solicitar información a una red de sensores externa, desplegarla en la pantalla cuando esté disponible, y almacenarla en una base de datos interna al dispositivo. En la Fig. 1 se puede apreciar el sistema completo. Existen dos tipos de personas que interactúan con la aplicación; el primero se denomina usuario paciente, quien tendrá acceso a una ventana en donde podrá enviar mensajes de pánico a una lista de personas llamada círculo de acompañamiento y/o comenzar la petición de datos a la red de sensores en unos tiempos predefinidos. El segundo es el usuario médico, quién tiene acceso a ventanas de configuración, vista de reportes y toma de datos en cualquier momento; todo ello a través de una ventana de acceso que solicita un nombre de usuario y contraseña. Para lograr el objetivo se utilizaron una serie de materiales y metodologías que se listan y describen a continuación.

Fig. 1 Sistema completo. 

Materiales

El hardware utilizado consta de 2 elementos fundamentales, un dispositivo móvil y un módulo de conversión usb-serial (ver Fig. 2). A continuación se describen en más detalle.

Fig. 2 Diagrama de Hardware. 

El dispositivo móvil utilizado cuenta con las características descritas en la Tabla 1 y el integrado FT232RL es el conversor utilizado, encargado de realizar un puente de comunicación entre la salida del Smartphone (USB) y la salida de la red de sensores (interfaz serial).

Tabla 1 Características del dispositivo móvil². 

Metodología

El aplicativo para Android tiene como objetivo solicitar, almacenar, analizar y desplegar los resultados de la señal ECG y variables médicas (temperatura, nivel de oxígeno en la sangre, frecuencia cardiaca y glucosa), ayudando en el monitoreo de una persona con ECV e informando a las personas cercanas del paciente si se presenta algún contratiempo. Para ello el aplicativo está conformado por varios módulos, que pueden ser apreciados en la Fig. 3. Cada uno de ellos tiene funciones específicas que interactúan entre sí para el funcionamiento adecuado del sistema.

Fig. 3 Diagrama de software. 

Interfaz de Usuario

El diseño de la interfaz gráfica se realizó con la ayuda de la herramienta de diseño de QT. En este, se implementaron 8 ventanas principales para dos tipos de usuario: paciente y médico. El usuario paciente tiene acceso a solamente una ventana, mientras que el médico tiene acceso a las demás a través de una ventana de acceso.

La interacción entre las diferentes ventanas se basa en una máquina de estados de la siguiente manera: Al iniciar la aplicación se revisa si ya se tienen configurados los datos del paciente. En caso afirmativo, se informa de la próxima hora en la que el paciente se debe tomar las mediciones los datos y se despliega la ventana en donde el usuario puede; a) enviar alertas al círculo de acompañamiento a través del botón de pánico, b) comprobar la conexión del dispositivo USB, c) iniciar la toma de datos en las horas que están registradas, y d) salir del aplicativo. Si los datos no están configurados, todos los botones estarán deshabilitados hasta que se ingrese la información del paciente, El único botón habilitado será el del logueo de médico; cuando el médico accede con los datos correctos se abre una ventana con un menú de opciones en donde aquel puede: a) cambiar su clave de acceso, b) registrar los datos del paciente (nombre, número de identificación, nombres y número de celular de sus acompañantes, horas en la que se debe realizar la toma de datos médicos y rangos las variables médicas), c) realizar pruebas en tiempo real, y d) observar históricos de datos. Cuando el usuario médico sale de la aplicación y ha configurado el usuario paciente correctamente se abre la ventana del paciente. Desde cualquier ventana se puede cerrar el aplicativo y desde cualquier ventana de la interfaz del médico se puede regresar a la interfaz del paciente El proceso anteriormente mencionado se indica de manera gráfica en la Fig. 4.

Fig. 4 Diagrama de Flujo para la aplicación de la interfaz de usuario. 

Comunicación con la base de datos

Se usó una base de datos interna SQLite para almacenar la información descrita a continuación con ayuda de la Fig. 5:

• Datos del médico: Nombres de usuario y contraseña.

• Datos del Paciente: Nombre y número de documento

• Círculo de acompañamiento: nombre del paciente, nombre del acompañante, número de teléfono del acompañante.

• Las horas prueba en que el paciente se debe realizar la toma de datos.

• Registros de mediciones en 3 tablas, relacionadas con el ID de la prueba. La primera con la fecha y hora de la prueba, la segunda con datos ECG, y una tercera con la información de las variables temperatura, frecuencia cardiaca, SPO2 (nivel de oxígeno en la sangre) y glucosa.

• Límites de valores: Son los valores extremos de los rangos de los datos médicos en que el paciente debe estar normalmente. Para las variables temperatura, frecuencia cardiaca y frecuencia respiratoria se tienen 4 limites, dos inferiores y dos superiores (límite para alerta amarilla y límite para alerta roja); mientras que para la variable SPO2 solo tiene un límite debido a que es un porcentaje y en las personas se tiene normalmente por encima de 90%.

Fig. 5 Estructura de las tablas de la base de datos. 

Análisis, resultados y reportes

Al aplicativo se le integró un módulo de análisis de señales ECG que requiere de una cantidad mínima de información (20 latidos) para realizar cálculos de frecuencias cardiaca y respiratoria. La información se envía en buffers de datos que no son consecutivos, por lo que se debe analizar cada uno por separado. Cada vez que llega un buffer se evalúa para ver si posee la cantidad mínima de información para ser analizado, si esto es correcto se entregan los datos al módulo ECG y los resultados se despliegan en pantalla en un mensaje emergente como se muestra en la Fig. 6, en caso contrario se informa que no se pudo realizar un análisis por falta de información.

Fig. 6 Ventana de usuario paciente y despliegue de resultados. 

III. RESULTADOS

Luego del diseño y la implementación del software y hardware, expuestos anteriormente, se obtiene un aplicativo prototipo en un Smartphone que tiene conectado por medio del módulo USB un radio de comunicaciones con la red de sensores.

Sobre este prototipo se realizan 12 pruebas. Cada prueba consiste en enviar peticiones de datos a la red de sensores que obtiene la información de las variables médicas del paciente. Las peticiones pueden ser de una trama de señal ECG o de una trama de variables médicas (temperatura, frecuencia cardiaca, SPO2). La solicitud de tramas se realiza en ciclos de 6 peticiones, 5 de señal ECG y 1 de variables médicas. En el momento en que la red detecta una solicitud, envía una trama de datos con información al Smartphone, en donde se almacena en una base de datos para su posterior uso. Si el Smartphone no recibe una respuesta 2 segundos después de haber realizado una petición a la red de sensores, se realiza una nueva solicitud; si la respuesta llega en un tiempo menor a 2 segundos, la siguiente petición se realiza inmediatamente.

Al iniciar cada prueba se ubica el Smartphone a menos de medio metro del módulo de sensado, en ese momento se realiza la primer petición y se desplaza el celular una distancia entre 0,5 y 3,0 metros que quedará fija durante el toda la prueba, la cual durará 1 hora. 6 de las pruebas se realizan en un ambiente abierto sin objetos entre la red de sensores y las otras 6 en un área en donde hay objetos e inclusive el paso de personas entre la red de sensores.

3.1 Tiempos de petición por buffer

La señal ECG se almacena por tramos, denominados ciclos, que tienen entre sí un tiempo de diferencia, por lo que se deben analizar por separado por el algoritmo de delineamiento ECG. Este algoritmo, como se mencionó en la sección de materiales y métodos, requiere un número mínimo de información para entregar resultados. La Tabla número 2 muestra la cantidad de datos y el retardo asociado a su transmisión por cada ciclo en las diferentes pruebas.

En la Tabla 2 se puede apreciar como la distancia no afecta el tiempo de transmisión y la cantidad de tramas ECG que llegan por cada ciclo, teniendo el primero un promedio general de 143 segundos y el segundo 214 tramas. El tiempo promedio aumenta de manera considerable cuando una persona, el objeto más influyente que se pudo observar, se interpone en el medio de la red de sensores, ya que al no recibir la respuesta se agregan 2 segundos al tiempo total de transmisión del buffer. Buscando mejorar este resultado, en el aplicativo se realiza un conteo de las peticiones haciendo notar al usuario cuando los datos no están llegando y aconsejando que, si esto sucede, acerque Smartphone al nodo de sensado.

Tabla 2 Números de datos y tiempos promedio de petición, llegada y almacenamiento de la información de las tramas ECG. 

S.O. (Pruebas sin obstáculos y personas transitando).

C.O. (Prueba con obstáculos y personas transitando).

Cuando una persona se acercaba al Smartphone y lo cubría con las manos, este dejaba de recibir información, mientras que en los casos que la persona solo se interponía en línea directa los datos dejaban de llegar por un par de segundos, como si buscara otro camino de transmisión.

3.2. Gráficos de transmisión de datos:

La Tabla 2 muestra solo la cantidad de tramas de los buffer completos de la señal ECG, que al ser sumadas a las tramas de los buffer que no alcanzaron a llegar completos y las tramas de la variables médicas se obtiene el total de tramas en cada prueba. La Fig. 7 muestra la cantidad de datos que llegaron al Smartphone y fueron almacenados en la base de datos en cada una de las 12 pruebas.

Fig. 7 Cantidad de datos recibidos por distancia en 1 hora de transmisión. 

Tanto la distancia como los obstáculos disminuyen la cantidad total de tramas por prueba. Siendo los obstáculos quienes influyen de mayor manera en estos resultados.

3.3. Consumo de batería con aplicativo en primer plano

En la Fig. 8. se ven los niveles de consumo de batería del aplicativo durante 1 hora. Este dato es importante por qué se debe asegurar el mínimo nivel de batería cada vez que se vaya a realizar una prueba de petición y transmisión de datos desde la red de sensores, es decir más de 12%. Con este dato se establece que el Smartphone tenga como mínimo 20% de batería para realizar una prueba.

Fig. 8 Consumo de batería del aplicativo con la aplicación. 

IV. DISCUSIÓN

Del número total de tramas de cada una de las pruebas y su duración, se puede observar que el aplicativo móvil recibe la trama solicitada y la almacena en la base de datos en un tiempo promedio inferior a un segundo y un buffer completo de señal ECG en un tiempo promedio de 2 a 3 minutos. Tener la posibilidad de implementar una base dedatos externa, comunicada con el Smartphone a través de la Internet, permitiría tener un software exterior para consultar el estado del paciente, ya sea estadísticas de los últimos días o información de una muestra que se esté tomando actualmente. En el primer caso para ver evoluciones o comportamientos en casos que el paciente deba consumir algún medicamento o realizar rutinas para mejorar su estado de salud; por otro lado, en el segundo caso para que el médico pueda tomar decisiones en momentos de presentarse un evento de alarma con los signos vitales del paciente, actuando en el menor tiempo posible. Todo esto sin depender del dispositivo móvil del paciente, que es donde actualmente se tiene la base de datos.

El software de desarrollo QT permite la compilación de un mismo proyecto para diferentes plataformas, teniendo presente que para cada una de ellas usa librerías y permisos particulares. Buscando que este aplicativo pueda ser usado por el mayor número de personas se plantea para trabajos futuros exportar el aplicativo para dispositivos móviles iOS o Windows phone. Teniendo presente que para el primero se requiere instalar QT en un computador con sistema a operativo Mac, mientras que para el segundo se necesita computador con sistema operativo Windows 8 en adelante.

V. CONCLUSIÓN

En este trabajo se diseñó e implementó un aplicativo para dispositivos móviles Android que se encarga solicitar, por medio de un conector conversor USB-serial a una red de sensores, información de temperatura, Frecuencia cardiaca, SPO2 y señal ECG de una persona y almacenarla internamente en una base de datos.

El aplicativo permite a través de una ventana de configuración registrar, agregar y eliminar datos del paciente que lo usará, como por ejemplo las horas en que la persona se debe hacer las pruebas, datos del círculo de acompañamiento, entre otros.

En tiempo de ejecución el aplicativo realiza un conjunto de recordatorios y eventos de alarmas en donde se llama la atención del usuario con ayuda de las funciones de vibración, sonido, toast o mensajes emergentes y notificaciones en la barra de tareas del dispositivo móvil; adicional enviando un mensaje de texto a los números registrados en la tabla de círculo de acompañamiento de la base de datos.

El integrado que se encarga de realizar el puente de comunicación con la red de sensores es el FT232RL, es un dispositivo muy usado para programar diferentes microcontroladores y otros sistemas electrónicos, por lo que se puede encontrar fácilmente en el mercado.

Las pruebas finales del aplicativo se realizaron en un Smartphone con sistema operativo Android 5.1.1; sin embargo, en el proceso de desarrollo se probaron etapas en dispositivos con versiones de Android 4.4.4 y 2.3. Esto nos indica que el aplicativo puede ser instalado en dispositivos que se encuentren en el rango 2.3 a 5.1.1, considerando que el tiempo de lectura del dispositivo USB, extracción de la información de las tramas, almacenamiento en la base de datos y posterior consulta descrito en las pruebas, varía según el procesador del equipo; en las pruebas descritas anteriormente se encontró que el tiempo en que las información solicitada llega a estar disponible es considerablemente corto, una trama se almacena en la base de datos en promedio 0,5 segundos después de ser solicitada; mientras que para todo un buffer de señal ECG de 2 a 2,5 minutos. Tomando muestras en un tiempo de una hora, se llega a almacenar suficiente información y entregar promedios en los momentos en que el paciente acuda donde el médico para evaluar su estado en los últimos días. Las pruebas con obstáculos solo presentan demora en la transmisión cuando el obstáculo es una persona y cubre con sus manos o alguna otra parte del cuerpo al radio que se encuentra conectado al Smartphone, impidiendo la salida de las peticiones, por lo tanto no se presentan llegadas de las tramas con información y su posterior almacenamiento, análisis y despliegue en pantalla.