SISTEMA HEALTH CARE PARA EL MONITOREO DE...
149
SISTEMA HEALTH CARE PARA EL MONITOREO DE ARRITMIAS CARDÍACAS EN PERSONAS CON PROBLEMAS CARDÍACOS UTILIZANDO SERVICIOS WEB. JOSE JAIME CASTRO CORONELL WILLIAM OSPINO ESPINOSA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA EN TELEMÁTICA BOGOTÁ D.C. 2017
Transcript of SISTEMA HEALTH CARE PARA EL MONITOREO DE...
SISTEMA HEALTH CARE PARA EL MONITOREO DE ARRITMIAS CARDÍACAS
EN PERSONAS CON PROBLEMAS CARDÍACOS UTILIZANDO
SERVICIOS WEB.
JOSE JAIME CASTRO CORONELL
WILLIAM OSPINO ESPINOSA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
INGENIERÍA EN TELEMÁTICA
BOGOTÁ D.C.
2017
SISTEMA HEALTH CARE PARA EL MONITOREO DE ARRITMIAS CARDÍACAS
EN PERSONAS CON PROBLEMAS CARDÍACOS UTILIZANDO SERVICIOS
WEB.
JOSE JAIME CASTRO CORONELL
20141678043
WILLIAM OSPINO ESPINOSA
20141678036
Proyecto presentado como requisito para optar al título de
Ingeniero en Telemática
Tutor
MIGUEL ANGEL LEGUIZAMÓN PÁEZ
Ingeniero de Sistemas
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
INGENIERÍA EN TELEMÁTICA
BOGOTÁ D.C.
2017
Nota de Aceptación:
___________________________
___________________________
___________________________
___________________________
___________________________
___________________________
___________________________
Firma del Tutor
___________________________
Firma del Jurado
Bogotá D.C. 10 de agosto de 2017
TABLA DE CONTENIDO
INTRODUCCIÓN
1. FASE DE DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN ......................... 14
1.1 TÍTULO .................................................................................................................................... 14 1.2 TEMA ....................................................................................................................................... 14 1.3 PLANTEAMIENTO DEL PROBLEMA ...................................................................................... 14 1..4 ALCANCES Y DELIMITACIONES .......................................................................................... 15 1.5 OBJETIVOS ............................................................................................................................. 15 1.6 JUSTIFICACIÓN ...................................................................................................................... 16 1.7 ANÁLISIS Y FUNCIONAMIENTO DE UN SISTEMA HEALTH CARE ........................................................ 17 1.8 IMPLEMENTACIÓN DE BLUETOOTH LOW ENERGY (BLE) ............................................................... 19 1.9 MARCO DE REFERENCIA ..................................................................................................... 21 1.9.1.1 PATIENTS LEADING AND MANAGING THEIR HEALTHCARE THROUGH EHEALTH ......................... 21 1.9.1.2 SISTEMA TELEMED .............................................................................................................. 22 1.9.1.3 TELEMEDICINA PARA CUIDADOS EN EL HOGAR: APLICACIÓN PARA PACIENTES CON SIDA ......... 23 1.9.1.4 ONLINE CARDIAC ARRHYTHMIA CLASSIFICATION BY MEANS OF CIRCLE MAPS ANALYSIS
IMPLEMENTED ON AN INTELLIGENT MINIATURIZED SENSOR .................................................................. 24 1.9.1.5 SEGMENTATION BASED ENCRYPTION METHOD FOR MEDICAL IMAGES. ................................... 25 1.9.2.1 TELEMEDICINA ..................................................................................................................... 26 1.9.2.2 ¿QUÉ ES UN WEB SERVICE? ................................................................................................. 29 1.9.2.3 TEORÍA DE LOS SISTEMAS ..................................................................................................... 36 1.9.2.4 SENSORES .......................................................................................................................... 37 1.9.2.5 CIFRADO AES ..................................................................................................................... 38 1.9.2.6 METODOLOGÍA ..................................................................................................................... 39 1.10 FACTIBILIDAD ...................................................................................................................... 47 1.11 CRONOGRAMA .................................................................................................................... 48
2. FASE DE ANÁLISIS ....................................................................................... 49
2.1 PLANEACIÓN PROCESO SCRUM ......................................................................................... 49 2.2 REQUERIMIENTOS CANDIDATOS ....................................................................................... 65 2.3 IDENTIFICACION DE ACTORES ............................................................................................ 66 2.4 LISTA PRELIMINAR DE CASOS DE USO .............................................................................. 66
3. FASE DE DISEÑO .......................................................................................... 75
3.1 DIAGRAMA DE DATOS........................................................................................................... 75 3.2.3.1 DOCUMENTO USUARIO ......................................................................................................... 76 3.2.3.2 DOCUMENTO MEDICIONES .................................................................................................... 77 3.2.3.3 DOCUMENTO ALERTAS ......................................................................................................... 78 3.2.3.4 DOCUMENTO TYCS ............................................................................................................... 78 3.2.3.5 DOCUMENTO CONTACTOS .................................................................................................... 79 3.2 DIAGRAMAS DE PAQUETES ................................................................................................. 79
3.2.1 DIAGRAMA PAQUETE SISTEMA ................................................................................................. 80 3.2.2 DIAGRAMA PAQUETE MOBILE ................................................................................................... 80 3.2.3 DIAGRAMA PAQUETE SHARED .................................................................................................. 81 3.2.4 DIAGRAMA DE PAQUETE WEAR ................................................................................................ 81 3.3 DIAGRAMAS DE CLASES ...................................................................................................... 81
4. FASE DE IMPLEMENTACION ....................................................................... 95
4.1 ARQUITECTURA DEL SISTEMA ............................................................................................ 95 4.2 COMUNICACIÓN ENTRE EL SISTEMA ................................................................................. 96 4.3 BLUETOOH LOW ENERGY(BLE) ........................................................................................... 99 4.4 AES256 EN LA TRANSMISIÓN DE LA INFORMACIÓN ......................................................... 99
5. FASE DE PRUEBAS .................................................................................... 104
5.1 COMPROBACIÓN DE FUNCIONAMIENTO DE LA APLICACIÓN ....................................... 104 5.2 COMPROBACIÓN DE LA BASE DE DATOS ........................................................................ 110
6. CONCLUSIONES .......................................................................................... 111
7. RECOMENDACIONES ................................................................................. 112
8. BIBLIOGRAFIA ............................................................................................. 113
9. DIAGRAMAS DE SECUENCIA Y ACTIVIDAD............................................. 138
9.1 DIAGRAMA DE SECUENCIA MENÚ PRINCIPAL ............................................................................. 138 9.2 DIAGRAMA DE SECUENCIA DE LOGIN ......................................................................................... 139 9.3 DIAGRAMA CONSULTA HISTORIAL ............................................................................................. 139 9.4 DIAGRAMA CERRAR SESIÓN ..................................................................................................... 140 9.5 DIAGRAMA CAMBIAR CONTRASEÑA ........................................................................................... 140 9.6 DIAGRAMA DE ACTIVIDAD REGISTRO .............................................................................. 141 9.7 DIAGRAMA DE ACTIVIDAD LOGIN / LOGOUT ................................................................................ 142 9.8 DIAGRAMA ACTIVIDAD GESTIONAR USUARIO. ............................................................................. 143 9.9 DIAGRAMA DE ACTIVIDAD INICIAR MEDICIÓN .............................................................................. 144 9.10 DIAGRAMA DE ACTIVIDAD GENERAR REPORTE ......................................................................... 145
10. TÉRMINOS DE LICENCIA Y CONDICIONES .............................................. 147
LISTADO DE FIGURAS
Figura 1, Relaciones de Health Care. .......................................................................................................... 17
Figura 2, Esquema Sistema TelMed. ........................................................................................................... 23
Figura 3, Ciclo PHVA. ................................................................................................................................. 40
Figura 4, Lista de tareas de Iteración. ......................................................................................................... 41
Figura 5, Cronograma de Actividades. ........................................................................................................ 48
Figura 6, Caso de uso Registrar usuario. ..................................................................................................... 67
Figura 7, Caso de uso Iniciar Sesión. ........................................................................................................... 68
Figura 8, Caso de uso Cambiar Contraseña. ................................................................................................ 69
Figura 9, Caso de uso Gestionar Usuario. ................................................................................................... 70
Figura 10, Caso de uso Generar Reportes. .................................................................................................. 71
Figura 11, Caso de uso Iniciar Medición. .................................................................................................... 72
Figura 12, Caso de uso Gestionar Contactos. .............................................................................................. 73
Figura 13, Modelo de datos. ....................................................................................................................... 76
Figura 14, Diagrama Sistema. ..................................................................................................................... 80
Figura 15, Diagrama Mobile. ...................................................................................................................... 80
Figura 16, Diagrama Shared. ...................................................................................................................... 81
Figura 17, Diagrama wear. ......................................................................................................................... 81
Figura 18, Diagrama de clases Mobile. ....................................................................................................... 82
Figura 19, Diagrama Útil y Entidades. ......................................................................................................... 83
Figura 20, Services and shared. .................................................................................................................. 83
Figura 21, Diagrama clases Shared. ............................................................................................................ 84
Figura 22, Diagrama clases wear. ............................................................................................................... 84
Figura 23, Diagrama clases global ............................................................................................................... 85
Figura 24 Diagrama clases autenticación .................................................................................................... 85
Figura 25, Diagrama clases de contactos. ................................................................................................... 86
Figura 26, Términos y condiciones. ............................................................................................................ 86
Figura 28, Diagrama de Usuario. ................................................................................................................ 88
Figura 29, Diagrama de alerta. ................................................................................................................... 89
Figura 30, Diagrama Dashboard. ................................................................................................................ 89
Figura 31, Diagrama Dashboard 2. ............................................................................................................. 90
Figura 32, Diagrama Dashboard 3. ............................................................................................................. 91
Figura 33, Diagrama Dashboard 4. ............................................................................................................. 92
Figura 34, Diagrama Dashboard 5. ............................................................................................................. 93
Figura 35, Diagrama Dashboard 6 .............................................................................................................. 93
Figura 36, Diagrama Dashboard 7. ............................................................................................................. 93
Figura 37, Diagrama Arquitectura sistema ................................................................................................. 95
Figura 38, petición get ................................................................................................................................ 97
Figura 39, petición post .............................................................................................................................. 97
Figura 40, petición put ............................................................................................................................... 98
Figura 41, petición delete ........................................................................................................................... 98
Figura 42, permisos necesarios para BLE .................................................................................................... 99
Figura 43, Variables necesarios para cifrar. .............................................................................................. 100
Figura 44, Métodos para cifrar y descifrar ................................................................................................ 100
Figura 45, Inclusión de métodos necesarios para cifrar ............................................................................ 100
Figura 46, ejemplo de cifrado de datos .................................................................................................... 101
Figura 47, resultados de petición con respuesta cifrada ........................................................................... 101
Figura 48, variables necesarias para descifrar mensajes en android ......................................................... 102
Figura 49, método para descifrar mensajes en android ............................................................................ 102
Figura 50, mensaje descifrado en android ................................................................................................ 102
Figura 51, splash ...................................................................................................................................... 118
Figura 52, formulario login ....................................................................................................................... 119
Figura 53, formulario registrarse .............................................................................................................. 120
Figura 54, formulario registrarse 2 ........................................................................................................... 121
Figura 55, menú principal ......................................................................................................................... 122
Figura 56, módulo medición ..................................................................................................................... 123
Figura 57, módulo medición resultado ..................................................................................................... 124
Figura 58, módulo histórico mediciones ................................................................................................... 125
Figura 59, módulo histórico alertas .......................................................................................................... 126
Figura 60, módulo contactos .................................................................................................................... 127
Figura 61, formulario agregar contacto .................................................................................................... 128
Figura 62, formulario agregar contacto 2 ................................................................................................. 129
Figura 63, listado de contactos ................................................................................................................. 130
Figura 64, eliminar contacto ..................................................................................................................... 131
Figura 65, listado de contactos después de eliminar contacto .................................................................. 132
Figura 66, excepciones formulario login ................................................................................................... 133
Figura 67, excepciones formulario login 2 ................................................................................................ 133
Figura 68, excepciones formulario login 3 ................................................................................................ 134
Figura 69, excepciones formulario registrarse .......................................................................................... 135
Figura 70, excepciones formulario agregar contacto ................................................................................ 136
Figura 71, Diagrama de Secuencia Menú Principal. .................................................................................. 138
Figura 72, Diagrama de secuencia Login. .................................................................................................. 139
Figura 73, Diagrama de secuencia Consultar Historial. ............................................................................. 139
Figura 74, Diagrama de secuencia Cerrar sesión. ...................................................................................... 140
Figura 75, Diagrama de secuencia Cambiar contraseña. ........................................................................... 140
Figura 76, Diagrama de actividad Registro. .............................................................................................. 141
Figura 77, Diagrama de actividad Login / logout. ..................................................................................... 142
Figura 78, Diagrama Gestionar Usuario. ................................................................................................... 143
Figura 79, Diagrama de secuencia Iniciar Medición. ................................................................................. 144
Figura 80, diagrama de actividad Generar reporte. .................................................................................. 145
LISTA DE TABLAS
Tabla 1, Factibilidad económica. ................................................................................................................ 47
Tabla 2, Registro de usuario. ...................................................................................................................... 50
Tabla 3, Registro de Administrador. ........................................................................................................... 50
Tabla 4, Acceso usuario. ............................................................................................................................. 51
Tabla 5, Acceso Administrador. .................................................................................................................. 51
Tabla 6, Administración de usuarios........................................................................................................... 52
Tabla 7, Realizar medición. ........................................................................................................................ 52
Tabla 8, Medición por defecto. .................................................................................................................. 53
Tabla 9, Ubicación. ..................................................................................................................................... 53
Tabla 10, Envío de notificaciones. .............................................................................................................. 54
Tabla 11, Ver Estadísticas. .......................................................................................................................... 54
Tabla 12, Notificaciones offline. ................................................................................................................. 55
Tabla 13, Envío de información a la base de datos. .................................................................................... 56
Tabla 14, Cambiar contraseña. ................................................................................................................... 56
Tabla 15, Cerrar Sesión . ............................................................................................................................. 57
Tabla 16, Objetivos de producto, Scrum backlog ........................................................................................ 58
Tabla 17, lista total de objetivos, Scrum backlog ....................................................................................... 61
Tabla 18, Requerimientos Candidatos. ...................................................................................................... 65
Tabla 19, Caso De Uso: Registrar Usuario en el Sistema. ............................................................................ 67
Tabla 20, Caso de Uso: Cambiar Contraseña............................................................................................... 68
Tabla 21, Caso de uso: Iniciar Sesión. ........................................................................................................ 69
Tabla 22, Caso de uso: Gestionar Usuario. ................................................................................................. 70
Tabla 24, Caso de uso: Generar Reportes. ................................................................................................. 71
Tabla 25, Caso de uso: Iniciar Medición. .................................................................................................... 72
Tabla 26, Caso de uso: Gestionar contactos. .............................................................................................. 73
Tabla 27, Diccionario de datos Documentos de usuario. ........................................................................... 76
Tabla 28, Documento mediciones. ............................................................................................................. 77
Tabla 29, Documento alertas. .................................................................................................................... 78
Tabla 30, Documento tycs. ........................................................................................................................ 78
Tabla 31, Documento Contactos. ............................................................................................................... 79
Tabla 32, historias de usuario, registro de usuario. .................................................................................. 104
Tabla 33, Historias de usuario, registro de Administrador. ....................................................................... 105
Tabla 34, Historias de usuario, Acceso de usuario/Administrador ............................................................ 105
Tabla 35, Tareas de usuario, administración de usuarios......................................................................... 105
Tabla 36, Historias de usuario, realizar medición. .................................................................................... 106
Tabla 37, Historias de usuario, Medición por defecto. ............................................................................. 106
Tabla 38, Historias de usuario, ubicación ................................................................................................ 106
Tabla 39, Historias de usuario, Envío de notificación. .............................................................................. 106
Tabla 40, Historias de usuario, Ver estadísticas. ...................................................................................... 106
Tabla 41, Historias de usuario, Notificaciones offline. ............................................................................. 107
Tabla 42, Historias de usuario, Cifrado de la información. ....................................................................... 107
Tabla 43, Historias de usuario, Guardado de información ....................................................................... 108
Tabla 44, Historias de usuario, Cambiar contraseña ................................................................................ 108
Tabla 45, Historias de usuario, cerrar sesión ........................................................................................... 108
Tabla 46, Comprobación de funcionamiento de la aplicación. .................................................................. 109
ANEXOS
Anexo A: Manual de Usuario
Anexo B: Diagramas de secuencias, actividad
Anexo C: Términos y condiciones
RESUMEN
EL SISTEMA HEALTH CARE PARA EL MONITOREO DE ARRITMIAS
CARDÍACAS EN PERSONAS CON PROBLEMAS CARDÍACOS UTILIZANDO
SERVICIOS WEB, se ha desarrollado como una herramienta de Health Care que
permite realizar un monitoreo de arritmias cardiacas, generando alertas con
geolocalización (Mensaje de texto, correo), que contiene datos de la medición y
ubicación del usuario, que además realiza registro en la base de datos remota,
cifrando la comunicación.
El sistema, ha sido desarrollado para hacer monitoreo de arritmias cardiacas,
usando tecnologías de comunicación y lenguajes de programación, con la finalidad
de brindarle un control adicional al usuario (y quien este designe), de su ritmo
cardiaco, y ubicación en caso de presentarse anomalías, con posibilidad de consulta
y administración vía web.
El sistema, se construyó, haciendo uso de varias tecnologías de comunicación
combinadas como bluetooth, internet, GPS, y lenguajes de programación Android,
JavaScript, html y bases de datos. El sistema consta de 3 partes, consta de una
aplicación para wearables (smart watchs Android), una aplicación para teléfonos
inteligentes Android versión 4.4 o superiores, y un servicio web, encargado de recibir
la información cifrada y almacenarla en la base de datos Mongo DB.
Adicionalmente, se ha desarrollado una herramienta web de administración y
consulta, que permite ver estadísticas y mediciones de arritmias de los diferentes
usuarios.
ABSTRACT
The project HEALTH CARE SYSTEM IS FOR THE MONITORING OF CARDIAC
ARRHYTHMIA IN PEOPLE WITH HEART PROBLEMS USING WEB SERVICES,
has the purpose of developing a system that allows monitoring and detecting the
arrhythmias in people with heart problems, allowing a control of the heart rate of the
Person, to alert when they may be close to having an arrhythmia and in case it
happens, inform the defined contacts, that the person is having an arrhythmia in real
time, to perform the actions necessary to avoid possible complications.
The system has been developed to monitor cardiac arrhythmias, using
communication technologies and programming language, to provide additional
control to the user (and whoever he designates), their heart rate and location in case
of anomalies can be presented, with the possibility of consultation and administration
in the web.
The system was built using may communication technologies, such as bluetooh,
internet, GPS and programming languages like android, javascript, html, and
databases. The system includes 3 modules, an application for wearables (android
smart watches), an android application for smart phones version 4.4 or higher, an
API that makes possible all the communication in the system to send and receive
data encrypted and stored in mongoDB.
In addition, a web-based administration and consultation tool has developed, which
allows the user to view statistics and measurements of arrhythmias.
INTRODUCCIÓN
El presente proyecto comprende el funcionamiento del sistema Health Care para
monitoreo de arritmias cardiacas y la obtención de la información a partir de
dispositivos smartwatch y smartband.
El monitoreo de arritmias cardiacas es importante para personas con este tipo de
padecimientos, pues contribuye a un control constante, que sirve de apoyo al
diagnóstico médico, este sistema, adicionalmente, tiene un sistema de envío de
alertas en caso de presentarse cambios anormales en el ritmo cardiaco, éstos
describen la ubicación aproximada donde se encuentra la persona a sus familiares
o personal médico.
Este sistema por medio del uso de Smartphones Android y de tecnologías bluetooth
de bajo consumo (BLE), permite sincronizar los datos medidos por el smartwatch y
enviar la información a la aplicación móvil para su análisis, lo que permitirá
determinar tres estados de la frecuencia cardiaca: Normal, Bajo, Elevado.
Lo anterior permite determinar en envío de alertas a quienes el usuario del sistema
haya inscrito para recibir las notificaciones.
Esta información obtenida de los dispositivos de medición es enviada de forma
segura (Cifrada), al servicio web para ser almacenada y acceder a históricos que
puedan ser consultados posteriormente vía web o mediante la misma aplicación
móvil.
1. FASE DE DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN
1.1 TÍTULO
SISTEMA HEALTH CARE PARA EL MONITOREO DE ARRITMIAS CARDIACAS
EN PACIENTES CON PROBLEMAS CARDIACOS UTILIZANDO SERVICIOS
WEB.
1.2 TEMA
Telemática como apoyo a procesos médicos.
1.3 PLANTEAMIENTO DEL PROBLEMA
1.3.1 Descripción del problema
En la actualidad las personas con problemas cardiacos cuentan con pocas
herramientas que les ayuden a tener un monitoreo y control preventivo y constante
de sus afecciones, más aún en personas de la tercera edad, que pueden tener una
complicación en cualquier momento, sin tener la posibilidad de informar de esto a
los servicios de urgencias o a sus familiares.
Algunas personas padecen arritmias y problemas cardiacos en la calle, en el
transporte público o centros comerciales, sin tener la posibilidad de que puedan ser
auxiliadas de manera rápida y eficaz.
Esto puede conllevar a que el tiempo de atención para auxiliar a una persona sea
muy grande y pueda causarle complicaciones, donde su condición se agrave.
1.3.2 Formulación del problema
¿De qué manera monitorear, evaluar, controlar e informar las complicaciones que
puedan tener personas con arritmias cardiacas?
1..4 ALCANCES Y DELIMITACIONES
1.4.1 Alcances
Dentro del alcance del sistema tendrá una aplicación móvil y web, que contará con
las siguientes funcionalidades:
Registro, captura de datos, reportes, alertas.
1.4.2 Delimitaciones
El sistema está limitado a que el paciente acepte los términos y condiciones, la
aplicación móvil solo está disponible para dispositivos Android con API 19 o
superiores compatibles con tecnología bluetooth de bajo consumo (BLE), el
monitoreo de la frecuencia cardiaca se hará cada 30 segundos, La plataforma web,
estará disponible para navegadores Chrome superiores a la versión 38.
1.5 OBJETIVOS
1.5.1 Objetivo General
Crear un sistema Health Care mediante servicios web para el monitoreo de las
arritmias cardiacas en personas con problemas cardiacos
1.5.2 Objetivos específicos
1. Analizar el funcionamiento de un sistema Health Care para definir las
mejores prácticas a implementar en el monitoreo y control de arritmias
cardiacas.
2. Diseñar un sistema Health Care para el monitoreo y control de arritmias
cardiacas.
3. Implementar y verificar el sistema para el monitoreo y control de arritmias
cardiacas en el sistema Health Care con el uso de servicios web.
4. Implementar bluetooth de bajo consumo (BLE) para captura de datos a
través de sensores que midan la frecuencia cardiaca.
5. Implementar cifrado AES-256 en la trasmisión de la información,
manipulada por los servicios web.
1.6 JUSTIFICACIÓN
Esta solución tecnológica, realizara un seguimiento de forma continua de la
frecuencia cardiaca y la ubicación del paciente durante todo el día.
La información se obtendrá del sensor que realiza las mediciones de la frecuencia
cardiaca(smartwatch, smartband) por medio de la tecnología bluetooth de poco
consumo (BLE) que permite la comunicación constante entre el dispositivo de
medición y el teléfono móvil que a su vez generará estadísticas y envía datos a una
central de información que puede ser accedida por familiares, amigos, médicos u
otras personas que el paciente especifique, estas personas, recibirán un mensaje
de texto y una notificación vía electrónica si el sensor registra una medición anormal,
lo que permitirá que sus familiares podrán contactarle y saber la ubicación precisa
de donde se ubica el paciente.
• El uso del sistema permitirá que el paciente pueda acceder en caso de
emergencia a ayuda por parte de sus familiares o personal médico, tendrá
la opción de que el paciente se comunique con los servicios de
emergencias médicas en caso de que lo necesite.
• Este sistema, también puede servir como un apoyo para el diagnóstico de
posibles cardiopatías, usando el sensor, es posible determinar si las
alteraciones en sus signos vitales son producidas por una posible falla o
si son producto del ejercicio físico.
• Este sistema puede ayudar al personal médico a llevar un histórico de las
variaciones de los signos vitales durante el día y ayudar a diagnosticar un
mejor tratamiento.
1.7 Análisis y funcionamiento de un sistema Health Care
Los hospitales, clínicas y agencias de salud de la comunidad pueden ser muy
diferentes de otros entornos de trabajo. Los sistemas de atención médica son
complejos y hay muchas cosas que se necesita conocer sobre los tipos de sistemas
hospitalarios, cuidado de pacientes, seguros, proveedores de atención médica y
asuntos legales. 1
Figura 1, Relaciones de Health Care.
Un sistema Health Care Combina esfuerzos para mantener o restaurar el bienestar
físico, mental o emocional, por medio del tratamiento y la prevención de
enfermedades, Los sistemas Health Care pueden estar apoyados con tecnologías
Cloud que facilitan la transmisión y obtención de la información.
Un sistema Health Care impulsa el valor en la asistencia sanitaria al permitir una
interacción rápida, fácil y sin fisuras en los datos y conocimientos, que mediante la
interconexión de datos y la innovación digital.
1.7.1 El código abierto contribuye a mejorar el sector de la salud
1. Patient navigator training Collaborative. Introduction to healtcare system, [En
linea].<http://www.patientnavigatortraining.org/healthcare_system/>[Citado en 13 de Mayo de 2017]
Según una encuesta de Gatepoint Research realizada en 2012, muchos directivos
del sector de la salud creen que los sistemas propietarios están repercutiendo
negativamente en los departamentos de TI, lo que dificulta centrar la atención en
las prioridades de la salud. A diferencia de las soluciones propietarias, el software
de código abierto surge de la colaboración de cientos de miles de desarrolladores,
incluidos los propios usuarios del sector de la salud que utilizan y mejoran el
software para satisfacer sus necesidades.
El modelo de desarrollo de código abierto ofrece un enfoque rápido, eficiente y muy
innovador para la creación de software que se adapte adecuadamente a las
demandas fundamentales del sector de la salud en términos de TI.
En el ámbito de la salud es fundamental poder acceder a la información en cualquier
momento. Red Hat Gluster Storage proporciona un entorno virtual para almacenar
datos estructurados y no estructurados. Le permite gestionar de forma eficaz los
cada vez mayores requisitos implícitos a los datos médicos, además de controlar el
aumento y el coste de los nuevos datos que se van generando a diario.2
Una nube de atención de la salud es un servicio de computación en nube utilizado
por los proveedores de atención médica para almacenar, mantener y respaldar la
información de salud personal.
Los servicios en la nube de la atención de la salud son capaces de almacenar
significativamente más datos que un servidor físico en el sitio, particularmente
cuando se trata de los archivos de imagen grandes comunes en los departamentos
de radiología. Además, los costos de almacenamiento en la nube de atención
médica son una fracción de los de los servidores en el sitio; Sin embargo, la
transición requiere una implementación completa de virtualización de servidores.
2. Ret Hat. Sector de la salud y ciencias de la vida, Conozca de primera mano los nuevos desafíos asociados al
sector de la salud. [En línea]. <https://www.redhat.com/es/technologies/industries/health-life-sciences >[Citado en 13 de Mayo de 2017]
Muchos médicos y organizaciones de cuidado de la salud son reacios a usar los
servicios de la nube de atención médica por temor a sufrir una violación de datos en
violación de la Ley de Responsabilidad y Portabilidad del Seguro Médico.
Debido a la naturaleza sensible de los datos que se almacenan y se accede, muchas
organizaciones de atención médica están optando por evitar los servicios de nube
pública y la implementación de un servicio de nube privada en su lugar.
1.8 Implementación de Bluetooth Low Energy (BLE)
Desde Android 4.3 (API Level 18), se incorpora la compatibilidad integrada para
bluetooth de baja energía en la función central que proporcionan un API para que
las aplicaciones puedan utilizar y descubrir dispositivos, hacer consulta a servicio y
transmitir información.
El caso más común en el uso de bluetooth de bajo consumo es la transferencia de
pequeñas cantidades de información entre dispositivos cercanos.3
En comparación con los dispositivos de bluetooth comunes, estos están diseñados
para proporcionar un consumo de energía significativamente menor lo que permite
a las aplicaciones Android, se puedan comunicar con dispositivos como sensores
de proximidad, monitores de frecuencia cardiaca, y dispositivos de
acondicionamiento físico.
1.8.1 Funciones y responsabilidades
Estos son los roles y responsabilidades que se aplican cuando un dispositivo
Android interactúa con un dispositivo BLE:
3. Android Developers. Bluetooth Low Energy (Bluetooth de bajo consumo). [En línea].
<https://developer.android.com/guide/topics/connectivity/bluetooth-le.html> [Citado en 16 de Mayo de 2017]
Central y periférica, esto se aplica a la conexión BLE misma. El dispositivo en el
papel central escanea, busca que dispositivos están disponibles, y el dispositivo en
el papel periférico hace el anuncio es decir publica que está disponible.
Para entender la distinción, se debe imaginar que se tiene un teléfono Android y un
rastreador de actividades que es un dispositivo BLE. El teléfono hace el papel
central y el rastreador de actividad, seria periférico, para poder establecer la
comunicación, se requiere que los dos dispositivos tengan el soporte de tecnología
BLE, de lo contrario no es posible hacer la comunicación adecuadamente.
Una vez que el teléfono y el rastreador de actividad han establecido una conexión,
comienzan a transferir metadatos GATT entre sí. Dependiendo del tipo de datos que
transfieren, uno u otro puede actuar como servidor. Por ejemplo, si el rastreador de
actividad desea informar datos del sensor al teléfono, podría tener sentido que el
rastreador de actividad actúe como servidor. Si el rastreador de actividades desea
recibir actualizaciones desde el teléfono, entonces podría tener sentido que el
teléfono actúe como servidor.
En el ejemplo utilizado en este documento, la aplicación de Android (que se ejecuta
en un dispositivo Android) es el cliente GATT. La aplicación obtiene datos del
servidor GATT, que es un monitor de frecuencia cardíaca BLE que admite el perfil
de frecuencia cardíaca . Pero, alternativamente, puede diseñar su aplicación de
Android para que desempeñe el rol de servidor
GATT. Consulte BluetoothGattServer para obtener más información en los
manuales de desarrollador de Android en línea. 4
4. Android Developers. Bluetooth Low Energy, Roles and Responsibilities (Roles y responsabilidades). [En línea].
<https://developer.android.com/guide/topics/connectivity/bluetooth-le.html> [Citado en 16 de Mayo de 2017]
1.9 MARCO DE REFERENCIA
1.9.1 Marco Histórico
A través del tiempo se han desarrollado algunas soluciones tecnológicas que
buscan ayudar a las personas en el cuidado de su salud a continuación se
mencionan algunas y los aportes a este proyecto.
1.9.1.1 Patients Leading and Managing Their Healthcare Through Ehealth
Descripción del proyecto
El empoderamiento de los pacientes a través de la telemedicina se considera una
potencial herramienta para reducir los costes sanitarios y mejorar la eficiencia de
los sistemas de salud, reforzando la calidad asistencial, por ello, se ha convertido
en un elemento de alta prioridad en la estrategia sanitaria de la UE.
El proyecto PALANTE se centra en la aplicación, la ampliación y optimización de
7pilotos basados en el concepto de acceso seguro y fácil de los ciudadanos a sus
datos médicos / de salud. El objetivo principal de esta propuesta es capacitar a los
pacientes para que sean capaces de tomar decisiones sobre su salud, de forma que
tome un papel activo en su cuidado y colabore eficazmente con el equipo sanitario
gracias al uso de tecnologías de la información y la comunicación.
Todos los pilotos abordan la cuestión del acceso seguro del paciente a su propia
información médica, además, cinco de estos pilotos abordan innovadoras
soluciones de telemedicina para el control de enfermedades crónicas, incluidos los
sistemas integrales de formación para la autogestión y el seguimiento de su
enfermedad que será validado para la diabetes, hipertensión arterial, insuficiencia
cardiaca crónica, artritis severa y enfermedades respiratorias.
El proyecto también tiene en cuenta el reto de la movilidad de los pacientes al
abordar la interoperabilidad entre los pilotos. Algunos socios del consorcio
PALANTE están directamente involucrados en el proyecto epSOS. 5
Este proyecto evidencia la importancia de las personas a la hora de utilizar el
sistema para tomar decisiones en el cuidado de su propia salud ayudándose de su
historial clínico.
1.9.1.2 Sistema TeleMed
TeleMed- Sistema telemático para el apoyo en el tratamiento intensivo de insulina
en los nuevos pacientes diagnosticados con diabetes tipo 1- Primera aplicación
clínica
La arquitectura del sistema desarrollado consta de: una unidad móvil de paciente
(PMU), la unidad móvil de diabetologos, la clínica de diabetologos y una estación
de trabajo en casa, también el servidor de la clínica central. 6
5. Indra. Proyectos de Innovación, PALANTE - PAtients Leading and mANaging their healThcare through EHealth. [En
línea]< http://www.indracompany.com/es/indra/palante-patients-leading-managing-healthcare-ehealth> [Citado en
1 de Junio de 2017]
6. IEEE. TeleMed - the Telematic System Supporting Intensive Insulin Treatment of the Newly Diagnosed Type 1
Diabetic Patients. First Clinical Application. [En Linea]. <
http://ieeexplore.ieee.org.bdigital.udistrital.edu.co:8080/stamp/stamp.jsp?tp=&arnumber=1280948 > [Citado en 10
de Julio de 2017]
Figura 2, Esquema Sistema TelMed.
Este proyecto evidencia una arquitectura que puede ser aplicada para el desarrollo
del proyecto, donde puede verse que hay trasmisión de información a trav1és de
varios dispositivos.
1.9.1.3 Telemedicina para cuidados en el hogar: Aplicación para pacientes
con SIDA
En los países desarrollados el sistema de salud es cambiante contantemente y tanto
hospitales como médicos de familia deben adaptarse a esta condición.
Por ello debe presentarse una mejor atención en el hogar, para esto deben tener en
cuenta dos funciones complementarias, el acceso a el historial clínico y a la
información complementaria de los tratamientos médicos en cualquier momento y
desde cualquier lugar.
Los médicos familiares de los pacientes con SIDA pueden solicitar la información a
través de la red creada en este proyecto de dos maneras, tele-experiencia remota,
si hay un especialista disponible o correos electrónicos.7
Este proyecto se observa la posibilidad de compartir información de un paciente
usando correo electrónico, por lo que puede ser de utilidad para el proyecto a
desarrollarse a la hora de enviar alertas o consultar información de la persona.
1.9.1.4 Online cardiac arrhythmia classification by means of circle maps
analysis implemented on an intelligent miniaturized sensor
El análisis de los osciladores y su sincronización mutua es un problema fundamental
en la fisiología. La concentración en la dinámica de fase da lugar a métodos
sensibles y robustos al mismo tiempo, para detectar y caracterizar fenómenos de
sincronización. En las personas sanas la variación a corto plazo del ritmo cardiaco
está dominado por la llamada arritmia sinusal respiratoria, el corazón se acelera y
desacelera durante la durante la respiración. Esta modulación respiratoria causa
arritmias como, por ejemplo, fibrilación auricular. Esta modulación puede ser
detectada sin que se presente la fibrilación auricular y por lo tanto puede ayudar a
resolver las dificultades de diagnóstico causados por la mayoría de estos
problemas.
En este proyecto se diseñó un sensor miniatura autónomo (i-nodo, red inteligente
dispositivo de operación) que incluye un microcontrolador MSP430, con dispositivos
periféricos internos y externos para el procesamiento digital de señales. Un
7. IEEE EXPLORE. TELEMEDICINE FOR HOMECARE: APPLICATIONS FOR AIDS PATIENTS, [En Linea] <
http://ieeexplore.ieee.org.bdigital.udistrital.edu.co:8080/stamp/stamp.jsp?tp=&arnumber=757818 > [Citado en 10
de Julio de 2017]
amplificador de ultra baja potencia ECG y un acelerómetro de 3-D en tecnología
MEMS sirven como terminal de la parte frontal del sensor. Con sólo 20 mm por eje
de cada entidad funcional y las capas flexibles entre ellos este sistema ofrece una
comodidad de uso casi imperceptible. Esto con el fin de medir la aceleración y
desaceleración del corazón para prevenir problema de arritmias.8
En este proyecto se puede evidenciar el uso de sensores para la lectura de las
arritmias cardiacas, lo cual es punto vital para el proyecto.
1.9.1.5 Segmentation Based Encryption Method for Medical Images.
La transferencia de los datos médicos tales como los resultados radiológicos de un
centro de datos médicos a otro, o a un radiólogo remoto sin aplicar técnicas de
seguridad significa un bajo nivel de privacidad para los pacientes. La necesidad de
aplicar técnicas de seguridad para imágenes médicas ha aumentado con el uso de
tecnologías de telecomunicaciones para el diagnóstico médico y la atención al
paciente cuando el proveedor y el cliente están separados por la distancia, en un
sistema conocido como la telemedicina.
La telemedicina es importante porque permite a las consultas de los especialistas
remotos de comunicación, sin pérdidas y la disponibilidad inmediata de la
información individual del paciente. Esto conduce a una mejora en la calidad de la
atención médica, y simplifica el acceso a bases de datos médicas, de las cuales las
imágenes médicas se pueden transmitir a través de un canal de destino en particular
8. IEEE Explore. Online cardiac arrhythmia classification by means of circle maps analysis implemented on an
intelligent mitiaturized sensor. [En Linea]
<http://ieeexplore.ieee.org.bdigital.udistrital.edu.co:8080/stamp/stamp.jsp?tp=&arnumber=4649485 > [Citado en
10 de Julio de 2017]
y luego se da al especialista. El método de cifrado AES es propuesto por muchos
investigadores para asegurar los datos médicos transmitido.
En este proyecto se utiliza AES como, algoritmo de cifrado para asegurar la
información que viaja entre diferentes medios, de valor importante para el proyecto
ya que se puede implementar en las transferencias de esté.9
1.9.2 Marco Teórico
El marco teórico, de este proyecto, está encaminado a conceptos de telemedicina,
aplicaciones, uso en Colombia, una breve introducción a los servicios web, tipos de
servicio, sensores y cifrados utilizados para la protección de la transmisión de la
información.
1.9.2.1 Telemedicina
El campo que ha logrado importantes descubrimientos ha sido el de la salud, de
esta manera con la aplicación de procedimientos y metodologías prácticas se habla
de un nuevo concepto que en definitiva está revolucionando la forma de llevar la
medicina: e-salud o telemedicina.
En términos generales, se define como el uso de las Tecnologías de la Información
y las Comunicaciones en la medicina, a través de la distancia. En ese sentido, un
profesional de la salud puede realizar diagnósticos, consultas e incluso cirugías en
áreas de difícil acceso o remotas, utilizando las TIC para el mejoramiento de la
calidad de vida de los pacientes.
9. IEEE Conference Publication, Segmentation based encryption method for medical images. [En línea]. <
http://ieeexplore.ieee.org/abstract/document/6148405/?reload=true > [Citado en 1 de junio de 2017]
Cabe destacar, que con esta nueva modalidad además de facilitar y optimizar los
servicios médicos, también se ahorran tiempos, desplazamientos, se reducen
costos en los equipos y de la efectividad de la aplicación del diagnóstico es posible
que a los pacientes se les detecten más temprano las causas probables de cualquier
enfermedad, ya que en este es más eficiente aplicar la telemedicina pues, permite
decidir de inmediato la conducta a seguir.
Una de las grandes ventajas de la medicina a distancia es que aquellos países o
ciudades que carecen de especialistas en áreas a fines pueden tratar casos
complejos y valorarlos de acuerdo con la condición de los pacientes, sin que estos
deban desplazarse hasta la clínica u hospital.10
La telemedicina es aplicable como:
• Realización de diagnósticos inmediatos.
• Atención complementaria de un especialista.
• Estudiantes de medicina pueden adelantar sus estudios a través de la
modalidad e-learning.
• Servicios de archivo digital de exámenes cardiológicos, respiratorios,
radiológicos, ecografías y otros.
Aunque en Colombia el tema apenas empieza a perfilarse y todavía no se conocen
importantes avances en el área, de momento existen algunos centros médicos que
la aplican, entre ellos:
• SaludCoop
• Centro de Telemedicina de la Universidad Nacional
• Centro de Telemedicina de Colombia
10. Colombia Digital. Telemedicina: ¿qué es y cómo funciona? [En línea]. <
https://colombiadigital.net/actualidad/articulos-informativos/item/4384-telemedicina-que-es-y-como-fuciona.html >
[Citado en 10 de Julio de 2017]
De otro lado, con base en un estudio realizado por Cisco3 casi el 85% de las
consultas médicas no necesitan de una interacción física entre médico y paciente,
de ahí que la Telemedicina entre en terreno de juego, generando beneficios como:
Además de evitar el transporte hacia lugares de difícil acceso, se logra un
cubrimiento de los sistemas de salud más amplio.
Se les brinda una mejor y más óptima atención a los pacientes crónicos o con
enfermedades de alta complejidad.
A través de los sitios web es posible encontrar información relevante y oportuna,
mediante software especializados en gestión administrativa, para los médicos,
enfermeros, y personal administrativo.
Son evidentes las ventajas que proporciona la Telemedicina en el campo de la
salud. No solo facilita el trabajo de los especialistas, sino que también se convierte
en una alternativa para los pacientes. En ese sentido, aquellos centros que
funcionan bajo esta modalidad o prestan dicho servicio deben contar con una serie
de características específicas: 11
• Acceso a Internet, a comunicación satelital.
• Empleo de videoconferencias.
• Estándares y protocolos de interoperabilidad de información (HL7 y DICOM).
• El hospital o clínica de apoyo que debe gestionar los recursos necesarios
(infraestructura, tiempo y especialmente especialistas) para prestar los
servicios médicos.
11. Colombia Digital. Telemedicina: ¿qué es y cómo funciona? [En línea]. <
https://colombiadigital.net/actualidad/articulos-informativos/item/4384-telemedicina-que-es-y-como-fuciona/4384-
telemedicina-que-es-y-como-fuciona.amp.html > [Citado en 10 de junio de 2017]
El funcionamiento de los computadores es simple: un conjunto de circuitos
electrónicos interconectados con interruptores que cierran o abren el paso de
electricidad. Su paso se representa con el número 1, y su no paso con el número 0.
El lenguaje interno de los computadores se denomina lenguaje máquina y su menor
unidad de almacenamiento es el bit, cuyo valor puede ser 0 o 1, de donde se deriva
el nombre de código binario.
Recientemente ha aparecido la computación cuántica que permite ampliar el código
convencional de unos y ceros a un código prácticamente infinito que comprende
además de unos y ceros las posibilidades incluidas entre ellos.
Los lenguajes de computación se derivan del inglés, son sencillos, lógicos y se
aprenden intuitivamente. Su aprendizaje es más simple que el de un idioma
extranjero. La tarea más difícil es la parte creativa, o sea escribir el algoritmo; pero
para ello no se requieren lenguajes de computador. Lo demás es simple traducción.
No es necesario ser ingeniero de sistemas para escribir un programa de obstetricia,
periodos sí es indispensable conocer al máximo las funciones obstétricas que
ejecutará el programa.
La Telemedicina expande el cuidado de salud gracias a las telecomunicaciones, y
hace dicho cuidado de mejor calidad y precisión gracias a la automatización de
procesos mediante algoritmos aplicados a cada tarea.
1.9.2.2 ¿Qué es un web service?
Es un conjunto de protocolos y estándares que sirven para intercambiar datos entre
aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de
programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar
los servicios web para intercambiar datos en redes de ordenadores como Internet.
La interoperabilidad se consigue mediante la adopción de estándares abiertos.
Las organizaciones OASIS y W3C son los comités responsables de la arquitectura
y reglamentación de los servicios Web. Para mejorar la interoperabilidad entre
distintas implementaciones de servicios Web se ha creado el organismo WS-I,
encargado de desarrollar diversos perfiles para definir de manera más exhaustiva
estos estándares.12
Los estándares empleados son:
• Web Services Protocol Stack: Así se denomina al conjunto de servicios y
protocolos de los servicios Web.
• XML (Extensible Markup Language): Es el formato estándar para los datos
que se vayan a intercambiar.
• SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Procedure
Call): Protocolos sobre los que se establece el intercambio.
• Otros protocolos: los datos en XML también pueden enviarse de una
aplicación a otra mediante protocolos normales como HTTP (Hypertext
Transfer Protocol), FTP (File Transfer Protocol), o SMTP (Simple Mail
Transfer Protocol).
• WSDL (Web Services Description Language): Es el lenguaje de la interfaz
pública para los servicios Web. Es una descripción basada en XML de los
requisitos funcionales necesarios para establecer una comunicación con los
servicios Web.
• UDDI (Universal Description, Discovery and Integration): Protocolo para
publicar la información de los servicios Web. Permite comprobar qué
servicios web están disponibles.
• WS-Security (Web Service Security): Protocolo de seguridad aceptado como
estándar por OASIS (Organization for the Advancement of Structured
12. Culturización. ¿Qué es y para qué sirve un web service? [En línea]. < http://culturacion.com/que-es-y-para-que-
sirve-un-web-service/ > [Citado en 10 de junio de 2017]
Information Standards). Garantiza la autenticación de los actores y la
confidencialidad de los mensajes enviados.13
Algunas ventajas de los servicios web son:
• Aportan interoperabilidad entre aplicaciones de software
independientemente de sus propiedades o de las plataformas sobre las que
se instalen.
• Los servicios Web fomentan los estándares y protocolos basados en texto,
que hacen más fácil acceder a su contenido y entender su funcionamiento.
• Al apoyarse en HTTP, los servicios Web pueden aprovecharse de los
sistemas de seguridad firewall sin necesidad de cambiar las reglas de filtrado.
• Permiten que servicios y software de diferentes compañías ubicadas en
diferentes lugares geográficos puedan ser combinados fácilmente para
proveer servicios integrados.
• Permiten la interoperabilidad entre plataformas de distintos fabricantes por
medio de protocolos estándar y abiertos. Las especificaciones son
gestionadas por una organización abierta, la W3C, por tanto, no hay
secretismos por intereses particulares de fabricantes concretos y se
garantiza la plena interoperabilidad entre aplicaciones.14
Algunas desventajas de los servicios web son:
• Para realizar transacciones no pueden compararse en su grado de desarrollo
con los estándares abiertos de computación distribuida como CORBA
(Common Object Request Broker Architecture).
• Su rendimiento es bajo si se compara con otros modelos de computación
distribuida, tales como RMI (Remote Method Invocation), CORBA o DCOM
13. Clarenc, Claudio Ariel, Nociones de cibercultura y periodismo, lulu.com, 2011, P. 497.
14. Clarenc, Claudio Ariel, Nociones de cibercultura y periodismo, lulu.com, 2011, P. 498.
(Distributed Component Object Model). Es uno de los inconvenientes
derivados de adoptar un formato basado en texto. Y es que entre los objetivos
de XML no se encuentra la concisión ni la eficacia de procesamiento.
• Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en
firewall cuyas reglas tratan de bloquear o auditar la comunicación entre
programas a ambos lados de la barrera.
Los elementos de los Web Services son:
Para conocer cómo se realiza el intercambio de mensajes en los Web Services se
debe saber cuáles son los elementos fundamentales que lo componen. Estos son
el XML, SOAP, WSDL, y UDDI.
REST
Cada día se necesitan más usar servicios web REST. Estos servicios se diferencian
de una forma importante de los servicios web SOAP.
REST (Representational State Transfer) es un estilo de arquitectura para desarrollar
servicios. Los servicios web que siguen este estilo deben cumplir con las siguientes
premisas.
• Cliente/Servidor: Como servicios web son cliente servidor y definen una
interface de comunicación entre ambos separando completamente las
responsabilidades entre ambas partes.
• Sin estado: Son servicios web que no mantienen estado asociado al cliente.
Cada petición que se realiza a ellos es completamente independiente de la
siguiente. Todas las llamadas al mismo servicio serán idénticas.
• Cache: El contenido de los servicios web REST ha se puede cachear de tal
forma que una vez realizada la primera petición al servicio el resto puedan
apoyarse en la cache si fuera necesario.
• Servicios Uniformes: Todos los servicios REST compartirán una forma de
invocación y métodos uniforme utilizando los métodos GET, POST, PUT,
DELETE
• Arquitectura en Capas: Todos los servicios REST están orientados hacia la
escalabilidad y un cliente REST no será capaz de distinguir entre si está
realizando una petición directamente al servidor, o se lo está devolviendo un
sistema de cache intermedio o por ejemplo existe un balanceador que se
encarga de redirigirlo a otro servidor.15
SOAP
Son las siglas de Simple Object Access Protocol. Este protocolo deriva de un
protocolo creado por David Winer, XML-RPC en 1998. En su sitio web, Userland,
http://www.userland.com se puede encontrar multitud de documentación acerca de
este primer protocolo de comunicación bajo http mediante XML. Con este protocolo
se pedían realizar RPC o remote procedure calls.
En el núcleo de los servicios Web se encuentra el protocolo simple de acceso a
datos SOAP, que proporciona un mecanismo estándar de empaquetar mensajes.
SOAP ha recibido gran atención debido a que facilita una comunicación del estilo
RPC entre un cliente y un servidor remoto. Pero existen multitud de protocolos
creados para facilitar la comunicación entre aplicaciones, incluyendo RPC de Sum,
DCE de Microsoft, RMI de Java y ORPC de CORBA.
¿Por qué se presta tanta atención a SOAP?
Una de las razones principales es que SOAP ha recibido un increíble apoyo por
parte de la industria. SOAP es el primer protocolo de su tipo que ha sido aceptado
prácticamente por todas las grandes compañías de software del mundo. Compañías
que en raras ocasiones cooperan entre sí están ofreciendo su apoyo a este
protocolo. Algunas de las mayores Compañías que soportan SOAP son Microsoft,
IBM, SUN, Microsystems, SAP y Ariba.
Algunas de las ventajas de SOAP son
15. Álvarez, Cecilio. Introducción a Servicios REST. [En linea] < http://www.arquitecturajava.com/servicios-rest/ >
[Citado en Junio 30 de 2017]
No está asociado con ningún lenguaje: los desarrolladores involucrados en nuevos
proyectos pueden elegir desarrollar con el último y mejor lenguaje de
programación que exista, pero los desarrolladores responsables de mantener
antiguas aflicciones heredadas podrían no poder hacer esta elección sobre el
lenguaje de programación que utilizan. SOAP no especifica una API, por lo que la
implementación de la API se deja al lenguaje de programación, como en Java, y la
plataforma como Microsoft .Net.
No se encuentra fuertemente asociado a ningún protocolo de transporte: La
especificación de SOAP no describe como se deberían asociar los mensajes de
SOAP con HTTP. Un mensaje de SOAP no es más que un documento XML, por lo
que puede transportarse utilizando cualquier protocolo capaz de transmitir texto.
No está atado a ninguna infraestructura de objeto distribuido La mayoría de los
sistemas de objetos distribuidos se pueden extender, y ya lo están alguno de ellos
para que admitan SOAP.
Aprovecha los estándares existentes en la industria: Los principales contribuyentes
a la especificación SOAP evitaron, intencionadamente, reinventar las cosas.
Optaron por extender los estándares existentes para que coincidieran con sus
necesidades. Por ejemplo, SOAP aprovecha XML para la codificación de los
mensajes, en lugar de utilizar su propio sistema de tipo que ya están definidas en la
especificación esquema de XML. Y como ya se ha mencionado SOAP no define un
medio de trasporte de los mensajes; los mensajes de SOAP se pueden asociar a
los protocolos de transporte existentes como HTTP y SMTP.
Permite la interoperabilidad entre múltiples entornos: SOAP se desarrolló sobre los
estándares existentes de la industria, por lo que las aplicaciones que se ejecuten en
plataformas con dichos estándares pueden comunicarse mediante mensaje SOAP
con aplicaciones que se ejecuten en otras plataformas. Por ejemplo, una aplicación
de escritorio que se ejecute en una PC puede comunicarse con una aplicación del
back-end ejecutándose en un mainframe capaz de enviar y recibir XML sobre
HTTP.16
La anatomía de un mensaje de SOAP esta proporcionada por un mecanismo
estándar de empaquetar un mensaje. Un mensaje SOAP se compone de un sobre
que contiene el cuerpo del mensaje y cualquier información de cabecera que se
utiliza para describir le mensaje. A continuación, tiene un ejemplo: El elemento raíz
del documento es el elemento Envelope. El ejemplo contiene dos subelementos,
Body y Header. Un ejemplo de SOAP valido también puede contener otros
elementos hijo en el sobre.
El sobre puede contener un elemento Header opcional que contiene información
sobre el mensaje. En el ejemplo anterior, la cabecera contiene dos elementos que
describen a quien compuso el mensaje, y posible receptor del mismo.
El sobre debe contener un elemento body el elemento body (cuerpo) contiene la
carga de datos del mensaje. En el ejemplo el cuerpo contiene una simple cadena
de caracteres.
Un mensaje debe estar dentro de sobre de SOAP bien construido. Un sobre se
compone de un único elemento envelope el sobre puede contener un elemento
Header y puede contener un elemento body. Si existe, la cabecera debe ser el
elemento hijo inmediato del sobre, con el cuerpo siguiendo inmediatamente a la
cabecera.
El cuerpo contiene la carga de datos del mensaje y la cabecera contiene los datos
adicionales que no pertenecen necesariamente al cuerpo del mensaje.
Además de definir un sobre de SOAP, la especificación de SOAP define una forma
de codificar los datos contenidos en un mensaje. La codificación de SOAP
proporciona un mecanismo estándar para serializar tipos de datos no definidos en
la parte 1 de la especificación del esquema de XML.
16. González, Benjamin. SOAP (Simple Object Access Protocol). [En línea]
<http://www.desarrolloweb.com/articulos/1557.php > [Citado en 10 de Julio de 2017]
La especificación de SOAP también proporciona un patrón de mensaje estándar
para facilitar el comportamiento de tipo RPC. Se emparejan dos mensajes de SOAP
para facilitar la asociación de un mensaje de petición con un mensaje de respuesta.
La llamada a un método y sus parámetros se serializan en el cuerpo del mensaje
de petición en forma de una estructura.
El elemento raíz tiene el mismo nombre que el método objetivo, con cada uno de
los parámetros codificado como una subelemento.
El mensaje de respuesta puede contener los resultados de la llamada al método o
una estructura de fallo bien definida. Los resultados de la llamada a un método se
serializan en el cuerpo de la petición como una estructura. Por convenio, el elemento
raíz tiene el mismo nombre que el método original al que se añade result. Los
parámetros de retorno se serializan como elementos hijo, con el parámetro de
retorno en primer lugar. Si se encuentra un error el cuerpo del mensaje de respuesta
contendrá una estructura de fallo bien definida.
Por convenio, el elemento raíz tiene el mismo nombre que el método original al que
se añade result. Los parámetros de retorno se serializan como elementos hijo, con
el parámetro de retorno en primer lugar. Si se encuentra un error el cuerpo del
mensaje de respuesta contendrá una estructura de fallo bien definida.17
1.9.2.3 Teoría de los sistemas
La teoría de los sistemas es ante todo un campo matemático que ofrece técnicas,
en parte novedosas y muy detalladas. Estrechamente vinculadas a la ciencia de la
computación, y orientado más que nada por et imperativo de vérselas con un nuevo
tipo de problema. La teoría de los sistemas representa un amplio punto de vista que
trasciende grandemente los problemas y los requerimientos tecnológicos, una
17. González, Benjamin. SOAP (Simple Object Access Protocol). [En línea] <http://www.desarrolloweb.com/articulos/1557.php
> [Citado en 10 de Julio de 2017]
reorientación que se ha vuelto necesaria en la ciencia en general, en toda la gama
de disciplinas que va de la física y la biología a las ciencias sociales y del
comportamiento y hasta a la filosofía. Con distintos grados de éxito y de exactitud.
Interviene en varios dominios y anuncia una nueva visión del mundo que tendrá
repercusiones considerables.
1.9.2.4 Sensores
Tracy Allen, aplicó este término al termómetro digital DS1620, el cual tiene
elementos electrónicos interconstruídos que simplifican las mediciones de
temperatura del microcontrolador. Adicionalmente, podía recordar la configuración
que recibía del microcontrolador y, más aún, funcionar independientemente como
un controlador de termostato.
En contraste con los sensores inteligentes, los sensores primitivos son dispositivos
o materiales que tienen alguna propiedad eléctrica que cambia con algún fenómeno
físico.
Un ejemplo de un sensor primitivo en ¿Qué es un Microcontrolador? es la
fotorresistencia de sulfato de cadmio. Su resistencia cambia con la intensidad de la
luz.
Con el programa y el circuito adecuados, es posible realizar mediciones de luz con
un microcontrolador. Otros ejemplos de sensores primitivos comunes son los
sensores de temperatura con salida de corriente/tensión, transductores de
micrófonos y aún el potenciómetro, que es un sensor de posición rotacional.
Dentro de cada sensor inteligente radica uno o más sensores primitivos y la
circuitería de soporte. Lo que hace a un sensor inteligente “inteligente” es la
electrónica interconstruída adicional. Esta electrónica hace que estos sensores
sean capaces de hacer una o más de las siguientes funciones:
• Pre-procesar los valores medidos en cantidades que posean algún significado.
• Comunicar las medidas con señales digitales y protocolos de comunicación.
• Orquestar las acciones de los sensores primitivos y sus circuitos para “tomar”
mediciones.
• Tomar decisiones e iniciar alguna acción en base a las condiciones censadas,
de manera independiente al microcontrolador.
• Recordar la calibración o la configuración de sus parámetros.18
1.9.2.5 Cifrado AES
Es un algoritmo de cifrado simétrico desarrollado por los estudiantes Vincent Rijmen
y Joan Daemen de la Katholieke Universiteit Leuven en Bélgica, bajo el nombre
"Rijndael" fue presentado en 1997 al concurso organizado por el Instituto Nacional
de Normas y Tecnologías (NIST) para elegir el mejor algoritmo de cifrado; el
algoritmo gano el concurso transformándose en un estándar en el año 2002, con
algunos cambios fue posteriormente renombrado AES (Advanced Encryption
Standard) y se convirtió en uno de los algoritmos más utilizados en la actualidad.1
Por ser simétrico, se utiliza la misma clave para encriptar como para descifrar, la
longitud de la clave puede ser de 128, 192 o 256 bits según especifica el estándar,
esto permite tres implementaciones conocidas como AES-128, AES-192 y AES-
256, el presente trabajo está basado en AES-128.
Partiendo de una clave inicial de 16 bytes (128 bits), que también se la puede ver
como un bloque o matriz de 4x4 bytes, se generan 10 claves, estas claves
resultantes junto con la clave inicial son denominadas subclaves.
18. Parallax Inc. Sensores inteligentes y sus aplicaciones. [En Línea].
<https://www.parallax.com/sites/default/files/downloads/122-28029-Smart-Sensors-Espanol-v1.0.pdf > [Citado en 15
de Julio de 2017]
El proceso de cifrado del algoritmo consiste en aplicar a cada estado un conjunto
de operaciones agrupadas en lo que se denominan rondas, el algoritmo realiza 11
rondas, donde en cada ronda se aplica una subclave diferente.
Las 11 rondas se pueden clasificar en 3 tipos:
- 1 ronda inicial (se aplica la subclave inicial).
- 9 rondas estándar (se aplican las 9 subclaves siguientes, una en cada ronda).
- 1 ronda final (se aplica la última subclave).
Las operaciones que realiza el algoritmo dentro de las rondas se reducen a 4
operaciones
básicas:
- SubBytes.
- ShiftRows.
- MixColumns.
- AddRoundKey.19
1.9.2.6 Metodología
Para este proyecto se utilizará la metodología PHVA:
La utilización continua del PHVA, brinda una solución que realmente permite
mantener la competitividad de los productos y servicios, mejorar la calidad, reduce
los costos, mejora la productividad, reduce los precios, aumenta la participación de
19. Pousa, Adrián. Algoritmo de cifrado simétrico aes. Aceleración de tiempo de cómputo sobre arquitecturas
multicore. [En Linea]
<http://postgrado.info.unlp.edu.ar/Carreras/Especializaciones/Redes_y_Seguridad/Trabajos_Finales/Pousa_Adria
n.pdf > [Citado en 15 de Julio de 2017]
mercado, supervivencia de la empresa, provee nuevos puestos de trabajo, aumenta
la rentabilidad de la empresa.
Figura 3, Ciclo PHVA.
PLANEAR
Es establecer los objetivos y procesos necesarios para conseguir resultados de
acuerdo con los requisitos del cliente y las políticas de la organización.
1. Identificar servicios
2. Identificar clientes
3. Identificar requerimientos de los clientes
4. Trasladar los requerimientos del cliente a especificaciones
5. Identificar los pasos claves del proceso (diagrama de flujo)
6. Identificar y seleccionar los parámetros de medición
7. Determinar la capacidad del proceso
8. Identificar con quien compararse
HACER
• Implementación de los procesos.
• Identificar oportunidades de mejora
• Desarrollo del plan piloto
• Implementar las mejoras
VERIFICAR
Realizar el seguimiento y medir los procesos y los productos contra las políticas, los
objetivos y los requisitos del producto e informar sobre los resultados.
ACTUAR
Tomar acciones para mejorar continuamente el desarrollo de los procesos.
1. Institucionalizar la mejora y-o volver al paso de Hacer20
Metodología de desarrollo de software SCRUM
Para el desarrollo del componente de software de este proyecto, se implementará
la parte del HACER del ciclo PHVA, la metodología de desarrollo de software
SCRUM, una metodología de desarrollo ágil que comprende un conjunto de buenas
prácticas para trabajar colaborativamente en equipo. Se utiliza esta metodología
dado que se necesita obtener resultados de forma rápida donde se ejecutarán
bloques temporales y cortos en la que cada iteración deberá proporcionar un
resultado completo.
Figura 4, Lista de tareas de Iteración.
20. 1Blog top punto com. EL CICLO PHVA PLANEAR-HACER-VERIFICAR-ACTUAR. [EN línea]. < http://www.blog-top.com/el-ciclo-
phva-planear-hacer-verificar-actuar/> [Citado en 10 de Julio de 2017 ]
Actividades de Scrum
Planeacion de la iteracion
El primer dia de la iteracion se realiza un reunion de planificacion de la iteracion la
cual consta de dos partes:
• Selección de requisitos:
El cliente presenta al equipo la lista de requisitos priorizada del producto, el equipo
pregunta las dudas al cliente, y selección los requisitos mas prioritarios que se
compromete a completar en la iteracion.
• Planificacion de la iteracion:
El equipo elabora un lista de tareas de la iteracion necesaria para desarrollar los
requisitos a que se ha comprometido, haciendo un estimacion del esfuerzo donde
los miembros del equipo se autoasignan tareas.
Ejecucion de la Iteracion:
Reunion de Sincronizacion:
Cada equipo realiza una reunión de sincronización (15 minutos aproximadamente),
cada miembro del equipo inspecciona el trabajo que el resto esta realizando
(dependencias entre tareas, problemas al cumplir el objetivo, tareas bloqueadas,
etc), lo anterior para poder planear adaptaciones que permitan cumplir el
compromiso adquirido.
En la reunion cada miembro responde a tres preguntas:
• ¿Qué he hecho desde la última reunión de sincronización?
• ¿Qué voy a hacer a partir de este momento?
• ¿Qué impedimentos tengo o voy a tener?
Durante la reunion, el facilitador (Scrum master) se encarga de que el equipo pueda
cumplir con su compromiso y de que no se merme su productividad.
- Eliminando los obstaculos que el equipo no puede resolver por si mismo.
- Proteger al equipo de interrupciones externas que puedan afectar su
compromiso o su productividad.
Inspeccion y Adaptacion:
El ultimo dia de la iteracion se realiza una reunion de revision de la iteracion la cual
consta de dos partes:
• Demostracion:
El equipo presenta al cliente los requisitos completados en la iteracion, el
cliente realiza adaptaciones necesarias de manera objetiva desde la primera
iteracion, replanificando el proyecto.
• Retrospectiva:
El equipo analiza como ha sido su manera de trabajar y cuales son los
problemas que podrian impedirle prograsar adecuadamente, mejorando de
manera continua su productividad. El Scrum master se encargara de ir
eliminado los los obstaculos identificados.21
1.9.3 Marco conceptual
El marco conceptual tiene por objetivo hacer una introducción a los conceptos más
relevantes se software y hardware que se usaran para el desarrollo del sistema,
en el contenido del marco conceptual podemos encontrar que es un sistema, que
es un servicio web (web service), que es Android, que es Health Care, entre otros
conceptos.
• Sistema
Un sistema es un conjunto de partes o elementos organizadas y relacionadas que
interactúan entre sí para lograr un objetivo. Los sistemas reciben (entrada) datos,
energía o materia del ambiente y proveen (salida) información, energía o materia.
Software
Es un término informático que hace referencia a un programa o conjunto de
programas de cómputo que incluye datos, procedimientos y pautas y que permite
realizar distintas tareas en un sistema informático.
Comúnmente se utiliza este término para referirse de una forma muy genérica a los
programas de un dispositivo informático.
Hardware
Es la parte física de un ordenador o sistema informático, está formado por los
componentes eléctricos, electrónicos, electromecánicos y mecánicos, tales como
circuitos de cables y circuitos de luz, placas, utensilios, cadenas y cualquier otro
material, en estado físico, que sea necesario para hacer que el equipo funcione.
21. Proyectos Agiles Org. QUE ES SCRUM. [En Línea] < https://proyectosagiles.org/que-es-scrum/> [Citado en 15 de
Julio de 2017]
Health Care
Hace referencia aquellos sistemas encargados de controlar y ayudar a pacientes
que tienen diferentes enfermedades
Android
Es un sistema operativo orientado a dispositivos móviles, basado en una versión
modificada del núcleo Linux. Inicialmente fue desarrollado por Android Inc., una
pequeña empresa, que posteriormente fue comprada por Google; en la actualidad
lo desarrollan los miembros de la Open Handset Alliance (liderada por Google).
Bluetooth
Es una especificación tecnológica para redes inalámbricas que permite la
transmisión de voz y datos entre distintos dispositivos mediante una radiofrecuencia
segura (2,4 GHz). Esta tecnología, por lo tanto, permite las comunicaciones sin
cables ni conectores y la posibilidad de crear redes inalámbricas domésticas para
sincronizar y compartir la información que se encuentra almacenada en diversos
equipos.
Smarthwatch
Es un reloj pulsera que incorpora un conjunto de componentes electrónicos junto
con un microprocesador capaz de ejecutar aplicaciones informáticas gracias a las
cuales el propietario puede acceder a internet, consultar su correo electrónico,
realizar y recibir llamadas, monitorizar y cuantificar su actividad diaria, ejecutar
determinadas apps
Servicios Web
Es una interfaz de software que describe un conjunto de operaciones a las cuales
se puede acceder por la red a través de mensajería XML estandarizada. Usa
protocolos basados en el lenguaje XML con el objetivo de describir una operación
para ejecutar o datos para intercambiar con otro servicio web.
Mysql
MySQL es un sistema de gestión de base de datos relacional (RDBMS) de código
abierto, basado en lenguaje de consulta estructurado (SQL).
PHP
PHP (acrónimo recursivo de PHP: Hypertext Preprocessor) es un lenguaje de
código abierto muy popular especialmente adecuado para el desarrollo web y que
puede ser incrustado en HTML.
Arritmia
Es un trastorno de la frecuencia cardíaca (pulso) o del ritmo cardíaco. El corazón
puede latir demasiado rápido (taquicardia), demasiado lento (bradicardia) o de
manera irregular.
Frecuencia cardiaca
La frecuencia normal en reposo oscila entre 50 y 100 latidos por minuto. Sin
embargo, hay algunos aspectos que alteran su estado.
Cifrado
Es una técnica para ocultar información de personas ajenas a estas, para que no
pueda ser manipulada, ni alterada, debe mantenerse siempre integra.
AES-256
Es un algoritmo de cifrado simétrico que utiliza varias sustituciones, permutaciones
y transformaciones lineales, con el fin de cifrar la información.
Sensor
Es cualquier dispositivo capaz de realizar una medición, puede ser del pulso
cardiaco, de distancia, de presión, entre otros.
1.10 FACTIBILIDAD
La factibilidad económica del proyecto es alta, la inversión no es muy elevada y el
tiempo de ejecución del proyecto se ajusta al presupuesto, se requieren 2 equipos
de cómputo para el trabajo, asesorías de los tutores del proyecto, acceso a Internet
y papelería para realizar el modelado del proyecto.
Tabla 1, Factibilidad económica.
TIPO DESCRPCION CANTIDAD UNIV ESTUDIANTES
Portatil
PC. Intel Core i7
RAM: 8GB
Disco Duro: 1000 GB
Hardware Smartwatch 1 900000 x 1 900000
otros Plan de datos 2 ETB ESP 540000 X 2
0
JDK 2 Oracle 0 0 0.00
Android Studio 2 Google 0 0 0.00
16000 hora x 440 Horas 3360000
Acceso a Internet 2 ETB ESP 720000 x 720000
$ 450,000
2
$ 150,000.00
200000
1
2 $3´000.000
1
Desarrol lador 1
Desarrol lador 2
x 1
x
700000
Hardware Telefono Android 2 2000000
Software
Windows 2 Microsoft 700000
Total
150000
RECURSOS PROVEEDOR COSTOS
FUENTE DE FINANCIACIONTOTAL COSTOS
Hardware x 3000000
Hardware Smartband
17160000
7680000
Otros
TOTAL
x
x 450000
RecursoAsesorías , Tutorías y
Programadores
16000 hora 480 horas
Papelería , fotocopias ,
transporte, medios
magnéticos de
a lmacenamiento
1.11 CRONOGRAMA
Figura 5, Cronograma de Actividades.
2. FASE DE ANÁLISIS
La fase de análisis tiene por objeto describir la realización del proyecto, describiendo
las fases de planeación, definición del equipo de trabajo, definición de los objetivos
del producto (Scrum backlog), definición de los objetivos del sprint, y la lista total de
objetivos a realizar.
Teniendo en cuenta la fase de definición analizaremos en detalle los ítems
necesarios para desarrollar el proyecto teniendo en cuenta lo siguiente:
2.1 PLANEACIÓN PROCESO SCRUM
Al utilizar la metodología scrum en este proyecto, debemos realizar una planeación
lo más exacta posible, estableceremos el equipo de trabajo, los objetivos que se
dividirán en sprints máximo de 15 días, teniendo stand up de 15 minutos todos los
días, para comprobar si se están cumpliendo las tareas del sprint y en caso de que
no, definir un plan de acción para cumplir con las tareas definidas.
2.1.1 Definición del equipo
El scrum team está conformado por:
• Product Owner: el rol será desempeñado por Jose castro, quien será el
encargado de determinar los objetivos del producto.
• Scrum Master: el rol será ejecutado por William Ospino, quien estará a
cargo de que se cumplan las etapas de SCRUM.
• Development Team: encargado de realizar todo el proceso de desarrollo del
proyecto, quien será ejecutado por William Ospino y Jose Castro.
2.1.1.1 Historias de usuario Tabla 2, Registro de usuario.
Registro de usuario
Numero: 1 Usuario: Usuario
Prioridad:
Alta
Riesgo en desarrollo:
Bajo
Puntos estimados: 3 Interacción Asignada:1
Programador responsable: Jose Jaime Castro
Descripción:
Quiero poderme registrar con usuario y contraseña para que nadie más pueda ver mis datos
Validación:
El usuario, puede registrarse con usuario y contraseña diligenciando el formulario de registro.
Tabla 3, Registro de Administrador.
Registro de Administrador
Numero: 2 Usuario: Administrador
Prioridad:
Alta
Riesgo en desarrollo:
Bajo
Puntos estimados: 3 Interacción Asignada:1
Programador responsable: William Ospino
Descripción:
Quiero poder registrarme con usuario y contraseña para luego poder ver los usuarios que tengo inscritos.
Validación:
El administrador, puede registrarse con usuario y contraseña en la aplicación diligenciando el formulario.
Tabla 4, Acceso usuario.
Acceso usuario
Numero: 3 Usuario: Usuario
Prioridad:
Alta
Riesgo en desarrollo:
Bajo
Puntos estimados: 3 Interacción Asignada:2
Programador responsable: Jose Jaime Castro
Descripción:
Quiero poder entrar a la aplicación con mi usuario y contraseña y ver que nadie más puede ver mis datos.
Validación:
El usuario, puede acceder a la aplicación con su usuario y contraseña registrados.
Tabla 5, Acceso Administrador.
Acceso Administrador
Numero: 4 Usuario: Administrador
Prioridad:
Alta
Riesgo en desarrollo:
Bajo
Puntos estimados: 3 Interacción Asignada:2
Programador responsable: William Ospino
Descripción:
Quiero entrar a la aplicación con mi usuario y contraseña que registre.
Validación:
El administrador puede acceder a la aplicación con su usuario y contraseña registrados.
Tabla 6, Administración de usuarios
Administración de usuarios
Numero: 5 Usuario: Administrador
Prioridad:
Alta
Riesgo en desarrollo:
Bajo
Puntos estimados: 3 Interacción Asignada:3
Programador responsable: William Ospino
Descripción:
Quiero poder entrar a ver mis usuarios, agregar nuevos, modificarlos existentes, eliminar usuarios
Validación:
El administrador, puede listar los usuarios, modificarlos, crear nuevos o eliminarlos.
Tabla 7, Realizar medición.
Realizar medición
Numero: 6 Usuario: Usuario / Administrador
Prioridad:
Alta
Riesgo en desarrollo:
Medio
Puntos estimados: 5 Interacción Asignada:3
Programador responsable: Jose Jaime Castro
Descripción:
Quiero poder realizar una medición de mis latidos del corazón cuando yo quiera.
Validación:
El administrador / usuario, pueden realizar la medición del ritmo cardiaco en demanda (Cuando lo deseen)
Tabla 8, Medición por defecto.
Medición por defecto
Numero: 7 Usuario: Usuario / Administrador
Prioridad:
Alta
Riesgo en desarrollo:
Alta
Puntos estimados: 5 Interacción Asignada:4
Programador responsable: Jose Jaime Castro
Descripción:
Quiero que la aplicación mida el ritmo cada rato.
Validación:
La aplicación realizara las periódicamente cada 30 segundos.
Tabla 9, Ubicación.
Ubicación
Numero: 8 Usuario: Usuario / Administrador
Prioridad:
Alta
Riesgo en desarrollo:
Alta
Puntos estimados: 5 Interacción Asignada:4
Programador responsable: Jose Jaime Castro /William Ospino
Descripción:
Quiero que la se registre la ubicación de las mediciones.
Validación:
La aplicación, tendrá la capacidad de determinar la posición del usuario haciendo uso de GPS.
Tabla 10, Envío de notificaciones.
Envío de Notificaciones
Numero: 9 Usuario: Usuario
Prioridad:
Alta
Riesgo en desarrollo:
Alta
Puntos estimados: 5 Interacción Asignada:5
Programador responsable: Jose Jaime Castro
Descripción:
Quiero que la aplicación envíe le avise a los que inscribí de las mediciones que estén fuera del rango.
Validación:
La aplicación, realizara el envío de las notificaciones a la lista de personas que el usuario haya inscrito.
Tabla 11, Ver Estadísticas.
Ver estadísticas
Numero: 10 Usuario: Usuario
Prioridad:
Alta
Riesgo en desarrollo:
Alta
Puntos estimados: 5 Interacción Asignada:6
Programador responsable: William Ospino
Descripción:
Quiero poder ver graficas de las mediciones que se hacen con la aplicación.
Validación:
El usuario, podrá ver las estadísticas de las mediciones que se realizan.
Tabla 12, Notificaciones offline.
Notificaciones Offline
Numero: 11 Usuario: Usuario
Prioridad:
Alta
Riesgo en desarrollo:
Alta
Puntos estimados: 3 Interacción Asignada:6
Programador responsable: Jose Jaime Castro
Descripción:
Quiero que la aplicación avise aun si no tengo internet.
Validación:
La aplicación, podrá enviar las notificaciones de las mediciones por mensajes de texto SMS aun cuando no haya internet.
Cifrado de la información
Numero: 12 Usuario: Usuario
Prioridad:
Alta
Riesgo en desarrollo:
Alta
Puntos estimados: 5 Interacción Asignada:6
Programador responsable: William Ospino
Descripción:
Quiero que los datos que se envían no los puedan ver otras personas.
Validación:
La aplicación, cifrará los datos con AES 256 para su envío por la red cuando se usa internet.
Tabla 13, Envío de información a la base de datos.
Envío de información a la base de datos
Numero: 13 Usuario: Usuario
Prioridad:
Alta
Riesgo en desarrollo:
Alta
Puntos estimados: 5 Interacción Asignada: 7
Programador responsable: Jose Jaime Castro
Descripción:
Quiero que la información se guarde en la nube, y que se guarde aun si no hay internet.
Validación:
La aplicación, transmitirá los datos a la base de datos de forma cifrada consumiendo un servicio web y cuando no haya conexión, guardará los datos en el teléfono de forma temporal hasta poder enviarlos a la base de datos.
Tabla 14, Cambiar contraseña.
Cambiar contraseña
Numero: 14 Usuario: Usuario
Prioridad:
Alta
Riesgo en desarrollo:
Alta
Puntos estimados: 2 Interacción Asignada:8
Programador responsable: William Ospino
Descripción:
Quiero que poder cerrar sesión y que nadie más pueda entrar si no tiene mis datos.
Validación:
El usuario, puede cerrar la sesión y esta se desconectará del servicio web dejando de transmitir información.
Tabla 15, Cerrar Sesión.
Cerrar Sesión
Numero: 15 Usuario: Usuario
Prioridad:
Alta
Riesgo en desarrollo:
Alta
Puntos estimados: 2 Interacción Asignada:9
Programador responsable: William Ospino
Descripción:
Quiero que la información se guarde en la nube, y que se guarde aun si no hay internet.
Validación:
La aplicación, transmitirá los datos a la base de datos de forma cifrada consumiendo un servicio web y cuando no haya conexión, guardará los datos en el teléfono de forma temporal hasta poder enviarlos a la base de datos.
2.1.2 Definición de los objetivos del producto (Product Backlog)
Los objetivos del producto son:
Tabla 16, Objetivos de producto, Scrum backlog
Orden Título Esfuerzo Descripción
1 Base de datos
3 Análisis, diseño e implementación de la base de datos en mongoDB
2 Aplicación nodejs
7 Análisis, diseño e implementación de aplicación nodejs encargada de mantener la comunicación dentro de todo el sistema
3 Aplicación web
5 Análisis, diseño e implementación de aplicación web, encargada de la administración de los datos del sistema
4 Aplicación Android
7 Análisis, diseño e implementación de aplicación Android, encargada de la interacción con los usuarios
2.1.3 Definición de los objetivos del sprint (Spring Backlog)
A continuación, se definen los sprints necesarios para completar el proyecto.
Sprint 1:
Definición del proyecto.
Diseño de la base de datos.
Creación de la base de datos.
Creación de servicio web.
Configuración de acceso remoto a servicio web.
Registro de usuario.
Registro De administrador.
Sprint 2:
Implementación de cifrado en servicio web.
Diseño de core de la aplicación Android.
Diseño de splash inicio aplicación Android.
Login de usuario en aplicación web.
Login de administrador en aplicación web.
Sprint 3:
Implementación menú principal.
Administración de usuarios.
Creación de la opción de inicio de medición.
Sprint 4:
Creación de los perfiles de usuario.
Creación de menú de acceso a histórico mediciones.
Implementación de ubicación.
Sprint 5:
Reportes y estadísticas.
Crear opción adición de contactos.
Administrar contactos.
Cambiar datos de acceso.
Sprint 6:
Crear inicio de mediciones.
Búsqueda paramiento de dispositivos Smartband.
Sprint 7:
Envío de información a la base de datos.
Inserción y guardado de datos.
Implementación de cifrado de datos.
Implementación transmisión de datos.
Sprint 8:
Recuperación de históricos
Generación de gráficos y reportes de medición
Sprint 9:
Cambiar contraseña.
Cierre de sesión.
Lista total de objetivos
Tabla 17, lista total de objetivos, Scrum backlog
Orden Sprint Horas tem Asignado a
1 1 24 Definición del proyecto
Jose Castro, William Ospino
2 1 4 Diseño de la base de datos
William Ospino
3 1 6 Creación de la base de datos
William Ospino
4 1 8 Creación de servicio web
Jose Castro
5 1 2 Configuración de acceso remoto a servicio web
William Ospino
6 2 6 Implementación de cifrado en servicio web
Jose Castro
7 2 6 Diseño de core de la aplicación Android
William Ospino
8 2 1 Diseño de splash inicio aplicación Android
Jose Castro
9 2 4 Registro de usuario en aplicación web
Jose Castro
10 3 4 Implementación login de usuario
William Ospino
11 3 2 Recuperación de datos de acceso
Jose Castro
12 3 2 Implementación menú principal
Jose Castro
13 3 4 Creación de la opción de inicio de medición
William Ospino
14 4 1 Creación de los perfiles de usuario
William Ospino
15 4 1 Creación de menú de acceso a histórico mediciones
Jose Castro
16 4 1 Opciones de cierre de la aplicación
Jose Castro
17 5 4 Crear opción adición de contactos
William Ospino
18 5 4 Administrar contactos
Jose Castro
19 5 2 Cambiar datos de acceso
William Ospino
20 6 4 Crear inicio de mediciones
Jose Castro
21 6 6 Búsqueda paramiento de dispositivos Smartband
William Ospino
22 7 8 Implementación cifrada de datos
Jose Castro
2.1.4 Planeación sprints
Los sprints tendrán una duración máxima de 15 días de 8 horas cada uno y se han
planeado de la siguiente manera:
Sprint 1: Desde el 16 de febrero hasta el 2 de marzo de 2017
Sprint 2: Desde el 3 de marzo hasta el 18 de marzo de 2017
Sprint 3: Desde el 19 de marzo hasta el 2 de abril de 2017
Sprint 4: Desde el 3 de abril hasta el 17 de abril de 2017
Sprint 5: Desde el 18 de abril hasta el 2 de mayo de 2017
23 7 2 Implementación transmisión de datos
William Ospino
24 7 4 Inserción y guardado de datos
William Ospino
25 8 2 Recuperación de históricos
William Ospino
26 8 8 Generación de gráficos y reportes de medición
Jose Castro
27 9 2 Registro usuarios portal web
William Ospino
28 9 4 Administración usuarios monitoreados
Jose Castro
29 9 4 Generación de reportes y estadísticas
William Ospino
30 9 16 Pruebas funcionales
Jose Castro
Sprint 6: Desde el 17 de mayo hasta el 31 de mayo de 2017
Sprint 7: Desde el 1 de junio hasta el 15 de junio de 2017
Sprint 8: Desde el 16 de junio hasta el 31 de junio de 2017
Sprint 9: Desde el 1 de julio hasta el 15 de Julio de 2017
Requerimientos funcionales
Esta aplicación es creada para suplir la necesidad de monitoreo de personas con
arritmias cardiacas usando tecnologías móviles, ya que estas personas no métodos
aparte de los controles médicos, que les permita hacer un chequeo durante el día,
llevar un control y notificar a otras personas designadas por él, si se presentan
alteraciones importantes en las mediciones de ritmo cardiaco, a lo largo del día,
informando por medio de mensaje de texto la ubicación y los resultados de la
medición.
Los requerimientos para el desarrollo de la aplicación son:
- Monitoreo de ritmo cardiaco por medio de Smartwatch.
- Poder hacer el registro del usuario al que se le hará monitoreo del ritmo
cardiaco.
- Guardar la información de monitoreo en una base de datos.
- Acceder a la información de monitoreos por medio del navegador web.
- Cifrar la información que se envíe a la base de datos.
- Generar informes estadísticos de las mediciones realizadas.
- Notificar a las personas que se elija de la ubicación y los datos de la
medición de la persona que se monitorea.
- Poder adicionar o quitar personas de la lista de notificaciones usando la
agenta del Smartphone.
2.2 REQUERIMIENTOS CANDIDATOS
Tabla 18, Requerimientos Candidatos.
REQUISITO
CANDIDATO DESCRIPCION
Registro de
Usuario
El usuario debe poder hacer el registro desde la aplicación
Android, elegir su usuario y contraseña.
Adicionar
contactos
El usuario debe poder adicionar o eliminar personas de
contacto para el envío de notificaciones.
Alertas La aplicación Android, debe poder enviar un SMS a los
contactos adicionados para el envío de notificaciones.
Guardado de la
información
La aplicación debe realizar el guardado de la información
en una base de datos remota.
Seguridad La aplicación Android debe poder realizar el guardado de
las mediciones en la base de datos, enviando la
información de manera cifrada.
Realizar
Consultas
El usuario debe poder realizar la consulta de sus mediciones
por medio de la aplicación Android o por medio del acceso
web.
Realizar
Estadísticas
La aplicación debe permitir la generación de gráficos y
reportes por medio de la aplicación Android o por medio del
acceso web.
2.3 IDENTIFICACION DE ACTORES
El sistema Health Care constara de los siguientes actores:
Administrador:
Es la persona que realizará el control de los monitoreos por medio del acceso web,
quien podrá a su vez tener una o más usuarios asignados en el acceso web, donde
podrá realizar consultas, generar reportes, gráficos activar o desactivar el monitoreo
de usuarios.
Usuario:
El usuario, es la persona a quien se le realiza el monitoreo, este puede realizar los
monitoreos manuales (iniciar medición), ver los reportes, adicionar y eliminar
contactos para notificación.
2.4 LISTA PRELIMINAR DE CASOS DE USO
ADMINISTRADOR:
➢ Registro.
➢ Gestionar contactos.
➢ Gestionar usuario.
➢ Generar reporte.
USUARIO
➢ Login.
➢ Gestionar contactos.
➢ Iniciar medición.
➢ Generar reporte.
2.4.1 Diagrama de caso de uso registrar usuario en el sistema Healt Care
Figura 6, Caso de uso Registrar usuario.
Tabla 19, Caso De Uso: Registrar Usuario en el Sistema.
Identificación 001
Actores Administrador y Usuario
Descripción Este caso de uso permite ingresar un nuevo usuario en
el sistema.
Precondición
En el caso del administrador debe haberse logueado
en la página web, en caso del usuario, deba abrir la
aplicación y contar con acceso a internet para poder
realizar el registro.
Flujo de eventos
1. La aplicación despliega la opción de login y registro.
El actor selecciona la opción de registro.
La aplicación despliega el formulario, y se realiza el
registro en la base de datos vía internet pulsando el
botón confirmar.
La aplicación valida la información
Se despliega el menú principal de la aplicación.
Pos condición El usuario queda registrado en el sistema.
Flujo alternativo
En administrador realiza el registro por medio del
acceso web, para luego hacer el login en la aplicación
Android para poder continuar.
2.4.2 Diagrama caso de uso iniciar sesión (Login)
Figura 7, Caso de uso Iniciar Sesión.
Tabla 20, Caso de Uso: Cambiar Contraseña.
Identificación 002
Actores Administrador y Usuario
Descripción Este caso de uso permite ingresar a hacer uso de la
aplicación Android y / o acceso web
Precondición El Administrador y/o usuario deben haber realizado el
registro en la aplicación.
Flujo de eventos
El actor, inicia la aplicación, ingresa su usuario y
contraseña registrados.
El actor pulsa el botón iniciar sesión y se accede al
menú principal de la aplicación.
Pos condición El actor inicia sesión en la aplicación Android o en el
portal web.
Flujo alternativo
En administrador accede al acceso web digita su
usuario y contraseña registrados, da clic en iniciar
sesión y se abre el menú principal.
2.4.3 Diagrama caso de uso cambiar contraseña
Figura 8, Caso de uso Cambiar Contraseña.
Tabla 21, Caso de uso: Iniciar Sesión.
Identificación 003
Actores Administrador y Usuario
Descripción Este caso de uso permite al actor realizar el cambio
de contraseña de acceso al sistema.
Precondición El actor, debe haber iniciado sesión en el sistema.
Flujo de eventos
El actor, inicia sesión y accede al menú principal.
El actor elige cambiar la contraseña.
El actor diligencia el formulario y presiona el botón
confirmar
El sistema valida e indica el resultado de la
operación.
Pos condición Se cambia la contraseña de acceso al sistema.
Flujo alternativo
El administrador, accede por medio del acceso web
en el menú principal selección cambiar la
contraseña, diligencia el formulario, confirma y se
realiza el cambio de la contraseña.
2.4.4 CASOS DE USO: ACTOR ADMINISTRADOR
Diagrama de caso de uso: Gestionar Usuario.
Figura 9, Caso de uso Gestionar Usuario.
Tabla 22, Caso de uso: Gestionar Usuario.
Identificación 004
Actores Administrador
Descripción Este caso de uso permite al actor realizar la gestión
de los usuarios que tiene a su cargo.
Precondición El actor, debe haber iniciado sesión en el sistema y
debe tener por lo menos un usuario a su cargo.
Flujo de eventos
El actor, inicia sesión y accede al menú principal.
El actor elige de la lista de usuarios el usuario a
gestionar.
El actor da clic en el botón de configuración.
El actor elige la acción a realizar, y confirma.
Se guardan los cambios sobre el usuario.
Pos condición Se realiza el cambio elegido sobre el usuario
seleccionado.
Tabla 23, Caso de uso: Gestionar Usuario.
2.4.5 CASOS DE USO: ACTOR ADMINISTRADOR /USUARIO
Diagrama de caso de uso: Generar reportes
Figura 10, Caso de uso Generar Reportes.
Tabla 23, Caso de uso: Generar Reportes.
Flujo alternativo
Identificación 005
Actores Administrador /usuario
Descripción Este caso de uso permite al actor generar y ver los
reportes.
Precondición El actor, debe haber iniciado sesión en el sistema y
debe tener por lo menos un usuario a su cargo.
Flujo de eventos
El actor, inicia sesión y accede al menú principal.
El actor elige un usuario y selecciona generar
reporte.
Se genera el reporte.
2.4.6 CASOS DE USO: ACTOR USUARIO
Diagrama caso de uso: Iniciar Medición.
Figura 11, Caso de uso Iniciar Medición.
Tabla 24, Caso de uso: Iniciar Medición.
Pos condición Se visualiza el reporte en la página web a manera
de gráfica en la página web o en el dispositivo
Android.
Flujo alternativo El usuario accede a la aplicación, abre el menú
principal, y selecciona generar reporte.
Identificación 006
Actores Usuario
Descripción Este caso de uso permite al iniciar una medición.
Precondición El actor, debe haber iniciado sesión en el sistema
debe acceder al menú principal para poder elegir
realizar una nueva medición.
2.4.7 CASOS DE USO: ACTOR USUARIO.
Diagrama de caso de uso: Gestionar contactos.
Figura 12, Caso de uso Gestionar Contactos.
Tabla 25, Caso de uso: Gestionar contactos.
Flujo de eventos El actor, inicia sesión y accede al menú principal.
El actor en el menú principal elige iniciar medición.
Pos condición Se visualiza el resultado de la medición en la
pantalla del dispositivo Android.
Flujo alternativo
Identificación 007
Actores Administrador /usuario
Descripción Este caso de uso permite al usuario, gestionar los
contactos para las notificaciones.
Precondición El actor, debe haber iniciado sesión en el sistema
debe acceder al menú principal para poder ingresar
a gestionar los contactos.
Flujo de eventos El actor, inicia sesión y accede al menú principal.
El actor en el menú principal elige gestionar
contactos.
El actor elige la adicionar contacto.
El actor accede a la lista de contactos del teléfono
móvil y se puede elegir un contacto.
El actor Administrador, puede elegir modificar o
eliminar un contacto ya existente.
Pos condición Se adiciona, modifica o elimina un contacto para
notificaciones.
Flujo alternativo
3. FASE DE DISEÑO
Teniendo en cuenta las fases anteriores podemos proceder a definir los procesos
necesarios para diseñar los elementos que el sistema necesita para
implementarse posteriormente, aplicando ciertos principios y técnicas.
3.1 DIAGRAMA DE DATOS
3.1.1 Modelo de datos
Un modelo de datos nos permite realizar una abstracción del comportamiento de
los datos que se necesitan en nuestro sistema, en este caso al usar base de datos
no relacionales, se omiten las tablas comunes y se utilizan documentos que son
los elementos propios de las base de datos no relacionales y las que utiliza
mongoDB.
Teniendo en cuenta los parametros definidos para nuestro sistema encontramos
que son necesarios la creación de los siguientes documentos:
• Usuarios, para manipular toda la información relevante de los usuarios que
se registren en el sistema.
• Alertas, para controlar las alertas generadas del usuario, del debido
proceso de control de la frecuencia cardiaca de este.
• Medicions, para manipular las mediciones manuales que realice el usuario,
para llevar un historico de estas.
• Contactos, sirve para controlar los contactos que el usuario decida agregar
para informar en caso de que se generen alertas.
• Tycs, contiene información de los terminos y condiciones para el uso del
sistema.
A continuación podemos ver en detalle el modelo diseñado para el sistema:
Figura 13, Modelo de datos.
3.1.2 Diccionario de datos
Nuestro diccionario de dato contiene las definiciones de cada uno de los campos
utilizados en cada uno de los documentos y muestran características de estos
como el tipo, si son llaves principales, entre otros
3.2.3.1 Documento usuario
Tabla 26, Diccionario de datos Documentos de usuario.
CAMPO DESCRIPCION TIPO
_ID Id del usuario OID
Email Correo electrónico string
Nombre Nombre completo string
Tyc Acepta términos y
condiciones boolean
Dirección Dirección de contacto string
Teléfono Teléfono de contacto double
Cc No de identificación Integer
Password Contraseña String
Créate Fecha creación registro Date
_V Version document Integer
3.2.3.2 Documento mediciones
Tabla 27, Documento mediciones.
CAMPO DESCRIPCION TIPO
_ID Id medición OID
Valor Valor obtenido integer
Id_usuario Id del usuario OID
Créate Fecha creación registro Date
_V Version document Integer
3.2.3.3 Documento alertas
Tabla 28, Documento alertas.
CAMPO DESCRIPCION TIPO
_ID Id alerta OID
Valor Valor obtenido integer
tipoAlerta Tipo alerta string
Id_usuario Id del usuario OID
Créate Fecha creación registro Date
_V Version document Integer
3.2.3.4 Documento tycs
Tabla 29, Documento tycs.
CAMPO DESCRIPCION TIPO
_ID Id alerta OID
Valor Valor obtenido integer
nombre Nombre string
descripcion Descripción string
_V Version document integer
3.2.3.5 Documento contactos
Tabla 30, Documento Contactos.
CAMPO DESCRIPCION TIPO
_ID Id contacto OID
email Correo electrónico string
nombre Nombre completo string
Id_usuario Id usuario OID
direccion Dirección de contacto string
telefono Teléfono de contacto double
Créate Fecha creación registro Date
_V Version document Integer
3.2 DIAGRAMAS DE PAQUETES
Diseñamos los siguientes diagramas de paquetes dentro de nuestro sistema para
mantener una jerarquía lógica, teniendo en cuenta las aplicaciones que son
necesarias implementar para que el sistema trabaje adecuadamente.
3.2.1 Diagrama paquete Sistema
Figura 13, Diagrama Sistema.
3.2.2 Diagrama paquete Mobile
Figura 14, Diagrama Mobile.
3.2.3 Diagrama paquete Shared
Figura 15, Diagrama Shared.
3.2.4 Diagrama de paquete Wear
Figura 16, Diagrama wear.
3.3 DIAGRAMAS DE CLASES
Para el presente sistema se definieron los siguientes diagramas para visualizar las
clases que se relacionan, teniendo en cuenta la herencia, las asociaciones, los usos
y demás que se presentan entre las clases necesarias del sistema.
Para la aplicación en Android se diseñaron las siguientes clases,
3.3.1 Diagrama Mobile
Figura 17, Diagrama de clases Mobile.
3.3.2 Diagrama Util y entidades
Figura 18, Diagrama Útil y Entidades.
3.3.3 Diagrama Services and shared
Figura 19, Services and shared.
3.3.4 Diagrama Shared
Figura 21, Diagrama clases Shared.
3.3.5 Diagrama Wear
Figura 22, Diagrama clases wear.
Para nuestra aplicación core (API) se diseñaron los siguientes diagramas de clase.
3.3.6 Diagrama Global
Figura 23, Diagrama clases global
3.3.7 Diagrama de Autenticación
Figura 24 Diagrama clases autenticación
3.3.8 Diagrama de Contactos
Figura 25, Diagrama clases de contactos.
3.3.9 Diagrama de Medición
Figura 26, Términos y condiciones.
3.3.10 Diagrama de Términos y condiciones
Figura 27, Términos y condiciones.
3.3.11 Diagrama de Usuario
Figura 28, Diagrama de Usuario.
3.3.12 Diagrama de Alerta
Figura 29, Diagrama de alerta.
Para el dashboard del sistema se diseñaron los siguientes diagramas de clase.
3.3.13 Diagrama Dashboard
Figura 30, Diagrama Dashboard.
Figura 31, Diagrama Dashboard 2.
Figura 3220, Diagrama Dashboard 3.
Figura 33, Diagrama Dashboard 4.
Figura 34, Diagrama Dashboard 5.
Figura 35, Diagrama Dashboard 6
Figura 36, Diagrama Dashboard 7.
Figura 46, Diagrama Dashboard 8.
4. FASE DE IMPLEMENTACION
En esta fase se procedió con la implementación del sistema teniendo en cuenta las fases anteriores, siguiendo paso a paso los parámetros definidos para el sistema.
4.1 ARQUITECTURA DEL SISTEMA
Teniendo en cuenta la fase de diseño, se definió una arquitectura de tipo cliente/
servidor, que cuenta con una REST API, base de datos en mongoDB, y dos clientes
encargados de realizar peticiones a la API que son el dashboard que es una
aplicación web y la app mobile.
Figura 37, Diagrama Arquitectura sistema
REST API
Se implemento utilizando nodeJS para el entorno de ejecución de nuestro servidor
utilizando ECMAScript 5(javascript), además se usó la librería mongoose para
permitir la conexión a la base de datos y el framework Express para permitir las
peticiones a través del protocolo HTTP
MONGODB
Se creo la base de datos con motor mongo, por las ventajas que esta tiene, como
su escalabilidad, rapidez, alta disponibilidad entre otras.
WEB APP-DASHBOARD
Se implemento un pequeño dashboard con html y jquery para comunicarnos con la
REST API, usando el protocolo HTTP a través del método Ajax de jquery, este
dashboard permite consultar la información de los usuarios, como son las
mediciones, alertas y contactos de cada uno de los usuarios.
MOBILE
Se creo una aplicación en Android que es soportada desde la versión 4.4 en
adelante y que sean compatibles con BLE, para la comunicación con los
smartwatchs que es de donde se obtienen los datos de la frecuencia cardiaca,
además se creó la posibilidad de que la aplicación pueda funcionar de una manera
transparente para el usuario cuando esta esté offline a excepción del envío de
alertas a los contactos, para ello se utilizó SQLite que nos permite guardar toda
nuestra información de manera local en el teléfono mientras esta se sincroniza con
la información del lado del servidor.
4.2 COMUNICACIÓN ENTRE EL SISTEMA
Para este sistema al implementarse la REST API, debemos utilizar el protocolo
HTTP para la comunicación entre los diferentes componentes.
Para realizar una petición a la API se debe realizar a la url:
https://healthcareapi.herokuapp.com/api/
Adicionalmente se deben enviar ciertos parámetros dependiendo el tipo de petición
que se realiza.
GET
Sirve para obtener datos de la API como la lista de mediciones, alertas, contactos.
Un ejemplo de una petición GET debe llevar lo siguiente,
Figura 38, petición get
La url está formada de la siguiente manera:
Hots/api/tipodedatoaobtener/
Además, se debe enviar dentro del header el parámetro Authorization de tipo jwt
que es el token del usuario ante puesto por la palabra Bearer como se observa en
la imagen anterior.
POST
Sirve para agregar datos al sistema a través de la API. Un ejemplo de una petición
POST debe llevar lo siguiente:
Figura 39, petición post
Debe ser de tipo x-www-form-urlencoded, debe llevar los parámetros del dato que
queremos crear esto dentro del body, en el header debemos incluir el parámetro
Authorization como en la petición anterior.
PUT
Permite actualizar registros existentes en el sistema, es similar a la petición post lo
que cambia es que debemos agregar los datos que queremos modificar teniendo
en cuenta que debe ir el id del elemento.
Figura 40, petición put
DELETE
Nos permite eliminar elementos de nuestro sistema, la petición se realiza de la
siguiente manera.
Figura 41, petición delete
Demos enviar en la url el id del elemento a eliminar junto con el parámetro
Authorization en el header de la petición.
4.3 BLUETOOH LOW ENERGY(BLE)
Para implementar BLE, seguimos las instrucciones de la documentación de Android
para ello definimos los permisos necesarios como se ven en la imagen a
continuación.
Figura 42, permisos necesarios para BLE
Debemos tener en cuenta que el bluetooth debe estar activo, para ello se utilizan la
función de android BluetoothAdapter.getDefaultAdapter().isEnabled() en caso de
ser falso lo podemos activar BluetoothAdapter.getDefaultAdapter().enabled()
llamando esta función.
El siguiente paso es buscar los dispositivos compatibles con BLE para ello usamos
la función BluetoothAdapter.startLeScan(afterGetBleDevice) donde enviamos como
parámetro un callback necesario para procesar nuestros dispositivos BLE.
Después de esto definimos nuestro listener para la comunicación entre el
smartwatch y el handphone para poder enviar y recibir datos, los listener son de tipo
WearableListenerService que nos permiten realizar la comunicación de manera
sencilla con los métodos que esta implementa como onDataChange y
onMessageReceived.
4.4 AES256 EN LA TRANSMISIÓN DE LA INFORMACIÓN
Para dar cumplimiento al objetivo específico número cinco, de implementar cifrado AES-256 en la trasmisión de la información, manipulada por los servicios web, se realizó el proceso y se obtuvo el siguiente resultado.
En este sistema se implementó un cifrado aes256, en las respuestas de las
peticiones http necesarias para mantener una mayor seguridad de los datos del
sistema, para ello se utiliza la librería CryptLib(cross platform 256bits AES
encryption / decryption), que permite cifrar y descifrar mensajes entre diferentes
lenguajes como son ios, Android, javascript.
En la API del sistema se creó un servicio(cifrado.js) que implementa la librería, para
el funcionamiento de esta, Se definieron dos variables que son necesarias para
cifrar y descifrar la variable password(array 32 bits) y iv(array 16 bits),
Figura 43, Variables necesarios para cifrar.
También definimos los dos métodos necesarios para cifrar y descifrar en este caso
encrypt y decrypt
Figura 44, Métodos para cifrar y descifrar
Para utilizar el cifrado y descifrado de datos el servicio se incluye en los controllers
de la API para poder utilizar los métodos de este.
Figura 45, Inclusión de métodos necesarios para cifrar
Como ejemplo podemos evidenciar obteniendo los contactos de un usuario
Figura 46, ejemplo de cifrado de datos
Al realizar las pruebas obtenemos el siguiente resultado.
Figura 47, resultados de petición con respuesta cifrada
{
"message":
"LGcI2lpG8i0z5Y2iKgXhNJPcBzrRFjCWaGxKZ9sKYE7ttIQn5l1Nc/F8BKzJ
wGEDzGLOYy5X7/hSwrJz4RPnTgY4NnVp4o4MSK0c7x1bfBPiGQLwx2MR
ZBAboN7xX4e7xIjPI53wPjxm8ORLimUxsshSKLFw1On4n838vT6z+hr6VHg
rC7lYbEr3BxhK1OJSjC7lq35BJovGZ9gXfheJ8j/MHg+Qwu8Az+5aTJvXaftq
ghfeiZbEHXPDo+nDn1IvgpjNvzMXGSPMQe1tubGFJMTkC7LcOf7rPdvw/O
Ey01/znlhmR/dSOLiBk8AE4+MimNQxYOS2L0OaRHq0ae7m6pYmGG0YF
SZJCuFokmHm+i9QWlFwNStwNu3cpMgusjS4vpA8136smfO3z5BrrbfnlPriP
3UhOwZPidy7I8kZnew1oqRKEkG2KbXEfkRzHUZgChiaQQzv7WE0aG4bv+
gYNm+bl6hf4mgyVUofZ8IY0rH5/cUuycm4PIZkasCTt+QHqm4h+1COfxt958
aTL2R+BwN117PGr+dg19zD5DCh59Y="}
Para decodificar el mensaje usamos la función descifrar de la librería pasándole los
valores definidos en el password y en iv, en android implementamos la librería en la
clase CryptLib dentro de utils y en nuestra clase DataGlobal.java creamos la función
decryptmessageContacto que recibe el mensaje
Figura 48, variables necesarias para descifrar mensajes en android
Figura 49, método para descifrar mensajes en android
Los resultados obtenidos luego de descifrar nuestro mensaje es un array de
contactos.
Figura 50, mensaje descifrado en android
[{"_id":"5955d9b001a57a05b621f620","id_usuario":"595925aaa0eb44e6314c3cb0",
"telefono":3202727295,"direccion":"tv 74 no 11a-
35","email":"[email protected]","nombre":"jose
jaime","__v":0,"create":"2017-06-
30T04:55:10.096Z"},{"_id":"597d685323d48b9578fde295","telefono":123456789,"di
reccion":"Direcci�neee","email":"[email protected]","nombre":"Nombre124","__v"
:0,"create":"2017-07-30T01:20:26.078Z"}]
5. FASE DE PRUEBAS
Se ha realizado un set de pruebas integrales y funcionales del sistema, para establecer su correcto funcionamiento, las pruebas se realizaron por 3 semanas, se estableció un ambiente de pruebas para con el que hacer pruebas de estrés con grandes volúmenes de información para simular un gran número de usuarios realizando múltiples transacciones concurrentes.
5.1 COMPROBACIÓN DE FUNCIONAMIENTO DE LA APLICACIÓN
La fase de pruebas de este proyecto desarrollado en la metodología ágil scrum,
busca realizar las pruebas integrales de las funcionalidades del sistema Health
Care, las pruebas se han enfocado en hacer pruebas de las historias de usuario que
se definieron anteriormente, aclarando que puede que el desarrollo tenga un
contenido más amplio del descrito en las historias de usuario.
Para este sistema, no se ha hecho la implementación de pruebas automatizadas o
el uso de herramientas de pruebas para testing automatizado.
Tabla 31, historias de usuario, registro de usuario.
Operación Descripción del
resultado
Correcciones
Inicio de la aplicación Correcto, se inicia aplicación y se
carga formulario de inicio de
sesión con opción de registrarse.
Se adiciona la opción de
registrarse de forma más visible
Despliegue de formulario de
registro.
Se prueba la opción registrarse, se
despliega correctamente.
N/A
Llenado de formulario de registro. Se realiza el llenado del formulario
de registro, los datos obligatorios
de exigen para continuar
Se ponen de color rojo los campos
obligatorios o que no cumplen con
las validaciones del formulario.
Guardado de formulario. Se prueba la función de guardado
del formulario y la información se
envía al servicio web, la
información se refleja en la base de
datos.
Se hace validación total de los
campos nuevamente antes de
enviar la información al servicio
web.
Tabla 32, Historias de usuario, registro de Administrador.
Operación Descripción del resultado correcciones
Registro Administrador Correcto, se inicia aplicación y se
carga formulario de inicio de sesión
con opción de registrarse.
Se aplican las mismas correcciones
del registro del usuario.
Despliegue de formulario de registro. Se prueba la opción registrarse, se
despliega correctamente. N/A
Llenado de formulario de registro. Se realiza el llenado del formulario de
registro, los datos obligatorios de
exigen para continuar
Se ponen de color rojo los campos
obligatorios o que no cumplen con las
validaciones del formulario.
Guardado de formulario. Se prueba la función de guardado del
formulario y la información se envía al
servicio web, la información se refleja
en la base de datos.
se aplica las correcciones del
formulario de registro del usuario.
Tabla 33, Historias de usuario, Acceso de usuario/Administrador
Operación Descripción de resultado Correcciones
Login de usuario se realiza comprobación de usuario y contraseña
registrados, se realiza login correctamente
Se muestran mensajes de alerta
indicando teclado mayúsculas
encendido, y error de inicio de
sesión
Recordar datos de acceso Se prueba funcionalidad de recuperación de datos
de usuario correctamente al diligenciar el
formulario.
N/A
Tabla 34, Tareas de usuario, administración de usuarios.
Operación Descripción de resultado Correcciones
Se realiza login de administrador Se realiza login del administrador, y se
carga en menú principal donde se listan
los usuarios que se han registrado, y las
opciones de adicionar, modificar y borrar
usuarios.
N/A
Adición de usuario Se realiza el registro de un nuevo usuario
correctamente. N/A
Modificar usuario Se realiza la edición de los datos
registrados del usuario correctamente.
Se refresca la grilla de usuarios
al terminar la edición de un
usuario.
Eliminación de usuario Se selecciona un usuario y de marca para
eliminar, se elimina correctamente al
confirmar.
N/A
Tabla 35, Historias de usuario, realizar medición.
Operación Descripción de resultado Correcciones
Login Se realiza autenticación del usuario u
administrador correctamente
N/A
Carga menú principal Se despliega correctamente el menú
principal.
N/A
Medición manual Se realiza prueba de la opción realizar
medición, se confirma la medición y el
proceso se realiza correctamente.
N/A
Tabla 36, Historias de usuario, Medición por defecto.
Operación Descripción de resultado Correcciones
Login Se realiza autenticación del usuario u
administrador correctamente
N/A
Medición automática Se abre la aplicación, se espera un lapso de
30 segundos, y a aplicación dispara la
medición automáticamente.
N/A
Tabla 37, Historias de usuario, ubicación
Operación Descripción de resultado Correcciones
login Se realiza autenticación del usuario u administrador
correctamente
N/A
Ubicación La aplicación hace uso del recurso gps para
ubicación, se provoca una medición fura de
parámetros para comprobar y la aplicación registra
correctamente la ubicación aproximada.
N/A
.
Tabla 38, Historias de usuario, Envío de notificación.
Operación Descripción de resultado Correcciones
login Se realiza autenticación del usuario u
administrador correctamente
N/A
Envío de notificación Se realiza una prueba de medición fuera de
parámetros, para verificar que las notificaciones
se envíen, se envían correctamente.
Se valida que, si el teléfono móvil
no tiene internet, la notificación se
pueda hacer solo por sms.
Tabla 39, Historias de usuario, Ver estadísticas.
Operación Descripción de resultado Correcciones
Login Se realiza autenticación del usuario u
administrador correctamente
N/A
ver estadísticas Administrador Se accede al menú principal del
administrador, se listan los usuarios, se elige
un usuario, y se pueden ver las estadísticas
de las mediciones que han tenido alguna
anomalía.
N/A
Ver estadísticas usuario Se accede al menú principal de la aplicación
y se selecciona generar reporte, se muestran
los reportes de las mediciones que han
tenido anomalías.
N/A
Tabla 40, Historias de usuario, Notificaciones offline.
Operación Descripción de resultado Correcciones
login Se realiza autenticación del usuario u
administrador correctamente
Prueba de notificación sin internet Se apagan los datos y se genera una
medición fuera de parámetros para
que la aplicación genere una
notificación, se hace la notificación
por medio de SMS.
Tabla 41, Historias de usuario, Cifrado de la información.
Operación Descripción de resultado Correcciones
login Se realiza autenticación del usuario u
administrador correctamente
Envío cifrado de información Se hacen pruebas en el servicio web,
se recibe solo información cifrada
desde la aplicación móvil y solo se
envía información cifrada hacia la
aplicación móvil, el cifrado
implementado es AES 256
Tabla 42, Historias de usuario, Guardado de información
Operación Descripción de resultado Correcciones
login Se realiza autenticación del usuario u
administrador correctamente
Guardado en la base datos Se verifican la información de las
pruebas anteriores, y se encuentra
que esta se encuentra registrada en
la base de datos.
Guardado de información offline Se verifica y la información de la
medición hecha fuera de línea se
sincroniza al encender los datos.
Tabla 43, Historias de usuario, Cambiar contraseña
Operación Descripción de resultado Correcciones
login Se realiza autenticación del usuario u
administrador correctamente
Cambiar contraseña Se selecciona la opción cambiar
contraseña, se diligencia el
formulario, se confirma, se cierra
sesión y se vuelve a iniciar, usando la
nueva contraseña.
Tabla 44, Historias de usuario, cerrar sesión
Operación Descripción de resultado Correcciones
login Se realiza autenticación del usuario u
administrador correctamente
Logout Se hace logout, la aplicación se
desconecta del servicio web y no se
sigue sincronizando información del
smartwatch
Tabla 45, Comprobación de funcionamiento de la aplicación.
OPERACION DESCRIPCIÓN RESULTADO CORRECIONES
Registrar Usuario Captura y almacenamiento satisfactorio de datos.
Ninguna
Registrar Administrador Captura y almacenamiento satisfactorio de datos.
Ninguna
Login Usuario Ingreso a la aplicación de forma correcta
Ninguna
Login de Administrador Ingreso a la aplicación de forma correcta Ninguna
Administración de usuarios Funcionamiento correcto Se corrigió la relación de
usuarios para los administradores
Eliminar usuario Se elimina correctamente los usuarios Ninguna
Adicionar usuario Se puede adicionar usuarios Ninguna
Realizar medición Se puede realizar medición a petición Ninguna
Realizar medición por defecto
Se hace medición por defecto Se programó hacer las mediciones cada 30 segundos por cuestiones de rendimiento de la batería del smartwatch
Pruebas de ubicación
La aplicación tiene acceso al servicio de GPS del Smartphone
Se optimiza para que se haga uso de ubicación de alta precisión (GPS, WIFI, Bluetooth o redes móviles)
Envío de notificaciones
Se puede hacer el envío de notificaciones SMS y mail
Se mejora el envío de notificaciones, el usuario no podrá evitar el envío de una notificación.
Ver estadísticas
Muestra estadísticas coherentes con lo revisado
Se corrigen graficas no salían correctamente en diferentes tamaños de pantalla.
envío de notificaciones offline
La aplicación captura datos y envía notificaciones sin conexión a internet vía SMS
Ninguna
Cifrado de la información
Se hace envío cifrado de la información. Se implementó tokens de autenticación para usuarios, que ayudan a garantizar que el usuario es quien dice ser.
envío de información a la base de datos
Se verifica el envío de los datos a la base de datos.
Se mejora el envío de datos para cuando el Smartphone esta sin conexión y vuelve a conectarse, este sincroniza los datos recopilados mientras estuvo offline.
Cambiar Contraseña Modifica clave exitosamente Ninguna
Salir Cierra sesión satisfactoriamente
5.2 COMPROBACIÓN DE LA BASE DE DATOS
Se realizan pruebas de acceso a la base de datos, pruebas de estrés y de sincronización de dispositivos offline, haciendo sincronización de los datos en el que el Smartphone estuvo offline.
Se hace simulación de 100 usuarios concurrentes, accediendo a la base de datos adicionando y consultando estadísticas, haciendo login y loguot, para probar el desempeño de la base de datos y de las librerías de node.js
6. CONCLUSIONES
De la implementación del sistema health care para el monitoreo de arritmias
cardíacas en personas con problemas cardíacos utilizando servicios web se
concluye:
• Que el problema permitió hacer el uso de elementos de telemática, para el
envío y recepción de información sensible, en este caso la información de las
mediciones de ritmo cardiaco.
• Además, se concluyó que es posible la creación de una red de monitoreo que
incluya a muchas personas, y que la creación de esta podría ayudar a
controlar arritmias y ayudar a salvar vidas.
• Se estableció mecanismos de control para garantizar la privacidad y
seguridad de la información obtenida de las mediciones y almacenarla de
forma segura en servidores ubicados en la nube.
• El desarrollo de software y las tecnologías de la información está en
constante evolución, razón por la cual la aparición de nuevas tecnologías en
el futuro permitirá mejorar las mediciones y las comunicaciones de la
aplicación.
7. RECOMENDACIONES
1. Se recomienda el uso de dispositivos Android actualizados, ya que las
compatibilidad y estabilidad de la aplicación se garantiza.
2. Se recomienda el uso de un plan de datos que incluya el envío de sms,
actualmente, la mayoría de operadores incluye una gran cantidad de SMS
que usualmente nadie usa.
3. Aunque el uso de batería de la aplicación no es considerable, si se
recomienda, que no se tengan múltiples aplicaciones de redes sociales
instaladas y generando tráfico pues deterioran el rendimiento de la batería
4. La aplicación está sujeta a mejoras se recomienda tener la última versión de
la aplicación instalada para garantizar tener las ultimas características.
5. El dispositivo smartwatch, opera con bluetooth, una tecnología de
comunicaciones que opera en cortas distancias, por lo cual se recomienda,
para el uso de la aplicación que el smartwatch y el Smartphone, se encuentren
a una distancia menor a 10 metros con línea de vista, de lo contrario la
comunicación no será posible entre el smartwatch y el Smartphone, haciendo
imposible el uso de aplicación.
8. BIBLIOGRAFIA
1. PALANTE - PAtients Leading and mANaging their healThcare through EHealth, 9
Abril 2016, de http://www.indracompany.com/es/indra/palante-patients-leading-
managing-healthcare-ehealth
2. TeleMed - the Telematic System Supporting Intensive Insulin Treatment of the
Newly Diagnosed Type one Diabetic Patients. First Clinical Application, 9 Abril
2016, de
http://ieeexplore.ieee.org.bdigital.udistrital.edu.co:8080/stamp/stamp.jsp?tp=&arn
umber=1280948
3. TELEMEDICINE FOR HOMECARE: APPLICATIONS FOR AIDS PATIENTS,9
Abril 2016, de
http://ieeexplore.ieee.org.bdigital.udistrital.edu.co:8080/stamp/stamp.jsp?tp=&arn
umber=757818
4. Alvares, Eliana (2015). Telemedicina: ¿qué es y cómo funciona?, 9 de abril 2016,
de http://www.colombiadigital.net/actualidad/articulos-informativos/item/4384-
telemedicina-que-es-y-como-fuciona.html
5. Díaz, Gonzalo, Telemática Médica-e-Health-Telecomunicaciones en Medicina,9
de abril 2016, de http://drgdiaz.com/eco/telemedicina/index.shtml
6. ARQUITECTURA DE SERVICIOS WEB (WS), 9 de abril 2016, de
http://www.mad.es/serviciosadicionales/ficheros/est-tema12.pdf
7. Álvarez, Cecilio (2015). Introducción a Servicios REST,9 de abril de 2016, de
http://www.arquitecturajava.com/servicios-rest/
8. González, Benjamín (2014). SOAP (Simple Object Access Protocol) ,9 de abril de
2016, de http://www.desarrolloweb.com/articulos/1557.php
9. EL CICLO PHVA PLANEAR-HACER-VERIFICAR-ACTUAR,9 de abril de 2016, de
http://www.blog-top.com/el-ciclo-phva-planear-hacer-verificar-actuar/
10. Online cardiac arrhythmia classification by means of circle maps analysis
implemented on an intelligent mitiaturized sensor, 9 de mayo de 2016, de
http://ieeexplore.ieee.org.bdigital.udistrital.edu.co:8080/stamp/stamp.jsp?tp=&arn
umber=4649485
11. Segmentation Based Encryption Method for Medical Images, 9 de mayo de 2016,
de
http://ieeexplore.ieee.org.bdigital.udistrital.edu.co:8080/stamp/stamp.jsp?tp=&arn
umber=6148405
12. Von Bertalanffy, Ludwig, (1989), Teoría General De Los Sistemas, Fundamentos,
desarrollo, aplicaciones, México DF, México: Fondo de Cultura Económica.
13. Sensores inteligentes y sus aplicaciones, 9 de mayo de 2016, de
https://www.parallax.com/sites/default/files/downloads/122-28029-Smart-
Sensors-Espanol-v1.0.pdf
14. Algoritmo de cifrado simétrico aes. Aceleración de tiempo de cómputo sobre
arquitecturas multicore, 9 de mayo de 2016, de
http://postgrado.info.unlp.edu.ar/Carreras/Especializaciones/Redes_y_Seguridad
/Trabajos_Finales/Pousa_Adrian.pdf
15. QUE ES SCRUM, 9 Mayo de 2017, de https://proyectosagiles.org/que-es-scrum/
16. Siemens Healthineers Digital Ecosystem, The benefits for Healthcare providers,
https://www.healthcare.siemens.com.co/healthineers-digital-ecosystem/digital-
ecosystem
17. Introduction to the Healthcare System,
http://www.patientnavigatortraining.org/healthcare_system/
18. Conozca de primera mano los nuevos desafíos asociados al sector de la salud,
https://www.redhat.com/es/technologies/industries/health-life-sciences
19. health care cloud, http://searchhealthit.techtarget.com/definition/health-care-
cloud
Anexo A
Manual Usuario
SISTEMA HEALTH CARE PARA EL MONITOREO DE ARRITMIAS CARDÍACAS
EN PERSONAS CON PROBLEMAS CARDÍACOS UTILIZANDO SERVICIOS
WEB.
Manual Usuario
Requerimientos mínimos hardware y software
Los requerimientos mínimos para el uso de la aplicación son:
Sistema Operativo
Android versión 4.2 o superiores
Procesador
Snapdragon 600 o equivalentes o superiores
RAM
512 MB
Almacenamiento Disponible
500 MB
Periféricos
Smartwatchs compatibles con Android wear versión 1 o superiores
Excepciones de uso.
Bluetooth inactivo
Si el bluetooth no está habilitado, debe ser habilitado para realizar las mediciones
de la frecuencia cardiaca.
Distancia smartwatch
Se debe mantener dentro de los límites de distancia el smartwatch con el teléfono
porque se puede perder la comunicación entre los dispositivos y puede evitar la
captura de las mediciones correctamente.
Teléfono apagado
Sí el teléfono está apagado el sistema no podrá funcionar, por eso es importante
mantener encendido nuestro teléfono.
Sin datos y saldo
Una de las condiciones del sistema es tener datos y saldo para permitir la
comunicación del sistema en caso de que no tenga saldo no se podrán enviar sms,
y si no tiene datos el sistema guarda los datos capturados mientras se conecta a
una red de datos (móvil, wi-fi).
Modo avión
Por lo general los dispositivos cuando entran en modo avión deshabilitan las redes
del teléfono, en estos casos el sistema se mantendrá funcionando para la captura
de datos siempre y cuando exista emparejamiento entre el smartwatch y el teléfono,
la captura de mediciones continuará sin problemas, por la funcionalidad de trabajar
sin red del sistema, a excepción del envío de correos electrónicos y sms a los
contactos.
Inicio
Al iniciar la aplicación lo primero que vemos es un splash
Figura 51, splash
Cuando termina encontramos la pantalla de login
Figura 52, formulario login
Sino contamos con usuario y contraseña debemos presionar en el botón
registrarse que nos llevara al módulo de registro
Figura 53, formulario registrarse
Debemos llenar todos los campos ya que son obligatorios y aceptar los términos y
condiciones, luego presionamos el botón enviar
Figura 54, formulario registrarse 2
Sí todo es correcto nos autentica en el sistema de una vez y nos muestra el menú
principal
Figura 55, menú principal
Podemos elegir cualquiera de las cuatro opciones
Módulo Medición
Nos permite medir nuestra frecuencia cardiaca en tiempo real, al momento de
ingresar se inicia la medición y al terminar nos muestra el resultado,
Figura 56, módulo medición
Resultado
Figura 57, módulo medición resultado
Podemos medir nuevamente presionando el botón volver a medir.
Módulo Histórico Mediciones
Este módulo muestra el listado de mediciones realizadas por el usuario y un
gráfico con la información de esta
Figura 58, módulo histórico mediciones
Módulo Histórico Alertas
Muestra el listado de las alertas del usuario y un gráfico con información de esta
Figura 59, módulo histórico alertas
Módulo Contactos
Encargado de los contactos a los cuales el usuario quiere notificar cuando sucede
una alerta, al ingresar muestra el listado de contactos del usuario la opción de
agregar un nuevo contacto o de eliminar los del listado de la tabla
Figura 60, módulo contactos
Si presionamos en el botón contacto nos aparece el formulario para agregar uno
nuevo
Figura 61, formulario agregar contacto
Llenamos los datos y presionamos en enviar
Figura 62, formulario agregar contacto 2
Nos muestra el listado de usuarios
Figura 63, listado de contactos
Si queremos eliminar un contacto debemos presionar la x en las opciones y nos
aparece una dialog pidiéndonos confirmación
Figura 64, eliminar contacto
Si presionamos que si borra el contacto y deja de recibir notificaciones
Figura 65, listado de contactos después de eliminar contacto
Excepciones de formularios
Login
Se solicitan dos campos el usuario que es el correo y la contraseña ambos son
obligatorios.
Figura 66, excepciones formulario login
Figura 67, excepciones formulario login 2
Para evitar estas excepciones se deben ingresar los dos campos correctamente,
sino generara error de usuario y contraseña:
Figura 68, excepciones formulario login 3
Registro
Se solicitan los campos de nombre, email, contraseña, dirección, identificación y
teléfono, todos los campos son obligatorios.
Figura 69, excepciones formulario registrarse
Para evitar esto se deben diligenciar todos los campos.
Contactos
En contacto es necesario ingresar el nombre, el correo, la dirección y el teléfono,
todos los campos son obligatorios.
Figura 70, excepciones formulario agregar contacto
Para que no se genere ningún error se debe ingresar toda la información.
Anexo B
Diagramas
de Secuencia y Actividad
9. DIAGRAMAS DE SECUENCIA Y ACTIVIDAD
9.1 Diagrama de Secuencia Menú Principal
Figura 71, Diagrama de Secuencia Menú Principal.
9.2 Diagrama de secuencia de Login
Figura 72, Diagrama de secuencia Login.
9.3 Diagrama Consulta Historial
Figura 73, Diagrama de secuencia Consultar Historial.
9.4 Diagrama Cerrar Sesión
Figura 74, Diagrama de secuencia Cerrar sesión.
9.5 Diagrama Cambiar Contraseña
Figura 75, Diagrama de secuencia Cambiar contraseña.
9.6 DIAGRAMA DE ACTIVIDAD REGISTRO
Figura 76, Diagrama de actividad Registro.
9.7 Diagrama De actividad Login / Logout
Figura 77, Diagrama de actividad Login / logout.
9.8 Diagrama actividad Gestionar usuario.
Figura 78, Diagrama Gestionar Usuario.
9.9 Diagrama de actividad Iniciar Medición
Figura 79, Diagrama de secuencia Iniciar Medición.
9.10 Diagrama de actividad Generar reporte
Figura 80, diagrama de actividad Generar reporte.
Anexo C
Términos y Condiciones
10. TÉRMINOS DE LICENCIA Y CONDICIONES
10.1. Introducción:
10.1.1 El presente acuerdo de uso entre el
"SISTEMA HEALTH CARE PARA EL MONITOREO DE ARRITMIAS
CARDÍACAS EN PERSONAS
CON PROBLEMAS CARDÍACOS UTILIZANDO SERVICIOS WEB" y el
usuario final.
10.1.2 El presente software está desarrollado con tecnologías libres, y es de
libre sin ánimos de lucro, el usuario final entiende que, para la prestación del
servicio, se deben generar una relación de confianza entre el usuario y la
aplicación, teniendo en cuenta que la aplicación requiere de unas mínimas
condiciones para su funcionamiento, así como se hace la aclaración de que
el sistema no solo está compuesto por software si no en parte por hardware,
hardware que no está incluido con la instalación de esta aplicación.
10.1.3 Esta aplicación está disponible solo para dispositivos Android con
sistema Android 4.4 y posteriores que soporte BLE (bluettooh low energy),
para el funcionamiento del sistema, aplicación requiere obtener las lecturas
mediante un smartwatch o un smartband compatible.
10.1.4 “Android" se refiere a la pila de software de Android para dispositivos,
disponible mediante el Proyecto de código abierto de Android, que se
encuentra en la siguiente URL: http://source.android.com/, según se
actualice de manera periódica.
10.1.5 Android bluettooh y demás tecnologías con propiedad de sus
respectivos dueños.
10.2 Aceptación de este Acuerdo de licencia
10.2.1 Para poder hacer uso del sistema el usuario debe aceptar los términos
de licencia.
10.2.2 Debe facilitar acceso al registro de sus datos personales y de las
mediciones que el sistema requiere para su funcionamiento, tales como
ubicación, número de teléfono, datos recopilados acerca de la frecuencia
cardiaca, acceso a la agenda telefónica, acceso a envío de mensajes de texto
y acceso a internet para el envío de la información.
10.2.3 No puede usar la aplicación con fines comerciales.
10.2.4 Usted acepta el tratamiento de su información personal y datos
clínicos sean usados para estadísticas y que estos puedan ser accedidos por
su personal médico y a quien usted autorice.
10.2.5 los presentes términos y condiciones no implican una relación o
contrato de prestación de servicio.
10.3 RENUNCIA DE GARANTÍAS
10.3.1 Usted comprende y acepta expresamente que cualquier riesgo que la
aplicación para enviar la información a los servicios web hace uso de internet
y que a pesar de que la información que viaja desde el dispositivo Android y
el (los) servicios web está cifrada, no es garantía absoluta de que no pueda
ser interceptada por terceros y leída.
10.3.2 El SISTEMA HEALTH CARE PARA EL MONITOREO DE ARRITMIAS
CARDÍACAS EN PERSONAS CON PROBLEMAS CARDÍACOS
UTILIZANDO SERVICIOS WEB expresa su renuncia de responsabilidad
respecto al acceso por parte de cibercriminales que pudieran acceder a la
información personal que usted acepta compartir para el funcionamiento del
sistema.
10.3.3 Se considera de que conocimiento general que la aplicación para su
funcionamiento debe permanecer activa en segundo plano, y que, por su
funcionamiento y recopilación constante de datos, es posible que se note una
diferencia en el consumo de batería de su dispositivo Android, además es de
aclarar que el bluetooth encendido consume batería.
10.4. Cambios en el Acuerdo de licencia
10.4.1 Los términos y condiciones del uso del sistema pueden cambiar en
cualquier momento sin previo aviso.
10.4.2 De cualquier forma, los datos suministrados por usted no serán
vendidos ni compartidos con ninguna otra entidad a menos que la ley así lo
requiera.
