SciELO - Scientific Electronic Library Online

 
vol.12 issue24Structure of Department of Engineering and Maintenance, for _Hospital Institutions of Ill Level in Colombia author indexsubject indexarticles search
Home Pagealphabetic serial listing  

Services on Demand

Article

Indicators

Related links

  • On index processCited by Google
  • Have no similar articlesSimilars in SciELO
  • On index processSimilars in Google

Share


Revista Ingeniería Biomédica

Print version ISSN 1909-9762
On-line version ISSN 1909-9991

Rev. ing. biomed. vol.12 no.24 Medellín July/Dec. 2018

http://dx.doi.org/10.24050/19099762.n24.2018.810 

Artículos originales

Desarrollo de aplicativo prototipo en QT para apoyo a la hospitalización domiciliaria en dispositivos móviles Android

Prototype development application in QT for home care support for Android mobile devices

Desenvolvimento de aplicação de protótipos em QT para apoio atendimiento domiciliar para dispositivos móveis Android

Jaime Alberto Ríos-Palacioa  *  , Juan Felipe Botero-Vegaa 

a Universidad de Antioquia. Medellín, Colombia.

Resumen

El monitoreo constante de los signos vitales de un paciente con enfermedades cardiovasculares es de vital importancia. En el artículo se presenta el diseño de un aplicativo móvil, orientado a la telemedicina, para sistema operativo Android en el entorno de desarrollo QT. El aplicativo realiza peticiones de variables médicas y señal del electrocardiograma (ECG) por medio de interfaz USB a una red de sensores conectada al cuerpo del paciente, almacenándolas en una base de datos. El aplicativo activa alarmas para informar sobre eventos particulares y envía mensajes de texto a un grupo de personas denominado círculo de acompañamiento. Para probar el funcionamiento de la aplicación se realiza una serie de pruebas que consisten en medir el tiempo en que la información está disponible en la base de datos luego de realizar la petición a la red de sensores, y mostrarla en pantalla; los resultados arrojan tiempos promedios de 0,5 segundos por trama, y de 120-150 segundos una señal de 30 segundos de ECG. En estas pruebas se mide constantemente el consumo de batería del dispositivo y se compara con el consumo cuando la aplicación no está realizando peticiones, encontrando una diferencia de 4% para periodos de 1 hora.

Palabras-clave: Android; Aplicativos móviles; Atención domiciliaria; Electrocardiograma; mHealth; QT

Abstract

Constant monitoring of vital signs of a patient with cardiovascular disease is vital. This article presents a design in QT of an applicative mobile to Android operative system focused on telemedicine. The Application does requests of medical variables and electrocardiogram signal (ECG) way to USB interface to a sensor network connected to patient body, store it in a database. Applicative activates alarms to inform about some events and send text messages to a group of people called escort circle. To probe the operation of application it has been made a serie of tests that consisting in measure the time that takes the information to be available in the database after be requested to the sensor network and deployed on screen. The results gives average times of 0,5 seconds per frame and 120-150 second per ECG signal of 30 seconds. On these tests the consume of battery device level has been measured and compared with the consume when the application is no doing requests, find differences of 4% in period of times of 1 hour.

Key words: Android; movile app; Home care; Electrocardiogram; mHealth; QT

Resumo

A monitorização constante dos signos vitais de um paciente com doenças cardiovasculares é muito importante. No articulo se apresenta o desenho de uma aplicação móvel, orientada à telemedicina, para o sistema operativo Android no entorno de desenvolvimento QT. A aplicação realiza petições de variáveis médicas e do sinal do eletrocardiograma (ECG) por meio de uma interface USB a uma rede de sensores que estão ligadas ao corpo do paciente, e depois as armazena em uma base de dados. A aplicação liga as alarmas para informar sobre eventos particulares e envia mensagens de texto a um grupo de pessoas chamado círculo de acompanhamento. Para testar o funcionamento da aplicação se realiza uma serie de provas que consistem em medir o tempo de disponibilidade da informação após de realizar a petição à rede de sensores e mostra a informação na tela da aplicação. Os resultados mostram médias de 0,5 segundos por trama, e de 120 - 150 segundos para uma sinal de 30 segundos de ECG. Nestas provas se mede constantemente o consumo da bateria e se compara com o consumo quando a aplicação não está fazendo petições, encontrando uma diferença de 4% para períodos de 1 hora.

Palavras-Chave: Android; aplicação móvel; atendimiento domiciliar; eletrocardiograma; mHealth; QT

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 ejes1, 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óvil2

Software

Se usó la plataforma de desarrollo QT aprovechando las capacidades de: programación en lenguaje C++ y compilación de los programas para dispositivos móviles Android, así como la posibilidad de llevar a futuro a otras plataformas reutilizando el código ya creado. Desde esta plataforma se trabajó en tres herramientas que interactúan entre sí: 1) módulo de diseño gráfico para la apariencia de la aplicación, 2) lenguaje C++ para el control y procesos de la aplicación y 3) JNI (Java Native Interface) para obtener los permisos y programar los elementos particulares de Android.

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. 

El gestor de Recordatorios

Un gestor de recordatorios de las horas en las que se debe realizar las muestras de los datos es el encargado de indicar por medio de alertas y mensajes emergentes las horas en que se deben realizar la medición de variables, así como realizar recordatorios y registros en la base de datos e informe al círculo de acompañamiento cuando no se realiza una toma 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. 

Llamadas al sistema operativo Android a través de la comunicación C++y JNI

