Post on 19-Jul-2020
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS
COMPUTACIONALES
SISTEMA DE AUTOGESTIÓN DE LA SALUD PARA PACIENTES CON DIABETES Y ASMA, DESARROLLADO E IMPLEMENTADO EN
UNA PLATAFORMA ANDROID; CON MONITOREO DE UNA APLICACIÓN WEB EN PHP DIRIGIDA A LOS MÉDICOS
TRATANTES, ENFOCADO EN LA ADMINISTRACIÓN Y GESTIÓN DE LA BASE DE DATOS PARA LA
INTEGRACIÓN DE DATOS DESDE EL APLICATIVO MÓVIL ANDROID
HACIA EL MANEJADOR DE BASE DE DATOS MYSQL
PROYECTO DE TITULACIÓN
Previa a la obtención del Título de:
INGENIERO EN SISTEMAS COMPUTACIONALES
AUTOR:
HERMES RICARDO RODRÍGUEZ MUÑIZ
TUTOR:
Ing. Jimmy Sornoza Moreira, M. Sc.
GUAYAQUIL – ECUADOR 2017
REPOSITORIO NACIONAL EN CIENCIAS Y TECNOLOGÍA FICHA DE REGISTRO DE TESIS
TÍTULO Y SUBTÍTULO:
“Sistema de autogestión de la salud para pacientes con diabetes y asma, desarrollado e implementado en una plataforma Android; con monitoreo de una aplicación web en PHP dirigida a los médicos tratantes, enfocado en la administración y gestión de la base de datos para la integración de datos desde el aplicativo móvil Android hacia el manejador de base de datos MySQL”.
AUTOR: HERMES RICARDO RODRÍGUEZ MUÑIZ
REVISOR/TUTOR: ING. JIMMY SORNOZA MOREIRA, M.Sc. ING. FABRICIO SÁNCHEZ MORENO, M. SIG
INSTITUCIÓN: UNIVERSIDAD DE GUAYAQUIL
FACULTAD: CIENCIAS MATEMÁTICAS Y FÍSICAS
ESPECIALIDAD: INGENIERÍA EN SISTEMAS COMPUTACIONALES
GRADO OBTENIDO: TERCER NIVEL
FECHA DE PUBLICACIÓN:
2017 No. DE PÁGINAS 81 PÁGINAS
ÁREAS TEMÁTICAS: BASE DE DATOS
PALABRAS CLAVES / KEYWORDS:
ANDROID, MYSQL, INTEGRACIÓN, CAMPO, PHP, DATOS
RESUMEN/ABSTRACT: La aplicación HealthMonitor fue lanzada en su primera versión en mayo de 2017, para dispositivos móviles con sistema operativo Android; en esta fase de rediseño tendremos la facilidad de registrar nuestros datos sin tener acceso a internet todo el tiempo. Esta consiste en la integración de datos entre base de datos del aplicativo móvil hacia el manejador de base de datos MySQL. Radica en adoptar o agregar un nuevo campo a cada tabla para que pueda identificarse al momento de la migración de datos. La modificación permitirá a los usuarios tener la seguridad de que sus datos se guarden exitosamente una vez su conexión a internet se haya restablecido.
ADJUNTO PDF: SI NO
CONTACTO CON AUTOR: Teléfono: 0914256193 E-mail: hermes.rodriguezm@ug.edu.ec
CONTACTO CON LA INSTITUCIÓN:
Nombre: AB. JUAN CHÁVEZ ATOCHA
Teléfono: 2307729
E-mail: juan.chaveza@ug.edu.ec
X
II
CARTA DE APROBACIÓN DEL TUTOR
En mi calidad de Tutor del trabajo de titulación, “Sistema de autogestión de
la salud para pacientes con diabetes y asma, desarrollado e implementado
en una plataforma Android; con monitoreo de una aplicación web en PHP
dirigida a los médicos tratantes, enfocado en la administración y gestión de
la base de datos para la integración de datos desde el aplicativo móvil
Android hacia el manejador de base de datos MySQL“ elaborado por el Sr.
Hermes Ricardo Rodríguez Muñiz, Alumno no titulado de la Carrera de
Ingeniería en Sistemas Computacionales, Facultad de Ciencias
Matemáticas y Físicas de la Universidad de Guayaquil, previo a la
obtención del Título de Ingeniero en Sistemas, me permito declarar que
luego de haber orientado, estudiado y revisado, la Apruebo en todas sus
partes.
Atentamente
Ing. Jimmy Sornoza Moreira, M. Sc.
TUTOR
III
DEDICATORIA
Dedico este trabajo de titulación a mi madre, que me ha apoyado en todo momento para continuar con este gran paso, a mi tía Blanca Rodríguez por su incondicional apoyo en cada etapa de mis estudios y, a todas las personas amadas que ya no están con nosotros que formaron parte de nuestras vidas y que de alguna forma permitieron continuar con esta etapa de mi vida.
IV
AGRADECIMIENTO
Quiero agradecer a Dios todo poderoso, por permitirme llegar hasta donde estoy, porque sin Él, nada sería posible. A mi madre, que siempre está ahí, a mis tías Blanca y Leonor por brindarme ese apoyo incondicional. A mi amiga Cony Vélez Suárez, por su inmensa ayuda, dedicación y ánimos. A todos mis familiares, amigos y compañeros que de alguna manera estuvieron allí ayudándome a hacer posible este trabajo de titulación.
V
TRIBUNAL PROYECTO DE TITULACIÓN
Ing. Eduardo Santos Baquerizo, M.Sc. DECANO DE LA FACULTAD
CIENCIAS MATEMÁTICAS Y FÍSICAS
Ing. Jimmy Sornoza Moreira, M.Sc. PROFESOR TUTOR DEL PROYECTO
DE TITULACIÓN
Ing. Abel Alarcón Salvatierra, M.Sc. DIRECTOR (E)
CISC
Ing. Fabricio Sánchez Moreno, M.SIG PROFESOR REVISOR DEL ÁREA-
TRUBUNAL
Ab. Juan Chávez A. SECRETARIO
VI
DECLARACIÓN EXPRESA
“La responsabilidad del contenido de este Proyecto de Titulación, me corresponden exclusivamente; y el patrimonio intelectual de la misma a la UNIVERSIDAD DE GUAYAQUIL”
Autor:
HERMES RICARDO RODRÍGUEZ MUÑIZ
0914256193
VII
.
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS
COMPUTACIONALES
SISTEMA DE AUTOGESTIÓN DE LA SALUD PARA PACIENTES CON DIABETES Y ASMA, DESARROLLADO E IMPLEMENTADO EN
UNA PLATAFORMA ANDROID; CON MONITOREO DE UNA APLICACIÓN WEB EN PHP DIRIGIDA A LOS MÉDICOS
TRATANTES, ENFOCADO EN LA ADMINISTRACIÓN Y GESTIÓN DE LA BASE DE DATOS PARA LA
INTEGRACIÓN DE DATOS DESDE EL APLICATIVO MÓVIL ANDROID
HACIA EL MANEJADOR DE BASE DE DATOS MYSQL
Proyecto de Titulación que se presenta como requisito para optar por el
título de INGENIERO EN SISTEMAS COMPUTACIONALES
Autor: HERMES RICARDO RODRÍGUEZ MUÑIZ
C.I.0914256194
Tutor: Ing. Jimmy Sornoza Moreira, M.Sc.
Guayaquil, diciembre de 2017
VIII
CERTIFICADO DE ACEPTACIÓN DEL TUTOR
En mi calidad de Tutor del proyecto de titulación, nombrado por el Consejo Directivo de la Facultad de Ciencias Matemáticas y Físicas de la Universidad de Guayaquil.
CERTIFICO:
Que he analizado el Proyecto de Titulación presentado por el estudiante HERMES RICARDO RODRÍGUEZ MUÑIZ, como requisito previo para optar por el título de Ingeniero en Sistemas Computacionales cuyo problema es: “Sistema de autogestión de la salud para pacientes con diabetes y asma, desarrollado e implementado en una plataforma Android; con monitoreo de una aplicación web en PHP dirigida a los médicos tratantes, enfocado en la administración y gestión de la base de datos para la integración de datos desde el aplicativo móvil Android hacia el manejador de base de datos MySQL” Considero aprobado el trabajo en su totalidad.
Presentado por:
Hermes Ricardo Rodríguez Muñiz Cédula de ciudadanía N° 0914256193
Tutor: Ing. Jimmy Sornoza Moreira, M. Sc.
Guayaquil, diciembre de 2017
IX
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
Autorización para Publicación de Proyecto de
Titulación en Formato Digital 1. Identificación del Proyecto de Titulación Nombre Alumno: Hermes Ricardo Rodríguez Muñiz Dirección: Guasmo Sur Teléfono: 0984902451 E-mail: hermes.rodriguezm@ug.edu.ec
Facultad: Ciencias Matemáticas y Físicas Carrera: Ingeniería en Sistemas Computacionales Proyecto de titulación al que opta: Ingeniero en Sistemas Computacionales Profesor tutor: Ing. Jimmy Sornoza Moreira, M.Sc.
Título del Proyecto de titulación: Sistema de autogestión de la salud para pacientes con diabetes y asma, desarrollado e implementado en una plataforma Android; con monitoreo de una aplicación web en PHP dirigida a los médicos tratantes, enfocado en la administración y gestión de la base de datos para la integración de datos desde el aplicativo móvil Android hacia el manejador de base de datos MySQL.
Tema del Proyecto de Titulación: Android, MySQL, integración, campo, PHP, datos
2. Autorización de Publicación de Versión Electrónica del Proyecto de Titulación A través de este medio autorizo a la Biblioteca de la Universidad de Guayaquil y a la Facultad de Ciencias Matemáticas y Físicas a publicar la versión electrónica de este Proyecto de titulación.
X
Publicación electrónica: Inmediata Después de 1 año
Firma Alumno: Hermes Ricardo Rodríguez Muñiz C.I.: 0914256193 3. Forma de envío: El texto del proyecto de titulación debe ser enviado en formato Word, como archivo .Doc. O .RTF y. Puf para PC. Las imágenes que la acompañen pueden ser: .gif, .jpg o .TIFF. DVDROM CDROM
XI
ÍNDICE GENERAL
CARTA DE APROBACIÓN DEL TUTOR ................................................... II
DEDICATORIA ......................................................................................... III
AGRADECIMIENTO ................................................................................. IV
TRIBUNAL PROYECTO DE TITULACIÓN ................................................ V
DECLARACIÓN EXPRESA ...................................................................... VI
CERTIFICADO DE ACEPTACIÓN DEL TUTOR .................................... VIII
ÍNDICE GENERAL .................................................................................... XI
ABREVIATURAS ................................................................................... XIV
SIMBOLOGÍA ......................................................................................... XV
ÍNDICE DE CUADROS .......................................................................... XVI
ÍNDICE DE GRÁFICOS ....................................................................... XVIII
RESUMEN .............................................................................................. XX
ABSTRACT ............................................................................................ XXI
INTRODUCCIÓN ....................................................................................... 1
CAPÍTULO I ............................................................................................... 3
EL PROBLEMA ...................................................................................... 3
PLANTEAMIENTO DEL PROBLEMA ................................................. 3
UBICACIÓN DEL PROBLEMA EN UN CONTEXTO .......................... 3
SITUACIÓN CONFLICTO NUDOS CRÍTICOS ................................... 4
CAUSAS Y CONSECUENCIAS DEL PROBLEMA ............................. 5
DELIMITACIÓN DEL PROBLEMA ..................................................... 6
FORMULACIÓN DEL PROBLEMA .................................................... 6
EVALUACIÓN DEL PROBLEMA ........................................................ 6
XII
ALCANCES DEL PROBLEMA ............................................................ 8
OBJETIVOS DE LA INVESTIGACIÓN ................................................... 8
OBJETIVO GENERAL ........................................................................ 8
OBJETIVOS ESPECÍFICOS ............................................................... 9
JUSTIFICACION E IMPORTANCIA DE LA INVESTIGACIÓN ............... 9
CAPÍTULO II ............................................................................................ 11
MARCO TEÓRICO ............................................................................... 11
ANTECEDENTES DEL ESTUDIO .................................................... 11
FUNDAMENTACIÓN TEÓRICA ....................................................... 19
FUNDAMENTACIÓN LEGAL ........................................................... 28
DEFINICIONES CONCEPTUALES ...................................................... 40
CAPÍTULO III ........................................................................................... 41
METODOLOGÍA DE LA INVESTIGACIÓN .......................................... 41
DISEÑO DE LA INVESTIGACIÓN .................................................... 41
CAPÍTULO IV ........................................................................................... 53
PROPUESTA TECNOLÓGICA ............................................................ 53
ANÁLISIS DE LA FACTIBILIDAD ......................................................... 67
FACTIBILIDAD OPERACIONAL ....................................................... 68
FACTIBILIDAD TÉCNICA ................................................................. 68
FACTIBILIDAD LEGAL ..................................................................... 69
FACTIBILIDAD ECONÓMICA .......................................................... 72
ETAPAS DE LA METODOLOGÍA DEL PROYECTO ........................... 72
ENTREGABLES DEL PROYECTO .................................................. 78
CRITERIOS DE VALIDACIÓN DE LA PROPUESTA ....................... 78
CRITERIOS DE ACEPTACIÓN DEL PRODUCTO O SERVICIO ..... 78
XIII
CONCLUSIONES ................................................................................. 80
RECOMENDACIONES ........................................................................ 81
XIV
ABREVIATURAS API Interfaz Programable de Aplicación BD Base de Datos CISC Carrera de Ingeniería en Sistemas Computacionales UG Universidad de Guayaquil FTP Protocolo de Transferencia de Archivos HTML Lenguaje de Marca de salida de Hyper Texto HTTPS Protocolo seguro de transferencia de Hyper Texto IDE Ambiente de desarrollo Integrado Ing. Ingeniero GUI Interfaz Gráfica de Usuario GPL GNU Public License (Licencia Pública General GNU) CC.MM.FF Facultad de Ciencias Matemáticas y Físicas ISP Proveedor de Servicio de Internet M.Sc. Master en ciencias LOES Ley Orgánica de Educación Superior LPM Latidos Por Minuto RDBMS Sistema Gestor de Base de Datos Relacional PHP Acrónimo recursivo de Hypertext Pre-Processor SQL Lenguaje de consultas estructurado URL Localizador de Fuente Uniforme www World Wide Web (red mundial)
XV
SIMBOLOGÍA
s Desviación estándar e Error E Espacio muestral E(Y) Esperanza matemática de la v.a. y s Estimador de la desviación estándar e Exponencial
XVI
ÍNDICE DE CUADROS Pág.
CUADRO 1
CAUSAS Y CONSECUENCIAS DEL PROBLEMA .................................... 5
CUADRO 2
DELIMITACIÓN DEL PROBLEMA ............................................................. 6
CUADRO 3
CRITERIO PARA DEFINIR LA POBLACIÓN........................................... 41
CUADRO 4
DESCRIPCIÓN DE SÍMBOLOS DE LA MUESTRA ................................. 42
CUADRO 5
DEFINICIÓN DEL ÍNDICE DE CONFIANZA............................................ 42
CUADRO 6
VALORES PARA REEMPLAZAR DE LA MUESTRA .............................. 43
CUADRO 7
VALORES QUE SE USARAN EN LA MUESTRA .................................... 43
CUADRO 8
RESULTADOS DE LA PRIMERA PREGUNTA ....................................... 44
CUADRO 9
RESULTADOS DE LA SEGUNDA PREGUNTA ...................................... 45
CUADRO 10
RESULTADOS DE LA TERCERA PREGUNTA ...................................... 46
CUADRO 11
RESULTADOS DE LA CUARTA PREGUNTA ......................................... 47
CUADRO 12
RESULTADOS DE LA QUINTA PREGUNTA .......................................... 48
CUADRO 13
RESULTADOS DE LA SEXTA PREGUNTA ............................................ 49
CUADRO 14
RESULTADOS DE LA SÉPTIMA PREGUNTA ........................................ 50
CUADRO 15
XVII
RESULTADOS DE LA OCTAVA PREGUNTA ......................................... 51
CUADRO 16
RESULTADOS DE LA NOVENA PREGUNTA ........................................ 52
CUADRO 17
DESCRIPCIÓN DEL HARDWARE UTILIZADO PARA EL PROYECTO . 68
CUADRO 18
DESCRIPCIÓN DEL SOFTWARE UTILIZADO EN EL PROYECTO ....... 69
CUADRO 19
DESCRIPCIÓN DE PRESUPUESTO PARA EL PROYECTO ................. 72
CUADRO 20
SPRINTS DE ACTIVIDADES DEL PROYECTO ...................................... 73
CUADRO 21
CRITERIOS DE ACEPTACIÓN DEL PROYECTO .................................. 79
XVIII
ÍNDICE DE GRÁFICOS
Pág. GRÁFICO 1: IESS SUR VALDIVIA, CENTRO DE ATENCIÓN
AMBULATORIA ....................................................................................... 11
GRÁFICO 2: LOGO DE MYSQL .............................................................. 23
GRÁFICO 3: PANEL PRINCIPAL DE TRELLO ....................................... 27
GRÁFICO 4: DESCRIPCIÓN DE PANELES, LISTAS DE FASES Y
TAREAS DE TRELLO .............................................................................. 28
GRÁFICO 5: RESULTADOS DE LA PRIMERA PREGUNTA .................. 44
GRÁFICO 6: RESULTADOS DE LA SEGUNDA PREGUNTA................. 45
GRÁFICO 7: RESULTADOS DE LA TERCERA PREGUNTA ................. 46
GRÁFICO 8: RESULTADOS DE LA CUARTA PREGUNTA.................... 47
GRÁFICO 9: RESULTADOS DE LA QUINTA PREGUNTA ..................... 48
GRÁFICO 10: RESULTADOS DE LA SEXTA PREGUNTA .................... 49
GRÁFICO 11: RESULTADOS DE LA SÉPTIMA PREGUNTA................. 50
GRÁFICO 12: RESULTADOS DE LA OCTAVA PREGUNTA ................. 51
GRÁFICO 13: RESULTADOS DE LA NOVENA PREGUNTA ................. 52
GRÁFICO 14: ESTRUCTURA CENTRAL DE SCRUM ........................... 54
GRÁFICO 15: VALORES DE LA METODOLOGÍA SCRUM .................... 54
GRÁFICO 16: VENTANA PRINCIPAL DE SQLYOG ............................... 56
GRÁFICO 17: DESCRIPCIÓN DE TABLAS ALARMAS Y CONTROL
MEDICACIÓN .......................................................................................... 57
GRÁFICO 18: DESCRIPCIÓN DE TABLAS MEDICAMENTO Y
MEDICACIÓN .......................................................................................... 58
GRÁFICO 19: DESCRIPCIÓN DE TABLA DETALLE_PESO .................. 59
GRÁFICO 20: DESCRIPCIÓN DE TABLA DETALLE_PRESION ............ 60
GRÁFICO 21: DESCRIPCIÓN DE TABLA DETALLE_COLESTEROL .... 61
GRÁFICO 22: DESCRIPCIÓN DE TABLA
EXAMENES_COMPLEMENTARIOS ....................................................... 62
GRÁFICO 23: PARTE DEL CODIGO DEL SP
PR_INSERTA_ALARMA_MEDICACION ................................................. 63
XIX
GRÁFICO 24: PARTE DEL CÓDIGO DE SP
PR_INSERTA_CONTROL_MEDICACION .............................................. 64
GRÁFICO 25: PARTE DEL CÓDIGO DEL SP
PR_INSERTA_MEDICACION.................................................................. 65
GRÁFICO 26: PARTE DE CÓDIGO DEL SP PR_INSERTA_PRESION . 66
GRÁFICO 27: PARTE DE CÓDIGO DEL SP PR_INSERTA_PESO ....... 67
GRÁFICO 28: DESCRIPCIÓN DEL SPRINT 1 ........................................ 74
GRÁFICO 29: DESCRIPCIÓN DEL SPRINT 2 ........................................ 74
GRÁFICO 30: DESCRIPCIÓN DEL SPRINT 3 ........................................ 75
GRÁFICO 31: DESCRIPCIÓN DEL SPRINT 4 ........................................ 75
GRÁFICO 32: DESCRIPCIÓN DEL SPRINT 5 ........................................ 76
GRÁFICO 33: DESCRIPCIÓN DEL SPRINT 6 ........................................ 77
GRÁFICO 34: DESCRIPCIÓN DEL SPRINT 7 ........................................ 77
XX
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS
COMPUTACIONALES
SISTEMA DE AUTOGESTIÓN DE LA SALUD PARA PACIENTES CON DIABETES Y ASMA, DESARROLLADO E IMPLEMENTADO EN UNA
PLATAFORMA ANDROID; CON MONITOREO DE UNA APLICACIÓN WEB EN PHP DIRIGIDA A LOS MÉDICOS TRATANTES, ENFOCADO EN LA ADMINISTRACION Y GESTION DE LA BASE DE DATOS PARA LA
INTEGRACIÓN DE DATOS DESDE EL APLICATIVO MOVIL ANDROID HACIA EL MANEJADOR DE BASE DE DATOS MYSQL.
RESUMEN
La aplicación HealthMonitor fue lanzada en su primera versión en mayo de 2017, para dispositivos móviles con sistema operativo Android; en esta fase de rediseño tendremos la facilidad de registrar nuestros datos sin tener acceso a internet todo el tiempo. Esta consiste en la integración de datos entre base de datos del aplicativo móvil hacia el manejador de base de datos MySQL. Radica en adoptar o agregar un nuevo campo a cada tabla para que pueda identificarse al momento de la migración de datos. La modificación permitirá a los usuarios tener la seguridad de que sus datos se guarden exitosamente una vez su conexión a internet se haya restablecido.
Palabras clave: Android, MySQL, integración, campo, datos.
Autor: Ricardo Rodríguez Muñiz Tutor: Ing. Jimmy Sornoza, M. Sc.
XXI
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS
COMPUTACIONALES
SELF-MANAGEMENT HEALTH SYSTEM FOR PATIENTS WITH ASTHMA AND DIABETES, IMPLEMENTED AND DEVELOPED ON AN ANDROID PLATFORM; WITH MONITORING PROGRESS IN A WEB APPLICATION IN PHP DIRECTED TO DEALING DOCTORS; FOCUSED ON DATABASE ADMINISTRATION AND
MANAGEMENT FOR DATA INTEGRATION FROM THE MOBILE APPLICATION TO DATABASE MANAGEMENT SYSTEM MySQL
ABSTRACT The HealthMonitor application was launched at its first version in May, 2017, for mobile devices using Android Operating System; in this redesign phase we will get the ease of record our data with no internet access all time. This consists in data integration between the mobile application's database and the MySQL relational database management system. It resides in to adopt or to add a new field to each table, in order to identify itself at the moment of data migration. The modification will let to the users to have the reliability that their information be successfully stored, once their internet access has been restored.
Keywords: Android, MySQL, integration, field, data.
Author: Ricardo Rodríguez M. Advisor: Ing. Jimmy Sornoza, M. Sc.
1
INTRODUCCIÓN
El presente proyecto tiene como finalidad retroalimentar la aplicación móvil
para sistemas operativos Android, HealthMonitor - primera versión; la cual
ayuda a los pacientes a controlar los diferentes tipos de diabetes como: tipo
1, tipo 2 y gestacional.
Esta actualización se basa en la modificación de tablas en la base de datos
MySQL, agregando campos que servirán de identificación para poder
integrar los registros que se guardan temporalmente en el dispositivo
cuando no se cuenta con acceso a internet. Para esto se va a emplear la
administración y gestión de base de datos para integrar información del
modelo entidad relación mediante el uso de APIs desde el manejador
MySQL hacia la plataforma móvil; controlando mediante logs las respuestas
hacia la base interna móvil de las validaciones implementadas en los APIs.
La elaboración de este proyecto es de gran utilidad ya que no solo abarca
a los pacientes (usuarios) que presentan diabetes, sino también para
aquellos que padezcan asma.
Cabe recalcar que para su correcto funcionamiento esta aplicación móvil
se vinculará con una de las redes sociales más utilizadas por los usuarios;
en este caso “Twitter”.
La metodología implementada en este proyecto es descriptiva y se
enfocará en organizar, resumir, analizar y presentar los datos de una
determinada situación.
Concluido el proyecto, se estima que cumpla con las expectativas de los
usuarios (pacientes), facilitando la gestión de los mismos.
2
En el capítulo 1 es donde se detallada la problemática del proyecto que
además del planteamiento del problema, la ubicación en un contexto, la
situación conflicto y los nudos críticos, las causas y consecuencias,
delimitación del problema, formulación, evaluación, alcances del proyecto,
los objetivos generales y específicos la su respectiva justificación.
En el capítulo 2, se realiza una reseña de los antecedentes del proyecto,
en el marco teórico se habla de las fundamentaciones teórica y legal, y las
definiciones conceptuales.
En el capítulo 3, se definió la población y la muestra para aplicar el estudio,
recolección de información, el procesamiento y análisis de los datos
obtenidos.
En el capítulo 4 se detalla la propuesta tecnológica, los análisis de
factibilidad (operacional, técnico, legal y económico), las etapas de la
metodología del proyecto, se define los entregables del proyecto, criterios
de validación de la propuesta, criterios de aceptación del producto,
conclusiones y las recomendaciones
3
CAPÍTULO I
EL PROBLEMA
PLANTEAMIENTO DEL PROBLEMA Ubicación del Problema en un Contexto
En el Ecuador, según el Instituto Ecuatoriano de estadísticas y censos,
INEC, (INEC, 2016) en el 2015, más de tres millones aseguraron contar al
menos con un Smartphone (teléfono inteligente), elevando la cifra a casi
cinco veces según lo registrado en el censo del 2011. También agrega que
“en el caso de las redes sociales, el 17,11% de la población mayor de 5
años, es decir 2,8 millones de ecuatorianos declara usar redes sociales a
través de su teléfono inteligente”.
Esto quiere decir que, para este proyecto, al menos el 17 % de la
población usa redes sociales y cuenta con un Smartphone, entre ellos, usan
la red social Twitter, que es a la que se enfoca esta problemática.
Las aplicaciones móviles deben actualizarse periódicamente debido a
las diferentes demandas / necesidades que presentan los usuarios. Dicha
aplicación en sus constantes actualizaciones trae un sin número de
necesidades entre los que se incluyen mejoras en su diseño y en sus
funciones, además de adentrar un tipo de parche de seguridad para sus
usuarios.
4
El rediseño de esta aplicación beneficiará a los usuarios porque su uso
será más sencillo, como también sus registros personales, conllevará un
sin número de funcionalidades y tomará datos de cada usuario y lo
comparará a medida que él lo requiera y podrá ver los resultados de estos
en una sencilla vista que mostrará cada interacción.
Es bien sabido que no existe cobertura de internet en algunos sectores
de la ciudad y los sectores con cobertura abierta no son seguros para los
usuarios de Smartphones, un gran problema porque además los
ciudadanos apenas cuentan con un Smartphones y estos no pueden en
muchos casos introducir una recarga a sus celulares y tener megas por
tiempo limitado o contratar un servicio de plan móvil para poder acceder a
la red por lo cual es imposible que la aplicación mantenga los datos
siempre guardados o que estos se puedan sincronizar al momento de ser
registrados.
Situación Conflicto Nudos Críticos
La principal causa de la restructuración en las estructuras de tablas y
procedimientos almacenados, es porque las tablas no contienen o no
utilizan el campo que sirve de identificador para los registros que serán
importados/exportados entre la base de datos del dispositivo móvil y la
nube.
Al no contar con la característica offline existe la alta posibilidad de que
los datos que el paciente haya registrado, no se respalden ya sea por
cualquier circunstancia que fuere, por ejemplo, dañó su teléfono móvil,
alguna actualización hizo perder los datos del mismo, por una intervención
errónea del mismo usuario o persona cercana a este, desinstalación de la
aplicación o peor un restablecimiento de fábrica del móvil.
5
Causas y Consecuencias del Problema
1 CAUSAS Y CONSECUENCIAS DEL PROBLEMA CUADRO N. 1
CAUSAS CONSECUENCIAS
Falta de acceso a internet en la
comunidad de usuarios de la
aplicación
La aplicación no permitiría acceder
a los módulos de control del
paciente y por ende, no podrá
contar registros actualizados del
paciente
Que no todos los pacientes que
usen la aplicación tengan cuenta
en la red social Twitter
El paciente no podrá ingresar a la
aplicación más que con sus
credenciales con las cual se
registró al inicio
La mayoría de puntos de acceso
gratuitos ofrecen internet
solamente para ciertos servicios
(en su mayoría redes sociales)
Aumenta la probabilidad de que el
paciente/usuario de la aplicación
móvil, use sus datos móviles.
Complicaciones al acceder o
instalar la aplicación por casos
fortuitos
Desinstalación por error de la
aplicación, robo del móvil,
restablecimiento de fábrica forzoso
del móvil.
Desconocimiento del uso de la
aplicación
Un usuario que no conozca de las
funcionalidades puede introducir
información errónea, eliminar
inconscientemente datos o
eliminar dicha aplicación del móvil.
Fuente: Información recopilada en la problemática del proyecto
Elaborado por: Ricardo Rodríguez M.
6
Delimitación del Problema
2 DELIMITACIÓN DEL PROBLEMA CUADRO N. 2
Campo: Salud
Área: Base de datos
Aspecto: Administración y rediseño de estructuras y procesos de
negocio
Tema:
Sistema de autogestión de la salud para pacientes con
diabetes y asma, desarrollado e implementado en una
plataforma Android; con monitoreo de una aplicación web
en PHP dirigida a los médicos tratantes, enfocado en la
administración y gestión de la base de datos para la
integración de datos desde el aplicativo móvil Android
hacia el manejador de base de datos MySQL.
Fuente: Información recopilada en la problemática del proyecto Elaborado por: Ricardo Rodríguez M.
Formulación del Problema
¿Cómo podrá mejorar la disponibilidad de la información de los pacientes
de la aplicación Salud Control la integración de datos entre la base interna
móvil y el manejador de base de datos MySQL?
Evaluación del Problema
Por consiguiente, se detallará los aspectos generales de valoración del
proyecto:
Delimitado Las personas que utilizan la aplicación móvil HealthMonitor, que tienen
cuenta en la red social Twitter y que disponen de acceso a internet limitado
o restringido.
7
Claro Esta aplicación ofrece a los pacientes que usan la aplicación mantener
sus datos de manera offline hasta que el dispositivo tenga acceso a internet
ilimitado.
Evidente Facilita a los doctores a obtener información actual y detallada de los
pacientes. La calidad de servicio que presta la aplicación ya que el paciente
tiene la opción de iniciar sesión con sus credenciales normales o con su
cuenta de red social Twitter vinculada a la aplicación HealthMonitor.
Concreto
Es notable que la falta de acceso a internet en ciertos sectores es un
obstáculo para las personas que desean mantener sus registros de control
médico actuales y precisos.
Relevante
Es importante porque ayuda a optimizar tiempo entre el doctor y sus
pacientes ya que el médico se encargaría de ver el historial clínico
registrado por el usuario.
Factible
Es factible porque el médico no necesitará largos periodos para obtener
información actualizada del historial clínico del paciente. Además, el
paciente ahorrará gastos en planes de datos o megabytes del consumo del
mismo, aprovechándolos para su mejor conveniencia.
Identifica los productos esperados
Esta característica offline de la aplicación ayuda a preservar la
información hasta encontrar un punto de acceso sin restricciones,
preferiblemente una conexión de red inalámbrica local.
8
ALCANCES DEL PROBLEMA
El rediseño de la aplicación móvil tendrá como propósito implementar el
nuevo campo de identificación de las tablas a los cuales pertenecen los
módulos del control que se integrarán con la base de datos MySQL,
analizando las estructuras ya existentes para determinar cuáles serán
modificas y cuales agregadas, así como también la creación y modificación
de los procesos de negocio que devolverán el campo implementado en las
estructuras modificadas. Para esto se necesita que la información de los
pacientes este correctamente validada.
Para complementar el alcance del problema del proyecto, se detallan los
siguientes puntos:
Proceso de controles enfermedades y control de medicamentos.
Se rediseñará la estructura del proceso de negocio para que soporte
control de errores y para que devuelva como parámetro de salida el
identificador de la tabla correspondiente.
Se rediseñarán las estructuras para agregar el campo que se
necesita como identificador al momento de integrar los datos entre
las bases de datos móviles y el manejador MySQL.
Se aplicará control de calidad para evitar datos nulos y que se guarden
información errónea.
OBJETIVOS DE LA INVESTIGACIÓN OBJETIVO GENERAL
Emplear la gestión de base de datos mediante el uso de APIs de
Procesamiento para, la integración de información del modelo entidad
relación desde el manejador MySQL hacia la plataforma móvil.
9
OBJETIVOS ESPECÍFICOS
Restructurar tanto procesos de negocio (Store Procedures) como
estructuras (tablas, campos, índices) para sincronizar los datos
almacenados en la base interna móvil.
Aplicar reglas de negocio en los APIs de procesamiento evitando el
envío de datos erróneos durante la migración de la información entre
la base de datos móvil y el manejador de base datos MySQL.
Controlar mediante logs las respuestas y errores que se presenten
en tiempo de ejecución, de las validaciones implementadas en los
APIs de Procesamiento hacia la base interna móvil.
Crear pruebas de los procesos modificados en conjunto con las
demás áreas involucradas en desarrollo del proyecto (Webservice y
Andriod).
JUSTIFICACION E IMPORTANCIA DE LA INVESTIGACIÓN
La falta de control de errores en los procesos de negocio de la aplicación
móvil y el campo de identificación en las estructuras que no existían o no
se usaban, llevó a realizar una retroalimentación exhaustiva de la misma,
con el fin de cumplir con las expectativas del paciente y usuarios en general
de la aplicación. Este proyecto se encargará:
Proyectar un avance en la aplicación gracias al uso de tecnología
Open Source y la metodología SCRUM.
La actualización de esta aplicación dará seguridad a los usuarios por
motivo de que sus registros se guardaran sin importar de cuente con
conexión a internet gracias la nueva implementación offline.
10
Con todo lo exhibido anteriormente se demuestra que el rediseño del
proyecto es viable porque cumple en su totalidad con las
necesidades que presentan los usuarios del mismo.
11
CAPÍTULO II
MARCO TEÓRICO
ANTECEDENTES DEL ESTUDIO
La Universidad de Guayaquil dio inicio en noviembre de 2016 en la
creación de una aplicación móvil para dispositivos con sistema operativo
Android HealthMonitor, en su primera versión la aplicación se encarga
principalmente del control de diabetes tipo 1, tipo 2 y gestacional,
medicamentos, alimentación y dietas, además de recomendaciones para
ejercicios para este tipo de pacientes del Hospital del Día Sur Valdivia,
incluyendo una versión web en la cual los doctores puedan dar seguimiento
a los pacientes que tienen asignados.
GRÁFICO 1: IESS Sur Valdivia, Centro De Atención Ambulatoria
Fuente: página web de Google Maps Elaborado por: Google Maps
12
En los últimos años, la tecnología ha abarcado diferentes áreas, en este
caso, la salud. La versatilidad de los smartphones además de permitir el
uso de funciones básicas como llamar o enviar de mensajes de texto,
también permiten monitorear y administrar mediante el uso de aplicaciones
móviles el estilo de vida en ámbito salud; y es por esto que según el sitio
Web (Rodríguez, 2015):
Los pacientes consultan herramientas digitales para estar informados y formados en sus patologías. Así, por ejemplo, el 18% de las búsquedas en Google son temas relacionados con la salud o en las plataformas de apps móviles para Smartphone ya hay más de 97.000 apps de salud disponibles, siendo la 3ª categoría en la que se han desarrollarlo más aplicaciones móviles.
Además, (Rodríguez, 2015) agrega que, varios beneficios que los
usuarios pueden obtener al incursionar en el mundo de las aplicaciones
móviles en la salud, como son:
Acceso a información y formación en temas relacionados con su salud. Empoderamiento de pacientes. e-pacientes.
Consulta rápida de temas o dudas concretos que pueden ser solucionados sin necesidad de consulta a un profesional sanitario.
Localización y facilitación de acceso a recursos en salud
(localizadores de farmacias de guardia o servicios de urgencia) o de profesionales sanitarios.
Monitorización de variables en domicilio. Pacientes crónicos.
Posibilidad de realizar tratamientos domiciliarios (tele-
rehabilitación a través de sistemas Kinect).
Aumento de seguridad en la toma de medicación.
Contacto en red con otras personas en su misma situación.
13
Aplicaciones móviles para una alimentación y una vida sana
En toda aplicación con un mínimo de información a guardar, es necesario
disponer de una base de datos.
Se documentó en el primer trimestre de 2014. La Fairview Health Services en Minnesota involucró a 41 servicios de atención primaria del Estado para ofrecer apps específicas a pacientes crónicos. El estudio de campo resolvió que los resultados de uso de las aplicaciones con pacientes reales fueron bajos, pero la eficiencia de entre quienes las emplearon fue muy alta. El paciente familiarizado con su utilización se benefició de ella, si bien la resistencia o falta de voluntad para incluirla en los hábitos fue mayoritaria. (Zudaire, Aplicaciones para una alimentación y una vida sana, 2014)
Sin importar que los pacientes potenciales usen la aplicación, se logró
registrar con éxito las actividades de los mismos ayudando a mejorar en el
campo de investigación.
No obstante, alertó de que, si bien grandes y pequeñas empresas están trabajando en su desarrollo, no deben olvidar incluir a un especialista en nutrición en el equipo desde el principio. Este apunte lo realizó al describir cómo las aplicaciones médicas que han logrado su consolidación y su éxito, es decir, la aceptación de los pacientes, han contado con especialistas de las diferentes patologías en todo el proceso de desarrollo. (Zudaire, Aplicaciones para una alimentación y una vida sana, 2014)
Es importante, además, incluir la opinión de expertos para mejorar el
desarrollo de la aplicación en cuanto a la enfermedad que se necesita o se
requiere controlar. Es por esto que, el autor concluye que “de ahí la
importancia de que ese criterio sea el más riguroso y más acertado posible.
Si los ciudadanos premian con su éxito una aplicación rigurosa es
14
importante, y en el caso de la nutrición es esencial”. (Zudaire, Aplicaciones
para una alimentación y una vida sana, 2014)
Esto no acontece con este tipo de aplicaciones móviles, sino que, existe
sin número dedicada al campo de la salud y bienestar de la salud, a
continuación, se mencionará otros campos en que se inmiscuyen dichas
aplicaciones y sus resultados.
Sucede lo mismo con las aplicaciones que acompañan en el ejercicio físico. Las hay que ayudan a trazar el recorrido o calcular el gasto calórico del usuario en las salidas a correr y las que quieren inspirar el ejercicio al aire libre. También son numerosas las que se refieren al fitness, adaptadas a ejercicios aeróbicos, las que simulan gimnasios virtuales o pautan entrenamientos específicos de glúteos, piernas o abdomen. Incluso, sin ser apps propiamente dichas, en el mercado se encuentran accesorios como pulseras o pulsómetros que digitalizan el ejercicio en la búsqueda de un mejor resultado, más eficaz y eficiente. (Zudaire, 2014)
Hay aplicaciones que son orientadas para un público objetivo bastante
definido, son las aplicaciones que van de la mano con las rutinas de
ejercicios que realizamos. Este tipo de aplicaciones hay un montón, pero
sus funcionalidades son casi las mismas, nos ayudan a medir nuestros
avances, miden nuestras calorías quemadas, rutinas cronometradas que
tenemos que realizar, medición constante del ritmo cardiaco, elección de
un plan de ejercicio establecidas, etc. Estas aplicaciones vienen
acompañadas de accesorios como smartwatch o pulseras inteligentes que
ayudan de mejor manera a tomar una medición de lo anteriormente
mencionado.
Estas aplicaciones son de gran ayuda para nuestra vida cotidiana y son
casi que imprescindibles, pero con estos nos debemos hacer la siguiente
pregunta.
15
¿Aplicaciones para la salud son personalizables y son el futuro que
esperamos los usuarios?
Con esta interrogante nace muchas inquietudes, menciones, teorías.
Pero realmente este tipo de aplicaciones nos ayudan a llevar un mejor
monitoreo en nuestra salud, estas aplicaciones son realmente lo que
necesitan los usuarios, muchos responderán que si, por diversas razones
a su favor. Pero un problema muy importante que no tomamos en cuenta
es que no todos los usuarios en un futuro comprenderán el uso de las
funcionalidades de dichas aplicaciones a menos que los usuarios tenga
conciencia de la tecnología, pues bien, y los ignorantes de ella donde
quedan.
Tecnología de “bolsillo”, a beneficio de nuestra salud
La gran ventaja es el repunte de estas aplicaciones cada semana
aparecen unas nuevas aplicaciones ya sean gratuitas o aquellas que tienen
precios. Lo malo de ellas es que muchas no tienen el mismo impacto
positivo que otras y los desarrolladores las dejan ahí y en muchas de las
ocasiones no se le da soporte y quedan obsoletas. Por eso el criterio de
los usuarios de estas aplicaciones son de mucha importancia ya que las
empresas de desarrollo que ofertan estas aplicaciones en el mercado solo
ven el lado mercantilista y no hacen énfasis en las necesidades propias del
usuario. No se arriesgan en ir más allá de los superficial para después en
el mejor de los casos brindar soporte para mejorar su producto.
Esa “tecnología de bolsillo” está aún un escalón abajo en ser realmente
beneficiosa para nosotros en lo que a salud respecte. La tecnología si bien
avanza, pero deja detrás muchas cosas, que son detalles imperceptibles a
veces pero que ayudarían a ser mejor y decir si la ayuda de la tecnología
en aplicaciones de salud es realmente beneficiosa para los usuarios.
16
Servicio en la nube
El Servicio en la nube es una simple metáfora para referirse que los
servicios informáticos que se utilizan por la red global o popularmente
llamado internet. A través de la evolución de las ciencias informáticas se ha
representado a la internet como una “nube” esquematizado a su
infraestructura y servicios intangibles que nos brinda a nivel global. Por citar
ejemplos de servicios son los repositorios que sirven para almacenar
cualquier tipo de información con una limitada capacidad de
almacenamiento ya sea por medio de Mega, Dropbox, OneDrive, etc.
¿Pero a que llamamos servicio en la nube o Cloud Computing?
Pues bien, estos son simplemente todo programa o servicio que usamos
y que no tenemos físicamente instalado en nuestro ordenador o servidor y
su accesibilidad a ellos es por medio del internet.
Estos servicios en línea siempre constan de un conjunto estructurado y
distribuido centro de procesamiento de información el cual funciona con un
software instalado que es el que brinda el servicio en la red mundial a quien
requiera de ellos.
Según TOURON, Javier. Manifiesta que: “El término nube proviene de la
definición que se le dio al procesamiento masivo de datos y
almacenamiento de información en grupos de servidores conectados a una
conexión de internet llamada ‘Cloud Computing o Computación en la
nube’.”
La Computación en la nube puede reducir costos a los clientes al disminuir las necesidades de adquisición de hardware avanzado. Una empresa ya no necesita comprar computadoras más rápidas, con una mayor cantidad de memoria RAM o discos duros de gran capacidad, pues el sistema de la nube se hace cargo de todas esas
17
necesidades. Al contrario, las empresas pueden comprar terminales más económicos y solamente con la memoria necesaria para utilizar un software llamado middleware, que es el que permite conectarse a la nube. Los sistemas que alojan los servicios tienen todas las condiciones de seguridad necesarias para garantizar el servicio de manera continua. (Mercedes Kamijo, Álvaro Fernández, Susana Trabaldo, 2015)
Tipos de Servicios en la Nube y los que usamos normalmente
Aunque no se crea nosotros somos usuarios recurrentes de este tipo de
servicios, pero en muchos de los casos y sin el conocimiento del caso sin
saber que usamos los servicios en la nube o cloud computing, estos
servicios son:
Las tiendas de aplicaciones. – Es un claro ejemplo de cloud
computing o servicio en la nube, un usuario puede acceder a ellas
mediante un inicio de sesión en algún tipo de servicio de mensajería
o servicio de correo electrónico, así se accede a las múltiples
diversidades de aplicaciones que estas contienen. Estas tiendas son
Play Store de Google en su sistema operativo Android y App Store
de Mac en su sistema operativo iOS.
Las aplicaciones Web. – Son de gran ayuda para los que quieren
salir de apuros, su portabilidad es tan importante que ha sacado de
aprietos a más de un despistado, estas aplicaciones son las
ofimáticas de google Drive o de Microsoft Office, etc.
Servicio de reposito o almacenamiento de datos. – Este tipo de
servicio son de gran ayuda para quienes tener una mejor portabilidad
de datos, acceder a ellas por medio de internet, estos son Dropbox,
OneDrive, Mega, etc.
18
Plataformas de entretenimientos. – Son el gran boom del
momento quien no tiene una plataforma ya sea pagada o gratuita de
entretenimiento, estos servicios nos permiten tener música, videos,
videojuegos, televisión, etc. a disposición 24/7 de nosotros, estas
plataformas son Spotify, Steam, Netflix, PlayView, You Player TV,
etc.
Ventajas que nos brinda el servicio en la nube
Esta tecnología tiene un sin número innegable de servicios, los cuales
mencionaremos los siguientes y más importantes:
Accesibilidad fácil. – Ya que se puede acceder a nuestros datos
desde cualquier lugar recóndito del mundo, lo único e indispensable
es tener internet para acceder a ellos.
Uso fácil. – Son fáciles de usar ya que cualquier personal sin tener
tanto conocimiento de informática puede acceder y usar como le
plazca.
Cero preocupaciones. - Estos servicios son manejados por
terceros (empresas con personal altamente clasificado) los cuales
son los responsable tanto del mantenimiento, actualizaciones de
software y de la inversión que implica la infraestructura con que
consta estos servicios.
Datos más seguros. - A sus inicios este punto era de gran
controversia entre la comunidad tecnológica, ya que, no era tan
segura el servicio que brindaba la nube, pero las empresas han
invertido mucho en ellos y hoy por hoy son los más seguros que
puedan existir.
19
Significativo ahorro económico. – Pensar en contratar este tipo de
servicio nos quitara un gran dolor de cabeza y un gran peso de
encima ya que nosotros como usuarios pagamos por el servicio que
nos den las empresas que ofertan ese tipo de servicio.
Desventajas del servicio en la nube
Todo gran servicio, a pesar de su robustez y efectividad, consta de varias
desventajas:
Poca Privacidad. – Incluimos esto porque estos servicios son
administrados por terceros y nosotros no sabemos que uso le den a
la información que subimos a la nube.
Problemas de Propiedad Intelectual. - Es muy probable que
muchas de estas plataformas en su contrato de servicio incluyan
cláusulas que digan que toda información que subamos a sus
servidores sea netamente de ellos.
Vacíos Legales. – Esto dependerá mucho y es de suma importancia
ya que si una empresa que ofrezca estos servicios, sea de un
determinado país y que este tenga sus servidores en otro
deberíamos tomar en cuenta a que leyes regirnos del de oferta o en
donde está almacenado nuestra información.
Disponibilidad de internet. - Es de suma importancia ya que sin
esta vía no tendremos acceso a nuestro servicios o datos.
FUNDAMENTACIÓN TEÓRICA
Para una mayor comprensión del contexto de este proyecto, se aclaran
las definiciones:
20
Android
Android es un sistema operativo creado esencialmente para teléfonos
móviles y dispositivos portables (smartphones, tablets, smartwatch, etc),
parecidos a BlackBerry, Symbia, etc, pero con la gran diferencia que
Android fue creado en Linux, haciéndolo de código libre, gratuito y
multiplataforma.
Considerado como “el sistema operativo más famoso del mundo”,
diseñado para teléfonos inteligentes o smartphones, la mayoría con
pantalla táctil, usando como base el núcleo de Linux, desarrollado por
Android inc. hasta que la empresa Google la adquirió en el 2005.
Este sistema operativo permite a los desarrolladores crear aplicaciones
en java en donde las corre en una especie de variación o máquina virtual
llamada Dalvik, hace que estas aplicaciones tengan total acceso a todas
las funcionalidades operativas del teléfono como GPS, agenda telefónica,
etc) de una forma rápida y sencilla por medio de código hecho en Java.
API
Aplicación de Interfaz Programable (Application Programming Interface,
de su abreviatura en inglés) como su nombre lo indica es una interfaz que
contiene métodos, procesos y rutinas que son utilizadas por otro software
para comunicarse entre sí para el intercambio de información.
Las API pueden servir para comunicarse con el sistema operativo (WinAPI), con bases de datos (DBMS) o con protocolos de comunicaciones (Jabber/XMPP). En los últimos años, por supuesto, se han sumado múltiples redes sociales (Twitter, Facebook, Youtube, Flickr, LinkedIn, etc) y otras plataformas online (Google Maps, WordPress…), lo que ha convertido el social media marketing es algo más sencillo, más rastreable y, por tanto, más rentable. (Merino, 2014)
21
Las APIs nos permiten implementar funciones y procedimiento de otros
proyectos de software, para así ya no tener que programarlos de nuevo, en
programación se puede hablar que las APIs vienen siendo una capa de
abstracción.
Base de datos Una base de datos no es nada más ni menos que un gran “almacén”
donde reside nuestra información y que puede ser accedida, modificada o
eliminada a placer de quien la administre. Para ello debemos contar con un
software o programa que nos permita realizar lo anteriormente mencionado
y tener total acceso y control a ellos. Estos programas gestores o
administradores de base de datos se conforman de una base de donde se
derivan un conjunto de tablas donde se almacena la información.
Es un conjunto de información ordenada de manera que un programa de
computador pueda acceder a ella, tal como un sistema de administración
de base de datos (SGBD). Según el sitio web (Microsoft, 2017) dice:
Una base de datos es una herramienta para recopilar y organizar información. Las bases de datos pueden almacenar información sobre personas, productos, pedidos u otras cosas. Muchas bases de datos comienzan como una lista en una hoja de cálculo o en un programa de procesamiento de texto. A medida que la lista aumenta su tamaño, empiezan a aparecer redundancias e inconsistencias en los datos. Cada vez es más difícil comprender los datos en forma de lista y los métodos de búsqueda o extracción de subconjuntos de datos para revisión son limitados. Una vez que estos problemas comienzan a aparecer, una buena idea es transferir los datos a una base de datos creada con un sistema de administración de bases de datos (DBMS).
Características
Podemos mencionar las siguientes características:
22
Total, independencia física y lógica de los datos.
Sin redundancia.
Múltiple acceso por parte de varios usuarios.
Alto grado en la integridad de los datos.
Optimización de consultas en alto grado de complejidad.
Seguridad en accesos y auditorias.
Permite hacer respaldo y tener recuperación de información.
Su acceso es mediante lenguaje de programación estándar.
Open Source
Hizo su debut por primera vez en el año 1998 de la mano de un conjunto
de desarrolladores de la comunidad “Free Software”, dichos software son
los que podemos modificar libremente sin persecución legal. A muchos no
le pareció ese nombre para estos tipos de programas o software ya que
representaba una forma explícita de que libre significaría “gratis”. Esto
repercutiera en entre dichos entre conocedores de la comunidad ya que, al
tratarse de código libre, donde este se puede modificar y distribuirlos a
otros.
Se entiende como Open Source a todo aquel programa informático o
software desarrollado por y para usuarios de la comunidad el cual se
distribuye de forma libre y gratuita (en cierto modo) permitiendo así que los
mismos desarrolladores aporten con mejoras y valor agregado para poder
redistribuirlo, teniendo como ventaja el menor tiempo en que toma liberarse
una nueva versión.
El término Open Source se deriva de Software Libre ya que en sus inicios
a estos tipos de software se los llamo así, pero con el pasar del tiempo este
término tuvo algunos inconvenientes por sus conceptos ya que software
libre para algunos significaría software gratis y ese no es el punto. Es de
23
mucha ayuda contar con este tipo de software, ya que permite ahorrar
costos a la hora de implementar proyectos de este tipo.
MySQL
Es un sistema gestor de base de datos, parcialmente de código libre
(open source) actualmente patrocinado por la empresa Oracle.
GRÁFICO 2: LOGO DE MySQL
Elaborado: Datos de recopilación del proyecto Fuente: Página principal del website de MySQL
La historia del MySQL (cuya sigla en inglés se traslada a My Structured Query Language o Lenguaje de Consulta Estructurado) se remite a principios de la década de 1980. Programadores de IBM lo desarrollaron para contar con un código de programación que permitiera generar múltiples y extendidas bases de datos para empresas y organizaciones de diferente tipo. Desde esta época numerosas versiones han surgido y muchas de ellas fueron de gran importancia. Hoy en día MySQL es desarrollado por la empresa Sun Mycrosystems. (Bembibre, 2009)
Al igual que otros gestores de base de datos MySQL permite acceder a
ellos vía web ya que son multiusuarios, y a diferentes lenguajes de
programación que se adapten a sus requerimientos y necesidades. “Por
otro lado, MySQL es conocida por desarrollar alta velocidad en la búsqueda
24
de datos e información, a diferencia de sistemas anteriores”. (Bembibre,
2009)
Actualmente se está dando estudios para desarrollar nuevas versiones
con nuevas características que permitan tener una mejor iteración y
desempeño con las bases de datos relacionales. “Entre estas mejoras
podemos mencionar un nuevo dispositivo de depósito y almacenamiento,
backup para todos los tipos de almacenamientos, replicación segura,
planificación de eventos y otras más”. (Bembibre, 2009)
Trello
Como herramienta colaborativa para el control de las actividades del
proyecto, se usó Trello. Es una aplicación web y móvil para la gestión y
administración de proyectos, utilizando el sistema kanban. Según el sitio
web (IDERA, 2014), esta herramienta ayuda a la organización de proyectos
propios en grupo, y a la vez, de uno o múltiples proyectos con la supervisión
de listas en las que se obtiene información de actividades en curso o ya
realizadas.
Funcionamiento
Un board de Trello es básicamente una página web que contiene listas dispuestas de manera horizontal de modo que puedas apreciar, de un vistazo, todo lo que hay en tu proyecto. Los ítems dentro de las listas, llamados cards, pueden arrastrarse y soltarse en otras listas o reordenarse. (Pinola, 2015)
Trello funciona con una interfaz que divide el proyecto en listas
horizontales todo esto vía web, cada lista horizontal está conformada por
varios ítems o consultas donde podremos ver más a detalle el avance de
nuestro proyecto, los cuales podemos arrastrar y reordenarse en su forma
original.
25
Las cards o ítems individuales pueden contener listas de tareas, imágenes, archivos adjuntos, fechas de entrega, etiquetas de colores y comentarios de otras personas que compartan contigo el board. Puedes tener tanto boards como quieras, utilizar una para "Tareas del Hogar", por ejemplo, y otra para "Planes de dominación mundial". (Pinola, 2015)
Cada ítem está formado por tareas, imágenes, archivos, fechas de
entregas, algo muy parecido a un cronograma de actividades, pero aún más
detallado que incluyen opiniones de otros miembros del grupo del proyecto
con sus observaciones en cada una de estas tareas que se comparten en
la vista y están a disposición de los demás miembros del equipo. Esta
herramienta es de gran ayuda ya que se puede tener varias vistas o boards
con diferentes etapas de un proyecto, algo así como fragmentar las
actividades para llevar de mejor modo y no tener inconvenientes en el
transcurso del desarrollo de algún proyecto.
Esta herramienta de apoyo es muy útil ya que, al incorporar etiquetas,
detalles coloridos y demás opiniones están se quedan pregnados en
nuestra mente y visualmente no podemos pasar por desapercibido estos
cards, que también se pueden crear vía mail y añadirlo a la vista de una
tarea.
Ejemplos de los boards en Trello
Big Picture/Proyectos: me gusta llevar seguimiento de los proyectos que tengo en ese instante, así que creo un card para cada uno y le pongo un proyecto. Así, cuando veo una tarea relacionada con ese color en otra lista, sé que es parte del mismo. También añado cards describiendo qué significa cada color, porque a
26
veces no recuerdo si Azul pera para personal y Verde para trabajo. (Pinola, 2015)
Un card colorido dentro del board de Trello nos permite diferenciar que
tarea específica se refiere y en qué etapa se lo lleva y con su disponibilidad
de comentarios hace que sean de gran ayuda.
“Inbox: Descarga todas las tareas que tengas pendientes de tu cabeza a Trello y luego arrástralas en las otras listas para priorizarlas y organizarlas. También puedes añadir fechas de entrega, una descripción más detallada y adjuntar archivos.” (Pinola, 2015)
Los Inbox nos permite descargar tareas de Trello para poder
reasignarlas a otra lista del board y darles un grado de prioridad si amerita
el caso de este Inbox, así como reasignar o modificar fechas de entrega o
fin de alguna etapa, una descripción más detallada de esta tarea y adjuntar
archivo o imágenes.
“NextActions: Básicamente, lo siguiente que tengo que hacer.”
(Pinola, 2015)
Es un board que netamente hace el trabajo de dar siguiente a otra tarea.
“En espera: Tareas delegadas o en espera.” (Pinola, 2015)
En Espera son tareas que fueron asignadas a algún o algunos miembros
del equipo, pero con una fecha predefinida para que esta pueda ser
ejecutada.
“Algún día/quizá: Tareas que quiero hacer... algún día.”
(Pinola, 2015)
27
Es un board muy peculiar ya que, se distribuye en alguna lista con una
fecha predefinida permitiendo modificarla para poder hacer esa tarea en
otra fecha si así lo desea el usuario.
“Hecho: una vez he completado la tarea, dejo aquí las cards
para ver mi progreso.” (Pinola, 2015)
Es un board de verificación visible para que podemos diferenciar entre
las tareas pendientes, las nuevas tareas y las que ya se han realizado, todo
esto para llevar un mejor control al monitorear las actividades planificadas
en Trello.
GRÁFICO 3: PANEL PRINCIPAL DE TRELLO
Elaborado: Datos de recopilación del proyecto Fuente: Página principal del website de Idera
Como se describe en la sección de arriba, Trello usa un sistema de listas,
en un tablero para distribuir o difundir los avances de tareas de cada grupo
del proyecto. Tal y como describe el sitio (IDERA, 2014) en la pantalla del
tablero, desde izquierda a derecha se muestra el título de las tareas del
grupo. En la parte derecha se muestran los participantes y debajo de ellos
las notificaciones que otros colaboradores hayan escrito o alertado de
28
cualquier cambio o advertencia. En el gráfico de abajo se puede apreciar lo
antes descrito:
GRÁFICO 4: DESCRIPCIÓN DE PANELES, LISTAS DE FASES Y TAREAS DE TRELLO
Elaborado: Datos de recopilación del proyecto Fuente: Página principal del website de Idera
FUNDAMENTACIÓN LEGAL
CONSTITUCIÓN DE LA REPÚBLICA DEL ECUADOR
LA PROTECCIÓN DE DATOS PERSONALES
BASE CONSTITUCIONAL
El Art. 66 de la Constitución de la República, en su parte pertinente
dispone “…Se reconoce y garantizará a las personas: 19. El derecho a la
protección de datos de carácter personal, que incluye el acceso y la
29
decisión sobre información y datos de este carácter, así como su
correspondiente protección. La recolección, archivo, procesamiento,
distribución o difusión de estos datos de información requerirán la
autorización del titular y el mandato de la ley”.
Concordancias: Art. 92 CR; Arts. 49,50,51 LOGJCC; 202.2 CP. (Asambela
Constituyente, 2008)
TRATADOS INTERNACIONALES SOBRE EL DERECHO
CONSTITUCIONAL A LA PROTECCIÓN DE DATOS DE CARÁCTER
PERSONAL
a) Convención Europea de Salvaguardia de los Derechos del Hombre
y las Libertades Fundamentales, que en su Art. 18.1 dice, que toda
persona tiene derecho a su vida privada;
b) La Convención Americana de Derechos Humanos de 1969, que se
la conoce como Pacto de San José de Costa Rica, que en el Art. 25
se reconoce, que toda persona tiene derecho a un recurso sencillo
y práctico, que lo ampare contra actos que violen los derechos
fundamentales reconocidos por la Constitución y la ley; y, entre ellos
el de la vida privada;
c) La Declaración Americana de Derechos y Deberes del Hombre,
aprobada en la IX Conferencia Interamericana en la ciudad de
Bogotá Colombia, en 1948;
d) La Declaración Universal de Derechos Humanos, aprobados por la
Organización de las Naciones Unidas, que en su Art. 12 garantiza
este derecho;
30
e) El Pacto Internacional de Derechos Civiles y Políticos, firmado en
Nueva York el 19 de diciembre de 1966, que en su Art. 17 garantiza
el derecho antes mencionado;
f) La Convención Europea de Salvaguardia de los Derechos del
Hombre y Libertades Fundamentales; Art. 8.1. Convenio No. 108;
g) Tratado de la Unión Europea de 07 de febrero de 1992, en su Art.
72 trata sobre este derecho;
h) El Parlamento Europeo ha dictado varias Resoluciones en el año de
1989, especialmente en los Arts. 6 y 18;
i) La Organización de Cooperación y Desarrollo Económico OCDE,
también trata sobre el derecho a la intimidad, en la Recomendación
del 23 de noviembre de 1980. (García Falconí, 2011)
TÍTULO II
DERECHOS
Capítulo segundo
Derechos del buen vivir
Sección Tercera
Comunicación e Información
Art. 16.- Todas las personas, en forma individual o colectiva, tienen
derecho a:
31
1. Una comunicación libre, intercultural, incluyente, diversa y
participativa, en todos los ámbitos de la interacción social, por
cualquier medio y forma, en su propia lengua y con sus propios
símbolos.
2. El acceso universal a las tecnologías de información y comunicación.
3. La creación de medios de comunicación social, y al acceso en
igualdad de condiciones al uso de las frecuencias del espectro
radioeléctrico para la gestión de estaciones de radio y televisión
públicas, privadas y comunitarias, y a bandas libres para la
explotación de redes inalámbricas.
4. El acceso y uso de todas las formas de comunicación visual,
auditiva, sensorial y a otras que permitan la inclusión de personas
con discapacidad.
5. Integrar los espacios de participación previstos en la Constitución en
el campo de la comunicación. (Asambela Constituyente, 2008)
TÍTULO VII
RÉGIMEN DEL BUEN VIVIR
Capítulo primero
Inclusión y equidad
Sección primera
Educación
Art. 350.- El sistema de educación superior tiene como finalidad la
formación académica y profesional con visión científica y humanista; la
32
investigación científica y tecnológica; la innovación, promoción, desarrollo
y difusión de los saberes y las culturas; la construcción de soluciones para
los problemas del país, en relación con los objetivos del régimen de
desarrollo. (Asambela Constituyente, 2008)
LEY ORGÁNICA DE EDUCACIÓN SUPERIOR
TÍTULO VIl
INTEGRALIDAD
CAPITULO 2
DE LA TIPOLOGÍA DE INSTITUCIONES, Y RÉGIMEN ACADÉMICO
Sección Tercera
Del Funcionamiento de las Instituciones de Educación Superior
Art. 136.- Trabajos realizados por investigadores y expertos extranjeros.
- El reporte final de los proyectos de investigación deberán ser entregados
por los centros de educación superior, en copia electrónica a la Secretaría
Nacional de Educación Superior Ciencia, Tecnología e Innovación.
Esta información será parte del Sistema Nacional de Información de la
Educación Superior.
Art. 137.- Entrega de información a la Secretaría Nacional de Educación
Superior, Ciencia, Tecnología e Innovación. - Las instituciones del Sistema
de Educación Superior obligatoriamente suministrarán a la Secretaría
33
Nacional de Educación Superior, Ciencia, Tecnología e Innovación la
información que le sea solicitada.
Art. 144.- Tesis Digitalizadas. - Todas las instituciones de educación
superior estarán obligadas a entregar las tesis que se elaboren para la
obtención de títulos académicos de grado y posgrado en formato digital
para ser integradas al Sistema Nacional de Información de la Educación
Superior del Ecuador para su difusión pública respetando los derechos de
autor. (LOES, 2010)
DECRETO N° 1014
DEL GOBIERNO ACERCA DEL USO DE SOFTWARE LIBRE
Artículo 1: Establecer como política pública para las Entidades de la
Administración Pública Central la utilización de Software Libre en sus
sistemas y equipamientos informáticos.
Artículo 2: Se entiende por Software Libre a los programas de
computación que se pueden utilizar y distribuir sin restricción alguna, que
permite el acceso a sus códigos fuentes y que sus aplicaciones pueden ser
mejoradas.
Estos programas de computación tienen las siguientes libertades:
a) Utilización del programa con cualquier propósito de uso común.
b) Distribución de copias sin restricción alguna.
c) Estudio y modificación del programa (Requisito: código fuente
disponible).
34
d) Publicación del programa mejorado (Requisito: código fuente
disponible).
Artículo 3.- las entidades de la Administración Publica Central previa a
la instalación del software libre en sus equipos, deberán verificar la
existencia de capacidad técnica que brinde el soporte necesario para el uso
de este tipo de software.
Articulo 4.- Se efectúa la utilización de software propietario (no libre)
únicamente cuando exista una solución de Software Libre que supla las
necesidades requeridas, o cuando esté en riesgo la seguridad nacional, o
cuando el proyecto informático se encuentre en un punto de no retorno.
Para efectos de este decrete se comprende como seguridad nacional, las
garantías para la supervivencia de la colectividad y la defensa de
patrimonio nacional.
Para efectos de este decreto se entiende por punto de no retorno cuando
el sistema o proyecto informático se encuentre en cualquiera de estas
condiciones:
a) Sistema en producción funcionando satisfactoriamente y que un
análisis de costo beneficio muestre que no es razonable ni
conveniente una migración a Software Libre.
b) Proyecto en estado de desarrollo y que un análisis de costo –
beneficio muestre que no es conveniente modificar el proyecto y
utilizar Software Libre.
Periódicamente se evaluarán los sistemas informáticos que utilizan
software propietario con la finalidad de migrarlos a Software Libre.
35
Artículo 5.- Tanto para software libre como para software propietario,
siempre y cuando se satisfagan los requerimientos, se debe preferir las
soluciones en este orden:
a) Nacionales que permitan autonomía y soberanía tecnológica.
b) Regionales con componente nacional.
c) Regionales con proveedores nacionales.
d) Internacionales con componentes nacionales.
e) Internacionales con proveedores nacionales.
f) Internacionales.
Artículo 6.- La subsecretaría de Informática como órgano regulador y
ejecutor de las políticas y proyectos informáticos en las entidades del
Gobierno Central deberá realizar el control y seguimiento de este Decreto.
Para todas las evaluaciones constantes en este decreto la Subsecretaría
de Informática establecerá los parámetros y metodología obligatorias.
(Decreto Ejecutivo 1014, 2008)
Ley de Propiedad Intelectual
Capítulo I: Del Derecho de Autor.
Sección V
Disposiciones Especiales sobre ciertas Obras
Parágrafo Primero De los Programas de Ordenador
Art. 28: Los programas de ordenador se consideran obras literarias y se
protegen como tales. Dicha protección se otorga independientemente de
36
que hayan sido incorporados en un ordenador y cualquiera sea la forma en
que estén expresados, ya sea en forma legible por el hombre (código
fuente) o en forma legible por máquina (código objeto), ya sean programas
operativos y programas aplicativos, incluyendo diagramas de flujo, planos,
manuales de uso, y en general, aquellos elementos que conformen la
estructura, secuencia y organización del programa.
Art. 29: Es titular de un programa de ordenador, el productor, esto es la
persona natural o jurídica que toma la iniciativa y responsabilidad de la
realización de la obra. Se considerará titular, salvo prueba en contrario, a
la persona cuyo nombre conste en la obra o sus copias de la forma usual.
Dicho titular está además legitimado para ejercer en nombre propio los
derechos morales sobre la obra, incluyendo la facultad para decidir sobre
su divulgación. El productor tendrá el derecho exclusivo de realizar,
autorizar o prohibir la realización de modificaciones o versiones sucesivas
del programa, y de programas derivados del mismo. Las disposiciones del
presente artículo podrán ser modificadas mediante acuerdo entre los
autores y el productor.
Art. 30: La adquisición de un ejemplar de un programa de ordenador que
haya circulado lícitamente, autoriza a su propietario a realizar
exclusivamente:
Una copia de la versión del programa legible por máquina (código
objeto) con fines de seguridad o resguardo;
Fijar el programa en la memoria interna del aparato, ya sea que
dicha fijación desaparezca o no al apagarlo, con el único fin y en
la medida necesaria para utilizar el programa; y,
Salvo prohibición expresa, adaptar el programa para su exclusivo
uso personal, siempre que se limite al uso normal previsto en la
37
licencia. El adquirente no podrá transferir a ningún título el
soporte que contenga el programa así adaptado, ni podrá
utilizarlo de ninguna otra forma sin autorización expresa, según
las reglas generales. Se requerirá de autorización del titular de
los derechos para cualquier otra utilización, inclusive la
reproducción para fines de uso personal o el aprovechamiento
del programa por varias personas, a través de redes u otros
sistemas análogos, conocidos o por conocerse.
Art. 31: No se considerará que existe arrendamiento de un programa de
ordenador cuando éste no sea el objeto esencial de dicho contrato. Se
considerará que el programa es el objeto esencial cuando la funcionalidad
del objeto materia del contrato, dependa directamente del programa de
ordenador suministrado con dicho objeto; como cuando se arrienda un
ordenador con programas de ordenador instalados previamente.
Art. 32: Las excepciones al derecho de autor establecidas en los
artículos 30 y 31 son las únicas aplicables respecto a los programas de
ordenador. Las normas contenidas en el presente Parágrafo se
interpretarán de manera que su aplicación no perjudique la normal
explotación de la obra o los intereses legítimos del titular de los derechos.
(Derechos de Propiedad Intelectual, 2006)
Sección Octava
Ciencia, Tecnología, Innovación y Saberes Ancestrales
Art. 385: El sistema nacional de ciencia, tecnología, Innovación y
saberes ancestrales, en el marco del respeto al ambiente, la naturaleza, la
vida, las culturas y la soberanía, tendrá como finalidad:
38
Generar, adaptar y difundir conocimientos científicos y
tecnológicos.
Recuperar, fortalecer y potenciar los saberes ancestrales.
Desarrollar tecnologías e innovaciones que impulsen la
producción nacional, eleven la eficiencia y productividad, mejoren
la calidad de vida y contribuyan a la realización del buen vivir.
Art. 386: El sistema comprenderá programas, políticas, recursos,
acciones, e incorporará a instituciones del Estado, universidades y
escuelas politécnicas, institutos de investigación públicos y privados,
empresas públicas y privadas, organismos no gubernamentales y personas
naturales o jurídicas, en tanto realizan actividades de investigación,
desarrollo tecnológico, innovación y aquellas ligadas a los saberes
ancestrales. El Estado, a través del organismo competente, coordinará el
sistema, establecerá los objetivos y políticas, de conformidad con el Plan
Nacional de Desarrollo, con la participación de los actores que lo
conforman.
Art. 387: Será responsabilidad del Estado:
1. Facilitar e impulsar la incorporación a la sociedad del
conocimiento para alcanzar los objetivos del régimen de
desarrollo.
2. Promover la generación y producción de conocimiento, fomentar
la investigación científica y tecnológica, y potenciar los saberes
ancestrales, para así contribuir a la realización del buen vivir, al
sumak kausay.
3. Asegurar la difusión y el acceso a los conocimientos científicos y
tecnológicos, el usufructo de sus descubrimientos y hallazgos en
el marco de lo establecido en la Constitución y la Ley.
39
4. Garantizar la libertad de creación e investigación en el marco del
respeto a la ética, la naturaleza, el ambiente, y el rescate de los
conocimientos ancestrales.
5. Reconocer la condición de investigador de acuerdo con la Ley.
Art. 388: El Estado destinará los recursos necesarios para la
investigación científica, el desarrollo tecnológico, la innovación, la
formación científica, la recuperación y desarrollo de saberes ancestrales y
la difusión del conocimiento.
Un porcentaje de estos recursos se destinará a financiar proyectos
mediante fondos concursables. Las organizaciones que reciban fondos
públicos estarán sujetas a la rendición de cuentas y al control estatal
respectivo. (Asambela Constituyente, 2008)
Variables de la Investigación
Se identificaría como variables las siguientes:
Administración y gestión de base de datos (variable independiente).
APIs para enlace de información desde MySQL hacia Android
(variable dependiente).
Integración de datos desde el manejador MySQL hacia Android
creando y modificando APIs (variable dependiente).
PREGUNTA CIENTÍFICA A CONTESTARSE
El Sistema de autogestión de la salud para pacientes con diabetes y
asma, desarrollado e implementado en una plataforma Android; con
monitoreo de una aplicación web en PHP dirigida a los médicos tratantes,
enfocado en la administración y gestión de la base de datos para la
integración de datos desde el aplicativo móvil Android hacia el manejador
40
de base de datos MySQL… ¿cumplirá con las expectativas de los usuarios
que la usarán?
DEFINICIONES CONCEPTUALES
Campo: Atributo de una tabla que identifica a una entidad en un
modelo entidad - relación de una base de datos.
Integración: En términos de base de datos, sincronización de
información entre una o más entidades, sistemas gestores de base de
datos, aplicaciones, etc.
Kinect: Es un controlador creado por Microsoft para usarlo en su
consola Xbox 360y PC que utiliza sensores de movimiento como principal
parámetro de entrada además de usar reconocimiento de voz para ejecutar
órdenes y comandos.
Tabla: Nombre de la entidad de la cual está conformada el conjunto de
información ordenada en una base de datos.
SQL: Stucture Query Language, lenguaje universal de programación
que se usa en sistemas de gestión de base de datos.
Smartphone: Generalmente es un dispositivo móvil con panel táctil que
administra diferentes tareas de uso diario ya sean de oficina o personales,
como correos electrónicos, fotos, llamadas, mensajes, etc.
PHP: Hypertetext Preprocessor es un lenguaje de programación
interpretado que se ejecuta del lado del servidor, usado generalmente para
el desarrollo web de páginas dinámicas.
41
CAPÍTULO III
METODOLOGÍA DE LA INVESTIGACIÓN
DISEÑO DE LA INVESTIGACIÓN
POBLACIÓN Y MUESTRA Población
La población a la que se enfoca este proyecto de rediseño de esta
aplicación móvil, afecta a los pacientes registrados en la base de datos
desde la versión anterior del proyecto de App Salud Control.
Con este concepto podemos detallar el siguiente cuadro:
3 CRITERIO PARA DEFINIR LA POBLACIÓN CUADRO N. 3
POBLACIÓN CRITERIO DE DEFINICION DE
POBLACION
CANTIDAD
Pacientes Que hayan registrado sus datos en la
aplicación
Que padezcan o tengas indicios de la
enfermedad relacionada con la
aplicación movil
182
Fuente: Información obtenida de consultas SQL del proyecto Elaborado por: Ricardo Rodríguez Muñiz
42
Según el libro (Guayaquil, 2014) define población como “conjunto o
agregado número de elementos, con caracteres comunes, en un espacio y
tiempo determinados, sobre los cuales se pueden realizar observaciones”.
Muestra
Según el libro (Universidad de Guayaquil, 2014) se conoce como
muestra a un subconjunto que representa los componenetes de una
poblacion o universo.
Para obtener el tamaño de la muestra, se utiliza la siguiente fórmula:
𝑛 =𝑁(𝑍 ∗ 0,5)
1 + (𝑒 ∗ (𝑁 − 1))
En donde:
4 DESCRIPCIÓN DE SÍMBOLOS DE LA MUESTRA CUADRO N. 4
SÍMBOLO DESCRIPCIÓN
N Tamaño de la muestra
𝑍 Constante del nivel de confianza
N Tamaño de la población
E Error máximo permitido (por ejemplo: 2 % = 0.002)
Fuente: Datos para la investigación del proyecto Elaborado por: Ricardo Rodríguez Muñiz
Así mismo, existe una tabla de valores que se usan para la constante de
nivel confianza, la cual se detalla en el siguiente cuadro:
5 DEFINICIÓN DEL ÍNDICE DE CONFIANZA CUADRO N. 5
NIVEL DE CONFIANZA EN PORCENTAJES 90 % 95 % 97 % 98 % 99 %
VALORES 1.645 1.96 2.17 2.326 2.576 Fuente: Datos para la investigación del proyecto
Elaborado por: Ricardo Rodríguez Muñiz
43
Con los datos ya obtenidos, procedemos a definir los valores para
calcular la muestra, usando un error permitido del 5 % y un nivel de
confianza de 90 %:
6 VALORES PARA REEMPLAZAR DE LA MUESTRA
CUADRO N. 6 SÍMBOLO A UTILIZAR CANTIDAD REPRESENTATIVA N 182 𝑍 1.645 e 0.05
Fuente: Datos para la investigación del proyecto Elaborado por: Ricardo Rodríguez Muñiz
Cálculo para a muestra de pacientes:
𝑛 =182(1.645 ∗ 0,5)
1 + (0.05 ∗ (182 − 1))
𝑛 = 85
Entonces, obtenemos que la muestra para este proyecto de titulación es
de:
7 VALORES QUE SE USARAN EN LA MUESTRA
CUADRO N. 7 MUESTRA CANTIDAD
Pacientes 85
Fuente: Datos para la investigación del proyecto Elaborado por: Ricardo Rodríguez Muñiz
RECOLECCIÓN DE LA INFORMACIÓN La información que se utilizó para este análisis se basó en sentencias
SQL de los registros de los pacientes ya almacenados en la base de datos.
Estos registros se obtuvieron el 22 de septiembre del 2017.
44
PROCESAMIENTO Y ANÁLISIS
Pregunta # 1 ¿De los pacientes registrados en la aplicación, cuáles fueron los rangos
de pulsos totales?
8: RESULTADOS DE LA PRIMERA PREGUNTA CUADRO N. 8
RANGOS DE PULSO
CANTIDAD DE PACIENTES
PORCENTAJE
De 40 a 60 18 21 % De 61 a 80 27 32 % Mayor a 80 40 47 %
TOTAL 85 100 % Fuente: Datos para la investigación del proyecto
Elaborado por: Ricardo Rodríguez Muñiz
GRÁFICO 5: RESULTADOS DE LA PRIMERA PREGUNTA
Elaborado: Ricardo Rodríguez Muñiz
Fuente: Datos para la investigación del proyecto
Análisis
El grafico 5 demuestra que existe un mayor número de pacientes
registrados, con un 47 %, con pulso mayor a 80 latidos por minuto según
información tomada con la aplicación, en relación con el 21 % de los
pacientes con pulsos menores a 60 LPM.
45
Pregunta # 2 ¿De los pacientes registrados en la aplicación, cuáles fueron los rangos
de peso totales?
9: RESULTADOS DE LA SEGUNDA PREGUNTA
CUADRO N. 9 RANGOS DE PESO
CANTIDAD DE PACIENTES
PORCENTAJE
De 50 a 80 37 44 % De 81 a 100 29 34 % Mayor a 100 19 22 %
TOTAL 85 100 % Fuente: Datos para la investigación del proyecto
Elaborado por: Ricardo Rodríguez Muñiz
GRÁFICO 6: RESULTADOS DE LA SEGUNDA PREGUNTA
Elaborado: Ricardo Rodríguez Muñiz
Fuente: Datos para la investigación del proyecto
Análisis
En el gráfico 6 indica que el mayor porcentaje de pacientes registrados
en la aplicación tiene un peso aceptable, esto es 44 %, tomando en cuenta
que son pacientes de mayores de 20 años. Pero, a pesar de su peso
equilibrado, existen ciertas personas que eventualmente adelgazan o
pierden peso, por motivo de su preocupación por la enfermedad, por
razones ajenas a esta o por otras dolencias.
46
Pregunta # 3 ¿De los pacientes registrados en la aplicación, cuáles fueron los rangos
de colesterol totales que presentaron hasta ahora?
10: RESULTADOS DE LA TERCERA PREGUNTA CUADRO N. 10
RANGOS DE COLESTEROL
CANTIDAD DE PACIENTES
PORCENTAJE
De 72 a 90 14 16 % De 91 a 120 37 44 % Mayor a 120 34 40 %
TOTAL 85 100 % Fuente: Datos para la investigación del proyecto
Elaborado por: Ricardo Rodríguez Muñiz
GRÁFICO 7: RESULTADOS DE LA TERCERA PREGUNTA
Elaborado: Ricardo Rodríguez Muñiz
Fuente: Datos para la investigación del proyecto
Análisis
El gráfico 7 indica que del total de pacientes elegidos como muestra de
la población de 182, el 44 % tiende a tener valores por encima del promedio
en sus niveles de colesterol en la sangre, pero aún en el rango normal, y
que 40 % de pacientes registran problemas con su salud en este ámbito.
47
Pregunta # 4 ¿De los pacientes registrados en la aplicación, cuáles fueron los valores
de triglicéridos que mostraron hasta ahora?
11: RESULTADOS DE LA CUARTA PREGUNTA CUADRO N. 11
RANGOS DE TRIGLICÉRIDOS
CANTIDAD DE PACIENTES
PORCENTAJE
normal (150 mg/dL) 59 69 % alto (200 - 499 mg/dL) 17 20 %
muy alto (mayor a 500 mg/dL) 9 11 % TOTAL 85 100 %
Fuente: Datos para la investigación del proyecto Elaborado por: Ricardo Rodríguez Muñiz
GRÁFICO 8: RESULTADOS DE LA CUARTA PREGUNTA
Elaborado: Ricardo Rodríguez Muñiz
Fuente: Datos para la investigación del proyecto
Análisis
Con el gráfico 8 se obtiene que existe un alto porcentaje de pacientes
con niveles de triglicéridos por debajo de nivel normal, esto es el 69 % de
pacientes. En contraste con esto, el 11 % de los pacientes tiene un nivel
muy alto de triglicéridos en la sangre, consecuencia de una mala
alimentación y poca actividad física. Es recomendable como sugerencia a
este reporte que, el paciente aumente su nivel de actividad física, para
mejor su calidad de vida y llevar un mejor control de su enfermedad.
48
Pregunta # 5 ¿De los pacientes registrados en la aplicación, cuáles fueron los
resultados según los tipos de ejercicios que practicaban los pacientes?
12: RESULTADOS DE LA QUINTA PREGUNTA CUADRO N. 12
TIPO DE EJERCICIO CANTIDAD DE PACIENTES
PORCENTAJE
Caminar 29 34 % Hacer yoga 4 5 %
Pasear en bicicleta 13 15 % Nadar 3 4 %
No hace actividades 36 42 % TOTAL 85 100 %
Fuente: Datos para la investigación del proyecto Elaborado por: Ricardo Rodríguez Muñiz
GRÁFICO 9: RESULTADOS DE LA QUINTA PREGUNTA
Elaborado: Ricardo Rodríguez Muñiz
Fuente: Datos para la investigación del proyecto
Análisis
Con el resultado del gráfico 9, se puede ver que el 42 % de los pacientes
registrados, prefiere hacer caminatas o simplemente caminar para al
menos hacer alguna actividad física, a diferencia de los que prefieren andar
en bicicleta o hacer yoga lo cual es un porcentaje mínimo, 15 y 5
respectivamente.
49
Pregunta # 6 ¿De los pacientes registrados en la aplicación, cuáles fueron los que
realmente consumían su medicación?
13: RESULTADOS DE LA SEXTA PREGUNTA CUADRO N. 13
DESCRIPCIÓN DE MEDICACIÓN (de pacientes
que)
CANTIDAD DE PACIENTES
PORCENTAJE
Sí termina su medicación 66 78 % No termina su medicación 15 18 %
Nunca la tomaron 4 5 % TOTAL 85 100 %
Fuente: Datos para la investigación del proyecto Elaborado por: Ricardo Rodríguez Muñiz
GRÁFICO 10: RESULTADOS DE LA SEXTA PREGUNTA
Elaborado: Ricardo Rodríguez Muñiz
Fuente: Datos para la investigación del proyecto
Análisis
Como se puede observar en el gráfico 10, el 77 % de los pacientes sí
cumple con su medicación y, por otro lado, el 5 % no la tomaron debido a
que olvidaron hacerlo o no tenían tiempo. Es recomendable que los
pacientes no dejen su medicación a un lado ya que es de mucha
importancia para el control de su enfermedad.
50
Pregunta # 7 ¿De los pacientes registrados en la aplicación, cuáles mostraron llevar
dietas recomendadas según sus controles de salud de diabetes?
14: RESULTADOS DE LA SÉPTIMA PREGUNTA CUADRO N. 14
DESCRIPCIÓN DE DIETA (de pacientes que
mantienen)
CANTIDAD DE PACIENTES
PORCENTAJE
Dieta saludable 27 32 % Dieta regular 42 49 %
No cuidan su dieta 16 19 % TOTAL 85 100 %
Fuente: Datos para la investigación del proyecto Elaborado por: Ricardo Rodríguez Muñiz
GRÁFICO 11: RESULTADOS DE LA SÉPTIMA PREGUNTA
Elaborado: Ricardo Rodríguez Muñiz
Fuente: Datos para la investigación del proyecto
Análisis
En el gráfico 11 se puede observar que el 49 % de los pacientes no
prefiere cuidar su dieta, siendo esto perjudicial para la salud y el avance y
control de su enfermedad. Mientras que el 32 % de pacientes optan por una
dieta saludable, lo cual le beneficia.
51
Pregunta # 8 ¿De los pacientes registrados en la aplicación, cuáles fueron los rangos
de glucosa en la sangre de acuerdo a los controles que han llevado los
pacientes?
15: RESULTADOS DE LA OCTAVA PREGUNTA CUADRO N. 15
RANGOS DE GLUCOSA EN LA SANGRE
CANTIDAD DE PACIENTES
PORCENTAJE
De 70 a 100 mg/Dl 11 13 % De 101 a 140 mg/Dl 46 54 % Mayor a 140 mg/Dl 28 33 %
TOTAL 85 100 % Fuente: Datos para la investigación del proyecto
Elaborado por: Ricardo Rodríguez Muñiz
GRÁFICO 12: RESULTADOS DE LA OCTAVA PREGUNTA
Elaborado: Ricardo Rodríguez Muñiz
Fuente: Datos para la investigación del proyecto
Análisis
Se observa en el gráfico 12 que, el 54 % de pacientes registrados en la
aplicación móvil cuenta con niveles de glucosa en el rango estable,
mientras que el 33 % registra niveles altos de glucosa en la sangre, y el 13
% registra un nivel bajo de glucosa en la sangre, concluyendo que se
encuentran en condiciones estables.
52
Pregunta # 9 ¿De los pacientes registrados en la aplicación, cuáles fueron los valores
de hemoglobina glicolisada según los exámenes complementarios de los
pacientes?
16: RESULTADOS DE LA NOVENA PREGUNTA CUADRO N. 16
RANGOS DE hbA1c EN LA SANGRE
CANTIDAD DE PACIENTES
PORCENTAJE
Menor a 5.7 % 16 19 % Entre 5.7 a 6.4 % 21 25 %
Mayor a 6.4 % 48 56 % TOTAL 85 100 %
Fuente: Datos para la investigación del proyecto Elaborado por: Ricardo Rodríguez Muñiz
GRÁFICO 13: RESULTADOS DE LA NOVENA PREGUNTA
Elaborado: Ricardo Rodríguez Muñiz
Fuente: Datos para la investigación del proyecto
Análisis
Se puede observar en el gráfico 13 que los pacientes registrados en la
aplicación, el 56 % cuenta con niveles elevados de hbA1c en la sangre, a
pesar de ser una prueba que no se realiza con mucha frecuencia. Mientras
que el 25 % de los pacientes registrados cuentan con rangos que podría
estar conduciendo a una pre diabetes tipo 2 o corren el riesgo de desarrollar
esta enfermedad.
53
CAPÍTULO IV
PROPUESTA TECNOLÓGICA
El rediseño de este proyecto (aplicación móvil) permite la sincronización
de datos en modo offline, mediante el uso de procedimientos almacenados
y rediseño de estructuras (tablas), cuando el usuario no dispone de
conexión a internet, permitiendo que sus datos se mantengan guardados
en el teléfono móvil hasta que pueda conectarse a una red con acceso a
internet. Es por esto que este proyecto es factible ya que los datos del
paciente no se perderán y todo esto es posible gracias a la facilidad que
brindan las soluciones Open Source, que, en este caso, se usa como gestor
de base de datos a MySQL.
Además de la aplicación móvil para dispositivos basados en el sistema
operativo más popular en los últimos tiempos, Android, se usa como
solución web, una página que será de uso para los doctores en cual
controlaran el progreso de los pacientes registrados en la aplicación.
Todo esto es posible gracias a la Metodologia Scrum, la cual permite el
control de avances en el proyecto por medio de sprints (sub-tareas cortas
que se revisan periódicamente para terminar una tarea) para así agilizar las
entregas de cada tarea.
54
GRÁFICO 14: ESTRUCTURA CENTRAL DE SCRUM
Elaborado: Procesos de Software, bajo licencia Creative Commons
Fuente: Página principal de Procesos de Software
Valores de la Metodología Scrum
Para obtener un resultado satisfactorio de este rediseño de aplicación,
se debe practicar los siguientes valores:
Compromiso y disciplina.
Énfasis en las tareas y transparencia en su trabajo.
Independencia.
GRÁFICO 15: VALORES DE LA METODOLOGÍA SCRUM
Elaborado: Ricardo Rodríguez Muñiz Fuente: fuente propia
55
A partir de aquí se detallará los procesos de negocio y estructuras que
fueron creadas y modificadas, así como las herramientas usadas:
SQLYog Community Edition
Es una herramienta de interfaz de usuario gráfica (GUI, por sus siglas en
inglés Graphical User Interface) diseñada para el sistema de gestión de
base de datos relacional MySQL, programada en C++ disponible para los
sistemas operativos Windows, Linux y Mac OS (usando el virtualizador
Wine, para estos dos últimos).
Como unas de las principales características que ofrece son la
productividad mejorada, permitiendo código de autocompletado inteligente
y; productividad para administradores de base de datos, como,
administradores de usuarios, administrador de conexiones, administrador
de índices, reordenamiento de columnas, administrador de claves primarias
y foráneas y, muchas otras características, que lastimosamente solo están
disponibles en la versión de pago (Enterprise y Ultimate).
Además, en comparación con otras herramientas para la gestión del
motor de base de datos MySQL, como son MySQL Workbench, Toad for
MySQLy SQuirreL SQL, esta GUI, está por encima de todas esas
herramientas ya que ofrece facilidad de uso, inicio de transacciones,
exportar datos de tablas de manera sencilla, editar registros en el mimo
resultado de una consulta, administrar conexiones de manera rápida.
56
GRÁFICO 16: VENTANA PRINCIPAL DE SQLyog
Elaborado: Ricardo Rodríguez Muñiz Fuente: Página principal de webyog
Estructuras modificadas
alarma_medicacion - control_medicacion
Estas estructuras sirven para controlar las alarmas de las
medicaciones que el paciente registrar al momento de iniciar una
medicación, controlando por horas las dosis que debe ingerir / aplicar
de tal medicamento y, para saber si la medicación fue ingerida o no.
Para esto es la estructura control_medicacion.
Para el control de la integración entre la base de datos Android y la
base de datos MySQL, el campo id_alarma_medicacion, auto
57
incrementable y clave primaria, se enviará como parámetro de salida
en el procedimiento de insertar las alarmas. De la misma manera, el
campo id_control_medicacion hará lo mismo con el proceso de
negocio correspondiente.
En la figura se puede ver la descripción de cada estructura con sus
respectivos campos y tipos de datos:
GRÁFICO 17: DESCRIPCIÓN DE TABLAS ALARMAS Y CONTROL MEDICACIÓN
Elaborado: Ricardo Rodríguez Muñiz
Fuente: fuente propia
medicamento – medicación
Estas estructuras son complementarias con alarma_medicacion y
control_medicacion ya que aquí se encuentran los medicamentos
que el paciente registrará para el control de su medicación
dependiendo de sus necesidades patológicas y, para el registro de
la medicación tanto como la dosis, frecuencia y descripción de la
misma, fecha de inicio y fin de la medicación.
58
Varios de los campos de estas estructuras fueron modificados para
adaptarse a la necesidad del rediseño actual de la aplicación móvil
y web, así como la longitud de varios campos y tipos de datos que
resultaban insuficientes a la hora de registrar la medicación o el
medicamento respectivamente.
Para este caso, la estructura medicación cuenta con sus procesos
de negocio para el mantenimiento, el cual devolverá el campo
identificador id_medicacion.
GRÁFICO 18: DESCRIPCIÓN DE TABLAS MEDICAMENTO Y MEDICACIÓN
Elaborado: Ricardo Rodríguez Muñiz
Fuente: fuente propia
detalle_peso
Esta estructura, como su nombre lo indica, sirve para registrar el
peso del paciente, además de otros valores importantes referentes
a ello, como son Índice de Masa Corporal (IMC), Tasa Metabólica
Basal (TMB), Densidad Media Ósea (DMO), así como también
fechas de registro, actualización y eliminación.
59
Al igual que las demás estructuras, también cuenta con el campo
identificador, id_detalle_peso, el cual sirve para la integración entre
bases de datos para la funcionalidad fuera de línea (offline), que será
devuelto como parámetro de salida en su respectivo proceso de
negocio de mantenimiento (insertar).
GRÁFICO 19: DESCRIPCIÓN DE TABLA DETALLE_PESO
Elaborado: Ricardo Rodríguez Muñiz
Fuente: fuente propia
detalle_presion
Esta estructura indica que registrará el pulso del paciente asi como
otros valores escenciales, como la fecha en que se tomó el pulso,
presión diastolica, presión sistólica y el identificador medio, que
indica generelmente, en qué estado se encontraba el paciente al
momento de tomarse la presión / pulso.
60
El campo id_detalle_presion servirá como identificador al momento
la integración entre las bases de datos, para la modalidad offline de
la aplicación móvil.
Al igual que los demás estructuras, también cuenta con procesos de
negocio de mantemiento el cual sirve para devolver como parametro de
salida, que ayudará en la integración entre bases de datos.
GRÁFICO 20: DESCRIPCIÓN DE TABLA DETALLE_PRESION
Elaborado: Ricardo Rodríguez Muñiz
Fuente: fuente propia
detalle_colesterol
Esta estructura permite registrar los diferentes valores relacionados
con el colesterol del paciente, como son colesterol total, triglicéridos,
Lipoprotenia de Alta Densidad (HDL, por sus siglas en inglés, High
Density Lipoprotein) también conocido como colesterol bueno,
Lipoproteina de Baja Densidad (LDL, por sus siglas en inglés, Low
Density Lipoprotein), campos relacionados con fechas, y el más
61
importante para este rediseño, el campo identificador de la estructura
id_det_colesterol, que como las demás estructuras, permite la
integración entre bases de datos por medio de los procesos de
negocio de mantenimiento que lo devuelven como parámetro de
salida.
GRÁFICO 21: DESCRIPCIÓN DE TABLA DETALLE_COLESTEROL
Elaborado: Ricardo Rodríguez Muñiz
Fuente: fuente propia
examenes_complementarios
Esta estructura sirve para registrar exámenes que son necesarios
para el paciente con diabetes, para un mejor control de su
enfermedad, tales como cetonas, prueba de hemoglobina glicosilada
(hba1c) y campos complementarios como fecha de toma del examen
y estado del mismo.
El identificador de la estructura id_examen_complemt es el que
ayudará en la integración entre bases de datos ya que será devuelto
62
como parámetro de salida en los procesos de negocio de
mantenimiento.
GRÁFICO 22: DESCRIPCIÓN DE TABLA EXAMENES_COMPLEMENTARIOS
Elaborado: Ricardo Rodríguez Muñiz
Fuente: fuente propia
Store procedures o procesos de negocio modificados
Como ya se nombró en los puntos anteriores, se vio la necesidad de
modificar ciertos procesos de negocio existentes para que cumplan
con el objetivo del rediseño de la aplicación móvil y web, asimismo
para que controlen los errores que podría haber en el momento de
la ejecución de los mismos, ya que en la versión anterior de este
proyecto no se implementaron por diferentes razones ajena a la
actual investigación; por este motivo los procesos para el
mantenimiento de las estructuras involucrados fueron:
63
pr_inserta_alarma_medicacion
Este proceso se encarga de registrar las alarmas que el paciente
configuró en su medicación, en la estructura alarma_medicacion.
Como su nombre lo indica, inserta en la estructura los campos
indicados como parametros de entrada y para lo que se necesita,
devuelve el identificador de la estructura para la integración, como
pn_id_alarma_medic_new, de tipo de dato int. Además, realiza las
respectivas validaciones de inserción y de valores nulos o no
existentes, utilizando los bloques de excepciones controladas de
MySQL como son declare exit handler for o, declare continue handler
for… las cuales son muy útiles para el control de eventos y registro
de logs en las tablas de bitácora.
GRÁFICO 23: PARTE DEL CODIGO DEL SP PR_INSERTA_ALARMA_MEDICACION
Elaborado: Ricardo Rodríguez Muñiz
Fuente: fuente propia
pr_inserta_control_medicacion
Este proceso de negocio se encarga de registrar si la medicación fue
consumida o no por el paciente, devolviendo el identificador
64
id_control_medicacion, como parámetro de salida en la variable
pn_id_control_medic_new de tipo de dato int.
Valida que los campos insertados como parámetros de entrada en
el proceso, no estén vacíos y que existan, dependiendo del caso,
como la medicación del paciente a la que este asociado.
Además, se incluye la validación de excepciones con el controlador
de excepciones de MySQL Exception Handler, los cuales se
configuraron para el caso de errores generales y errores específicos
tales como campos nulos o duplicados y, por algún error que ocurra
al momento de la ejecución del procedimiento.
GRÁFICO 24: PARTE DEL CÓDIGO DE SP PR_INSERTA_CONTROL_MEDICACION
Elaborado: Ricardo Rodríguez Muñiz
Fuente: fuente propia
pr_inserta_medicacion
Este proceso de negocio permite registrar la medicación que el
paciente escoge al momento de chequear en el módulo medicación.
65
Existen opciones como frecuencias, cuantas veces al día se tomará
la medicación y cuántos medicamentos tomará.
Valida los parámetros de entrada tanto como el identificador que se
necesita como parámetro de salida, el campo id_medicacion, en la
variable pn_id_medicacion_new de tipo de dato int.
GRÁFICO 25: PARTE DEL CÓDIGO DEL SP PR_INSERTA_MEDICACION
Elaborado: Ricardo Rodríguez Muñiz
Fuente: fuente propia
pr_inserta_presion
Este proceso de negocio permite registrar todos los valores
relacionados con la presión del paciente, en la estructura
detalle_presion, tal y como se describió más arriba.
Valida los parámetros de entrada del proceso para que no sean
valores nulos o valores inexistentes. El identificador necesario para
66
la integración de bases de datos se devuelve como parámetro de
salida en la variable pn_id_detalle_presion_new, de tipo de dato int;
validándolo de que efectivamente se devuelva y no sea un valor nulo.
GRÁFICO 26: PARTE DE CÓDIGO DEL SP PR_INSERTA_PRESION
Elaborado: Ricardo Rodríguez Muñiz
Fuente: fuente propia
pr_inserta_peso
Este proceso permite registrar todos los valores relacionados con el
peso del paciente y, como fue descrito en la sección de estructuras
modificadas, devuelve como parámetro de salida el identificador
id_detalle_peso, en la variable de salida pn_id_detalle_peso_new,
que sirve para la integración entre bases de datos, Android y
MySQL.
67
GRÁFICO 27: PARTE DE CÓDIGO DEL SP PR_INSERTA_PESO
Elaborado: Ricardo Rodríguez Muñiz
Fuente: fuente propia
Así como en cada imagen en la que se describe parte del código de los
procedimientos almacenados que fueron modificados y/o creados, se
adjunta también como parte de los anexos el código fuente de estos para
una revisión más detallada.
ANÁLISIS DE LA FACTIBILIDAD
La aplicación móvil a utilizarse permite ser compatible con la mayoría de
teléfonos móviles, con sistema operativo Android (siendo la mejor versión
para utilizar la aplicación la versión 4.0.3 en adelante) existentes en el
mercado además de consumir pocos recursos hardware del mismo, siendo
intuitivo y de fácil uso para el usuario, debido a su interfaz amigable.
También cuenta con pantallas de tutoriales para los diversos módulos que
tiene el aplicativo para mejorar la experiencia del usuario con la aplicación.
En cuanto a la versión web, para los médicos tratantes, también cuenta de
una interfaz fácil de utilizar.
68
Factibilidad Operacional
La restructuración de este proyecto consta con el apoyo de la
Universidad de Guayaquil ya que aporta con el avance en la tecnología
para la comunidad y más si se trata del campo de la salud.
Factibilidad técnica
Este análisis permite determinar la viabilidad de la restructuración de
esta aplicación móvil en cuanto a hardware y software disponible para este
proyecto. Basándose en las herramientas que ya se usaron para la primera
versión de este proyecto, apuntando al beneficio que ofrecen las
herramientas Open Source y las ventajas de contar con equipos de
desarrollo propio.
Por esto, se detallarán las herramientas que se usaron para este
proyecto:
17: DESCRIPCIÓN DEL HARDWARE UTILIZADO PARA EL PROYECTO
CUADRO N. 17 TIPO DE EQUIPO PC laptop
MARCA DELL
SISTEMA
OPERATIVO
Microsoft Windows 7 Professional
SP1
PROCESADOR Intel Core i3
DISCO DURO 500 GB
RAM 12 GB
Fuente: Fuente propia Elaborado por: Ricardo Rodríguez Muñiz
69
Para las herramientas software, se detalla el siguiente cuadro:
18: DESCRIPCIÓN DEL SOFTWARE UTILIZADO EN EL PROYECTO CUADRO N. 18
Sistema gestor base de datos
relacional MySQL 5.7.x
Licencia GPL
Herramienta de interfaz gráfica de
usuario SQLYog 12.4.x para
MySQL
Licencia GPL (Community Edition)
Fuente: Fuente propia Elaborado por: Ricardo Rodríguez Muñiz
Factibilidad Legal
Todo la aplicación móvil y aplicación web están basados en software de
licencia Open Source GPL y con el apoyo de la Free Software Foundation,
por lo tanto, se concluye que no hay leyes vigentes hasta el momento que
se puedan quebrantar. Esto se puede corroborar con lo siguiente:
DECRETO N° 1014
DEL GOBIERNO ACERCA DEL USO DE SOFTWARE LIBRE
Artículo 1: Establecer como política pública para las Entidades de la
Administración Pública Central la utilización de Software Libre en sus
sistemas y equipamientos informáticos.
Artículo 2: Se entiende por Software Libre a los programas de
computación que se pueden utilizar y distribuir sin restricción alguna, que
70
permite el acceso a sus códigos fuentes y que sus aplicaciones pueden ser
mejoradas.
Estos programas de computación tienen las siguientes libertades:
a) Utilización del programa con cualquier propósito de uso común.
b) Distribución de copias sin restricción alguna.
c) Estudio y modificación del programa (Requisito: código fuente
disponible).
d) Publicación del programa mejorado (Requisito: código fuente
disponible).
Artículo 3.- las entidades de la Administración Publica Central previa a
la instalación del software libre en sus equipos, deberán verificar la
existencia de capacidad técnica que brinde el soporte necesario para el uso
de este tipo de software.
Articulo 4.- Se efectúa la utilización de software propietario (no libre)
únicamente cuando exista una solución de Software Libre que supla las
necesidades requeridas, o cuando esté en riesgo la seguridad nacional, o
cuando el proyecto informático se encuentre en un punto de no retorno.
Para efectos de este decrete se comprende como seguridad nacional, las
garantías para la supervivencia de la colectividad y la defensa de
patrimonio nacional.
Para efectos de este decreto se entiende por punto de no retorno cuando
el sistema o proyecto informático se encuentre en cualquiera de estas
condiciones:
71
a) Sistema en producción funcionando satisfactoriamente y que un
análisis de costo beneficio muestre que no es razonable ni
conveniente una migración a Software Libre.
b) Proyecto en estado de desarrollo y que un análisis de costo –
beneficio muestre que no es conveniente modificar el proyecto y
utilizar Software Libre.
Periódicamente se evaluarán los sistemas informáticos que utilizan
software propietario con la finalidad de migrarlos a Software Libre.
Artículo 5.- Tanto para software libre como para software propietario,
siempre y cuando se satisfagan los requerimientos, se debe preferir las
soluciones en este orden:
a) Nacionales que permitan autonomía y soberanía tecnológica.
b) Regionales con componente nacional.
c) Regionales con proveedores nacionales.
d) Internacionales con componentes nacionales.
e) Internacionales con proveedores nacionales.
f) Internacionales.
Artículo 6.- La subsecretaría de Informática como órgano regulador y
ejecutor de las políticas y proyectos informáticos en las entidades del
Gobierno Central deberá realizar el control y seguimiento de este Decreto.
Para todas las evaluaciones constantes en este decreto la Subsecretaría
de Informática establecerá los parámetros y metodología obligatorias.
(Decreto Ejecutivo 1014, 2008)
72
Factibilidad Económica
Gracias a una de las ventajas que ofrece software Open Source, no se
requiere de gastos para uso de licencias, se concluye que los egresos que
implican en este proyecto son mínimos, para lo cual se detalla cada uno de
los rubros en los que se requirió invertir costos:
19: DESCRIPCIÓN DE PRESUPUESTO PARA EL PROYECTO CUADRO N. 19
DESCRIPCIÓN RUBROS
ESTUDIANTES
TIEMPO/HORAS
PRECIO HORA
TOTAL
Recursos humanos
1 360 $8 $2880
Recursos hardware
$0 $0
Recursos software
$0 $0
Viajes y salidas de campo
$0 $0
Recursos varios Transporte
Alimentación
Servicio de Internet
$50 $40 $40
Servicios técnicos
$0
TOTAL $3010 Fuente: Información recopilada del proyecto
Elaborado por: Ricardo Rodríguez M.
ETAPAS DE LA METODOLOGÍA DEL PROYECTO
Como ya me mencionó en secciones anteriores, para llevar un mejor
control y entregar avances de una manera eficaz y oportuna, se utilizó la
73
metodología Scrum, para lo cual se hablará de las fases por las cuales se
vio involucrado el rediseño de la aplicación, en el siguiente cuadro:
20: SPRINTS DE ACTIVIDADES DEL PROYECTO CUADRO N. 20
Sprint Descripción del sprint
1 Análisis y rediseño de estructuras y procesos para registro
de modulo presión / peso, con integración en plataforma
móvil
2 Análisis y gestión con Android para identificar parámetros
necesarios para proceso de migración offline
3 Cambios en procesos para actualización de exámenes
complementarios; sección colesterol aplicando cambios de
presión
4 Desarrollo de proceso para migrar información desde BD
server hacia BD Android – implementando modo offline
5 Pruebas de integración de procesos, modulo control
paciente, glucosa, colesterol, presión / peso y exámenes
complementarios con equipo de WEBSERVICES
6 Corrección de procesos de negocio actualizar credenciales,
ingresar presión, ingresar peso
7 Fase de documentación
Fuente: Información recopilada en la problemática del proyecto Elaborado por: Ricardo Rodríguez Muñiz
A continuación, se describirá cada uno de los sprints según la etapa de
desarrollo del proyecto:
Sprint N. 1: En esta fase se llevó a cabo al análisis que se necesitaba
para cada proceso de negocio de los módulos de presión y peso, para
insertar, actualizar y eliminar y modificación de las estructuras para que
soporten el envío del identificador.
74
GRÁFICO 28: DESCRIPCIÓN DEL SPRINT 1
Elaborado: Ricardo Rodríguez Muñiz
Fuente: Página principal de Trello
Sprint N. 2: En esta fase se mantuvo reuniones con el equipo Android
para establecer métodos y procesos se necesitarán implementar o
modificar para la integración y migración de registros entre las bases de
datos.
GRÁFICO 29: DESCRIPCIÓN DEL SPRINT 2
Elaborado: Ricardo Rodríguez Muñiz Fuente: Página principal de Trello
75
Sprint N. 3: En esta etapa se modificaron procesos de negocio y
estructuras que involucran a la actualización de los registros para los
módulos de exámenes complementarios y colesterol, basándose en los que
ya se modificaron del módulo de presión.
GRÁFICO 30: DESCRIPCIÓN DEL SPRINT 3
Elaborado: Ricardo Rodríguez Muñiz Fuente: Página principal de Trello
Sprint N. 4: En esta fase se desarrolla los procesos de negocio para la
implementación de la integración entre la base de datos MySQL y la base
de datos Android.
GRÁFICO 31: DESCRIPCIÓN DEL SPRINT 4
Elaborado: Ricardo Rodríguez Muñiz
Fuente: Página principal de Trello
76
Sprint N. 5: En esta fase de pruebas, se verifica que todos los procesos
de negocio modificados (control paciente, glucosa, colesterol, presión /
peso y exámenes complementarios) y creados además de las estructuras,
cumplan con los requisitos planteados al inicio de este proyecto, en
conjunto con el equipo de Webservices.
GRÁFICO 32: DESCRIPCIÓN DEL SPRINT 5
Elaborado: Ricardo Rodríguez Muñiz
Fuente: Página principal de Trello
Sprint N. 6: En esta etapa se mejoró y corrigió los procesos de negocio
que presentaron ciertos inconvenientes y tales como validaciones, datos no
guardados o no replicados, así como también por filtros, que gracias a la
retroalimentación que proporcionaron los miembros de otros equipos, como
procesos e infraestructura, se pudo llevar a cabo las tareas requeridas en
el tiempo esperado. Los inconvenientes con los procesos de negocio fueron
resueltos gracias al apoyo de la comunidad de software libre que trabaja en
el mantenimiento y soluciones a problemas del motor de base de datos que
se usa en este proyecto, MySQL.
77
GRÁFICO 33: DESCRIPCIÓN DEL SPRINT 6
Elaborado: Ricardo Rodríguez Muñiz
Fuente: Página principal de Trello
Sprint N. 7: En esta fase se comienza con la documentación de cada
uno de los procesos involucrados en el rediseño de la aplicación móvil y
web.
GRÁFICO 34: DESCRIPCIÓN DEL SPRINT 7
Elaborado: Ricardo Rodríguez Muñiz
Fuente: Página principal de trello
78
Entregables del proyecto
Para el rediseño de este proyecto, como documentación se entregará lo
siguiente:
Anillados de tesis.
Documentación de tesis (empastado).
CDs con documentación y entregables del proyecto
CRITERIOS DE VALIDACIÓN DE LA PROPUESTA
Pare describir las estrategias de validación que se usaron para la
restructuración del proyecto, se cuenta con el siguiente informe de pruebas:
Informe de pruebas de la aplicación
Como cambio emergente de las estructuras, se valida que los
módulos modificados y creados devuelvan el identificador que
se necesita de parte de los servicios del sistema operativo
Android, que estará a la espera del mismo, todo esto a nivel
de base de datos MySQL.
Se valida que los módulos modificados y creados devuelvan
el campo identificador de cada estructura, ahora entre la base
de datos y los servicios web configurados que servirán de
puente entre el dispositivo móvil y la base de datos MySQL.
Como validación principal, se verifica que los módulos en el aplicativo
móvil guarden correctamente los registros y a su vez, se sincronicen los
datos una vez el usuario haya iniciado sesión con su cuenta.
Criterios de aceptación del producto o Servicio
En esta sección se describen los criterios de aceptación del proyecto, de
acuerdo en lo que este se ajusta y cumple y, en lo que se ha probado, los
alcances que se plantearon para demostrar que el mismo, satisface las
79
necesidades que se plantearon al principio de este proyecto, considerando
lo descrito en el cuadro número 21, lo siguiente como criterio de aceptación:
21: CRITERIOS DE ACEPTACIÓN DEL PROYECTO
CUADRO N. 21 ASPECTOS A
TRATAR CRITERIOS NIVEL DE
CUMPLIMIENTO Procesos involucrados con los módulos para control de enfermedades y medicación
Cada proceso de negocio cumple con lo establecido en todos sus niveles de mantenimiento y,
Cada estructura cumple con su nivel de respuesta y datos ingresados y retornados.
100 %
Rediseño de la estructura del proceso de negocio para soportar control de errores y retorno de parámetro de salida el identificador de la tabla correspondiente.
Cada validación que involucra al ingreso de datos y control de variables existentes, cumple con lo establecido.
Las excepciones controladas en los procesos de negocio cumplen con los requerido.
100 %
Control de calidad aplicado a cada proceso de negocio de los módulos correspondientes
Los datos que se ingresan mantienen un mismo formato (entero, alfanúmero, coma flotante)
La información en las estructuras cumple con lo que requiere cada proceso de negocio / método Webservices para su correcta integración.
100 %
Fuente: Datos para la investigación del proyecto Elaborado por: Ricardo Rodríguez Muñiz
80
CONCLUSIONES
La modificación de las estructuras y Store Procedures están organizados
de tal manera que sean comprensibles y así mismo, puedan ser adaptados
dependiendo de futuras necesidades. Por lo tanto, soportan la integración
de información para los módulos de control enfermedad y control
medicación.
Al implementar las reglas de negocio en los procedimientos
almacenados durante la ejecución de transacciones de los módulos control
enfermedades y control medicamentos de la aplicación Salud Control, se
pudo comprobar, mediante el uso de las tablas de bitácoras que guardan
los registros de eventos durante cada iteración de los Store Procedures,
que la base de datos móvil sí recibía con éxito los datos para mantener su
proceso offline sin perder la interacción con el usuario.
Todas las APIs de procesamiento en las que se implementaron las
validaciones, con bloques de excepciones y uso de las APIs de
bitacoriazación, cumplen con el envío de los mensajes correspondientes
(parámetros de salida), ya sea por error o por éxito, asegurando que las
transacciones de los procedimientos entre la base de datos móvil y el
manejador MySQL sean correctas.
Se desarrollaron pruebas ‘pilotos’ de la aplicación, con el fin de cumplir
con las expectativas por las que fue rediseñado. También se incluye un
estudio estadístico de los usuarios ingresados en cada prueba piloto con
sus datos actualizados.
81
RECOMENDACIONES
Se recomienda continuar con los mismos esquemas de definiciones para
las estructuras y procedimientos almacenados para evitar confusiones al
momento de realizar nuevas implementaciones y/o mejoras y así poder
adaptar y reusar código.
Es recomendable que, para futuras versiones de la aplicación, así como
para los módulos de control de diferentes enfermedades se apliquen estas
reglas de negocio a los Store Procedures para obtener un mejor control de
los errores en tiempo de ejecución.
En próximas actualizaciones se sugiere tomar en cuenta las
configuraciones que se les dio a los logs y que, con esto, sea más eficaz al
momento de informar lo que ocurre con los APIs de procesamiento para
poder conocer acerca de los errores controlados del propio motor base de
datos.
Para asegurar que las pruebas de las APIs de procesamiento sean
siempre exitosas, se recomienda que estas sean organizadas y realizadas
de manera oportuna, con el equipo de trabajo (tanto de desarrollo humano
como electrónico) completo evitando retrasos en las demás
implementaciones.
BIBLIOGRAFÍA
Asambela Constituyente. (20 de 10 de 2008). INOCAR. Obtenido de
http://www.inocar.mil.ec/web/images/lotaip/2015/literal_a/base_lega
l/A._Constitucion_republica_ecuador_2008constitucion.pdf
Bembibre, V. (25 de 02 de 2009). Definición ABC. Obtenido de
https://www.definicionabc.com/tecnologia/mysql.php
Decreto Ejecutivo 1014. (23 de abril de 2008). Control Hidrocarburos.
Obtenido de http://www.controlhidrocarburos.gob.ec/wp-
content/uploads/MARCO-LEGAL-2016/Registro-Oficial-322-
Decreto-Ejecutivo-1014.pdf
Derechos de Propiedad Intelectual. (28 de diciembre de 2006). SICE.
Obtenido de
http://www.sice.oas.org/int_prop/nat_leg/Ecuador/L320b.asp
García Falconí, J. (28 de abril de 2011). Derecho Ecuador. Obtenido de
http://www.derechoecuador.com/articulos/detalle/archive/doctrinas/
derechoinformatico/2011/02/07/la-proteccion-de-datos-personales
IDERA. (21 de enero de 2014). www.idera.gob.ar. Obtenido de
http://www.idera.gob.ar/portal/sites/default/files/TrelloTutorialBasico
INEC. (20 de julio de 2016). Ecuador en cifras. Obtenido de
http://www.ecuadorencifras.gob.ec/en-cinco-anos-se-
quintuplicaron-los-usuarios-de-telefonos-inteligentes/
LOES. (12 de octubre de 2010). Planificación Ecuador. Obtenido de
http://www.planificacion.gob.ec/wp-
content/uploads/downloads/2012/08/Ley-Org%C3%A1nica-de-
Educaci%C3%B3n-Superior.-Suplemento-del-Registro-Oficia-Nro.-
298..pdf
Mercedes Kamijo, Álvaro Fernández, Susana Trabaldo. (2015). Mobile
Learning: Nuevas realidades en el aula. Obtenido de
https://books.google.com.ec/books?id=AULhBgAAQBAJ&pg=PT#v
=onepage&q&f=false
Merino, M. (12 de julio de 2014). TICbeat. Obtenido de
http://www.ticbeat.com/tecnologias/que-es-una-api-para-que-sirve/
Microsoft. (2017). Soporte Office. Obtenido de
https://support.office.com/es-es/article/Conceptos-b%C3%A1sicos-
sobre-bases-de-datos-a849ac16-07c7-4a31-9948-3c8c94a7c204
Pinola, M. (02 de 08 de 2015). Gizmodo. Obtenido de
https://es.gizmodo.com/como-organizar-toda-tu-vida-utilizando-
trello-1684529913
Rodríguez, C. (21 de septiembre de 2015). Marketing Farmacéutico.
Obtenido de http://marketingfarmaceutico.bsm.upf.edu/lo-digital-las-
apps-moviles-sector-la-salud/
Universidad de Guayaquil. (2014). Proyectos de Investigación Proceso
Paso a Paso. Guayaquil: Edciones Minerva.
Zudaire, M. (4 de junio de 2014). EROSKI CONSUMER, el diario del
consumidor. Obtenido de
http://www.consumer.es/web/es/alimentacion/aprender_a_comer_bi
en/2014/06/04/220023.php
Zudaire, M. (4 de junio de 2014). Aplicaciones para una alimentación y
una vida sana. Obtenido de
http://www.consumer.es/web/es/alimentacion/aprender_a_comer_bi
en/2014/06/04/220023.php
ANEXOS Modelo Entidad – Relación de la base de datos actual App Salud Control
MODELO Entidad – Relación de la base de datos versión anterior (versión 1) App Salud Control
Códigos fuente de los Store Procedures modificados PROCEDIMIENTO PR_INSERTA_MEDICACION DELIMITER $$ USE `oap`$$ DROP PROCEDURE IF EXISTS `PR_INSERTA_MEDICACION`$$ CREATE DEFINER=`bdadmin`@`%` PROCEDURE `PR_INSERTA_MEDICACION`(IN PV_CODIGO_PACIENTE VARCHAR(50), -- EMAIL IN PN_ID_MEDICAMENTO INT, IN PN_DOSIS_MEDICAMENTO INT, IN PV_TIPO_FRECUENCIA VARCHAR(1), -- F FRECUENCIA / I INTERVALO IN PN_VECES_DOSIS INT, IN PV_DESCRIPCION_FRECUENCIA VARCHAR(50), IN PD_FECHA_INICIO DATETIME, IN PD_FECHA_FIN DATETIME, IN PV_OBSERVACION VARCHAR(1000), OUT PN_ID_MEDICACION_NEW INT, OUT PN_ERROR INT, OUT PV_ERROR VARCHAR(1000)) BEGIN /*============================ AUTOR: RICARDO RODRIGUEZ M. FECHA: 01/AGOSTO/2017 TITULACION 2017 CICLO 2 ===============================*/ DECLARE LN_ID_PACIENTE INT; DECLARE LD_FECHA_INICIO DATETIME DEFAULT NOW(); DECLARE LV_ERROR VARCHAR(1000); DECLARE LV_EXCEPCION VARCHAR (20); DECLARE LN_ERROR INT DEFAULT 1; DECLARE NO_NULO CONDITION FOR 1048; DECLARE DUPLICADO CONDITION FOR 1062; DECLARE LV_EXISTE_MEDICAMENTO VARCHAR(1); DECLARE EXIT HANDLER FOR NO_NULO
IF LN_ERROR = 1 THEN -- ROLLBACK; NO FUNCIONA A MENOS QUE SE DESACTIVE EL AUTO-COMMIT EN EL DBMS SET PN_ERROR = 1; SET PV_ERROR = 'NO SE PUEDEN INSERTAR CAMPOS VACIOS O NULOS!'; CALL OAP.BITACORIZA_ERROR (PV_CODIGO_PACIENTE, 'ANDROID', 'MEDICACION', PV_ERROR); END IF; DECLARE EXIT HANDLER FOR DUPLICADO IF LN_ERROR = 1 THEN -- ROLLBACK; NO FUNCIONA A MENOS QUE SE DESACTIVE EL AUTO-COMMIT EN EL DBMS SET PN_ERROR = 1; SET PV_ERROR = 'ERROR AL INSERTAR REGISTRO! YA EXISTE ID INSERTADO'; CALL OAP.BITACORIZA_ERROR (PV_CODIGO_PACIENTE, 'ANDROID', 'MEDICACION', PV_ERROR); END IF; DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; -- NO FUNCIONA A MENOS QUE SE DESACTIVE EL AUTO-COMMIT EN EL DBMS SET PN_ERROR = 1; IF LN_ERROR = 2 THEN SET PV_ERROR = CONCAT ('ERORR: ', LV_ERROR); ELSE SET PV_ERROR = 'ERROR GENERAL!'; END IF; CALL OAP.BITACORIZA_ERROR (PV_CODIGO_PACIENTE, 'ANDROID', 'MEDICACION', PV_ERROR); END; -- para buscar el paciente usando el la identificacion que se obtuvo por parámetro de entrada IF PV_CODIGO_PACIENTE IS NOT NULL THEN CALL OAP.BUSC_PAC (PV_CODIGO_PACIENTE, LN_ID_PACIENTE);
IF LN_ID_PACIENTE IS NULL THEN SET LN_ERROR = 2; SET LV_ERROR = 'ERROR EN EL PROCESO DE BÚSQUEDA DE PACIENTE.'; SET LV_EXCEPCION = MESSAGE; END IF; ELSE SET LN_ERROR = 1; SET LV_ERROR := MESSAGE; END IF; IF PD_FECHA_INICIO IS NULL THEN SET PD_FECHA_INICIO = LD_FECHA_INICIO; ELSE SELECT STR_TO_DATE (PD_FECHA_INICIO, '%Y-%m-%d %T') INTO LD_FECHA_INICIO; END IF; SET LV_EXISTE_MEDICAMENTO = (SELECT 'X' FROM `OAP`.`MEDICAMENTO` P WHERE P.ID_MEDICAMENTO = PN_ID_MEDICAMENTO AND P.ESTADO = 'A'); IF LV_EXISTE_MEDICAMENTO IS NULL THEN SET LN_ERROR = 2; SET LV_ERROR = 'NO SE ENCUENTRA MEDICAMENTO ASOCIADO CON SU MEDICACION!'; SET LV_EXCEPCION = MESSAGE; END IF; IF LV_EXISTE_MEDICAMENTO IS NOT NULL AND LN_ID_PACIENTE IS NOT NULL THEN START TRANSACTION; INSERT INTO `OAP`.`MEDICACION` (`ID_PACIENTE`, `ID_MEDICAMENTO`, `DOSIS_MEDICAMENTO`, `TIPO_FRECUENCIA`, `VECES_DOSIS`, `DESCRIPCION_FRECUENCIA`, `FECHA_INICIO`, `FECHA_FIN`, `OBSERVACION`)
VALUES (LN_ID_PACIENTE, PN_ID_MEDICAMENTO, PN_DOSIS_MEDICAMENTO,
PV_TIPO_FRECUENCIA, PN_VECES_DOSIS, UPPER(PV_DESCRIPCION_FRECUENCIA), IFNULL (PD_FECHA_INICIO, LD_FECHA_INICIO), PD_FECHA_FIN, UPPER(PV_OBSERVACION)); SET PN_ID_MEDICACION_NEW = (SELECT LAST_INSERT_ID());/*P.ID_MEDICACION FROM `OAP`.`MEDICACION` P WHERE P.ID_PACIENTE = LN_ID_PACIENTE AND P.FECHA_INICIO = LD_FECHA_INICIO AND P.ID_MEDICAMENTO = PN_ID_MEDICAMENTO AND P.TIPO_FRECUENCIA = PV_TIPO_FRECUENCIA AND P.DESCRIPCION_FRECUENCIA = PV_DESCRIPCION_FRECUENCIA);*/ SET PN_ERROR = 0; END IF; IF PN_ID_MEDICACION_NEW IS NULL THEN SET LN_ERROR = 2; SET LV_ERROR = 'NO SE PUDO OBTENER NUEVA SECUENCIA PARA LA TABLA MEDICACION!'; SET LV_EXCEPCION = MESSAGE; END IF; COMMIT; END$$ DELIMITER ;
PROCEDIMIENTO PR_INSERTA_ALARMA_MEDICACION DELIMITER $$ USE `oap`$$ DROP PROCEDURE IF EXISTS `PR_INSERTA_ALARMA_MEDICACION`$$ CREATE DEFINER=`bdadmin`@`%` PROCEDURE `PR_INSERTA_ALARMA_MEDICACION`(IN PV_CODIGO_PACIENTE VARCHAR(50), IN PN_ID_MEDICACION INT, IN PD_HORA_ALARMA TIME, IN PD_FECHA_CREACION DATETIME, IN PV_OBSERVACION VARCHAR(1000), OUT PN_ID_ALARMA_MEDIC_NEW INT, OUT PN_ERROR INT, OUT PV_ERROR VARCHAR(500)) BEGIN /*============================ AUTOR: RICARDO RODRIGUEZ M. FECHA: 01/AGOSTO/2017 TITULACION 2017 CICLO 2 ===============================*/ DECLARE LN_ID_PACIENTE INT; DECLARE LV_ERROR VARCHAR(20); DECLARE LN_ERROR INT DEFAULT 1; DECLARE NO_NULO CONDITION FOR 1048; DECLARE DUPLICADO CONDITION FOR 1062; DECLARE LV_EXISTE_MEDICACION VARCHAR(1); DECLARE EXIT HANDLER FOR NO_NULO IF LN_ERROR = 1 THEN -- ROLLBACK; NO FUNCIONA A MENOS QUE SE DESACTIVE EL AUTO-COMMIT EN EL DBMS SET PN_ERROR = 1; SET PV_ERROR = 'NO SE PUEDEN INSERTAR CAMPOS VACIOS O NULOS!'; CALL OAP.BITACORIZA_ERROR (PV_CODIGO_PACIENTE,
'ANDROID', 'ALARMA_MEDIC', IFNULL(Pv_Error,'ERROR GENERAL!')); END IF; DECLARE EXIT HANDLER FOR DUPLICADO IF LN_ERROR = 1 THEN -- ROLLBACK; NO FUNCIONA A MENOS QUE SE DESACTIVE EL AUTO-COMMIT EN EL DBMS SET PN_ERROR = 1; SET PV_ERROR = 'ERROR AL INSERTAR REGISTRO! YA EXISTE ID INSERTADO'; CALL OAP.BITACORIZA_ERROR (PV_CODIGO_PACIENTE, 'ANDROID', 'ALARMA_MEDIC', IFNULL(Pv_Error,'ERROR GENERAL!')); END IF; DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; -- NO FUNCIONA A MENOS QUE SE DESACTIVE EL AUTO-COMMIT EN EL DBMS SET PN_ERROR = 1; IF LN_ERROR = 2 THEN SET PV_ERROR = 'ERROR AL OBTENER NUEVA SECUENCIA PARA LA TABLA ALARMA_MEDICACION!'; ELSEIF LN_ERROR = 3 THEN SET PV_ERROR = 'ERROR EN EL PROCESO DE BÚSQUEDA DE PACIENTE.'; ELSEIF LN_ERROR = 4 THEN SET PV_ERROR = 'NO SE ENCUENTRA MEDICACION PARA ASIGANAR UNA ALARMA!'; ELSE SET PV_ERROR = 'ERROR GENERAL!'; END IF; CALL OAP.BITACORIZA_ERROR (PV_CODIGO_PACIENTE, 'ANDROID', 'ALARMA_MEDIC', IFNULL(Pv_Error,'ERROR GENERAL!')); END; -- para buscar el paciente usando el la identificacion que se obtuvo por parámetro de entrada IF PV_CODIGO_PACIENTE IS NOT NULL THEN
CALL OAP.BUSC_PAC (PV_CODIGO_PACIENTE, LN_ID_PACIENTE); IF LN_ID_PACIENTE IS NULL THEN SET LN_ERROR = 3; SET LV_ERROR = MESSAGE; END IF; ELSE SET LN_ERROR = 1; SET LV_ERROR := MESSAGE; END IF; IF PD_HORA_ALARMA IS NULL THEN SET PD_HORA_ALARMA = (SELECT DATE_FORMAT (NOW(), '%H:%i')); END IF; IF PD_FECHA_CREACION IS NULL THEN SET PD_FECHA_CREACION = (SELECT NOW()); END IF; SET LV_EXISTE_MEDICACION = (SELECT 'X' FROM `OAP`.`MEDICACION` P WHERE P.ID_PACIENTE = LN_ID_PACIENTE AND P.ID_MEDICACION = PN_ID_MEDICACION AND P.ESTADO = 'A'); IF LV_EXISTE_MEDICACION IS NULL THEN SET LN_ERROR = 4; SET LV_ERROR = MESSAGE; END IF; IF LV_EXISTE_MEDICACION IS NOT NULL AND LN_ID_PACIENTE IS NOT NULL THEN START TRANSACTION; INSERT INTO `OAP`.`ALARMA_MEDICACION` (`ID_MEDICACION`, `HORA_ALARMA`, `FECHA_CREACION`, `OBSERVACION`)
VALUES (PN_ID_MEDICACION, PD_HORA_ALARMA, IFNULL(PD_FECHA_CREACION, NOW()), UPPER(PV_OBSERVACION)); SET PN_ID_ALARMA_MEDIC_NEW = (SELECT LAST_INSERT_ID()); SET PN_ERROR = 0; END IF; IF PN_ID_ALARMA_MEDIC_NEW IS NULL THEN SET LN_ERROR = 2; SET LV_ERROR = MESSAGE; END IF; COMMIT; END$$ DELIMITER ;
PROCEDIMIENTO PR_INSERTA_PRESION DELIMITER $$ USE `oap`$$ DROP PROCEDURE IF EXISTS `PR_INSERTA_PRESION`$$ CREATE DEFINER=`bdadmin`@`%` PROCEDURE `PR_INSERTA_PRESION`(IN PV_CODIGO_PACIENTE VARCHAR(50), -- IDENTIFICACION O EMAIL IN PN_PRESION_DIAST FLOAT, IN PN_PRESION_SIST FLOAT, IN PN_PULSO FLOAT, IN PV_OBSERVACION VARCHAR(1000), IN PD_FECHA_TOMA_PRESION DATETIME, IN PV_MEDIO VARCHAR(500), OUT PN_ID_DETALLE_PRESION_NEW INT, OUT PN_ERROR INT, OUT PV_ERROR VARCHAR(1000)) BEGIN /*============================ AUTOR: RICARDO RODRIGUEZ M. FECHA: 20/JUNIO/2017 TITULACION 2017 CICLO 2 ===============================*/ DECLARE LN_ID_PACIENTE INT; DECLARE LD_FECHA_TOMA DATETIME DEFAULT NOW(); DECLARE LV_ERROR VARCHAR(1000); DECLARE LN_ERROR INT DEFAULT 1; DECLARE NO_NULO CONDITION FOR 1048; DECLARE DUPLICADO CONDITION FOR 1062; DECLARE LV_EXISTE VARCHAR(1); DECLARE LV_EXCEPCION VARCHAR(20); DECLARE EXIT HANDLER FOR NO_NULO IF LN_ERROR = 1 THEN -- ROLLBACK; NO FUNCIONA A MENOS QUE SE DESACTIVE EL AUTO-COMMIT EN EL DBMS
SET PN_ERROR = 1; SET PV_ERROR = 'NO SE PUEDEN INSERTAR CAMPOS VACIOS O NULOS!'; CALL OAP.BITACORIZA_ERROR (PV_CODIGO_PACIENTE, 'ANDROID', 'PRESION', IFNULL(Pv_Error,'ERROR GENERAL!')); END IF; DECLARE EXIT HANDLER FOR DUPLICADO IF LN_ERROR = 1 THEN -- ROLLBACK; NO FUNCIONA A MENOS QUE SE DESACTIVE EL AUTO-COMMIT EN EL DBMS SET PN_ERROR = 1; SET PV_ERROR = 'ERROR AL INSERTAR REGISTRO! YA EXISTE ID INSERTADO'; CALL OAP.BITACORIZA_ERROR (PV_CODIGO_PACIENTE, 'ANDROID', 'PRESION', IFNULL(Pv_Error,'ERROR GENERAL!')); END IF; DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; SET PN_ERROR = 1; IF LN_ERROR = 2 THEN SET PV_ERROR = CONCAT('ERROR: ', LV_ERROR); ELSE SET PV_ERROR = 'ERROR GENERAL!'; END IF; CALL OAP.BITACORIZA_ERROR (PV_CODIGO_PACIENTE, 'ANDROID', 'PRESION', IFNULL(Pv_Error,'ERROR GENERAL!')); END; IF PV_CODIGO_PACIENTE IS NOT NULL THEN CALL OAP.BUSC_PAC (PV_CODIGO_PACIENTE, LN_ID_PACIENTE); IF LN_ID_PACIENTE IS NULL THEN SET LN_ERROR = 2;
SET LV_ERROR = 'ERROR EN EL PROCESO DE BÚSQUEDA DE PACIENTE.'; SET LV_EXCEPCION = MESSAGE; END IF; ELSE SET PN_ERROR = 1; SET LV_EXCEPCION = MESSAGE; END IF; IF PD_FECHA_TOMA_PRESION IS NULL THEN SET PD_FECHA_TOMA_PRESION = LD_FECHA_TOMA; ELSE SELECT STR_TO_DATE (PD_FECHA_TOMA_PRESION, '%Y-%m-%d %T') INTO LD_FECHA_TOMA; END IF; SET LV_EXISTE = (SELECT 'X' FROM `OAP`.`DETALLE_PRESION` P WHERE P.ID_PACIENTE = LN_ID_PACIENTE AND P.FECHA_TOMA = PD_FECHA_TOMA_PRESION); IF LV_EXISTE IS NULL THEN START TRANSACTION; INSERT INTO `OAP`.`DETALLE_PRESION` (`ID_PACIENTE`, `PRESION_DIASTOLICA`, `PRESION_SISTOLICA`, `PULSO`, `FECHA_CREACION`, `OBSERVACION`, `FECHA_TOMA`, `MEDIO`) VALUES (LN_ID_PACIENTE, PN_PRESION_DIAST, PN_PRESION_SIST, PN_PULSO,
NOW(), UPPER(PV_OBSERVACION), PD_FECHA_TOMA_PRESION, UPPER(PV_MEDIO)); SET PN_ID_DETALLE_PRESION_NEW = (SELECT LAST_INSERT_ID());/*(SELECT P.ID_DETALLE_PRESION FROM `OAP`.`DETALLE_PRESION` P WHERE P.ID_PACIENTE = LN_ID_PACIENTE AND P.FECHA_TOMA = PD_FECHA_TOMA_PRESION);*/ UPDATE `OAP`.`CONTROL_PACIENTE` SET `ID_DETALLE_PRESION` = PN_ID_DETALLE_PRESION_NEW WHERE `IDCONTROL_PACIENTE` = LN_ID_PACIENTE AND `ESTADO` = 'A'; SET PN_ERROR = 0; END IF; IF PN_ID_DETALLE_PRESION_NEW IS NULL THEN SET LN_ERROR = 2; SET LV_ERROR = 'ERROR AL OBTENER NUEVA SECUENCIA PARA LA TABLA DETALLE_PACIENTE!'; SET LV_EXCEPCION = MESSAGE; END IF; COMMIT; END$$ DELIMITER ;