sistema para la obtención de datos médicos básicos de un...

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



3






6.3.9 Historia de usuario 109 ............................................................................................... 36


6.3.11 Historia de usuario 111 ............................................................................................ 37

6.3.12 Historia de usuario 112 ............................................................................................ 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.1 ID 1 .............................................................................................................................. 82

10.2.2 ID 2 .............................................................................................................................. 84

10.2.3 ID 3 .............................................................................................................................. 85

10.2.4 ID 4 .............................................................................................................................. 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.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):


Sprint:

Eliana Niño, Daniel Ortiz

Retroalimentación:


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


102 Registro de datos usuario


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


103 Configurar datos de pulso


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


104 Solicitud de cliente conexión Bluetooth


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


105 Realizar conexión vía bluetooth


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


106 Almacenar el estado actual del paciente


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:


Pulso.






médico y los pacientes que tenga asignados. Tabla 8 Historia de usuario 106

35


107 Notificar estado salud paciente a asistente





un paciente.


siguientes datos:


Pulso.

Nivel de urgencia.



configurados en la aplicación. Tabla 9 Historia de usuario 107


108 Enviar mensaje SMS


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


109 Visualizar un listado de pacientes


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


110 Detalle de paciente específicamente su pulso


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


111 Visualizar una gráfica del histórico pulso


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



para almacenarla. Tabla 13 Historia de usuario 111


112 Historificar las oximetrías del paciente



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


113 Editar número de contacto


38


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



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


HISTORIA DE USUARIO 105


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


Ilustración 34.Diagrama componentes lista médicos


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.


Ilustración 36.Diagrama de componentes conexión estandarizada

63


Ilustración 37.Diagrama de contexto validar conexión dispositivo

9.2 Historia de usuario 106



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:


Pulso.

64






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


Ilustración 41.Diagrama de contexto alerta paciente


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


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.


Ilustración 47.Diagrama de componentes notificación


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.


Ilustración 49.Diagrama de componentes mensaje y niveles alerta

71


Ilustración 50.Diagrama de contexto mensaje y niveles de urgencía.







un paciente.


siguientes datos:


Pulso.

72






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.


Ilustración 51Diagrama de componentes envió mensaje

73


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


Ilustración 53.Diagrama de componentes pulso mensaje


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


Ilustración 56.Diagrama de componentes alerta móvil

76


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


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.





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.


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


Ilustración 60.Centros médicos


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.




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.

https://firebase.google.com/?hl=es-419

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.


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


Ilustración 67.Diagrama de componentes registro paciente pulso


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.


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.



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



3 Icono que visualice alerta o normalidad del

pulso del paciente.



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


Ilustración 71 Diagrama de componentes vista paciente

90


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



92


Ilustración 76 Diagrama de Gantt sprint 4


Este último sprint se trata de completar las muestras y actualización de información con la

finalidad de brindar una aplicación funcional.





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



para almacenarla.


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


Ilustración 77Diagrama de componentes vista registros gráfica

94


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





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.


Ilustración 81 Diagrama de componentes lista oximetría gráfica

97


Ilustración 82 Diagrama de contexto gráfica





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.


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.


Ilustración 84 Diagrama de componentes número contacto

99


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


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

sistema para la obtención de datos médicos básicos de un...

Documents