sistema para la obtención de datos médicos básicos de un...
TRANSCRIPT
1
Sistema para la obtención de datos médicos básicos de un oximetro de pulso vía
bluetooth
Proyecto de grado
Daniel Ortiz Vega
Eliana Andrea Niño Pedraza
Universidad Distrital Francisco José de Caldas
Facultad de tecnología
Ingeniería en telemática
Bogotá
2
RESUMEN
Actualmente los centros médicos en Colombia brindan modelos de servicio de salud donde este
tipo de actividad se encuentra reglamentada por el ministerio de salud encargado velar por la
prestación de servicios de salud, en el cumplimiento de la ley 1122 de 2007 donde su objetivo
principal es garantizar el acceso a la calidad de los servicios. Optimizar el uso de los recursos
promover los enfoques de atención centrada en el usuario y lograr la sostenibilidad financiera de
las Instituciones Prestadoras de Servicios de Salud Públicas.
Algunas de las entidades que prestan este servicio en Colombia son Famisanar la cual tiene como
Subservicios a las organizaciones de Cafam, Colsubsidio, Cruz roja Colombia, Sanitas las cuales
proveen un portafolio de este servicio para proporcionar atención domiciliaria las 24 horas.
El presente trabajo pretende desarrollar una aplicación que permita apoyar algunos de los servicios
domiciliarios en relación con los datos generados por un dispositivo médico en este caso un
oxímetro. Dicha aplicación permitirá registrar los niveles de oxígeno en la sangre de una persona
y enviar las respectivas notificaciones a la entidad médica, asistente médico o contactos registrados
previamente. La aplicación permite transferir los datos desde el oxímetro hacia un dispositivo
móvil (celular) con sistema Android utilizando la tecnología bluetooth con BLE (Bluetooth Low
Energy). El documento describe el desarrollo de la aplicación bajo la tecnología bluetooth.
Adicionalmente se utilizaron tecnologías como FireBase Base de datos, FireBase notifications y
SMS y llamadas de un dispositivo a otro.
3
INTRODUCCIÓN
En el campo de la salud cada vez más se hace uso de la tecnologia móvil como una estrategia, por
lo cual según la organización mundial de la salud (OMS) indica que al menos un 83% de los paises
a nivel mundial han desarrollado una iniciativa de salud móvil en su país.Aun así la telemedicina
es un campo que aun requiere investigación donde se deben realizar pruebas sistemáticas sobre los
efectos en la salud.
Aun así lo que se busca es realizar mas investigaciones en este campo y suplir algunos
inconvenientes presentados en el sector de la salud; por lo cual este proyecto busca centrarse en
un area de este sector y atacar los problemas con el servicio de salud domiciliaria que es prestada
por algunos centros medicos en Colombia; para asi implementar una solucion tecnologica para
ello es fundamental que se tendrá en cuenta los modelos medicos que lo requieran. Algunos de
estos modelos son prioridad los cuales son para pacientes en cuidados intensivos en casa, somáticos
o con problemas que les generen alguna condición de discapacidad.
Para la aplicación de lo anteriormente mencionado se utilizan herramientas como los son firebase
para el manejo de información en la plataforma, ya que ofrece el servicio de base de datos no
relacional donde para el funcionamiento del mismo se realizó el consumo por medio de REST, éste
protocolo permite separar totalmente la interfaz de usuario del servicio y el almacenamiento de
datos, mejorando la escalabilidad y la portabilidad ya que permite comunicarse de manera
independiente. (QUORA, s.f.)
Además se utilizó el servicio de notificación de firebase el cual permite subscribir la aplicación y
personalizar esa mensajeria entre dispositivos móviles ya sea grupal o personal. Asi como tambien
el servicio SMS (Mensaje corto de texto) para realizar notificaciones de urgencia el paciente.
La comunicación directa entre el asistente y el centro médico se soluciona mediante el uso de la
tecnología BLE (Bluetooth Low Energy) donde con la sincronización con el dispositivo médico y
el móvil se incluyen y se transmiten los datos en tiempo real permitiendo conocer el verdadero
estado de salud de un paciente con cualquiera de los tres modelos mencionados anteriormente.
Por ende, la tecnología juega un papel importante en la salud en Colombia y a nivel mundial
facilitando procesos y procedimientos en los centros de salud médica.
4
ABSTRACT
In the field of health mobile technology is increasingly being used as a health strategy. According
to the World Health Organization, at least 83% of the countries worldwide have developed a mobile
health initiative in their Even telemedicine is a field that still requires research where systematic
testing of the effects of health must be carried out.
Even so, what is sought is to carry out more research in this field and to overcome some
disadvantages presented in the health sector; so this project seeks to focus on an area of this sector
and attack the inconveniences with the home health service that is provided by some medical
centers in Colombia to implement a technological solution for this is essential that will take into
account medical models that require it. Some of these models are priorities that are for patients in
intensive care at home, patients with somatic or with problems that cause them disability.
For the implementation of the aforementioned, free tools are used as the are firebase for the
information handling in the platform, since it offers the service of non-relational database where
for the implementation of the same the consumption was realized by means of REST, this protocol
allows to completely separate the user interface of the service and the storage of data, improving
the scalability and the portability since it allows to communicate independently (Firebase).
In addition also made use of the service of notification of firebase which allows to subscribe the
application and to personalize that messaging between mobile devices either group or personal.
As well as the SMS (Short text message) service to make urgent notifications to the patient.
The direct communication between the assistant and the medical center is solved through the use
of the technology BLE (Bluetooth Low Energy) where with the synchronization with the medical
device and the mobile are included transmit the data in real time and allows to know the true state
of a patient with any of the three models mentioned above.
Therefore, technology plays an important role in health in Colombia and worldwide facilitating
processes and procedures in medical health centers.
5
AGRADECIMIENTOS
“Si hiciéramos todas las cosas de las que somos capaces, literalmente
nos asustaríamos de nosotros mismos “
Thomas Edison
A mi familia y amigos en especial a Skate Rover
por acompañarme en este proceso, por último
y más importante a mí
compañera por creer y hacer posible este proyecto
Daniel Ortiz
Primero que todo a Dios por hacer esto posible y a mi familia
por acompañarme en cada paso que doy y finalmente a mi compañero
de equipo por ejecutar el proyecto y hacer posible esta gran idea.
Eliana Niño
1
CONTENIDO
RESUMEN ..................................................................................................................................... 2
1. Definición planeación y organización ................................................................................. 11
1.1. Título del trabajo ............................................................................................................ 11
1.2. Planteamiento del problema ........................................................................................... 11
1.3. Análisis del problema ..................................................................................................... 12
1.4. Soluciones actuales ......................................................................................................... 12
1.5. Objetivo general ............................................................................................................. 13
1.6. Objetivos específicos ....................................................................................................... 13
1.7. Alcances .......................................................................................................................... 13
2. Antecedentes ......................................................................................................................... 14
2.1 Jumper ................................................................................................................................. 14
2.2 MyOximeter ......................................................................................................................... 15
2.3 AngelSound .......................................................................................................................... 15
2.4 MyTermo .............................................................................................................................. 15
2.5 A&D ..................................................................................................................................... 15
2.6 MyFitnessCompanion .......................................................................................................... 15
2.7 Health Measure App (Android) ........................................................................................... 16
2.8 MyGlucoHealth .................................................................................................................... 16
3. Marco teórico ........................................................................................................................ 16
3.1 Tipos de aplicaciones móviles ........................................................................................ 16
3.1.1 Aplicación Nativa ........................................................................................................ 17
2
3.1.2 Aplicaciones Web Responsivas .................................................................................. 17
3.1.3 Aplicaciones Hibridas ................................................................................................. 17
3.2 Android ........................................................................................................................... 17
3.3 Android 4.3 Jelly Bean (API NIVEL 18) .............................................................................. 18
3.4 Bluetooth .............................................................................................................................. 18
3.5 Bluetooth Low Energy Android ........................................................................................... 18
3.5.1 Beneficios .......................................................................................................................... 19
3.5.2 GAP ................................................................................................................................... 19
3.5.3 Roles .................................................................................................................................. 19
3.5.4 Servicios y características ................................................................................................ 19
3.5.5 Perfil ................................................................................................................................. 20
3.5.6 Servicio ............................................................................................................................. 20
3.5.7 Características .................................................................................................................. 21
3.6 SQLite Android .................................................................................................................... 21
3.7 FireBase ............................................................................................................................... 22
3.8 Mensajería de FireBase ....................................................................................................... 22
3.9 Tele asistencia y telemedicina ............................................................................................. 23
4. Estudio de factibilidad ............................................................................................................ 23
4.1 Factibilidad técnica ............................................................................................................. 23
4.1.1 Dispositivo .................................................................................................................... 23
4.1.2 Canal de comunicaciones .............................................................................................. 24
4.1.3 Plataforma ..................................................................................................................... 24
4.1.4 Recurso Humano ........................................................................................................... 24
4.3 Factibilidad de gestión ........................................................................................................ 25
6. Fase de análisis ......................................................................................................................... 29
6.2 Definición de los objetivos del Product Backlog ................................................................. 29
6.3 Historias de usuario ............................................................................................................. 31
6.3.1 Historia de usuario 101 ................................................................................................. 31
6.3.2 Historia de usuario 102 ................................................................................................. 32
6.3.3 Historia de usuario 103 ................................................................................................. 33
3
6.3.4 Historia de usuario 104 ................................................................................................. 33
6.3.5 Historia de usuario 105 ................................................................................................. 34
6.3.6 Historia de usuario 106 ................................................................................................. 34
6.3.7 Historia de usuario 107 ................................................................................................. 35
6.3.8 Historia de usuario 108 ................................................................................................. 35
6.3.9 Historia de usuario 109 ............................................................................................... 36
6.3.10 Historia de usuario 110 ............................................................................................... 36
6.3.11 Historia de usuario 111 ............................................................................................ 37
6.3.12 Historia de usuario 112 ............................................................................................ 37
6.3.13 Historia de usuario 113 ............................................................................................... 37
6.4 Definición general del software ...................................................................................... 38
6.4.1 Definición de Sprint .................................................................................................... 38
6.4.2 Meta general software ................................................................................................. 38
6.4.3 Alcance general software ............................................................................................ 38
6.4.4 Vista de escenarios definido por ................................................................................... 38
6.4.5 Vista lógica definida por: .............................................................................................. 38
6.4.6 Vista de desarrollo definida por: ................................................................................... 39
7. Sprint Backlog: 1 ..................................................................................................................... 39
7.1 Ejecución del sprint ............................................................................................................. 40
7.1.1 Mockups: Vista Inicial .................................................................................................. 41
7.1.2 Mockups: Vista Representa el icono del paciente ......................................................... 42
7.2 Vista de escenarios .............................................................................................................. 43
7.2.1 Diagrama de casos de uso: Paciente registro ................................................................ 43
7.2.2 Paciente parámetros de configuración........................................................................... 43
7.2.3 Médico registro ................................................................................................................. 44
7.3 Vista Lógica ......................................................................................................................... 44
7.3.1 Diagrama de clases ........................................................................................................ 44
7.3.2 Diagrama de flujo definido en FireBase ....................................................................... 45
7.3.3 Diagrama de Contexto ................................................................................................... 45
7.4 Vista de Desarrollo ......................................................................................................... 46
7.5 Ejecución de tareas en este Sprint .................................................................................. 46
7.5.1 Mockups listado de centros médicos. ............................................................................ 46
7.5.2 Mockups para capturar los datos ................................................................................... 47
7.5.3 Mockups para el registro de los datos del asistente. ..................................................... 48
7.5.4 Mockups para registrar la fecha de nacimiento del paciente. ....................................... 48
4
7.6 Retroalimentación de este sprint. ........................................................................................ 49
7.7 Diagrama de Gantt Sprint ................................................................................................... 50
8.Sprint Backlog 2 ....................................................................................................................... 50
8.1 Ejecución del sprint ............................................................................................................. 51
8.2 Vista de escenarios .............................................................................................................. 52
8.2.1 Diagrama casos de uso .................................................................................................. 52
7.3 Vista Lógica ......................................................................................................................... 52
7.3.1 Diagrama de contexto.................................................................................................... 52
8.3 Vista de desarrollo ............................................................................................................... 53
8.3.1 Diagrama de componentes ............................................................................................ 53
8.3.2 Ejecución de las tareas del sprint Backlog ....................................................................... 54
8.4 Retroalimentacion del sprint ............................................................................................... 56
8.5 Diagrama de Gantt sprint .................................................................................................... 56
9. Sprint Backlog: 3 ..................................................................................................................... 56
9.1 Ejecución del Sprint ............................................................................................................. 57
9.1.1 Historia de usuario 105 .................................................................................................... 57
9.1.2 Caso de uso registrar oximetría ..................................................................................... 58
9.1.3 ID 1 ................................................................................................................................ 58
9.1.4 ID 2 ................................................................................................................................ 59
9.1.5 ID 3 ................................................................................................................................ 62
9.2 Historia de usuario 106 ....................................................................................................... 63
9.2.1 Caso de uso parámetros y alertas .................................................................................. 64
9.2.2 ID 1 ................................................................................................................................ 65
9.2.3 ID 2 ................................................................................................................................ 67
9.2.4 ID 3 ................................................................................................................................ 68
9.2.5 ID 4 ................................................................................................................................ 70
9.3 Historia de usuario 107 ....................................................................................................... 71
9.3.1 ID 1 ................................................................................................................................ 72
9.3.2 ID 2 ................................................................................................................................ 73
9.3.3 ID 3 ................................................................................................................................ 74
9.4 Retroalimentación del Sprint ............................................................................................... 76
9.5 Diagrama de Gantt .............................................................................................................. 77
5
10 Sprint Backlog: 4 .................................................................................................................... 77
10.1 Historia de usuario 108 ..................................................................................................... 77
10.1.1 ID 1 .............................................................................................................................. 78
10.1.2 ID 2 .............................................................................................................................. 80
10.1.3 ID 3 .............................................................................................................................. 81
10.1.4 ID 4. ............................................................................................................................. 81
10.2 Historia de usuario 109 ..................................................................................................... 81
10.2.1 ID 1 .............................................................................................................................. 82
10.2.2 ID 2 .............................................................................................................................. 84
10.2.3 ID 3 .............................................................................................................................. 85
10.2.4 ID 4 .............................................................................................................................. 87
10.3 Historia de usuario 110 ..................................................................................................... 87
10.3.1 ID 1 .............................................................................................................................. 88
10.3.2 ID 2 .............................................................................................................................. 90
10.3.3 ID 3 .............................................................................................................................. 90
10.3.4 ID 4 .............................................................................................................................. 91
10.4 Retroalimentación del sprint ............................................................................................. 91
10.5 Diagrama de Gantt ............................................................................................................ 92
11. Sprint Backlog: 5 ................................................................................................................... 92
11.1 Historia de usuario 111 ..................................................................................................... 92
11.2 Historia de usuario 112 ..................................................................................................... 95
11.3 Historia de usuario 113 ..................................................................................................... 97
11.3.2 ID 1 .............................................................................................................................. 98
11.3.3 ID 2 .............................................................................................................................. 98
11.4 Retroalimentación del sprint ............................................................................................. 99
11.5 Diagrama de Gantt ....................................................................................................... 100
12 Esfuerzo general ................................................................................................................. 100
12.1 Estimación de tiempo ....................................................................................................... 100
13.Descripción del sistema ........................................................................................................ 101
13.1 Implementación. ............................................................................................................... 101
13.2 La tecnología Bluetooth. .................................................................................................. 101
6
14. Gestión y correcciones de errores ...................................................................................... 103
14.1 Posibles Excepciones ....................................................................................................... 104
15. Recomendaciones ................................................................................................................. 105
15.1 Para el paciente que instale la aplicación ....................................................................... 105
15.2 Para el asistente del centro médico ................................................................................. 105
16. Anexo manual de usuario ver 1 .......................................................................................... 106
17. Anexo pruebas aplicación móvil ver 2 ............................................................................... 106
18. Conclusiones ......................................................................................................................... 107
19.Bibliografía ............................................................................................................................ 108
7
Tabla de ilustraciones
Ilustración 1 Componentes de BLE ________________________________________________________________ 20 Ilustración 2 Cronograma parte 1 _________________________________________________________________ 26 Ilustración 3 Cronograma Parte 2 _________________________________________________________________ 27 Ilustración 4 Cronograma Parte 3 _________________________________________________________________ 28 Ilustración 5:Aplicación Login ____________________________________________________________________ 41 Ilustración 6 Registro icono paciente ______________________________________________________________ 42 Ilustración 7.Inicio de botón asistente______________________________________________________________ 42 Ilustración 8.Caso de uso paciente registro _________________________________________________________ 43 Ilustración 9.Caso de parámetros de configuración ___________________________________________________ 43 Ilustración 10.Caso de parámetros de configuración __________________________________________________ 44 Ilustración 11 Diagrama de clases general __________________________________________________________ 44 Ilustración 12.Diagrama de clases general __________________________________________________________ 45 Ilustración 13.Diagrama de contexto registro _______________________________________________________ 45 Ilustración 14 Diagrama de desarrollo registro ______________________________________________________ 46 Ilustración 15 Listado centros médicos _____________________________________________________________ 47 Ilustración 16 Capturar datos inicio paciente ________________________________________________________ 47 Ilustración 17.Capturar datos personales paciente ___________________________________________________ 48 Ilustración 18.Capturar datos de fecha paciente _____________________________________________________ 48 Ilustración 19.Diagrama de Gantt sprint 1 __________________________________________________________ 50 Ilustración 20.Capturar de casos de uso bluetooth ___________________________________________________ 52 Ilustración 21.Capturar de casos de contexto Bluetooth _______________________________________________ 53 Ilustración 22.Capturar de casos de componentes bluetooth ___________________________________________ 53 Ilustración 23.Localización de archivos _____________________________________________________________ 54 Ilustración 24 Mockups tomar datos oximeter _______________________________________________________ 55 Ilustración 25.Tomar datos de pulso _______________________________________________________________ 55 Ilustración 26.Tomar datos de pulso bajo ___________________________________________________________ 56 Ilustración 27.Diagrama de Gantt sprint 2 __________________________________________________________ 56 Ilustración 28.Histórico de pulso paciente __________________________________________________________ 57 Ilustración 29.Caso de uso registrar oximetría _______________________________________________________ 58 Ilustración 30.diagrama de componentes registrar oximetría ___________________________________________ 59 Ilustración 31.Diagrama de contexto registrar oximetría ______________________________________________ 59 Ilustración 32 Diagrama componentes registro controlador oximetria ____________________________________ 60 Ilustración 33.Diagrama de contexto envió datos oximetría ____________________________________________ 60 Ilustración 34.Diagrama componentes lista médicos __________________________________________________ 61
8
Ilustración 35.Diagrama contexto listado médicos. ___________________________________________________ 61 Ilustración 36.Diagrama de componentes conexión estandarizada ______________________________________ 62 Ilustración 37.Diagrama de contexto validar conexión dispositivo _______________________________________ 63 Ilustración 38.Diagrama caso de uso registrar alerta _________________________________________________ 64 Ilustración 39 Alerta paciente estado ______________________________________________________________ 65 Ilustración 40.Diagrama componentes alerta paciente ________________________________________________ 65 Ilustración 41.Diagrama de contexto alerta paciente _________________________________________________ 66 Ilustración 42.Diagrama de componentes mensaje paciente ___________________________________________ 66 Ilustración 43.Diagrama de contexto mensaje paciente _______________________________________________ 67 Ilustración 44 Diagrama componentes mensaje SMS _________________________________________________ 67 Ilustración 45 Diagrama contexto mensaje SMS _____________________________________________________ 68 Ilustración 46.Configuración parámetros oximetría ___________________________________________________ 68 Ilustración 47.Diagrama de componentes notificación ________________________________________________ 69 Ilustración 48.Diagrama de componentes notificación ________________________________________________ 69 Ilustración 49.Diagrama de componentes mensaje y niveles alerta ______________________________________ 70 Ilustración 50.Diagrama de contexto mensaje y niveles de urgencía. _____________________________________ 71 Ilustración 51Diagrama de componentes envió mensaje _______________________________________________ 72 Ilustración 52.Diagrama de contexto valida conexión a móvil ___________________________________________ 73 Ilustración 53.Diagrama de componentes pulso mensaje ______________________________________________ 74 Ilustración 54 Diagrama de componentes número de contacto _________________________________________ 74 Ilustración 55 Mockups alerta a móvil _____________________________________________________________ 75 Ilustración 56.Diagrama de componentes alerta móvil ________________________________________________ 75 Ilustración 57.Diagrama de contexto alerta a móvil __________________________________________________ 76 Ilustración 58.Diagrama de Gantt sprint 3 __________________________________________________________ 77 Ilustración 59.Mockups listado de centros médicos ___________________________________________________ 79 Ilustración 60.Centros médicos ___________________________________________________________________ 79 Ilustración 61Diagrama de contexto ventanas registro ________________________________________________ 80 Ilustración 62.Clase médico ______________________________________________________________________ 81 Ilustración 63.Diagrama de componentes lista datos médico ___________________________________________ 83 Ilustración 64.Diagrama de contexto lista médico paciente ____________________________________________ 84 Ilustración 65Mockups registro pulso paciente ______________________________________________________ 85 Ilustración 66.Mockups registro estado pulso paciente ________________________________________________ 85 Ilustración 67.Diagrama de componentes registro paciente pulso _______________________________________ 86 Ilustración 68.Diagrama de contexto registro pulso paciente ___________________________________________ 86 Ilustración 69.Mockups datos paciente pulso ________________________________________________________ 87 Ilustración 70.Mockups Datos oximetría paciente ____________________________________________________ 89 Ilustración 71 Diagrama de componentes vista paciente_______________________________________________ 89 Ilustración 72.Diagrama de contexto datos pulso paciente _____________________________________________ 90 Ilustración 73 Pulso parámetros __________________________________________________________________ 90 Ilustración 74 Icono estado mal paciente ___________________________________________________________ 91 Ilustración 75 Icono estado bien paciente ___________________________________________________________ 91 Ilustración 76 Diagrama de Gantt sprint 4 __________________________________________________________ 92 Ilustración 77Diagrama de componentes vista registros gráfica _________________________________________ 93 Ilustración 78 Diagrama de contexto vista registros grafica ____________________________________________ 94 Ilustración 79 Mockups gráfica pulso ______________________________________________________________ 95
9
Ilustración 80 Entidad oximetría __________________________________________________________________ 96 Ilustración 81 Diagrama de componentes lista oximetría gráfica ________________________________________ 96 Ilustración 82 Diagrama de contexto gráfica ________________________________________________________ 97 Ilustración 83 Diagrama de caso de uso actualizar número contacto _____________________________________ 98 Ilustración 84 Diagrama de componentes número contacto ____________________________________________ 98 Ilustración 85 Diagrama de contexto contacto _______________________________________________________ 99 Ilustración 86 Diagrama de gantt sprint 5 _________________________________________________________ 100 Ilustración 87 Bluetooth BLE 4.0 _________________________________________________________________ 102 Ilustración 88 Servicio en Android ________________________________________________________________ 102 Ilustración 89 FireBase _________________________________________________________________________ 103 Ilustración 90 Consola de errores FireBase _________________________________________________________ 104
10
Tablas
Tabla 1 Versiones SQLite en Android _______________________________________________________________ 21 Tabla 2 Producto Backlog _______________________________________________________________________ 31 Tabla 3 Historia de usuario 100 ___________________________________________________________________ 32 Tabla 4 Historia de usuario 101 ___________________________________________________________________ 33 Tabla 5 Historia usuario 103 _____________________________________________________________________ 33 Tabla 6 Historia usuario 104 _____________________________________________________________________ 34 Tabla 7 Historia usuario 105 _____________________________________________________________________ 34 Tabla 8 Historia de usuario 106 ___________________________________________________________________ 34 Tabla 9 Historia de usuario 107 ___________________________________________________________________ 35 Tabla 10 Historia de usuario 108 __________________________________________________________________ 35 Tabla 11 Historia de usuario 109 __________________________________________________________________ 36 Tabla 12 Historia de usuario 110 __________________________________________________________________ 36 Tabla 13 Historia de usuario 111 __________________________________________________________________ 37 Tabla 14 Historia de usuario 112 __________________________________________________________________ 37 Tabla 15 Historia de usuario 113 __________________________________________________________________ 38 Tabla 16 Backlog 100 ___________________________________________________________________________ 40 Tabla 17 Backlog sprint 2 _______________________________________________________________________ 51 Tabla 18 sprint 3 historia 105 ____________________________________________________________________ 57 Tabla 19 sprint 3 historia usuario 106 ______________________________________________________________ 64 Tabla 20 sprint 3 historia de usuario 107 ___________________________________________________________ 72 Tabla 21 sprint 4 historia de usuario 108 ___________________________________________________________ 78 Tabla 22 sprint 4 historia de usuario 109 ___________________________________________________________ 82 Tabla 23 Sprint 4 historia de usuario 110 ___________________________________________________________ 88 Tabla 24 sprint 5 historia de usuario 111 ___________________________________________________________ 92 Tabla 25 Sprint 5 historia de usuario 112 ___________________________________________________________ 95 Tabla 26 sprint 5 historia de usuario 113 ___________________________________________________________ 97
11
1. Definición planeación y organización
1.1. Título del trabajo
Sistema para la obtención de datos médicos básicos de un oximetro de pulso vía Bluetooth
1.2. Planteamiento del problema
En la actualidad todas las instituciones que prestan el servicio de la salud cuentan con diferentes
modelos para prestar de una manera efectiva sus servicios entre estos se encuentra el servicio
a domicilio, el cual es brindado tanto servicios subsidiados (EPS, IPS) como por entidades
privadas (Servicios Complementarios y Medicina Propagada), este fomenta nuevas alternativas
de operación. (Colsanitas, s.f.)
Es así como en Bogotá están vigentes tres modelos de prestación de servicios domiciliarios que
se brindan en casos prioritarios, entre los cuales se encuentran: el programa de familias
protectoras de la salud y la vida desarrollada por la Secretaria de Salud, la hospitalización
domiciliaria en cuidados intensivos y por último el programa que atiende a pacientes crónicos
somáticos. (Agudelo, s.f.)
Teniendo en cuenta los modelos de salud mencionados anteriormente en la mayoría de los casos
estos son solicitados mediante una llamada del centro médico para que este proceda con la
visita; el centro médico es informado del estado del paciente solo mediante una descripción
telefónica de la persona que realizo la llamada; sin embargo muchas de estas visitas resultan
con diversos inconvenientes para la institución domiciliaria debido a que en ocasiones son
falsas alarmas y en realidad el paciente no se encontraba en mal estado por tal motivo puede
que hayan retrasado la visita a un paciente que si requería mayor prioridad. (SCIELO, s.f.)
En el momento que ocurre cualquier tipo de emergencia las instituciones que prestan el servicio
de salud deben determinar el estado del paciente, para lo cual utilizan un oximetro de pulso el
cual es un instrumento que permite conocer el nivel de oxígeno en la sangre y pulso arterial del
paciente, estos dispositivos se encuentran generalmente solo en centros médicos y en casos
muy críticos se le recomienda al usuario realizar la compra de este dispositivo.
Es así como se puede evidenciar que en las instituciones que prestan servicios domiciliaros de
salud, no cuentan con la información necesaria que en muchos casos les permite conocer de
forma oportuna el estado real de salud del paciente, y como consecuencia de ello se refleja una
12
necesidad de crear un medio fiable que supla dicha falencia en la prestación del servicio médico
domiciliario.
1.3. Análisis del problema
En el mercado actual existen muchas aplicaciones que realizan conectividad Bluetooth con
dispositivos médicos, algunas usan tecnología Bluetooth clásica la cual requiere
especificaciones del fabricante mientras que BLE tiene estandarizado todos estos protocolos
permitiendo realizar conexiones más rápidas y sencillas para la integración de dispositivos
médicos.
A nivel latinoamericano no se encuentra ninguna app disponible a nivel público que comparta
su información en tiempo real con un médico u otro usuario que pudiera atender o alertar sobre
fallos de salud en el paciente. Para estos casos se existe hospitalización domiciliaria
(Colsanitas, s.f.) y servicios de atención domiciliaria (Emermedica, s.f.) los cuales requieren de
móvilización de una persona capacitada con el suficiente equipo para evaluar a un paciente.
Nuestra aplicación al utilizar BLE podría conectar con diferentes oxímetros usando el mismo
protocolo de comandos para obtener información y así mismo llevar está a otros usuarios en
tiempo real sobre el estado del paciente en caso de que sea necesario pues de este modo tendría
un impacto en el cuidado de las personas.
1.4. Soluciones actuales
Como se habló en el planteamiento del problema la solución actual es ineficiente porque
requiere de hacer constantes visitas por parte de médicos y los equipos necesarios para hacer
control de este, lo cual implica gasto de recursos constantes, sin priorizar en atención medica
ni conocer las condiciones bajo las cuales un paciente requiere realmente de atención médica.
La solución propuesta brinda la capacidad de conocer el estado de un paciente de manera
remota, con el fin de dar asistencia personalizada y oportuna, eliminando el tiempo en que se
demora en llegar la asistencia domiciliaria ofreciendo un servicio eficiente de tele asistencia,
en el cual se optimizan costes y recursos, así como una oportuna atención para los pacientes
requieren algún tipo de asistencia.
Utilizando el concepto de mensajería PUSH la aplicación es capaz de alertar al doctor
encargado del paciente mediante una notificación, la cual permitirá acceder directamente a la
información tomada del paciente y registrar el tratamiento adecuado.
13
1.5. Objetivo general
Desarrollar una aplicación móvil para obtener datos médicos de un paciente por medio de un
oxímetro por medio de una conexión inalámbrica.
1.6. Objetivos específicos
Elaborar un subsistema de datos médicos el cual tendrá un perfil médico para visualizar su
información general y la de sus pacientes.
Implementar una conexión con un oximetro de pulso por medio de la tecnología 4.0
establecer una conexión Bluetooth siguiendo el estándar BLE, obteniendo los datos del
oxímetro en tiempo real (Spo2, Pulso, PI).
Implementar un subsistema de datos general el cual contenga el perfil del paciente donde
el podrá ver su información personal en tiempo real.
Implementar un sistema de mensajería FCM, la cual enviará la información a el medico
del paciente solicitado y su oximetría con el fin de obtener su estado general.
Definir niveles de alarmas con el fin de establecer alertas con la cual se deba informar al
centro de salud y por consiguiente ser atendido.
1.7. Alcances
Hacer uso de la tecnología BLE con el fin de abrir nuevas investigaciones a nivel académico
y general en Colombia.
Incentivar la investigación de nuevas tecnologías a nivel a académico en la universidad
Brindar una herramienta de tele monitoreo que pueda ser usada por todos los centros
médicos de todo tipo en el país.
Permitir el uso de la aplicación en todos los dispositivos Android que tengan Bluetooth
BLE 4.0
Permitir el uso de la aplicación en cualquier paciente que la requiera, por medio de la
parametrización de datos.
Permitir al paciente conocer su historial médico por medio de graficas comparativas que
muestre su estado.
14
Ser una herramienta de trabajo, para los servicios complementarios de salud que se presente
al hogar.
2. Antecedentes
Hoy en día existen varias tecnologías que permiten obtener datos de una persona o ser vivo, estos
tienen el nombre de Wearables. Basados en el concepto de IoT (Internet de las cosas) y IoU
(internet de los usuarios), estos a través de cualquier sensor que permita obtener algún parámetro
y enviarlo a través un canal de comunicaciones.
Uno de los canales de comunicaciones que ha surgido en este marco es la tecnología Bluetooth la
cual utiliza un canal inalámbrico de radio frecuencia de 2.4GHz. Esta tecnología ha llegado a su
versión 4.0 en la cual introduce la estandarización de comunicación con dispositivos de todo
incluyendo dispositivos médicos y ha sido implementada en la mayoría de PC, SmartPhones y
Tablets.
La implementación de bluetooth 4.0 sobre la mayoría de dispositivos ha permitido la creación
Wearables médicos que cumplen un estándar de comunicaciones haciendo posible la conexión
con dispositivos que retrasmitan esta información a la nube o almacenen a nivel local. Esto ha
permitido establecer técnicas de tele monitoreó en las cuales se envían los datos al centro médico
en tiempo real para obtener una perspectiva amplia y exacta de cómo se encuentra el paciente y
así realizar una prescripción, agendar un tratamiento o enviar asistencia médica. Esta información
permite rastrear datos de salud en el tiempo, con la posibilidad de ver tendencias y proporcionar
un sistema de alertas en caso de ser necesario.
A continuación, se definen algunas de las aplicaciones que hacen uso de la tecnología Bluetooth.
2.1 Jumper
Es un fabricante de dispositivos médicos, algunos integrados con conectividad bluetooth, tienen
publicadas 3 aplicaciones para dispositivos móviles las cuales se encuentran disponibles para
Estados Unidos y Asia. (Jumper Medical, s.f.)
15
2.2 MyOximeter
Consiste en una app disponible para Android y IOS la cual permite obtener los datos de cualquiera
de sus oximetro con conectividad bluetooth y realizar un seguimiento de este almacenando los
datos en el dispositivo. (Jumper, MyOximeter, s.f.)
2.3 AngelSound
Su aplicación insignia disponible para Android y IOS, la cual permite obtener datos vía bluetooth
de un ecógrafo el cual funciona por infrasonido obteniendo el latido del corazón, peso, día de
gestación del feto. (Jumper Medical, s.f.)
2.4 MyTermo
Consiste en una app disponible para Android y IOS la cual permite obtener los datos de cualquiera
de sus termómetros con conectividad bluetooth y realizar un seguimiento de este almacenando los
datos en el dispositivo. (Google, s.f.)
2.5 A&D
Es un fabricante de dispositivos médicos, algunos integrados con conectividad bluetooth, los cuales
integran sus dispositivos a diferentes apps médicas. (A&D Medical, s.f.)
2.6 MyFitnessCompanion
Permite realizar un seguimiento de ejercicios y realizar monitoreo de pulso por medio de
dispositivos médicos o con la palma de su mano. Una verdadera experiencia personalizada con
ajuste de objetivos, recordatorios, comentarios y un entrenador personal que estará a su lado
durante los ejercicios (myfitnesscompanion, s.f.)
16
2.7 Health Measure App (Android)
Disponible para Android proporciona una forma conveniente de registrar datos relacionados con
la salud. Realizar seguimiento de los registros médicos promedio de gráficos y tablas. (A&D
Medical, s.f.)
2.8 MyGlucoHealth
Es un fabricante de glucómetros integrados con tecnología bluetooth el cual tiene disponible una
APP para Android y IOS la cual realiza seguimiento a los registros de los dispositivos, también
este fabricante provee un kit de desarrollo (Bluetooth) . Para realizar la integración de sus
dispositivos, dado que estos no usan BLE, el fabricante tiene personalizada su comunicación.
(MyGlucoHealth, s.f.)
3. Marco teórico
La introducción de los Smart Phones (Teléfonos Inteligentes o Dispositivos Móviles) con sistemas
operativos con las mismas capacidades a los de un computador personal promedio, pero con GUI
(Interfaces de usuario) más sencillas e instintivas se ha creado un nuevo campo para los
desarrolladores de software el desarrollo de Apps (Software para dispositivos móviles). (BBC, s.f.)
El desarrollo de Apps consiste en la implementación de software para dispositivos móviles,
enfocándose en aprovechar todas las características de los Smart Phone, entre las cuales se
encuentra su conexión con periféricos vía Bluetooth e Internet, brindando “puentes” en los cuales
se puedan obtener los datos del periférico y enviarlos a la nube.
3.1 Tipos de aplicaciones móviles
Sin importar el tipo de negocio que se esté realizando, la implementación de una App se divide en
tres tipos, los cuales varían dependiendo que tipo de solución y que recursos estén disponibles para
la entidad que valla a realizar esta.
17
3.1.1 Aplicación Nativa
Las aplicaciones nativas son aquellas desarrolladas bajo un lenguaje y entorno de desarrollo
específico para un tipo de sistema operativo móvil (Android, IOS, Windows Phone, BlackBerry
OS), lo cual permite, un mejor control de flujo, operacional y aprovechamiento de hardware
brindado al usuario final aplicaciones estables y resistentes a fallos.
3.1.2 Aplicaciones Web Responsivas
Son aquellas desarrolladas usando lenguajes para el desarrollo web como HTML5 junto con un
framework para el desarrollo de aplicaciones web, como jquery mobile, Sencha, Kendo UI, los
cuales permiten que sus GUI, se adapten a la resolución de la pantalla desde la cual se esté
accediendo a la aplicación, permitiendo un acceso a todo tipo de dispositivos móviles sin importar
su sistema operativo.
Este tipo de aplicación es útil para el intercambio de información, sin embargo, no puede realizar
el uso de hardware de dispositivos móviles, ya que es accedida desde un navegador de internet.
3.1.3 Aplicaciones Hibridas
Este tipo de aplicaciones se desarrolla utilizando lenguajes de desarrollo web HTML5 y un
framework dedicado para la creación de aplicaciones híbridas, como lo es PhoneGap, Iconic,
Apache Cordova, entre otros los cuales brindan el desarrollo sobre lenguaje JavaScript.
La facilidad que brinda este tipo de desarrollo es que no hay un entorno especifico el cual hay que
utilizar para su desarrollo y la mayoría de olas herramientas son de uso gratuito, sin embargo,
requieren muchas veces su integración sobre aplicaciones nativas y no tienen un buen control sobre
el hardware ya que, al ser desarrollado para un funcionamiento en todos los dispositivos, este es
muy genérico y tienden a fallos cuando es usado.
3.2 Android
Android es un sistema operativo basado en el núcleo Linux. Fue diseñado principalmente para
dispositivos móviles con pantalla táctil, como teléfonos inteligentes, tablets o teléfonos; y también
18
para relojes inteligentes, televisores y automóviles. Inicialmente fue desarrollado por Android Inc.
(Google, Android, s.f.)
3.3 Android 4.3 Jelly Bean (API NIVEL 18)
Android 4.3 (JELLY_BEAN_MR2) es una actualización de la versión Jelly Bean que ofrece
nuevas características para los usuarios y desarrolladores de aplicaciones.
Puede utilizar las API de Android 4.3 se apoya en las versiones anteriores mediante la adición de
condiciones a su código que comprueban el nivel de API del sistema antes de ejecutar las API no
admitidas por la minSdkVersion. La versión Android 4.3 (API Nivel 18) introduce el soporte de
plataforma integrada para Bluetooth de baja energía y proporciona un API que las aplicaciones
pueden utilizar para detectar los dispositivos de consulta, servicios, características y leer / escribir.
En contraste con el clásico Bluetooth clásico versión (3.0), Bluetooth Low Energy (BLE) está
diseñado para proporcionar significativamente menor consumo de energía. Esto permite que las
aplicaciones Android al comunicarse con los dispositivos BLE tengan un menor consumo de
energía y mayor la eficiencia en transporte de comunicaciones con dispositivos tales como sensores
de proximidad, monitores de ritmo cardíaco, aparatos de fitness, etc. (Google, s.f.)
3.4 Bluetooth
Un dispositivo Bluetooth® utiliza ondas de radio en lugar de cables o cables para conectarse a una
un dispositivo. Un producto Bluetooth, como un auricular o un reloj, contiene un pequeño chip de
computadora con una radio Bluetooth y un software que lo hace fácil de conectar. El desarrollo de
conectividades soportadas por Bluetooth ha ido en aumento debido al uso cada vez mayor de
dispositivos móviles y la necesidad de que estos sean prácticos para los usuarios a llevado a integrar
la medicina dentro de los estándares de este tipo de conectividad.
3.5 Bluetooth Low Energy Android
La versión Android 4.3 (API Nivel 18) introduce el soporte de plataforma integrada para Bluetooth
de baja energía y proporciona un API que las aplicaciones pueden utilizar para detectar los
dispositivos de consulta, servicios, características y leer / escribir. En contraste con el clásico
Bluetooth clásico versión (3.0), Bluetooth Low Energy (BLE) está diseñado para proporcionar
significativamente menor consumo de energía. Esto permite que las aplicaciones Android al
comunicarse con los dispositivos BLE tengan un menor consumo de energía y mayor la eficiencia
19
en transporte de comunicaciones con dispositivos tales como sensores de proximidad, monitores
de ritmo cardíaco, aparatos de fitness, etc. (Google, API BLE, s.f.)
3.5.1 Beneficios
Bajo consumo de energía.
Tamaño reducido, ideal para dispositivos móviles y periféricos de todo tamaño
Con un menor costo que la tecnología Bluetooth clásica.
Tiene una mayor eficiencia en comunicación.
Permite la interoperabilidad entre varios dispositivos.
Está disponible a nivel mundial y su licencia no tiene costo.
3.5.2 GAP
GAP es un acrónimo para el perfil de acceso genérico, controla la conexión y la publicidad en
Bluetooth. GAP es lo que hace que el dispositivo sea visible para el mundo exterior, y determina
cómo dos dispositivos pueden (o no pueden) interactúan entre sí. (ADAFRUIT L. , s.f.)
3.5.3 Roles
GAP define dos roles para los dispositivos periféricos y centrales.
Periféricos: Los dispositivos periféricos son dispositivos pequeños, de baja potencia, de
recursos contrained que pueden conectarse a un dispositivo central mucho más potente.
Los dispositivos periféricos son cosas como un monitor de frecuencia cardíaca, una
tarjeta de proximidad activado BLE, etc.
Centrales: Suelen ser dispositivos móviles los cuales posen una mejor potencia de procesamiento
y memoria. (ADAFRUIT L. , s.f.)
3.5.4 Servicios y características
Las transacciones GATT BLE se basan en objetos anidados de alto nivel, denominados perfiles,
servicios y funciones que se pueden ver en la siguiente ilustración.
20
Ilustración 1 Componentes de BLE
3.5.5 Perfil
Un perfil no existe en realidad en el periférico BLE, solo es una colección predefinida de servicios
que ha sido compilado por cualquiera de Bluetooth SIG o por los diseñadores periféricos. El perfil
del ritmo cardíaco, por ejemplo, combina el servicio de frecuencia cardíaca y el dispositivo de
servicio de información. La lista completa de perfiles basados en el GATT adoptados.
3.5.6 Servicio
Los servicios se utilizan para romper los datos en entidades lógicas, y contienen trozos específicos
de datos llamados características. Un servicio puede tener una o más características, y cada servicio
se distingue de otros servicios por medio de una identificación numérica única llamada un UUID,
que puede ser de 16 bits (para adoptada oficialmente Servicios BLE) o 128 bits (para los servicios
personalizados).
Una lista completa de los servicios BLE aprobada oficialmente se puede ver en la página de
servicios del portal de desarrolladores de Bluetooth. Si nos fijamos en el Servicio de ritmo cardíaco,
por ejemplo, podemos ver que este servicio adoptado oficialmente tiene un UUID de 16 bits de
0x180D, y contiene hasta 3 característicos, aunque sólo la primera es obligatoria: Corazón
Medición de la frecuencia, sensor del cuerpo Ubicación y puntos de control del ritmo cardíaco.
21
3.5.7 Características
El concepto de nivel más bajo en las transacciones del GATT es la característica, que encapsula un
único punto de datos (aunque puede contener una serie de datos relacionados, tales como los
valores X / Y / Z de un acelerómetro de 3 ejes, etc.).
De manera similar a los servicios, cada característica se distingue a través de una de 16 bits o 128
bits UUID predefinido, y usted es libre de utilizar las características estándar definidos por el
Bluetooth SIG (que garantiza la interoperabilidad entre BLE y habilitado HW / SW) o definir sus
propias características personalizadas que sólo entiende su SW y periférica.
Las características son el punto principal que va a interactuar con los dispositivos periféricos BLE,
por lo que es importante entender el concepto. También se utilizan para enviar datos de vuelta al
BLE periférica, ya que también es capaz de escribir a la característica. Se puede implementar una
interfaz de tipo UART simple con un custom 'UART Service' y dos características, uno para el
canal TX y uno para el canal RX, donde una característica podría configurarse como de solo lectura
y el otro sería tener privilegios de escritura. (sig, s.f.)
3.6 SQLite Android
Android integra APIs para gestionar a base de datos de SQLite está disponible desde su primera
versión:
Android API SQLite
Versión
API 24 3.9
API 21 3.8
API 11 3.7
API 8 3.6
API 3 3.5
API 1 3.4
Tabla 1 Versiones SQLite en Android
22
Las aplicaciones usan SQLite para la creación de bases de datos privadas o con la creación de un
proveedor de contenido. La API que provee Android sirve para crear y administrar su propia base
de datos y almacenar contenido. (SQLITE, s.f.)
3.7 FireBase
Con la finalidad de que los desarrolladores pasen más tiempo en la aplicación que en los servicios
los cuales deben consumir esta, Google Cloud (Google, s.f.) creo servicios enfocados en el
BackEnd de aplicaciones móviles al que llamo Firebase.
Firebase permite realizar aplicaciones web y móviles sin programación en el servidor, de modo
que el desarrollo resulte más rápido y fácil. Ofrece en sus servicios: base de datos en tiempo real,
sincronización de datos, servicios de hosting y almacenamiento, testeos en laboratorio y no en
usuarios finales, reporte de errores, notificaciones a usuarios en el momento adecuado. (QUORA,
s.f.)
Además de sus funcionalidades incluye una consola de analítica similar a la que posee google cloud
que proporciona estadísticas sobre el uso de la aplicación y la participación que tienen los usuarios.
Dentro de esta analítica se pueden encontrar datos demográficos, conversión, seguimiento de hasta
500 eventos, lo que aporta un valor de entendimiento de comportamiento que ayudan a tomar
decisiones sobre la comercialización y mejora de la aplicación.
3.8 Mensajería de FireBase
FireBase Cloud Messaging (FCM) es una solución multiplataforma para él envió de notificaciones.
Permite él envió de notificaciones remotas a los usuarios y realizar mensajería instantánea con este
al permitir una transferencia de hasta 4KB en transferencia de datos de una aplicación. (Firebase,
s.f.) (FireBase, s.f.)
Él envió de notificaciones permite enviar un título, texto y claves como puede ser el ID de un
usuario o el campo de un Query que se quiera realizar, permitiendo así ejecutar procesos dentro de
una aplicación cuando este es enviado.
Utilizando API HTTPS y XMPP es posible realizar él envió de notificaciones desde cualquier
servidor o aplicación que pueda hacer consumo de estos servicios, permitiendo así establecer
arquitecturas descentralizadas.
23
3.9 Tele asistencia y telemedicina
La posibilidad de brindar herramientas que permitan a un médico atender o monitorear a un
paciente de una remota siempre se ha creído como una ficción o algo a lo que solo pueden acceder
personas con grandes recursos económicos. Lo cierto es que, a nivel mundial con el concepto de
internet de las cosas, se ha empezado a incluir en cualquier dispositivo posible una tarjeta de red
que permita enviar sus datos a través de una red. (Amazon Web Services, s.f.)
En el campo de la medicina se ha hecho enfoque en realizar diagnósticos y monitoreo de pacientes,
mediante dispositivos médicos especializados que puedan enviar esta información desde el lugar
donde se encuentra ubicado el paciente hasta el medico en el menor tiempo posible.
La tecnología Bluetooth Low Energy dentro de su estándar incluyo comunicación para obtener
datos de peso, presión arterial, sístole, diástole, pulso, nivel de oxigeno entre otros; permitiendo así
que los fabricantes de estos agreguen un módulo de conexión que use esta tecnología a los
dispositivos médicos con la posibilidad de enviárselos a un segundo que los pueda enviar a través
de la red, debido a que bluetooth no establece conexión directa con internet pues es una red punto
a punto. (Bluetooth, s.f.)
4. Estudio de factibilidad
4.1 Factibilidad técnica
Se requiere un dispositivo médico que pueda capturar el pulso y nivel de oxígeno en la sangre y
enviarlo a través de un algún medio de comunicación a un sistema que pueda almacenarlos en
tiempo real y notificar a un asistente medico en caso de ser necesario.
4.1.1 Dispositivo
En el mercado existe un oximetro de pulso, el cual se encarga calcular el nivel de oxígeno en la
sangre a través de un sensor infrarrojo que permite conocer la hemoglobina a través del color de
esta (aquella que tiene oxigeno es de un color rojo intenso) y con la frecuencia de este es capaz de
calcular el pulso generando una gran precisión en los datos obtenidos.
24
4.1.2 Canal de comunicaciones
Para un uso personal el canal de comunicaciones debe ser ampliamente usando en la actualidad
razón por la cual se contemplaron las opciones de Bluetooth 4.0, bluetooth tradicional y Wifi.
Debido a que Bluetooth 4.0 tiene un estándar específico para obtener datos de cualquier oximetro
que siga a este, lo consideramos más práctico dada la capacidad de conectarse a cualquier hardware
que cumpla el estándar, la móvilidad pues se puede enlazar a un dispositivo móvil para que este
envié los datos en el medio que esté utilizando en ese momento para acceder a internet. (Oximetro
de pulso estándar) (OXIMETRO MX, s.f.)
4.1.3 Plataforma
La plataforma Cloud de Firebase dentro de sus servicios ofrece una base de datos en tiempo real
optimizada para aplicaciones móviles, la cual es ideal para nuestra solución debido a los rápidos
tiempos de respuesta en consultas y manejo de información (FireBase, s.f.).
4.1.4 Recurso Humano
El equipo está conformado por dos desarrolladores con experiencia en metodologías ágiles y
desarrollo de software a la medida. Dentro de los perfiles hay estudiantes que tienen experiencia
en el desarrollo de aplicaciones móviles e integración con plataformas cloud lo cual permite la
realización del proyecto.
4.2 Factibilidad Financiera
Las herramientas a usar en el proyecto son de uso libre. El estándar de Bluetooth 4.0 está abierto y
documentado permitiendo establecer la conexión con un oximetro de pulso sin necesidad de pedir
ayuda al fabricante y solicitar un acuerdo de confidencialidad.
FireBase, aunque es una plataforma Cloud de pago por uso (PaaS), durante el desarrollo del
proyecto los recursos que provee en una cuenta libre serán capaces de cubrir este. Los equipos
médicos deben ser comprados, este financiamiento es por parte de los estudiantes, los cuales dentro
de sus ingresos pueden costearlos.
25
4.3 Factibilidad de gestión
Con la experiencia de los estudiantes en el desarrollo de software, se establece un esquema de
trabajo de metodología ágil en el cual es posible realizar una retro alimentación y monitoreo del
flujo del proyecto.
Con la finalidad de seguir buenas practicas, se implementa Scrum con procesos cortos que se
componente de actividades y a su vez de tareas predefinidas y esquematizadas por sprint los cuales
no son mayores a dos semanas de trabajo permitiendo conocer el estado del proyecto
constantemente y evaluándolo tomando como prioridad los requerimientos del cliente.
26
5.Cronograma
Ilustración 2 Cronograma parte 1
27
Ilustración 3 Cronograma Parte 2
28
Ilustración 4 Cronograma Parte 3
29
6. Fase de análisis
Personal encargado del desarrollo de la metodología
Product Backlog:
Eliana Niño, Daniel Ortiz
Sprint planning:
Integrates Daniel Ortiz, Eliana Niño
Sprint Backlog:
Eliana Niño, Daniel Ortiz.
Scrum master:
Daniel Ortiz
Product owner:
Eliana Niño
Equipo (Team):
Eliana Niño, Daniel Ortiz.
Sprint:
Eliana Niño, Daniel Ortiz
Retroalimentación:
Eliana Niño, Daniel Ortiz.
6.2 Definición de los objetivos del Product Backlog
PRODUCT BACKLOG
HISTORIA
ID
HISTORIA DE USUARIO ESTADO PRIORIDAD
Registro de usuario
100 El cliente requiere la realización de un
entorno donde con la contraseña del centro Realizada 5
30
médico asignado permita realizar la
inscripción a la aplicación.
Registro de datos usuario
101
El cliente requiere que los datos personales
tanto del paciente como del médico sean
almacenados en algún medio.
Realizada 5
Configurar datos de pulso
102
El cliente requiere poder configurar los
parámetros por los cuales se tomara el pulso. Realizada 3
Solicitud de cliente conexión Bluetooth
103
El cliente requiere que cuando la aplicación
sea instalada y cuando se proceda a la
apertura de la misma se solicite una conexión
a bluetooth.
Realizada 3
Realizar conexión vía bluetooth
104 El cliente requiere que la aplicación cuente
con la posibilidad de identificar el dispositivo
medico (Oximetro) y conectarse a la
aplicación móvil para poder tomar el pulso de
un paciente.
Realizada 5
Almacenar el estado actual del paciente
105 El cliente requiere que con los datos
capturados del pulso de un paciente este
pueda tener acceso a su estado actual
dependiendo de los niveles de gravedad del
mismo.
Realizada 5
Notificar estado salud paciente a asistente
106 El cliente requiere que una vez identificado
el estado de gravedad de un paciente este sea
notificado al médico desde la aplicación
móvil.
Realizada 5
Enviar mensaje SMS
107 El cliente requiere que además de una
notificación para informar al médico el Realizada 4
31
Tabla 2 Producto Backlog
6.3 Historias de usuario
6.3.1 Historia de usuario 101
101 Registro de usuario
ID DESCRIPCION ACTIVIDAD
1 Creación de un formulario donde pueda el
cliente pueda ingresar sus datos e inscribirse
para ingresar a la aplicación.
estado de salud del paciente también se pueda
enviar un SMS a el dispositivo del mismo.
Visualizar un listado de pacientes
109 El cliente requiere que en el perfil del médico
se pueda consultar los pacientes asociados a
el mismo.
Realizada 2
Detalle de paciente específicamente su pulso
110 El cliente requiere que el medico pueda ver
el detalle de un paciente en la cual se muestre
su historial de pulso.
Realizada 3
Visualizar una gráfica del histórico pulso
111 El cliente requiere que el médico y el
paciente puedan ver en una gráfica del
historial de pulso de cada paciente el cual
permita hacer un análisis de las oximetrías
del mismo.
Realizada 4
Historificar las oximetrías del paciente
112 El cliente requiere que el paciente pueda ver
un historial de sus oximetrías. Realizada 4
Editar número de contacto
113 El cliente requiere que el paciente pueda
editar un número de contacto. Realizada 1
32
2 Cargar un listado de centros médicos en los
cuales se pueda seleccionar a el que el
paciente pertenezca y por siguiente ingrese
la contraseña asignada a ese centro médico
la cual no puede ser repetible.
3 Registrar datos del paciente y almacenarlos
en una base de datos con el fin de que este
pueda acceder a la aplicación de forma
segura.
4 En el formulario de registro se deben
ingresar los siguientes datos:
Numero de cedula.
Nombres y Apellidos del paciente.
Descripción del paciente.
Fecha de nacimiento
5 Creación de una pantalla en la cual el
paciente o médico responsable podrá
configurar los parámetros por los cuales se
medirá los niveles de urgencia de un
paciente en el momento que decide tomar y
registrar su pulso.
6 En la pantalla de parámetros de
configuración para toma de oximetría se
deben registrar los siguientes parámetros:
Saturación de oxígeno, Pulsó alto, Pulso
bajo. Tabla 3 Historia de usuario 100
6.3.2 Historia de usuario 102
102 Registro de datos usuario
ID DESCRIPCION ACTIVIDAD
1 Crear un modelo de entidad el cual permita
identificar las entidades relacionadas en la
aplicación, definiendo atributos y
características de cada una de estas.
2 Definir una herramienta o motor de base de
datos que permita almacenar y establecer los
33
objetos para la creación e identificaron de la
información.
3 Creación de métodos que me permitan
Crear, actualizar la información de la
aplicación móvil.
Tabla 4 Historia de usuario 101
6.3.3 Historia de usuario 103
103 Configurar datos de pulso
ID DESCRIPCION ACTIVIDAD
1 Creación de una entidad que permita
realizar él envió de un mensaje SMS para
confirmar y alertar a el medico el estado de
un paciente.
2 El mensaje SMS debe contener los
siguientes datos:
Paciente que se realizó el pulso
Pulso.
Nivel de urgencia.
3 La aplicación debe asociar los niveles de
alerta con los parámetros de pulso
configurados en la aplicación.
4 Almacenar el histórico de alertas por cada
paciente el cual se podrá visualizar por el
médico y los pacientes que tenga asignados. Tabla 5 Historia usuario 103
6.3.4 Historia de usuario 104
104 Solicitud de cliente conexión Bluetooth
ID DESCRIPCION ACTIVIDAD
1 Creación de una pantalla que permita
visualizar una herramienta la cual realice la
comunicación entre el dispositivo de
oximetría y la aplicación móvil.
34
2 Definición y consolidación de una clase la
cual permita establecer la comunicación
entre el dispositivo (Oximetro) y la
aplicación móvil
3 Creación de una función que permita
identificar el estado de Bluetooth en el
dispositivo móvil y en caso de que no este
activo solicitar su activación. Tabla 6 Historia usuario 104
6.3.5 Historia de usuario 105
105 Realizar conexión vía bluetooth
ID DESCRIPCION ACTIVIDAD
1 Al momento de que el paciente toma su
pulso se debe registrar en base de datos.
2 Creación de una actividad en donde se
guarde un histórico del pulso del paciente.
3 La aplicación debe ser genérica para
dispositivos Android y los dispositivos de
oximetría. Tabla 7 Historia usuario 105
6.3.6 Historia de usuario 106
106 Almacenar el estado actual del paciente
ID DESCRIPCION ACTIVIDAD
1 Creación de una conexión mediante una
herramienta que permita enviar
notificaciones similares a las Push.
2 La notificación debe contener los siguientes
datos:
Paciente que se realizó el pulso
Pulso.
3 La aplicación debe asociar los niveles de
alerta con los parámetros de pulso
configurados en la aplicación.
4 Almacenar el histórico de alertas por cada
paciente el cual se podrá visualizar por el
médico y los pacientes que tenga asignados. Tabla 8 Historia de usuario 106
35
6.3.7 Historia de usuario 107
107 Notificar estado salud paciente a asistente
ID DESCRIPCION ACTIVIDAD
1 Creación de una entidad que permita
realizar él envió de un mensaje SMS para
confirmar y alertar a el medico el estado de
un paciente.
2 El mensaje SMS debe contener los
siguientes datos:
Paciente que se realizó el pulso
Pulso.
Nivel de urgencia.
3 La aplicación debe asociar los niveles de
alerta con los parámetros de pulso
configurados en la aplicación. Tabla 9 Historia de usuario 107
6.3.8 Historia de usuario 108
108 Enviar mensaje SMS
ID DESCRIPCION ACTIVIDAD
1 Creación de una actividad en la cual el
medico pueda registrarse.
2 Creación de una lista de centros médicos los
cuales el asistente pueda seleccionar al que
pertenece e ingresar el código asignado e
ingresar a el menú.
3 Los datos del asistente que se deben ingresar
en el momento del registro son los
siguientes:
Numero de documento
Nombres
Apellidos
4 Almacenar la información en una
herramienta que me permita visualizar la
información al momento de realizar las
consultar. Tabla 10 Historia de usuario 108
36
6.3.9 Historia de usuario 109
109 Visualizar un listado de pacientes
ID DESCRIPCION ACTIVIDAD
1 Creación de una actividad en la cual le
permita al asistente visualizar el registro de
los pacientes dentro de su centro médico.
2 En la lista de los pacientes se debe visualizar
lo siguiente:
Identificación y nombre del paciente.
Pulso más bajo y más alto del paciente.
3 Cuando un médico desee ver al detalle cada
paciente de la lista se debe visualizar el
histórico de pulsos del mismo.
4 La información a mostrar en la actividad
debe ser almacenada en una herramienta que
permita gestionarla. Tabla 11 Historia de usuario 109
6.3.10 Historia de usuario 110
110 Detalle de paciente específicamente su pulso
ID DESCRIPCION ACTIVIDAD
1 Creación de una actividad que permita a el
medico visualizar un historial de toma de
oximetrías de los pacientes.
2 En la lista del historial de un paciente se
debe poder visualizar la siguiente
información:
Pulso
SPO2 Saturación de oxígeno.
Índice de perfusión
3 Icono que visualice alerta o normalidad del
pulso del paciente.
4 Toda esta información debe ser gestionada
desde la herramienta que permita la gestión
para almacenarla. Tabla 12 Historia de usuario 110
37
6.3.11 Historia de usuario 111
111 Visualizar una gráfica del histórico pulso
ID DESCRIPCION ACTIVIDAD
1 Creación de una actividad la cual permita
visualizar una gráfica donde se compara los
históricos de las oximetrías.
2 La grafica debe ser lineal y debe permitir
comparar con las otras muestras de
oximetría tanto para el paciente como el
médico y los pacientes que tenga a su cargo
cuando vea el detalle.
3 Obtener los datos de base de datos en donde
se pueda
4 Toda esta información debe ser gestionada
desde la herramienta que permita la gestión
para almacenarla. Tabla 13 Historia de usuario 111
6.3.12 Historia de usuario 112
112 Historificar las oximetrías del paciente
ID DESCRIPCION ACTIVIDAD
1 Creación de una actividad en la cual el
paciente pueda ver el histórico de sus
oximetrías con el fin de guardar como una
historia general médica.
2 Dentro de los datos solicitados el paciente
podrá ver los siguientes:
Pulso
SPO2
Fecha de la toma de oximetría. Tabla 14 Historia de usuario 112
6.3.13 Historia de usuario 113
113 Editar número de contacto
ID DESCRIPCION ACTIVIDAD
38
1 Creación de una actividad la cual permita
editar un numero de contacto del paciente el
cual el medico podrá visualizar
2 Este número se podrá almacenar en la base
de datos general. Tabla 15 Historia de usuario 113
6.4 Definición general del software
6.4.1 Definición de Sprint
Para el manejo de los sprint en el desarrollo de este proyecto se tiene en cuenta que todos deben
cumplir con un alcance y una meta la cual está conformada de la siguiente manera:
6.4.2 Meta general software
Desarrollo de un aplicativo móvil que permita conectar y obtener datos de un dispositivo con
tecnología BLE el cual refleje la información de la oximetría o pulso de un paciente en el
dispositivo móvil y permita alertar a el centro médico además de llevar un control general del
estado general de un paciente.
6.4.3 Alcance general software
Conexión con dispositivo móvil permitiendo conocer a el medico el estado general del paciente,
dependiendo de unos parámetros de configuración previamente definidos.
En todos los sprint se tendrán en cuenta los diagramas generales para la identificación de roles,
procesos y funcionalidades de la cada actividad dependiendo el requerimiento de la historia de
usuario.
Para ello se van a desarrollar esquemas de diseño y análisis los cuales son los siguientes:
6.4.4 Vista de escenarios definido por
Agrupa escenarios de casos de uso y definición de roles principales
Diagrama de casos de uso.
6.4.5 Vista lógica definida por:
Modela elementos que soportan la funcionalidad del sistema este provee al usuario final desde el
punto de vista estático o dinámico.
Diagrama de contexto, Diagrama de clases
39
6.4.6 Vista de desarrollo definida por:
Esta describe la organización estética del software en su ambiente de desarrollo.
7. Sprint Backlog: 1
En este sprint lo que se busca desarrollar las actividades básicas para el registro de un paciente y
un médico, además del ingreso a la aplicación móvil donde se especifica con más detalle en el
Product Backlog las cuales poseen una prioridad de 5 pero las cuales son las base para poder
desarrollar y crear un modelo de base de datos estándar, el ID de estas historias de usuario son:
100,101,102 y que por definición se encuentran en las actividades 1,2,3,4.
Se toman en cuenta la realización de componentes y definición de arquitectura la cual se plantea
desde el punto inicial. Como también la definición de modelos UML que permiten definir el sprint
y las funcionalidades de las actividades.
Lo primero a realizar es la creación de usuarios tanto un paciente como un médico, los cuales deben
ser incluidos en un modelo de base de datos como entidades principales en la aplicación. El modelo
de base de datos se contempla bajo una versión 1.0.0.0 la cual está sujeta a cambios en las
posteriores ya que para esta entrega se desea contemplar las funcionalidades básicas como también
de la parte de codificación del build de software versión 1.0.0.0.
BACKLOG ID:100
ID Historia de
usuario
Tarea Prioridad Esfuerzo
100 Elección y creación de un modelo de base
de datos por objetos
1
Realización de vista de escenarios 1
Creación diagrama vista lógica para
definición inicial de funcionalidad registro
de usuarios (paciente y médico)
1
Definición de vista de desarrollo creación
de elementos que permitan codificar el
registro e ingreso a el aplicativo.
2
Creación y codificación del módulo de
registro en la que al ingresar los datos de
paciente permita ingresar a la pantalla de
inicio del mismo.
40
Sprint
ID 1
Backlog ID 100
Historias de U. 100,101,102
Responsables Eliana Andrea Niño, Daniel Ortiz Vega
Descripción de las
funcionalidades
La primera funcionalidad de este sprint consiste en la creación de
actividades dentro del aplicativo en las cuales permitirá el registro de
los pacientes, además de asociar la configuración inicial del pulso.
Como segunda funcionalidad es la creación de actividades las cuales
permitan el registro de un médico en el aplicativo móvil donde
inicialmente se almacenará este registro en base de datos teniendo en
cuenta la clave de acceso asignada por el médico.
Creación de funcionalidad donde permita guardar la fecha de
nacimiento de el paciente.
Tercera funcionalidad creación de una página de configuración de los
parámetros de oximetría en donde se podrán modificar
posteriormente. Tabla 16 Backlog 100
7.1 Ejecución del sprint
Para la ejecución de este sprint se tiene en cuenta la tabla número # que contiene el Backlog de este
sprint.
Creación y codificación del módulo de
registro en la que al ingresar los datos de
médico permita ingresar a la pantalla de
inicio del mismo.
2
Creación de Mockups de definición para
registro de paciente.
2
Creación de Mockups de definición para
registro de médico.
2
Definición de objetos y creación de
actividad para reflejar los pantallas.
2
101 Creación del código fuente que permitirá
el desarrollo de cada funcionalidad.
1
Definición de clases base para algunos
elementos
1
41
La primera tarea de desarrollar es lo que comprende almacenar los datos en el sistema. Para esto
se usa FireBase esta herramienta es una la cual está orientada a la creación de aplicaciones de alta
calidad ya que ofrece varios servicios dentro de este bases de datos en tiempo real realizar un
CRUD en tiempo real ya que los datos pueden ser refrescados y consultados en cualquier momento,
los datos se almacenan en formato JSON permitiendo un intercambio de datos ligero ya que maneja
estructura vectorial orientada a objetos y permite mayor flexibilidad y capacidad lógica a la base
de datos además que está orientada a los flujos de datos.
Con esta estructura inicial poder registrar tanto pacientes como doctores en la aplicación móvil
donde las actividades a desarrollar son un registro de paciente, registro de médico, configuración
de parámetros del oximetro dentro de los parámetros es importante tener en cuenta que: Se debe
capturar los niveles en cuanto a SPO2, pulso más bajo y el pulso más alto. Además de la fecha de
nacimiento del paciente.
En los siguientes Mockups se describe concretamente la ejecución del sprint.
7.1.1 Mockups: Vista Inicial
Ilustración 5:Aplicación Login
42
7.1.2 Mockups: Vista Representa el icono del paciente
Cuando el usuario ya ha seleccionado el centro médico al cual pertenece se debe indicar la
contraseña y dar clic en el icono al cual pertenece en este caso paciente.
Ilustración 6 Registro icono paciente
7.1.3 Mockups: Vista Representa el icono del doctor
Cuando el usuario ya ha seleccionado el centro médico al cual pertenece se debe indicar la
contraseña y dar clic en el icono al cual pertenece en este caso paciente.
Ilustración 7.Inicio de botón asistente
43
7.2 Vista de escenarios
7.2.1 Diagrama de casos de uso: Paciente registro
Ilustración 8.Caso de uso paciente registro
7.2.2 Paciente parámetros de configuración
Ilustración 9.Caso de parámetros de configuración
44
7.2.3 Médico registro
Ilustración 10.Caso de parámetros de configuración
7.3 Vista Lógica
7.3.1 Diagrama de clases
Ilustración 11 Diagrama de clases general
45
7.3.2 Diagrama de flujo definido en FireBase
Ilustración 12.Diagrama de clases general
7.3.3 Diagrama de Contexto
Ilustración 13.Diagrama de contexto registro
46
7.4 Vista de Desarrollo
Ilustración 14 Diagrama de desarrollo registro
7.5 Ejecución de tareas en este Sprint
7.5.1 Mockups listado de centros médicos.
La creación de una actividad o pantalla principal donde se puede visualizar un listado de los centros
médicos, para que tanto el paciente como el medico puedan seleccionar uno y luego elegir el que
perfil es de:
47
Ilustración 15 Listado centros médicos
7.5.2 Mockups para capturar los datos
La primera tarea es la realización de la actividad donde el usuario se pueda registrar es importante
capturar los siguientes datos.
Identificación del paciente
Nombres completos
Apellidos completos
Descripción: Este campo puede ser diligenciado con la edad, enfermedades pasadas o
situación actual del paciente.
Ilustración 16 Capturar datos inicio paciente
48
7.5.3 Mockups para el registro de los datos del asistente.
Creación de una actividad, que permita registrar los datos del asistente para ello previamente en la
actividad 1 se visualizan el listado de centros médicos relacionado con un perfil correspondiente.
Ilustración 17.Capturar datos personales paciente
En esta vista se coloca
La identificación del asistente
Nombres del asistente
Apellidos del asistente.
7.5.4 Mockups para registrar la fecha de nacimiento del paciente.
Creación de una actividad que permita seleccionar la fecha de nacimiento del paciente día de
nacimiento, mes y año, esta información es almacenada en la base de datos no relacional en el
objeto paciente.
Ilustración 18.Capturar datos de fecha paciente
49
7.6 Retroalimentación de este sprint.
En este sprint se realizó completamente, las tareas que se estimaron, dentro de las tareas las que
abarcaron mayor tiempo es la configuración de FireBase ya que para la creación y apertura de este
servicio, se requería el registro como desarrollador y la creación de un registro de aplicación para
poder consumir y que la API proporcionara los servicios Real time Database. En donde se
consolidó la instancia para el flujo de datos de la aplicación.
Luego se agregaron dichas librerías generadas por el servicio como google. services a la aplicación.
Para luego realizar el consumo de este servicio e incorporar las clases generadas.
Además, se realizó la creación de paquetes del negocio en la aplicación móvil las cuales se
distribuyen en las siguientes capas:
Datos.
Negocio
Red
Servicios
Utilidades
Vistas
En donde la capa de datos donde se almacena la información del servicio de FireBase y de base de
datos.
En el negocio se consolida la información del centro médico y las entidades del servicio de
FireBase como también el nivel de oximetría.
En la capa de red se distribuyen tres subcarpetas estas se dividen en bluetooth, celular, internet
donde en la de bluetooth se almacena el controlador que permite establecer la conexión bluetooth;
en la del celular se almacenan las entidades de llamada, SimGSM, SMS. En el internet Acceso
Internet donde comprueba si existe la conexión para poder descargar los datos del servicio de
FireBase.
En la capa de servicios se encuentran las librerías definidas en clases de los elementos más
importantes de FireBase, bluetooth y el servicio de notificación.
En utilidades se encuentran las funciones globales que abarcan toda la aplicación.
Por último, la capa de vistas donde se encuentran las clases definidas para cada actividad esta se
conecta directamente con la interface gráfica.
50
7.7 Diagrama de Gantt Sprint
Ilustración 19.Diagrama de Gantt sprint 1
8.Sprint Backlog 2
En este sprint se desarrollaron las actividades correspondientes a la historia de usuario 100 la cual
se subdivide en 1,2,3 donde las tareas a realizar son la creación de un objeto tipo clase que me
permita establecer la conexión entre el dispositivo móvil y el dispositivo oxímetro comprobando
que funciona en diferentes versiones del sistema operativo Android.
Se busca crear las actividades correspondientes a esta acción, como la integración de una interface
donde se pueda dar clic en un botón he inmediatamente establezca la conexión. Además de otra
actividad que me permita visualizar los datos capturados los cuales serán:
Spo2: nivel de saturación de oxígeno en la sangre
Pulso
PI
Los datos que se visualizan en la pantalla del móvil del nivel de saturación de oxígeno en la sangre,
por lo cual la imagen a mostrar se encuentra en dos estados: en mal estado o en buen estado.
Como segunda actividad a realizar se desea crear una función por la cual en el momento de que la
aplicación sea abierta solicite el servicio de bluetooth del dispositivo receptor y este se encuentre
habilitado esto para que en el momento de transfieran los datos de un medio a otro no exista
restricción.
BACKLOG ID:101
ID Historia de
usuario
Tarea Prioridad Esfuerzo
51
Tabla 17 Backlog sprint 2
8.1 Ejecución del sprint
Para la ejecución de este sprint la primera tarea a realizar es la implementación y consolidación de
la conexión Bluetooth donde se tendrán en cuenta las siguientes capas dentro de la solución del
aplicativo móvil.
Red: Se definirá el controlador de la tecnología BLE (Bluetooth Low Energy), aquí se podrán
parametrizar los elementos que valen la conexión y Scanear la información directa del dispositivo
de oximetría.
Servicios: En esta capa se tendrán implementan las funciones inherentes a la conexión directa con
el dispositivo móvil y el oximetro lo cual viene definido con la tecnología BLE donde para hacer
uso de esta se implementan las siguientes herramientas GAP y GATT los cuales son acrónimos del
perfil de acceso directo donde se controlan las conexiones de bluetooth, GAP es de gran
importancia en los dispositivos que manejan la tecnología bluetooth ya que es el que hace posible
la visualización del teléfono móvil a el exterior y determina la manera en que dos dispositivos
interactúan entre sí.
100 Obtener las librerías las cuales permiten
desarrollar la conexión entre el dispositivo
móvil y el oxímetro.
1
Definición de la clase donde se
desarrollaran todas las funciones que
hagan posible la conexión bluetooth
específicamente orientado a la tecnología
BLE.
1
Creación de una actividad o vista, donde el
usuario pueda dar clic en un botón que
dispare el trigger que permitirá lanzar el
evento de conexión con el dispositivo.
1
Definición de los elementos que
representaran los estados de un paciente.
2
101 Realizar una función que permita solicitar
al paciente que el servicio de bluetooth
debe estar habilitado para continuar a la
lectura de los datos.
1
Creación de una actividad o vista que
permita visualizar los datos capturado
desde el dispositivo móvil a el oxímetro.
1
52
Una vez con GAP esto sea posible se implementa la tecnología GATT esta define la forma en que
dos dispositivos BLE transfieren datos de ida y vuelta utilizando los servicios y características que
ofrecen se incorporan a el controlador del mismo para esto utiliza un protocolo de datos genérico
ATT.
Para ello cuando se logre la conexión directa entre ambos dispositivos como oxímetro y dispositivo
móvil entra a jugar GATT donde ya pasó por el proceso de registro GAP, para este tipo de conexión
se entiende que opera de manera exclusiva es decir que para un periférico que maneje la tecnología
BLE solo se puede conectar a un dispositivo central un teléfono a la vez que en este caso sería el
que el paciente designado tendrá para tomar su pulso.
8.2 Vista de escenarios
8.2.1 Diagrama casos de uso
Ilustración 20.Capturar de casos de uso bluetooth
7.3 Vista Lógica
7.3.1 Diagrama de contexto
53
Ilustración 21.Capturar de casos de contexto Bluetooth
8.3 Vista de desarrollo
8.3.1 Diagrama de componentes
Ilustración 22.Capturar de casos de componentes bluetooth
54
8.3.2 Ejecución de las tareas del sprint Backlog
Las librerías y algunos servicios directos de la tecnología BLE se consolidaron directamente de la
página de bluetooth Smart. Para poder obtener los servicios de GAND y GATT se incorporaron las
librerías necesarias.
Para la conexión en la capa de servicios se consolidaron funciones como validar la conexión
Bluetooth, verificar la conexión Bluetooth, scanear la conexión para utilizar el servicio GATT,
conectar el dispositivo y realizar también la desconexión del este.
Ilustración 23.Localización de archivos
8.3.2.1 Actividad tomar datos Oximeter
Se realiza la actividad que permite tomar los datos del paciente mediante un botón que a su vez
redirige a la página de los posibles estados del paciente, ya sea favorable o desfavorable.
55
Ilustración 24 Mockups tomar datos oximeter
Se capturan los datos generales del paciente visualizando su estado.
Ilustración 25.Tomar datos de pulso
Se realiza la vista general para poder iniciar la transferencia de datos del paciente a el móvil del
asistente asociado al paciente.
56
Ilustración 26.Tomar datos de pulso bajo
8.4 Retroalimentacion del sprint
Se realizo la clase que establece la conexion directa entre el dispostivo de oxímetria BLE
(Bluetooth Low Energy) conectando satisfactoriamente los servicios GATT y GAP, donde para
esta tarea en específico hubo mayor esfuerzo ya que se incorporaron servicios externos,ademas que
para esta conexión no se daba soporte directo con el medio
8.5 Diagrama de Gantt sprint
Ilustración 27.Diagrama de Gantt sprint 2
9. Sprint Backlog: 3
En este sprint se centra en el uso de la conectividad bluetooth con el dispositivo médico y en la
parametrización de datos que permitirá generar las alarmas en la aplicación. La conectividad
incluye la posibilidad de poderse conectar con cualquier oximetro que tenga el estándar de BLE.
La generación de alarmas incluye la creación de un mensaje SMS que permita a informar a una
57
persona elegida por el paciente (Este número podrá ser actualizado en cualquier momento),
adicional de una notificación FCM a un asistente asignado al registrarse en la aplicación.
La prioridad de este Backlog es alta pues corresponde al objetivo de la aplicación y al valor que
este tendrá en lis usuarios, corresponde a los ID 105, 106, 107 y que por definición se encuentran
en las actividades 1,2,3,4.
9.1 Ejecución del Sprint
9.1.1 Historia de usuario 105
HISTORIA DE USUARIO 105
ID DESCRIPCION ACTIVIDAD
1 Al momento de que el paciente toma su pulso se
debe registrar en base de datos.
2 Creación de una actividad en donde se muestre un
histórico del pulso del paciente.
3 La aplicación debe ser genérica para dispositivos
Android y los dispositivos de oximetría.
Tabla 18 sprint 3 historia 105
9.1.1.1 Mockups : Vista histórico de pulso paciente
En esta vista se muestra el listado de pacientes con la información de su pulso, tanto en el nivel
más alto como el más bajo de un historial de pulsos dependiendo de una fecha específica. Los
niveles de pulso se muestran en las barras de color azul. También se muestra el SPO2 que es el
nivel de oxígeno en la sangre.
Ilustración 28.Histórico de pulso paciente
58
9.1.2 Caso de uso registrar oximetría
Ilustración 29.Caso de uso registrar oximetría
9.1.3 ID 1
El primer paso a desarrollar es el registro de oximetrías en tiempo real. En el momento que el
dispositivo y la aplicación han confirmado una transferencia exitosa, este registro debe
almacenarse. Utilizando el valor de tiempo (Currentmills) el registro es almacenado en la base de
datos utilizando este valor como nodo con el fin de evitar repeticiones.
Haciendo uso de los servicios de FireBase, se incluye el registro en el nodo raíz oximetrías, en la
rama con el valor de identificación del paciente con el fin de realizar la asociación a este. Una vez
guardado el registro este estará disponible para ser consultado tanto por el paciente como por los
asistentes que pertenezcan al mismo centro médico.
59
9.1.3.1 Diagrama componentes 1
Ilustración 30.diagrama de componentes registrar oximetría
9.1.3.2 Diagrama contexto 1
Ilustración 31.Diagrama de contexto registrar oximetría
9.1.4 ID 2
El segundo paso a desarrollar es una vista en la cual el paciente pueda ver su histórico. Para esto
cuando el usuario selecciona la opción de registros la aplicación descargara estos utilizando los
métodos proveídos por FireBase, apuntando al nodo hijo que tiene como valor la identificación de
este.
60
9.1.4.1 Diagrama de componentes 2
Ilustración 32 Diagrama componentes registro controlador oximetria
9.1.4.2 Diagrama de contexto 2
Ilustración 33.Diagrama de contexto envió datos oximetría
En el caso del asistente, al iniciar se muestra la lista de pacientes que están en el centro médico. Al
hacer clic sobre cualquier registro de paciente, el asistente será re direccionado a una vista donde
encontrará los registros de todos del paciente seleccionado.
61
9.1.4.3 Diagrama de componentes 3
Ilustración 34.Diagrama componentes lista médicos
9.1.4.4 Diagrama de contexto 3
Ilustración 35.Diagrama contexto listado médicos.
62
9.1.5 ID 3
Como paso final, se realiza la construcción de una conexión estandarizada que permita realizar
conexión con cualquier oximetro que utilice tecnología bluetooth 4.0 con cualquier dispositivo
Android que soporte esta tecnología. Para realizar este requerimiento se realiza uso del API nativo
que tiene el sistema operativo para se realiza validación durante el escaneo que el dispositivo tenga
el patrón de nombre el cual contiene la palabra “Oximeter”, si este patrón coincide se realiza la
conexión.
Una vez realizada la conexión, se valida que el dispositivo contenga el valor de servicio 0x1822 el
cual corresponde a la transferencia de datos de oximetría, en caso que lo contenga es solicitado y
puede recibir los datos. En caso que no encuentre el servicio desconecta el dispositivo.
9.1.5.1 Diagrama de contexto 3
Ilustración 36.Diagrama de componentes conexión estandarizada
63
9.1.5.2 Diagrama de contexto 4
Ilustración 37.Diagrama de contexto validar conexión dispositivo
9.2 Historia de usuario 106
HISTORIA DE USUARIO 106
ID DESCRIPCION ACTIVIDAD
1 Creación de una conexión mediante una
herramienta que permita enviar
notificaciones similares a las Push.
2 La notificación debe contener los siguientes
datos:
Paciente que se realizó el pulso
Pulso.
64
3 La aplicación debe asociar los niveles de
alerta con los parámetros de pulso
configurados en la aplicación.
4 Almacenar el histórico de alertas por cada
paciente el cual se podrá visualizar por el
médico y los pacientes que tenga asignados.
Tabla 19 sprint 3 historia usuario 106
9.2.1 Caso de uso parámetros y alertas
Ilustración 38.Diagrama caso de uso registrar alerta
9.2.1.1 Mockups Vista alerta en móvil en caso de emergencia
En esta vista se muestra en el momento que se da click en la alerta con el número de identificación,
donde también se muestra el pulso actual tanto bajo como alto y el SPO2 nivel de oxígeno en la
sangre y por ultimo generar la atención donde se describe la atención del paciente y se atiende.
65
Ilustración 39 Alerta paciente estado
9.2.2 ID 1
El primer paso de esta actividad es implementar el SDK de FireBase y los métodos necesarios que
posee el API con el fin de poder recibir notificaciones. Una vez implementadas las notificaciones
se realiza la parametrización para que estas llamen una ventana emergente en la cual se debe
registrar el tratamiento que se le dé al paciente al momento de registrar una emergencia.
Ilustración 40.Diagrama componentes alerta paciente
66
9.2.2.1 Diagrama de contexto 5
Ilustración 41.Diagrama de contexto alerta paciente
9.2.2.2 Diagrama de contexto 6
Ilustración 42.Diagrama de componentes mensaje paciente
67
Ilustración 43.Diagrama de contexto mensaje paciente
9.2.3 ID 2
En este paso se debe incluir en la notificación los datos generados por el dispositivo médico. Para
esto se debe incluir un parámetro llamado “Data” en la notificación en el cual se le puede incluir
un objeto JSON, el cual será construido a partir de los datos obtenidos. Una vez enviada la
notificación en su interpretación se realiza la búsqueda del parámetro “Data” en el cual estarán los
valores del paciente que podrán ser mostrados.
Ilustración 44 Diagrama componentes mensaje SMS
68
9.2.3.1 Diagrama de contexto 7
Ilustración 45 Diagrama contexto mensaje SMS
9.2.4 ID 3
En esta actividad la aplicación debe guardar los parámetros bajos los cuales un paciente registra
una alarma, el nivel de oxígeno en la sangre y el pulso son los parámetros de salud pueden ser
monitoreados por lo cual se crean 3 variables:
Pulso Alto: Si el pulso del paciente supera este valor se genera una alarma.
Pulso Bajo: Si el pulso del paciente está por debajo de este valor se genera una alarma.
Oximetría: Si el valor de SPO2 (Nivel de oxigenación en la sangre)
Ilustración 46.Configuración parámetros oximetría
69
Si cualquiera de los 3 casos, sucede una alarma es generada y se envía la notificación.
9.2.4.2 Diagrama de componentes 8
Ilustración 47.Diagrama de componentes notificación
9.2.4.2 Diagrama de contexto 8
Ilustración 48.Diagrama de componentes notificación
70
9.2.5 ID 4
Utilizando las actividades realizadas en sprint anterior en la cual se permite a los pacientes y
médicos ver los registros de oximetrías almacenadas, se crean dos campos:
isUrgencia: Campo binario (1 urgencia o 0 si no es urgencia)
atención: Este campo de tipo texto, es donde se registra el tratamiento que del asistente al
paciente.
Todos los registros se muestran del mismo modo, pero aquellos que son una urgencia, tendrán un
símbolo rojo que los describe y a hacer clic sobre ellos es posible consultar el tratamiento que el
asistente ha registrado.
9.2.5.1 Diagrama de componentes 9
Ilustración 49.Diagrama de componentes mensaje y niveles alerta
71
9.2.5.2 Diagrama de componentes 9
Ilustración 50.Diagrama de contexto mensaje y niveles de urgencía.
9.3 Historia de usuario 107
HISTORIA DE USUARIO 107
ID DESCRIPCION ACTIVIDAD
1 Creación de una entidad que permita
realizar él envió de un mensaje SMS para
confirmar y alertar a el medico el estado de
un paciente.
2 El mensaje SMS debe contener los
siguientes datos:
Paciente que se realizó el pulso
Pulso.
72
3 La aplicación debe asociar los niveles de
alerta con los parámetros de pulso
configurados en la aplicación.
4 Almacenar el histórico de alertas por cada
paciente el cual se podrá visualizar por el
médico y los pacientes que tenga asignados.
Tabla 20 sprint 3 historia de usuario 107
9.3.1 ID 1
En este paso se divide en dos partes, una revisar que el dispositivo tenga efectivamente una tarjeta
SIM Card y red GSM con la finalidad de evitar errores en tiempo de ejecución. El segundo paso es
agregar una función que permita un enviar un SMS en segundo plano con la finalidad de que el
usuario no deba salir de esta.
9.3.1.1 Diagrama de componentes 10
Ilustración 51Diagrama de componentes envió mensaje
73
9.3.1.2 Diagrama de contexto 10
Ilustración 52.Diagrama de contexto valida conexión a móvil
9.3.2 ID 2
Para enviar un mensaje SMS se necesitan dos valores, un número de contacto y el mensaje a enviar.
Para enviar el mensaje se crea una plantilla. Del siguiente estilo:
"Hola , tengo un Spo2: " + oximetria.getSpo2() + "\n" + " y Pulso :" + oximetria.getPulse() +
"\n Neesecito Atencion Medica"
Donde getPulse(), es el valor del pulso y getSpo2 el nivel de saturación en la sangre.
74
9.3.2.1 Diagrama de componentes 11
Ilustración 53.Diagrama de componentes pulso mensaje
9.3.2.2 Diagrama de contexto 11
Ilustración 54 Diagrama de componentes número de contacto
9.3.3 ID 3
Utilizando el desarrollo realizado en la anterior actividad, cuando se genera una alarma se incluye
la función de envió de SMS, dentro de la validación de alarma usando la plantilla descrita en el id
anterior.
75
Ilustración 55 Mockups alerta a móvil
9.3.3.1 Diagrama de componentes 12
Ilustración 56.Diagrama de componentes alerta móvil
76
9.3.3.2 Diagrama de componentes 12
Ilustración 57.Diagrama de contexto alerta a móvil
9.4 Retroalimentación del Sprint
En este sprint se llevaron a cabo las tareas mencionadas, la primera a desarrollar fue el registro de
datos del paciente con el fin de obtener la información de su pulso luego de que el dispositivo de
oximetría transmita los datos a el dispositivo móvil, así mismo la implementación de un sistema
de comunicación implementando la tecnología SMS donde se dependiendo de los parámetros de
configuración del paciente se determina su estado de gravedad.
Se realizaron las actividades correspondientes a cada tarea dependiendo de la funcionalidad lógica,
para ello se desarrolló una vista donde se podía visualizar el histórico de pulsos correspondientes
a un paciente.
77
9.5 Diagrama de Gantt
Ilustración 58.Diagrama de Gantt sprint 3
10 Sprint Backlog: 4
En este Sprint se habilitan la visualización y actualización de registros. Para el manejo de datos se
usará una persistencia local por medio del uso de SharedPreferences que permitirá almacenar los
datos de cada usuario en su aplicación y luego relacionarlo con una base de datos global llamada
Base de datos en tiempo real, en la cual se almacenaran oximetrías, datos de pacientes y médicos
asociados a su respectivo centro médico.
La prioridad de este Backlog es media ya que corresponde a visualizar la información, permitiendo
a los asistentes y pacientes ver su histórico. Corresponde a los ID 108, 109, 110 y que por definición
se encuentran en las actividades 12,3.
10.1 Historia de usuario 108
HISTORIA DE USUARIO 108
ID DESCRIPCION ACTIVIDAD
1 Creación de una actividad en la cual el
asistente pueda registrarse.
2 Creación de una lista de centros médicos los
cuales el medico pueda seleccionar al que
78
pertenece e ingresar el código asignado e
ingresar a el menú.
3 Los datos del médico que se deben ingresar
en el momento del registro son los
siguientes:
Numero de documento
Nombres
Apellidos
4 Almacenar la información en una
herramienta que me permita visualizar la
información al momento de realizar las
consultar.
Tabla 21 sprint 4 historia de usuario 108
10.1.1 ID 1
Al iniciar sesión en la aplicación, al usuario se le solicita elegir el centro médico, la clave de este
mismo (Cada centro médico posee una clave asociada con la cual será posible realizar el registro)
y el rol que tendrá dentro de la aplicación. Para registrase una vez realizado esto por medio de
ventanas emergentes en el cual solicitara los datos necesarios.
79
Ilustración 59.Mockups listado de centros médicos
10.1.1.1 Diagrama de componentes 12
Ilustración 60.Centros médicos
10.1.1.2 Diagrama de componentes 12
80
Ilustración 61Diagrama de contexto ventanas registro
10.1.2 ID 2
La creación de centros médicos es lo primero que se debe realizar en la base de datos, razón por la
cual se realiza manual creando un JSON con los datos requeridos.
Nombre: Nombre centro medico
Pacientes: Array que contendrá la información de pacientes.
ClaveMedico: Clave para habilitar el registro como asistente
clavePaciente: Clave para habilitar el registro como paciente.
ID: ID del centro médico.
Medico: Array que contendrá la información de médicos.
En JSON luciría de la siguiente manera:
"Centro Medico" : [ {
"Pacientes" : {},
"claveMedico" : "sha1234",
"clavePaciente" : "sha1234",
"id" : 1,
"medico" : {},
"nombre" : "Famisanar" }
81
10.1.3 ID 3
El almacenamiento en la base de datos al ser jerárquica permite modelar datos como objetos razón
por la cual se crea la entidad Medico la cual contendrá los datos necesarios para el registro de estos,
los cuales a través de la clase Mensajes que hace el registro de datos por medio de ventanas
emergentes, realizara el registro como se visualiza en el ID anterior.
10.1.3.1 Diagrama de clases
Ilustración 62.Clase médico
10.1.4 ID 4.
FireBase es una plataforma BackEnd diseñada para aplicaciones en tiempo real pues su base de
datos esta optimizada para móviles, razón por la cual es posible hacer consultas, registros y
procesos en esta sin tener que recurrir a un gran recurso de red permitiéndola funcionar en una
aplicación como la nuestra. https://firebase.google.com/?hl=es-419
Dentro de los recursos que ofrece FireBase se encuentra una base de datos con un API REST
provisto de un SDK para Android nativo, en el cual podemos utilizar nuestro modelo de objetos
para construir esta base de datos utilizando una sintaxis JSON que nos permite un traspaso de
información rápido y seguro ya que este API se realiza sobre HTTPS y por medio de tokens.
10.2 Historia de usuario 109
HISTORIA DE USUARIO 109
ID DESCRIPCION ACTIVIDAD
1 Creación de una actividad en la cual le
permita el asistente visualizar el registro de
los pacientes dentro de su centro médico.
82
2 En la lista de los pacientes se debe visualizar
lo siguiente:
Identificación y nombre del paciente.
Pulso más bajo y más alto del paciente.
3 Cuando un médico desee ver al detalle cada
paciente de la lista se debe visualizar el
histórico de pulsos del mismo.
4 La información a mostrar en la actividad
debe ser almacenada en una herramienta que
permita gestionarla.
Tabla 22 sprint 4 historia de usuario 109
10.2.1 ID 1
Una vez registrado el usuario en la aplicación, este podría visualizar los pacientes dentro del centro
médico mediante una lista, que le mostrara los datos de cada uno.
10.2.1.1 Diagrama de componentes
83
Ilustración 63.Diagrama de componentes lista datos médico
10.2.1.2 Diagrama de contexto
84
Ilustración 64.Diagrama de contexto lista médico paciente
10.2.2 ID 2
Por medio del modelo provisto en la lista médico, se visualiza los datos de los pacientes y los
parámetros bajo los cuales este genera una alerta.
85
Ilustración 65Mockups registro pulso paciente
10.2.3 ID 3
En el momento que un médico selecciona un paciente en la lista, se le muestra el histórico de
registros de este. Los registros son traídos desde la base de datos de tiempo real, en la cual existe
un nodo con la identificación de cada paciente y dentro de este se encuentra el registro de cada
oximetría.
Ilustración 66.Mockups registro estado pulso paciente
86
10.2.3.1 Diagrama de componentes
Ilustración 67.Diagrama de componentes registro paciente pulso
10.2.3.2 Diagrama de contexto
Ilustración 68.Diagrama de contexto registro pulso paciente
87
10.2.3.3 Mockups: Vista lista de histórico de pulsos de paciente específico a asistente
Ilustración 69.Mockups datos paciente pulso
10.2.4 ID 4
Como se documenta en el SPRINT3, cada oximetría es guarda en la base de tiempo real, con el fin
de que los asistentes asociados al centro médico del paciente puedan ver esta en tiempo real.
10.3 Historia de usuario 110
Esta historia de usuario es complementaria a la 109, ya que en esta se especifica la forma en la cual
el asistente deberá ver la información de históricos de cada paciente.
HISTORIA DE USUARIO 110
ID DESCRIPCION ACTIVIDAD
88
1 Creación de una actividad que permita a el
medico visualizar un historial de toma de
oximetrías de los pacientes.
2 En la lista del historial de un paciente se
debe poder visualizar la siguiente
información:
Pulso
SPO2 Saturación de oxígeno.
Índice de perfusión
3 Icono que visualice alerta o normalidad del
pulso del paciente.
4 Toda esta información debe ser gestionada
desde la herramienta que permita la gestión
para almacenarla.
Tabla 23 Sprint 4 historia de usuario 110
10.3.1 ID 1
Al realizar clic sobre un paciente, la aplicación valida si este tiene registros para mostrar y re
dirige al usuario a una nueva actividad donde podrá ver el histórico.
89
Ilustración 70.Mockups Datos oximetría paciente
10.3.1.1 Diagrama de componentes
Ilustración 71 Diagrama de componentes vista paciente
90
10.3.1.2 Diagrama de contexto
Ilustración 72.Diagrama de contexto datos pulso paciente
10.3.2 ID 2
Por medio del modelo de vistas provisto, se muestran los datos de cada oximetría correspondientes
a (Fecha, SPO2, PI, Pulso y emergencia)
Ilustración 73 Pulso parámetros
10.3.3 ID 3
91
Se incluyen dos imágenes con el fin de visualizar cuando hay una urgencia, en caso de que esta sea
positiva se muestra un logo rojo y en caso de que no sea así esta se mostrara roja.
Ilustración 74 Icono estado mal paciente
Ilustración 75 Icono estado bien paciente
10.3.4 ID 4
Como se documenta en el SPRINT3, cada oximetría es guarda en la base de tiempo real, con el fin
de que los asistentes asociados al centro médico del paciente puedan ver esta en tiempo real.
10.4 Retroalimentación del sprint
Se creó una actividad dentro del login principal la cual permita el registro de un asistente médico
dependiendo del centro médico al cual fue afiliado.
En este sprint se desarrollaron las actividades de histórico de pulsos del médico a un paciente donde
se implementó una interface que permitiera visualizar cada detalle y fecha del paciente donde al
dar click sobre un ítem puede observar su información como también un histórico de pulsos
dependiendo el nivel en el que se encontraba. Dentro de la información que se visualiza en detalle
tenemos la siguiente:
Pulso
SPO2 Saturación de oxígeno.
Índice de perfusión
92
10.5 Diagrama de Gantt
Ilustración 76 Diagrama de Gantt sprint 4
11. Sprint Backlog: 5
Este último sprint se trata de completar las muestras y actualización de información con la
finalidad de brindar una aplicación funcional.
11.1 Historia de usuario 111
HISTORIA DE USUARIO 111
ID DESCRIPCION ACTIVIDAD
1 Creación de una actividad la cual permita
visualizar una gráfica donde se compara los
históricos de las oximetrías.
2 La grafica debe ser lineal y debe permitir
comparar con las otras muestras de
oximetría tanto para el paciente como el
asiste y los pacientes que tenga a su cargo
cuando vea el detalle.
3 Obtener los datos de base de datos en donde
se pueda
4 Toda esta información debe ser gestionada
desde la herramienta que permita la gestión
para almacenarla.
Tabla 24 sprint 5 historia de usuario 111
93
Lo primero a implementar son dos graficas una corresponde a los pulsos del paciente y la otra a los
datos de oximetría. Para realizar esto se implementa la Liberia MPAndroidChart que permite
implementar gráficas.
Al momento de recibir los registros, estos van generando una gráfica lineal que permite comparar
los datos de oximetrías, entre si al tiempo que se grafica el umbral bajo el cual se genera una gráfica
de los siguientes tipos:
SPO2: Aquí hay 2 funciones, una la de los registros del paciente y una constante al largo
del eje que representa el umbral bajo el cual se genera una alarma.
Pulso: Aquí hay 3 funciones, una muestra los registros del paciente y otras dos constantes
la cual representa el pulso bajo y el pulso alto bajo el cual se generan alarmas
11.1.1 Diagrama de componentes
Ilustración 77Diagrama de componentes vista registros gráfica
94
11.1.2 Diagrama de contexto
Ilustración 78 Diagrama de contexto vista registros grafica
11.1.3 Mockups: Vista grafica de oximetría
95
Ilustración 79 Mockups gráfica pulso
11.2 Historia de usuario 112
HISTORIA DE USUARIO 112
ID DESCRIPCION ACTIVIDAD
1 Creación de una actividad en la cual el
paciente pueda ver el histórico de sus
oximetrías con el fin de guardar como una
historia general médica.
2 Dentro de los datos solicitados el paciente
podrá ver los siguientes:
Pulso
SPO2
Fecha de la toma de oximetría.
Tabla 25 Sprint 5 historia de usuario 112
Dentro de la misma actividad que se muestran las gráficas, se incluye la vista de registros de
oximetría utilizando el modelo de lista oximetrías que permitirá mostrar los datos con el formato
indicado.
96
Ilustración 80 Entidad oximetría
Al recibir los registros estos pasan del modelo de FireBase al modelo local el cual puede ser
tratado por la lista para mostrarlo de la manera indicada.
11.2.1 Diagrama de componentes
Ilustración 81 Diagrama de componentes lista oximetría gráfica
97
10.2.2 Diagrama de contexto
Ilustración 82 Diagrama de contexto gráfica
11.3 Historia de usuario 113
HISTORIA DE USUARIO 113
ID DESCRIPCION ACTIVIDAD
1 Creación de una actividad la cual permita
editar un numero de contacto del paciente el
cual el medico podrá visualizar
2 Este número se podrá almacenar en la base
de datos general.
Tabla 26 sprint 5 historia de usuario 113
98
11.3.1 Diagrama casos de uso
Ilustración 83 Diagrama de caso de uso actualizar número contacto
11.3.2 ID 1
En la actividad de inicio dentro del menú se incluye un botón con el símbolo en el cual al
hacer clic sobre el mostrara el número de contacto actual de forma editable permitiéndole al
asistente editarlo en el momento que este desee.
11.3.3 ID 2
Una vez realizado el cambio, el número es actualizado en las preferencias locales y a nivel de
base de datos para ser consultado.
11.3.3.1 Diagrama de componentes
Ilustración 84 Diagrama de componentes número contacto
99
11.3.3.2 Diagrama de contexto
Ilustración 85 Diagrama de contexto contacto
11.4 Retroalimentación del sprint
En este sprint se implementaron actividades las cuales están relacionadas con el histórico de pulsos
de un paciente en donde a través de un complemento de Android se generan gráficos los cuales se
podrán visualizar por el asistente medico de un paciente y su paciente con el fin de visualizar el
análisis de la información y comparar respecto a otros posibles resultados.
Las gráficas que se implementaron fueron dos una para paciente y otra para asistente donde se
selecciona como elemento del menú de cada ítem.
100
11.5 Diagrama de Gantt
Ilustración 86 Diagrama de gantt sprint 5
12 Esfuerzo general
12.1 Estimación de tiempo
Cada integrante del equipo conto con 28 Horas semanales de trabajo, lo que implica un total
disponible de 56 horas semanales de todo el equipo. Para realizar el total del back log se
requirieron un total de 336 horas (6 meses de trabajo).
101
13.Descripción del sistema
13.1 Implementación.
El sistema creado tiene varios componentes, el primero de ellos es un sistema de datos médicos el
cual permite registrar pacientes y asistentes a centros médicos, para esto se realizó un modelo de
objetos sobre una base de altos de respuesta rápida en el cual un asistente puede ver la lista de
pacientes asociados al mismo centro médico de este y así mismo el histórico de oximetrías de cada
uno de ellos.
Debido a la velocidad de respuesta de la base de datos es posible implementar en los asistentes y
pacientes la visualización y posibilidad de actualizar sus datos, permitiéndoles conocer todos sus
históricos y demás registros en tiempo real.
En el modelo de objetos, los pacientes tienen 3 campos (Pulso alto, pulso bajo, nivel de saturación
en la sangre bajo) que permiten determinar una alarma. Cuando se registra una oximetría esta se
compara con los valores de los campos de la siguiente manera:
Pulso: Si el valor supera el campo de pulso alto o es menor al pulso bajo se generará una
alarma.
Saturación: Si el valor de la saturación es menor al campo nivel de saturación del paciente
se generará una alarma.
Cuando se genera una alarma, usando los API web de FCM, se consulta el campo IdMedico del
paciente el cual está asociado a la instancia de una aplicación y se envía la notificación Push a esta
instancia. Cuando el FCM llega a la aplicación de un paciente, si esta no se está ejecutando se
genera una notificación que tiene asociada una acción para escribir los datos médicos; en caso que
la aplicación este en ejecución se mostrara la ventana de atención.
13.2 La tecnología Bluetooth.
La conexión bluetooth, consiste de una red punto a punto es decir que no puede trasmitir a internet
de manera directa, pero gracias a la versión 4.0 de esta tecnología en la cual se incluye un estándar
abierto de conexión de varios dispositivos con un consumo de energía 10 veces menor a su versión
anterior es posible usarlo en un celular sin generar gasto de batería.
102
Ilustración 87 Bluetooth BLE 4.0
Para establecer una conexión, con el dispositivo se debe crear un servicio en Android. Un servicio
es un proceso continuó que se ejecuta sobre la aplicación de modo paralelo.
Ilustración 88 Servicio en Android
Este servicio contiene toda la conectividad BLE, en el cual la aplicación le envía los datos de
configuración (MAC del dispositivo a conectarse), servicios GATT a solicitar. El servicio responde
por medio de un BroadCast el cual es un canal de comunicación entre la aplicación y el servicio
ejecutado.
103
Los datos recibidos en este caso se obtienen cada 3ms (Milisegundos) lo cual permite evidenciar
una conexión en tiempo real con el dispositivo Android y el oximetro. Utilizando la trama
proveniente del oximetro se realiza una validación de datos, en el momento que estos sean válidos
la aplicación realiza el registro en base de datos con la finalidad de garantizar que se realice el
almacenamiento de datos fiables.
14. Gestión y correcciones de errores
Mediante la implementación de la plataforma crash reporting de Firebase es posible crear un
esquema de reporte de errores en la aplicación que nos ayude a establecer un esquema de control
frente la aplicación optimizando el tiempo en que se realiza alguna corrección.
Cuando en la aplicación se ejecuta una excepción no controlada, firebase reporta por medio de
correo electrónico con la traza del error. (Firebase, s.f.)
Ilustración 89 FireBase
Cuando se reporta un error, se revisa el error en la plataforma con el fin de obtener información
de en qué escenario se produjo esta:
104
Ilustración 90 Consola de errores FireBase
Una vez reconocido el error se debe proceder a corregirlo y probarlo en el mismo escenario que
se evidencio este con el fin de tener exactitud de que se ha corregido.
14.1 Posibles Excepciones
Permisos: En el caso de Android 6.0 los permisos de los usuarios se ejecutan sobre el tiempo
de ejecución, si el usuario los rechaza puede generase una ejecución en la conexión
bluetooth y mensajería SMS.
Base de datos: En caso de que no haya conexión, los registros pueden almacenarse de
manera local y subirse en el momento que la app detecte conexión a internet puede
sincronizar estos datos, sin embargo, pueden presentarse problemas durante este proceso.
Envió de mensajes SMS: El usuario debe permitir envió de mensajes SMS, de lo contrario
no se podrán enviar estos mensajes durante una alerta.
105
15. Recomendaciones
15.1 Para el paciente que instale la aplicación
Para la instalación de la aplicación es necesario contar con un dispositivo que tenga el
sistema operativo Android desde la versión 4.4 en adelante.
Contar con el espacio de memoria disponible para la instalación de la aplicación que es de
10 MB mínimo.
El dispositivo debe estar conectado a una red wifi o tener datos ya que la aplicación requiere
de conexión a internet.
El dispositivo debe contar con la tecnología bluetooth preferiblemente actualizado.
Al momento de abrir la aplicación se recomienda el Bluetooth activado.
Para poder realizar el proceso de notificación SMS es necesario contar con un servicio de
datos o saldo para que la aplicación pueda enviar los mensajes y el flujo de la aplicación se
dé correctamente.
Verificar que la información consignada sea correcta.
Limpiar caché del dispositivo en caso de que la información almacenada sea muy antigua.
Establecer un contacto directo verídico y fiable.
15.2 Para el asistente del centro médico
Para la instalación de la aplicación es necesario contar con un dispositivo que tenga el
sistema operativo Android desde la versión 4.4.
Contar con el espacio de memoria disponible para la instalación de la aplicación que es de
10 MB mínimo.
El dispositivo debe estar conectado a una red wifi o tener datos ya que la aplicación requiere
de conexión a internet.
El dispositivo debe contar con la tecnología bluetooth preferiblemente actualizado.
Para poder realizar el proceso de notificación SMS es necesario contar con un servicio de
datos o saldo para que la aplicación pueda enviar los mensajes y el flujo de la aplicación se
dé correctamente.
Verificar que la información consignada sea correcta.
Limpiar caché del dispositivo en caso de que la información almacenada sea muy antigua.
106
16. Anexo manual de usuario ver 1
17. Anexo pruebas aplicación móvil ver 2
107
18. Conclusiones
Con la implementación de tecnologías móviles en los servicios de salud se mejora de manera
considerable algunos de los procesos que se ejecutan diariamente y las condiciones como también
la experiencia del servicio de salud en toda la población en particular de aquellos que presentan un
estado de salud de mayor importancia por lo que requieran mayor atención.
Por lo cual en el ámbito de los servicios domiciliarios mejoraría de manera considerable la
comunicación entre el asistente asignado por el centro médico y el paciente a su cargo obteniendo
así su estado actual permitiendo generar un diagnostico en tiempo real y tomar una decisión asertiva
frente a la información que llegó desde el domicilio del paciente para realizar con la operación del
servicio también efectivamente.
Las tecnologías de la información y comunicación (TIC) permiten reforzar la calidad de un
procedimiento en cualquier ámbito no solo de la salud sino también de los otros campos
dependiendo de la necesidad y si es factible llegar aplicar dicha solución tecnológica. De manera
que para este proyecto se aplicaron tecnologías libres y que cumplieran con los requerimientos para
reforzar cada objetivo que se quería lograr además que es software libre lo cual permite brindar
una solución a la telemedicina a bajo costo.
Por todo lo anterior es un proyecto innovar y el sistema ofrece una alternativa a nivel local y
posiblemente se convierta en global ya que tecnologías como CLOUD que permite mayor
disponibilidad y seguridad de la información almacenada y la tecnología bluetooth implementada
que cada vez es más implementada y está en constante crecimiento debido a su alta capacidad para
transmitir de manera rápida la información y es manejable.
108
19. Bibliografía
A&D Medical. (s.f.). Aplicaciones y Software. Obtenido de
http://www.andonline.com/medical/wellness/apps_and_software/
A&D Medical. (s.f.). Health Measure App. Obtenido de
http://www.andonline.com/medical/products/details.php?catname=&product_num=Health_Me
asure_App_(Android)
A&D. (s.f.). Sitio Web. Obtenido de http://www.andonline.com/medical/
ADAFRUIT. (s.f.). Bluetooth Low Energy. Obtenido de GATT: https://learn.adafruit.com/introduction-to-
bluetooth-low-energy/gatt
ADAFRUIT. (s.f.). Bluetooth Low Energy. Obtenido de GAP: https://learn.adafruit.com/introduction-to-
bluetooth-low-energy/gap
ADAFRUIT, L. (s.f.). GAP. Obtenido de https://learn.adafruit.com/introduction-to-bluetooth-low-
energy/gap
ADAFRUIT, L. (s.f.). GATT. Obtenido de https://learn.adafruit.com/introduction-to-bluetooth-low-
energy/gatt
Agudelo, F. A.-D. (s.f.). Evaluación del Proceso de Priorización en. Obtenido de Evaluación del Proceso de
Priorización en: http://www.scielo.org.co/pdf/rsap/v11n2/v11n2a06.pdf
Amazon Web Services. (s.f.). AWS IOT. Obtenido de
https://aws.amazon.com/es/iot/?sc_channel=PS&sc_campaign=acquisition_CO&sc_publisher=g
oogle&sc_medium=english_iot_nb&sc_content=iot_e&sc_detail=iot&sc_category=iot&sc_segm
ent=153193541494&sc_matchtype=e&sc_country=CO&s_kwcid=AL!4422!3!153193541494!e!!g!
!i
BBC. (s.f.). BBC. Obtenido de http://www.bbc.co.uk/webwise/0/27488178
Bluetooth. (s.f.).
Bluetooth. (s.f.). BLE. Obtenido de https://www.bluetooth.com/what-is-bluetooth-technology/where-to-
find-it/medical-health
Bluetooth. (s.f.). Medical & Health. Obtenido de Bluetooth is Changing the Face of Healthcare:
https://www.bluetooth.com/what-is-bluetooth-technology/where-to-find-it/medical-health
Bluetooth SIG. (s.f.). specifications. Obtenido de assigned numbers:
https://www.bluetooth.com/specifications/assigned-numbers
109
CISCO. (s.f.). Entendiendo STP. Obtenido de http://www.cisco.com/c/en/us/support/docs/lan-
switching/spanning-tree-protocol/5234-5.html
Colsanitas. (s.f.). Porgrama de hospitalizacion domiciliaria. Obtenido de
https://portal.colsanitas.com/portal/web/clinica-colombia/programa-de-hospitalizacion-
domiciliaria-phd
Colsanitas. (s.f.). Salud. Obtenido de Programa de hospitalizacion domiciliaria :
https://portal.colsanitas.com/portal/web/clinica-colombia/programa-de-hospitalizacion-
domiciliaria-phd
cypress. (s.f.). Bluetooth Low Energy. Obtenido de Servicios y perfiles:
http://www.cypress.com/documentation/software-and-drivers/bluetooth-low-energy-ble-
profiles-and-services
Emermedica. (s.f.). Atencion Medica Domiciliaria. Obtenido de
https://www.emermedica.com.co/web/blog/portafolio/atencion-medica-domiciliaria-amd/
Entra Health. (s.f.). Inicio. Obtenido de http://entrahealth.com
Firebase. (s.f.). Cloud Messaging. Obtenido de Cloud Messaging:
https://firebase.google.com/docs/cloud-messaging/?hl=es-419
FireBase. (s.f.). Firebase Cloud Messaging. Obtenido de https://firebase.google.com/docs/cloud-
messaging/
Firebase. (s.f.). Firebase Crash Reporting. Obtenido de https://firebase.google.com/docs/crash/
FireBase. (s.f.). Firebase te ayuda a crear mejores apps para dispositivos móviles y hacer crecer tu
empresa. Obtenido de
https://firebase.google.com/?utm_source=google&utm_medium=cpc&utm_campaign=1001467
%20%7C%20Firebase*%20Brand%20GENERIC%20%7C%20Global%20%7C%20es%20%7C%20Des
k%2BTab%2BMobile%20%7C%20Text%20%7C%20BKWS%20%5B2017%5D&utm_term=%7Bkey
word%7D&gclid=Cj0KCQjwg7HPBR
Google. (s.f.). Android. Obtenido de https://www.android.com
Google. (s.f.). Android. Obtenido de Android: https://www.android.com
Google Android. (s.f.). Base de datos. Obtenido de SQLITE:
https://developer.android.com/reference/android/database/sqlite/package-summary.html
Google. (s.f.). Angel Sounds. Obtenido de Angel Sounds:
https://play.google.com/store/apps/details?id=cn.com.jumper.angelsounds.android_jumper_fe
at
110
Google. (s.f.). API BLE. Obtenido de https://developer.android.com/guide/topics/connectivity/bluetooth-
le.html#terms
Google. (s.f.). API BLE. Obtenido de API BLE:
https://developer.android.com/guide/topics/connectivity/bluetooth-le.html#terms
Google. (s.f.). Firebase. Obtenido de Cloud Messaging: https://firebase.google.com/docs/cloud-
messaging/?hl=es-419
Google. (s.f.). Google Cloud. Obtenido de https://cloud.google.com/?hl=es
Google. (s.f.). MyOximeter. Obtenido de MyOximeter:
https://play.google.com/store/apps/details?id=cn.com.jumper.oxygen
Google. (s.f.). MyThermo. Obtenido de MyThermo:
https://play.google.com/store/apps/details?id=com.jumper.mythermometer
Google. (s.f.). SQLITE Liberia . Obtenido de
https://developer.android.com/reference/android/database/sqlite/package-summary.html
Jumper. (s.f.). Angel Sound. Obtenido de
https://play.google.com/store/apps/details?id=cn.com.jumper.angelsounds.android_jumper_fe
at
Jumper Medical. (s.f.). Angelsounds Fetal Doppler. Obtenido de Angelsounds Fetal Doppler:
http://www.jumper-medical.com/enindex.php/pro_view/63
Jumper Medical. (s.f.). Sobre nosotros. Obtenido de Sobre nosotros: http://www.jumper-
medical.com/enindex.php/about
Jumper. (s.f.). MyOximeter. Obtenido de
https://play.google.com/store/apps/details?id=cn.com.jumper.oxygen
Jumper. (s.f.). MyThermometer. Obtenido de
https://play.google.com/store/apps/details?id=com.jumper.mythermometer
Jumper. (s.f.). Pagina Web Oficial. Obtenido de http://www.jumper-medical.com/enindex.php
Libelum. (s.f.). development. Obtenido de Zigbee networking guide:
http://www.libelium.com/development/waspmote/documentation/zigbee-networking-guide/
MT SYSTEMS. (s.f.). bluetooth le comparison. Obtenido de http://www.mt-
system.ru/sites/default/files/docs/documents/bluetooth_le_comparison.pdf
myfitnesscompanion. (s.f.). Learn More. Obtenido de http://www.myfitnesscompanion.com
MyGlucoHealth. (s.f.). Obtenido de http://myglucohealth.org/developers.html
111
NextU. (s.f.). Aplicaciones Web. Obtenido de https://www.nextu.com/blog/apps-nativas-vs-apps-
hibridas/
OMS. (s.f.). Colombia presenta experiencia en telemedicina y resalta como buena práctica en las
Américas. Obtenido de
http://www.paho.org/col/index.php?option=com_content&view=article&id=1726:colombia-
presenta-experiencia-en-telemedicina-y-resalta-como-buena-practica-en-las-
americas&Itemid=508
OXIMETRO MX. (s.f.). Cómo funciona el oxímetro de pulso. Obtenido de
https://oximetro.com.mx/blog/noticias/141-como-funciona-el-oximetro-de-pulso
QUORA. (s.f.). ¿Que es firebase? Obtenido de ¿Que es firebase?: https://www.quora.com/What-is-
firebase
QUROA. (s.f.). quora. Obtenido de What is Firebase: https://www.quora.com/What-is-firebase
RALUCA BUDIU. (s.f.). Mobile: Native Apps, Web Apps, and Hybrid Apps. Obtenido de Mobile: Native
Apps, Web Apps, and Hybrid Apps: https://www.nngroup.com/articles/mobile-native-apps/
SCIELO. (s.f.). Evaluación del Proceso de Priorización . Obtenido de
http://www.scielo.org.co/pdf/rsap/v11n2/v11n2a06.pdf
sig. (s.f.). Characteritics. Obtenido de GATT:
https://www.bluetooth.com/specifications/gatt/characteristics
SIG. (s.f.). SIG INTRODUCES BLUETOOTH LOW ENERGY WIRELESS TECHNOLOGY, THE NEXT GENERATION
OF BLUETOOTH WIRELESS TECHNOLOGY. Obtenido de SIG INTRODUCES BLUETOOTH LOW
ENERGY WIRELESS TECHNOLOGY, THE NEXT GENERATION OF BLUETOOTH WIRELESS
TECHNOLOGY: https://www.bluetooth.com/news/pressreleases/2009/12/17/sig-introduces-
bluetooth-low-energy-wireless-technologythe-next-generation-of-bluetooth-wireless-technology
SQLITE. (s.f.). Sitio Oficial. Obtenido de http://www.sqlite.org/about.html
SQLITE. (s.f.). SQLITE. Obtenido de Sobre nosotros: http://www.sqlite.org/about.htm