Es el módulo que permite acceder a los elementos particulares del sistema operativo Android. Se crea una clase con los métodos que permiten hacer llamados a funciones programadas en Java para realizar la vibración, notificaciones, Toast o mensajes emergentes, envío de mensajes de texto, lectura del nivel de la batería, control de volumen. Conformado por 4 elementos principales:

1. Comunicación USB

Es el software encargado de programar el integrado FT232RL que, como se indicó en la sección de hardware, es el puente entre la red de sensores y el dispositivo móvil. Para el uso del integrado se requiere un driver que la compañía FTID, diseñadora y distribuidora del integrado, pone a disposición en su página web3, este driver hace uso del API USB de Android, para obtener el permiso del sistema y enviar la configuración al integrado4.

2. Alarmas

Son las herramientas usadas para llamar la atención del usuario a eventos de información o alertas cuando un valor de un signo del paciente, enviados por la red de sensores, esté por fuera del rango normal. Se tiene la vibración del dispositivo, el uso del ringtone, toast o también llamados mensajes emergentes, notificaciones en la barra de tareas.

3. Lectura de nivel de batería:

Utilizada como un indicador de alerta al usuario cuando el nivel de batería es bajo para tenerlo listo para la próxima toma de datos.

4. MSM:

Es utilizada para enviar un mensaje al círculo de acompañamiento cuando ocurre un evento de alerta, cuando el paciente presiona el botón de pánico o cuando el paciente no se está haciendo la toma de datos.

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.

AGRADECIMIENTO

Deseo expresar mi agradecimiento al centro de excelencia ARTICA que bajo el proyecto "plataforma tecnológica para los servicios de teleasistencia, emergencias médicas, seguimiento y monitoreo permanente a los pacientes y apoyo a los programas de promoción y prevención" y el apoyo permanente de todos sus integrantes, permitió la realización de la aplicación.

A la universidad de Antioquia y a Colciencias por la beca de Joven investigador.

Al centro de innovación y negocios Ruta N por la prestación de instalaciones para trabajar durante el tiempo del proyecto.

Referencias

[1]. Instituto Nacional de Salud (2013). Enfermedad cardiovascular: principal causa de muerte en Colombia. Boletín Observatorio Nacional de Salud, 1(1) Diciembre, pp. 1-6. [Online] Disponible en: Disponible en: http://www.ins.gov.co/lineas-de-accion/ons/boletin%201/boletin_web_ONS/boletin_01_ONS.pdf [Consultado 11 de Diciembre de 2015]. [ Links ]

[2]. Kumar, K. M., & Venkatesan, R. S. (2014). A design approach to smart health monitoring using android mobile devices. En: Advanced Communication Control and Computing Technologies (ICACCCT). Ramanathapuran, India. 1740-1744 Mayo 2014. Disponible en: Disponible en: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7019406 [Consultado 11 de Diciembre de 2015]. [ Links ]

[3]. Lee J. (2014). Aplicaciones de salud diabética para dispositivos móviles: ¿Exageración o esperanza? Diabetes Voice, 59(3) Septiembre, pp. 43-46. [Online] Disponible en: Disponible en: https://www.idf.org/sites/default/files/attachments/2014_3_Lee_SP.pdf [Consultado 11 de Diciembre de 2015]. [ Links ]

[4]. Eng DS, Lee J.M. (2013). The promise and peril of mobile health applications for diabetes and endocrinology. Pediatric diabetes, 14(4) Junio, pp. 231-238. [ Links ]

[5]. Rosser BA, Eccleston C. (2011). Smartphone applications for pain management. Journal of Telemed and Telecare, 17(6) Septiembre, pp. 308-312. [ Links ]

[6]. Paschou M, Sakkopoulos E, Tsakalidis A. (2013). easy-HealthApps: e-Health apps dynamic generation for smartphones & tablets. Journal Medical System, 37(3) Mayo, pp. 1-12. [ Links ]

[7]. Diario El País Colombia (2015). Colombia, tercer mercado latinoamericano en usuarios de smartphones, Diario El País Colombia (2015). [Online] Disponible en: Disponible en: http://www.elpais.com.co/elpais/economia/noticias/colombia-tercer-mercado-latinoamericano-usuarios-smartphones . [Consultado el 2 de diciembre de 2015]. [ Links ]

[8]. Mera, A (2015). Los 'smartphones' siguen ganando protagonismo en el mercado tecnológico, Diario el País Colombia (2015). [Online] Disponible en: Disponible en: http://www.elpais.com.co/elpais/economia/noticias/smartphones-siguen-ganando-protagonismo-mercado-tecnologico . [Consultado el 2 de diciembre de 2015]. [ Links ]

[9]. Castro, A (2014). Futuro Digital Colombia 2014, Comscore (2014). [Online] Disponible en: Disponible en: https://www.comscore.com/lat/Prensa-y-Eventos/Presentaciones-y-libros-blancos/2014/2014-Digital-Future-in-Focus-Colombia . [Consultado el 2 de diciembre de 2015]. [ Links ]

1 Proyecto "plataforma tecnológica para los servicios de teleasistencia, emergencias médicas, seguimiento y monitoreo permanente a los pacientes y apoyo a los programas de promoción y prevención". Centro de Excelencia ARTICA.

Received: December 12, 2015; Accepted: June 22, 2018

* Dirección para correspondencia: shuin666@gmail.com

Creative Commons License Este es un artículo publicado en acceso abierto bajo una licencia Creative Commons