Servicios personalizados
Español (pdf)
Articulo en XML
Referencias del artículo
Enviar articulo por email
Citado por SciELO 
Similares en
SciELO 
Permalink
Introducción
Actualmente, la evolución hardware/software de los teléfonos móviles y tabletas electrónicas ha permitido su vinculación en todas las esferas que conforman la vida cotidiana del ser humano.
En Cuba, se han desarrollado varias aplicaciones software para dispositivos móviles con Sistema Operativo (SO) Android. Entre estas, se encuentra el desarrollo de un sistema inalámbrico utilizando dispositivos Android para asistir a personas discapacitadas motoras y débiles visuales, usando los sensores de un smartphone, el protocolo de transmisión Bluetooth v4.0, y un Arduino controlado por una aplicación (APK, del inglés Android Aplication Package) para accionar remotamente, equipos y sistemas de una vivienda: luces, aire acondicionado, apertura de puertas y equipos electrodomésticos.1)
La implementación de una minilengua electrónica portátil controlada por un teléfono inteligente para el reconocimiento de muestras de leche2, es otro ejemplo de este tipo de aplicaciones. El entorno de desarrollo utilizado fue Android Studio. Dos aplicaciones que emplean las posibilidades internas del hardware de dispositivos móviles: acelerómetro y micrófono para desarrollar un podómetro y un analizador de voz, respectivamente, son propuestas en el trabajo titulado: Development of Healthcare Applications using Facilities available in modern Mobile Devices.3
Por otro lado, en el país, innumerables son los proyectos que se han implementado en la búsqueda de un continuo perfeccionamiento de los sistemas que permiten monitorizar inalámbricamente bioseñales. Entre estos se encuentra el Sistema de Medición Biomédico para la Exploración Vestibular (SMB-EV®). (4 Utilizando el estándar 802.11 (Wi-Fi), este sistema, transmite la señal electroculográfica desde una silla rotatoria hacia una estación base conformada por un punto de acceso y un ordenador.
El Sistema de Adquisición de Datos con comunicación inalámbrica aplicado al monitoreo remoto de señales fisiológicas (5, es otra de las evidencias del trabajo desarrollado por investigadores cubanos en esta esfera. Está basado en un microcontrolador PIC del tipo 18F77A y una microcomputadora. El sistema incorpora un módulo de transmisión/recepción del tipo XBee, que permite la comunicación inalámbrica bidireccional entre ellos. Además, nuestro equipo de trabajo ha diseñado e implementado un sistema inalámbrico de monitorización electrocardiográfica para dispositivos Android.6 Está basado en una arquitectura cliente-servidor y permite mediante el estándar 802.11 (Wi-Fi) registrar el electrocardiograma (ECG) de forma ambulatoria con un alcance de hasta 15 m.
Hasta nuestro conocimiento no se ha encontrado un trabajo que permita resolver las siguientes cuestiones: (a) en salas hospitalarias de espacios reducidos puede ser de interés que especialistas visualicen desde el exterior las señales biomédicas asociadas a un paciente determinado con el fin de arribar a diagnósticos colaborativos, (b) en ocasiones, no debe ser obviada la privacidad del paciente, lo cual limita el número de personas en las pruebas médicas que requieren de esta restricción. En tales casos, además, resultaría conveniente proporcionar al personal docente de la salud una herramienta que permita desde entornos periféricos hacer partícipes a sus estudiantes, de pruebas con estas características sin entrar en contacto directo con el paciente.
Por lo anteriormente expuesto, el objetivo del presente trabajo es desarrollar una aplicación Android que permita adaptarse a múltiples sistemas de monitorización inalámbrica con el fin de adquirir, visualizar y almacenar señales biomédicas.
Método
En la parte superior de la figura 1 se muestra la arquitectura general propuesta para el sistema de comunicación inalámbrico, basado en el estándar IEEE 802.11, comúnmente conocido como Wi-Fi, que es el usado por los dos dispositivos que se muestran en la parte inferior de dicha figura: el Sistema Inalámbrico de Monitorización Electrocardiográfica para dispositivos Android (SIMEA)6 a la izquierda (Caso 1) y el Sistema de Medición Biomédico para la Exploración Vestibular (SMB-EV®) a la derecha (Caso 2).4
La señal biomédica registrada al paciente por cualquiera de ambos sistemas (que actúan como servidor en la red inalámbrica): el electrocardiograma (ECG) para el SIMEA o el electroculograma (EOG) para el SMB-EV® será transmitida hacia el teléfono o tableta móvil (que actúa como cliente) usando el “Protocolo de control de transmisión/Protocolo de Internet” (TCP, del inglés: “Transmission Control Protocol”) y “Protocolo de Datagrama de Usuario” (UDP, del inglés: “User Datagram Protocol”). TCP es un protocolo confiable que permite que el flujo de datos originado en un extremo se entregue sin errores a otro extremo cualquiera de la red. El protocolo UDP, a pesar de no controlar la secuencia de los datos transmitidos, se emplea en aplicaciones donde se requiere mayor velocidad de transmisión y en las que no es necesario el nivel de confiabilidad de TCP.7
Otro aspecto importante es la forma en la que los datos son transmitidos desde el servidor hasta el cliente (Figura 1). En este punto, juega un papel primordial el modelo de Interconexión de Sistema Abierto (OSI, del inglés: Open System Interconnection), el cual consta de 7 capas: (1) “Física”, (2) “Enlace de datos”, (3) “Red”, (4) “Transporte”, (5) “Sesión”, (6) “Presentación” y (7) “Aplicación”.8 Cada capa cuenta con un conjunto de protocolos encargados de entregar el dato a la capa superior si se está transmitiendo, o a la capa inferior si se está recibiendo. Este modelo nos permite, como diseñadores, definir nuestro propio protocolo en la capa “Aplicación” y el formato de los datos (Unidad de dato de protocolo, PDU), intercambiados entre las capas de aplicación de ambos extremos de la comunicación, como se verá más adelante para cada uno de los casos 1 y 2.
El diseño software de la herramienta Android, que reside en el cliente, se sustenta en el concepto de Actividad (“Activity” en inglés), la cual representa una unidad de interacción con el usuario. En la figura 2 se muestra la concepción del diseño software para la herramienta propuesta, basado en la definición de 5 actividades y el diagrama de interacción entre estas. Cada actividad está compuesta por una interfaz de usuario que tiene asociada una clase con varios métodos que pueden ser utilizados o no por el desarrollador. En las diferentes interfaces se colocan los componentes (botones, listas, imágenes, gráficas, etc.) y la clase basada en el lenguaje de programación Java garantiza la funcionalidad de cada componente. El usuario puede navegar entre las diversas actividades.9
Las funcionalidades son controladas por el desarrollador mediante los métodos que vienen por defecto asociados a la clase Java de una actividad. Dentro de los métodos más usados se destacan: (1) "onCreate()": se invoca cuando se crea la actividad y es apropiado para realizar cualquier configuración, como diseño y enlace de datos; (2) "onResume()": se invoca cuando la actividad va a comenzar a interactuar con el usuario; (3) "onPause()": indica que la actividad está a punto de ser lanzada a segundo plano, normalmente porque se ejecuta otra actividad y (4) "onDestroy()": se invoca cuando la actividad ha completado su ciclo de vida voluntariamente, o si el sistema operativo Android elimina la actividad porque necesita los recursos de memoria ocupados por esta.10
Fig. 2 Diagrama de interacción de las Actividades que conforman la herramienta. Cada actividad cuenta con al menos un botón ubicado en su parte inferior (ver texto).
Así, para cada actividad mostrada en la figura 2, en sus correspondientes métodos "onCreate()", se inicializan las variables globales que serán utilizadas por la actividad, se asocian los componentes que conforman su interfaz gráfica y se invocan los algoritmos que garantizan la correcta conexión a la base de datos con la que se desee trabajar. La aplicación cuenta con tres bases de datos: (1) “db_pacientes”, que almacena la información personal de los pacientes a los cuales se les realizarán las pruebas médicas, (2) “db_sennales”, almacena las señales adquiridas de los pacientes y (3) “db datos_conexion”, que contiene la información de configuración de la red (sockets de origen y destino) y el tiempo de duración que tendrá la señal adquirida.
Los métodos "onResume()" de cada actividad garantizan que exista una correcta conexión con la red Wi-Fi. Si hay fallas, se notifica al usuario mediante mensajes de textos cortos mostrados por pantalla. Los métodos "onPause()" de cada actividad permiten almacenar temporalmente los datos con los que estaba interactuando el usuario cuando la actividad pasa a segundo plano. Estos datos son recuperados cuando la actividad vuelve a primer plano, evitándose la pérdida de información sensible. Los métodos "onDestroy()" de cada actividad liberan los recursos de memoria ocupados por la APK mejorando así el rendimiento del dispositivo cuando el usuario deja de utilizar la herramienta.
La Actividad_1 ("Menu") es la primera actividad con la que interactúa el usuario brindándole la posibilidad de definir qué operación va a realizar. Para esto, cuenta con una serie de botones ubicados en su parte inferior. El botón “Menú” (M), permite al usuario regresar a esta pantalla para poder realizar una nueva operación. El botón “Pacientes” (P), carga en la Actividad_2 (“Pacientes”), todos los pacientes que se encuentran registrados en la base de datos “db_pacientes”. Una vez aquí, si el usuario presiona el botón “Atrás” (A) del dispositivo Android (DA), se regresa a la Actividad “Menu”. Si, por el contrario, presiona el botón “Nuevo Paciente” (NP) se lanzará la Actividad_4 nombrada “Escaner”.
Otra forma de llegar a esta actividad es presionando el botón “Escaner” (E) disponible en la Actividad “Menú”. Aquí, el usuario puede escanear el código QR presente en los carnés de identidad (CI) de los ciudadanos de nuestro país, para añadirlos a la base de datos “db_pacientes”. Al presionar el botón “Atrás” (A) del DA se regresa a la Actividad “Menú”; en caso de presionar el botón “Agregar”, se actualiza primero la base de datos y luego se vuelve a la Actividad “Menú”.
Con el fin de adaptar la herramienta a diferentes sistemas de monitorización, se incluye el botón “Configuración” (C). Está opción le permitirá al usuario, mediante la Actividad_3 (“Configuracion”) actualizar los datos almacenados en la base de datos “db_datos_conexion”. Si se presiona el botón “Atrás” del DA se vuelve a la Actividad “Menú”, en caso de presionar el botón “Guardar”, se actualiza primero la base de datos y luego se vuelve a la Actividad “Menú”.
Al presionar el botón “Graficar” (G), el usuario accederá a la Actividad_5 (“Graficar”). En esta, se grafican las señales recibidas desde el sistema de monitorización. De igual manera, cuando el usuario presione el botón “Atrás” del DA regresará a la Actividad “Menú”.
Resultados
Para la confección de la herramienta que reside en el cliente, se utilizó el programa Android Studio en su versión 4.1.3 de IntelliJ® Platform. Este es el entorno de desarrollo integrado (IDE, del inglés Integrated Development Environment) oficial para el desarrollo de aplicaciones móviles soportadas en el SO Android. Se optó por el lenguaje de programación Java por su sencillez y robustez, además, de poseer una amplia documentación.
El IDE, apoyado en el motor de lenguaje de consulta estructurada (SQL, del inglés Structured Query Language) brinda a los desarrolladores la posibilidad de dotar a las aplicaciones con la capacidad de gestionar las tres bases de datos de la aplicación descritas anteriormente: “db_pacientes”, “db_sennales” y “db_datos_conexion”.
A la izquierda de la figura 3 se observa dentro de un recuadro de color rojo la apariencia de la APK en un dispositivo con SO Android. Una vez que el usuario se dispone a utilizar la aplicación aparece la Actividad “Menú” tal y como se muestra en el centro de la Figura 3. En la parte inferior, de izquierda a derecha, se encuentran los botones: “Menú”, “Pacientes”, “Graficar”, “Configuración” y “Escáner”. En este punto, el botón “Escaner” dirige al usuario a la Actividad “Escáner”. A la derecha de la figura 3 se observa el resultado de escanear el carnet de identidad de un paciente.
Fig. 3 (Izquierda) Apariencia de la aplicación en un dispositivo con SO Android. (Centro) Actividad: “Menú” con los botones: “Menú”, “Pacientes”, “Graficar”, “Configuración” y “Escáner”. (Derecha) Actividad: “Escáner” durante el escaneo del carné de identidad (CI) de un paciente (Nombre, Apellidos, CI, FV). En la parte inferior se encuentra el botón “AGREGAR”.
Al presionar el botón “AGREGAR” los datos mostrados en la figura 3 (derecha) son agregados a la base de datos “db pacientes”. Además, junto a estos datos se almacena la hora y la fecha en la que se introducen los datos del paciente. Esta información puede ser consultada en la Actividad “Pacientes” tal y como se muestra a la izquierda de la figura 4.
Antes de comenzar el proceso de adquisición de las señales es necesario realizar las configuraciones de red y definir el tiempo que durará la adquisición. Esto se logra mediante la Actividad “Configuracion”, figura 4 (derecha), la cual permite, configurar los sockets de destino y origen a través de los cuales, la APK intercambiará información con el sistema de monitorización inalámbrico. Además, el tiempo de duración del segmento de señal que se almacenará en la base de datos “db_sennales” también puede ser seleccionado entre los valores: uno, tres, y cinco minutos. Una vez obtenida la configuración deseada, el botón “Guardar” almacena estos datos en la base de datos “db_datos_conexion”.
Fig. 4 (Izquierda) Actividad: “Pacientes”, mostrando la información referente al paciente agregado previamente a la base de datos. (Derecha) Actividad: “Configuración”, mostrando los valores predeterminados de IP destino, puerto destino, puerto de origen y tiempo de medición.
La evaluación de la aplicación se realizó incorporándola a los dos sistemas de monitorización antes mencionados.4,6 En el primer escenario (SIMEA)6, la APK intercambia datos con el sistema según las especificaciones que este define por medio del protocolo implementado en su capa de aplicación. Por otro lado, en el segundo escenario (SMB-EV®)4, no es necesario enviar información de control desde la APK ya que esta función es realizada por otra parte del sistema. En ambos sistemas, los dispositivos que captan las señales se alimentan a baterías y transmiten de forma inalámbrica, por lo que cumplen las normas de seguridad eléctrica según la norma NTC-IEC 60601-1.
A la izquierda de la figura 5 (recuadro de color rojo) se puede apreciar la Actividad “Graficar” durante la adquisición de una señal de ECG obtenida en el primer escenario. En esta se encuentran: (1) Nombres y Apellidos del paciente al que le serán acreditadas las señales adquiridas; (2) Los indicadores de disponibilidad de los servicios Wi-Fi del dispositivo y de conectividad a la Red; (3) Cronómetro; (4) Cuadro de texto en el que se introduce el comando a enviar hacia el sistema de monitorización, (5) Botón “Enviar” el cual permite enviar el comando; (6) Gráfica de la señal que se recibe en tiempo real y los botones “Play” (7) y “stop” (8) que permiten controlar el segmento de señal a almacenar en la base de datos “db sennales”. Cuando se presiona el botón “Play”, el cronómetro comienza a contar hasta completar el tiempo de medición definido previamente en la Actividad “Configuración”. El botón “stop” cancela este proceso brindándole al usuario la posibilidad de almacenar otro segmento de señal. Cuando el cronómetro llega al tiempo límite, la señal es guardada automáticamente en la base de datos “db_sennales”.
El protocolo de la capa de aplicación de este sistema se basa en el intercambio de comandos entre un módulo transmisor y el DA.6 El módulo se encarga de adquirir (a una frecuencia de 100 Hz), acondicionar y transmitir la señal de ECG hacia el DA conformando la PDU mostrada a la izquierda de la Actividad “Graficar” resaltada en un recuadro rojo en la figura 5. La transmisión de los datos comienza cuando desde el DA se envía el comando “comenzar” y se detiene cuando se envía el comando “detener”.
Fig. 5 (Izquierda) Actividad “Graficar” durante la adquisición de la señal de ECG de un paciente y estructura de la PDU conformada por el servidor. “Valor Leído” hace referencia a cada muestra de la señal de ECG y “separador” al carácter “:”. Al final de la PDU se coloca un marcador “Mdr” con el fin de elevar la confiabilidad del sistema. (Derecha) Actividad “Graficar” durante la adquisición de una señal electroculográfica transmitida durante una prueba rotatoria realizada por el sistema SMB-EV®.
En la figura 5 de la derecha (recuadro de color verde) se muestra la aplicación de la herramienta en el segundo escenario. Al ejecutar la Actividad “Graficar” se visualiza la señal electroculográfica recibida. Por motivos de propiedad intelectual, en el presente trabajo no se brindan detalles del protocolo de la capa de aplicación ni la PDU de dicho sistema.
Discusión
En el primer caso de estudio, las pruebas experimentales demostraron que para un rango de hasta 15 m las señales electrocardiográficas transmitidas desde el servidor (SMI) hacia el dispositivo móvil (cliente) fueron recibidas de forma correcta. Fuera de este rango existieron problemas de conexión entre ambos dispositivos. La implementación del protocolo TCP en la capa de transporte garantizó que en caso de fallas de conexión se descartara la adquisición. El consumo de batería del dispositivo móvil dependió del modelo y marca de este.
Para el segundo caso de estudio, las pruebas experimentales realizadas con señales electroculográficas exhibieron resultados muy similares al primer caso diferenciándose únicamente en el rango de medición, para este último fue de hasta 30 m. El rango de medición depende en gran medida de las características técnicas del sistema de monitorización inalámbrica.
La aplicación permitió almacenar las señales adquiridas en una base de datos creada en el dispositivo Android, de esta forma, por cada sistema de monitorización inalámbrica al que le sea incorporada la APK se obtendrá de una base de datos diferente. Esta prestación no solo brinda la posibilidad de llevar un seguimiento detallado de cada paciente, sino que, además, pudieran ser utilizadas como elementos de aprendizaje para desarrollar futuros algoritmos de inteligencia artificial.
La herramienta puede ser aplicada en otros escenarios siempre y cuando se conozca previamente el protocolo de la capa de aplicación y la PDU. Esto se debe a que los protocolos en esta capa corren a cargo de los desarrolladores y, por tanto, no siguen ninguna regla específica. Además, la herramienta pudiera redefinirse para otros dispositivos médicos que usen otros protocolos y estándares, por ejemplo: ZigBee basado en el estándar IEEE 802.15.4 y Bluetooth basado en el estándar IEEE 802.15.1, de forma que el diseñador pueda optimizar el desempeño final, dependiendo del escenario de aplicación, rango de transmisión, complejidad, velocidad de transferencia y consumo deseado.11,12
Conclusiones
En este trabajo se describió e implementó una aplicación software para teléfonos y tabletas con SO Android que permite visualizar y almacenar señales biomédicas. Las pruebas realizadas en dos sistemas de monitorización inalámbrica arrojaron excelentes resultados desde el punto de vista cualitativo. En el futuro se pudieran agregar otras funcionalidades afines al procesamiento y análisis de las bioseñales objetos de estudio.
