Prototipo de Gestor de Medicación Utilizando Bases de ...repository.udistrital.edu.co/bitstream/11349/13829/... · cristian alejandro bravo mora proyecto de grado directora: ph.d

1

PROTOTIPO DE GESTOR DE MEDICACIÓN UTILIZANDO BASES DE

DATOS NoSQL

JUAN SEBASTIAN OTÁLORA LEGUIZAMÓN

CRISTIAN ALEJANDRO BRAVO MORA

UNIVERSIDAD DISTRITAL “FRANCISCO JOSÉ DE CALDAS”

FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS

BOGOTA D.C.

2018

2

PROTOTIPO DE GESTOR DE MEDICACIÓN UTILIZANDO BASES DE

DATOS NoSQL

JUAN SEBASTIAN OTÁLORA LEGUIZAMÓN

CRISTIAN ALEJANDRO BRAVO MORA

PROYECTO DE GRADO

Directora:

Ph.D. SONIA ORDOÑEZ SALINAS

UNIVERSIDAD DISTRITAL “FRANCISCO JOSÉ DE CALDAS”

FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS

BOGOTA D.C.

2018

3

TABLA DE CONTENIDO

1. INTRODUCCIÓN ................................................................................................. 8

2. MARCO TEÓRICO Y REFERENCIAL ................................................................. 9

2.1. MARCO TEÓRICO ..................................................................................... 9

2.2. MARCO REFERENCIAL .......................................................................... 12

2.2.1. MARCO TECNOLÓGICO ..................................................................... 12

2.2.2. MARCO LEGAL .................................................................................... 18

2.2.3. MARCO METODOLÓGICO .................................................................. 18

3. ESTADO DEL ARTE .......................................................................................... 22

3.1. ONTOLOGÍAS FARMACÉUTICAS........................................................... 22

3.2. CORPUS FARMACEÚTICOS .................................................................. 25

4. OBJETIVOS ....................................................................................................... 26

4.1. OBJETIVO GENERAL .............................................................................. 26

4.2. OBJETIVOS ESPECÍFICOS ..................................................................... 26

5. METODOLOGÍA ................................................................................................ 27

6. DESARROLLO DE LA PROYECTO .................................................................. 30

6.1. Iteración 1 ................................................................................................. 30

6.2. Iteración 2 ................................................................................................. 35

6.3. Iteración 3 ................................................................................................. 44

6.4. Iteración 4 ................................................................................................. 50

6.5. Iteración 5 ................................................................................................. 59

7. PRUEBAS DE RENDIMIENTO DE LA APLICACIÓN MÓVIL ............................ 94

8. CONCLUSIONES .............................................................................................. 97

9. TRABAJO FUTURO .......................................................................................... 98

10. REFERENCIAS ............................................................................................... 99

11. ANEXO I: HISTORIAS DE USUARIO POR ITERACIÓN ............................... 103

12. ANEXO II: MANUAL DE USUARIO ............................................................... 138

4

LISTA DE FIGURAS

Figura 1. Arquitectura de un Crawler ..................................................................... 33

Figura 2. Diagrama de flujo del Crawler ................................................................. 33

Figura 3. Pseudocódigo del Crawler ...................................................................... 35

Figura 4. Flujo de trabajo de proceso ROC ........................................................... 37

Figura 5. Diagrama de flujo herramienta ROC ....................................................... 40

Figura 6. Pseudocódigo herramienta ROC ............................................................ 41

Figura 7. Pseudocódigo análisis de similitud ......................................................... 43

Figura 8. Gramática de posología .......................................................................... 46

Figura 9. Pseudocódigo de clasificación de posología .......................................... 48

Figura 10. Diagrama de flujo clasificación de posología ........................................ 49

Figura 11. Ejemplo clasificación de fórmula médica .............................................. 50

Figura 12. Representación en grafo de los datos .................................................. 54

Figura 13. Diagrama de flujo procesamiento y limpieza de datos .......................... 56

Figura 14. Pseudocódigo de procesamiento y limpieza de datos .......................... 57

Figura 15. Parte de los datos almacenados en Neo4j ........................................... 59

Figura 16. Arquitectura MVC.................................................................................. 63

Figura 17. Arquitectura en 3 capas de todo el sistema. ......................................... 64

Figura 18. Diagrama de actividades inicio de sesión ............................................. 66

Figura 19. Diagrama de actividades registro de usuario ........................................ 66

Figura 20. Diagrama de actividades fórmulas médicas ......................................... 67

Figura 21. Diagrama de actividades visualizar gráfica de históricos ...................... 68

Figura 22. Diagrama de actividades gestión del perfil ........................................... 69

Figura 23. Esquema petición de etiquetado de imagen ......................................... 71

Figura 24. Petición de almacenamiento en servidor .............................................. 72

Figura 25. Pseudocódigo de consulta de efectos adversos ................................... 72

Figura 26. Petición de eventos adversos a servidor .............................................. 73

Figura 27. Pseudocódigo funciones Firebase para consultas en tiempo real ........ 75

Figura 28. Pseudocódigo proveedor de acceso a servicios de base de datos ...... 76

Figura 29. Diagrama de colaboración: Gestión de usuarios. ................................. 77

Figura 30. Interfaz de gestión de usuarios. ............................................................ 77

Figura 31. Diagrama de colaboración: Gestión de Posologías. ............................. 79

Figura 32. Interfaz para la creación de posologías ................................................ 80

Figura 33. Interfaz para la confirmación y edición de información posológica ....... 80

Figura 34. Ejemplo notificaciones locales .............................................................. 82

Figura 35. Interfaz seguimiento semanal de medicamentos .................................. 82

Figura 36. Diagrama de colaboración: Gestión de historial y gráficos ................... 84

5

Figura 37. Interfaz para la visualización de posologías y eventos adversos .......... 84

Figura 38. Seudocódigo Gráficas de Usuario ........................................................ 85

Figura 39. Interfaz de gráficos de posologías ........................................................ 86

Figura 40. Interfaz de descarga JSON de formula médica .................................... 87

Figura 41. Página Web de información - Aplicación móvil ..................................... 88

Figura 42. Interfaz de inicio de sesión al Módulo de Administración...................... 89

Figura 43. Diagrama de colaboración Modulo Administración: Gráficas ................ 89

Figura 44. Interfaz visualización de gráficas del Módulo de Administración I ........ 90

Figura 45. Interfaz visualización de gráficas del Módulo de Administración II ....... 91

Figura 46. Diagrama de colaboración Modulo Administración: Gestión Usuarios . 91

Figura 47. Interfaz gestión de usuarios del Módulo de Administración .................. 92

Figura 48. Página Web Principal .......................................................................... 138

Figura 49. Ubicación instalador ISKA .................................................................. 139

Figura 50. Instalador ISKA ................................................................................... 139

Figura 51. Aplicación ISKA instalada ................................................................... 140

Figura 52. Opción de registro............................................................................... 140

Figura 53. Formulario de registro ......................................................................... 141

Figura 54. Inicio de sesión aplicación .................................................................. 141

Figura 55. Página principal aplicación ................................................................. 142

Figura 56. Pestaña acceso a formulas medicas .................................................. 142

Figura 57. Listado de fórmulas médicas del usuario ............................................ 143

Figura 58. Menú para añadir formula ................................................................... 143

Figura 59. Ejemplo ideal de fotografía de formula médica ................................... 144

Figura 60. Opciones carga de fotografía .............................................................. 144

Figura 61. Ventanas confirmación envío de fotografía. ........................................ 145

Figura 62. Ventana confirmación de medicamento .............................................. 145

Figura 63. Proceso de confirmación de medicamentos. ...................................... 146

Figura 64. Medicamento adicional ....................................................................... 146

Figura 65. Notificación: Recordatorio consumo de medicamento ........................ 147

Figura 66. Formulas Medicas............................................................................... 148

Figura 67. Vista formula médica de usuario ......................................................... 148

Figura 68. Acceso al módulo de graficas ............................................................. 149

Figura 69. Gráficos disponibles para el usuario ................................................... 149

Figura 70. Efectos adversos de un medicamento ................................................ 150

Figura 71. Proceso descarga de JSON de formula médica ................................. 150

Figura 72. Archivo JSON fórmula médica ............................................................ 151

Figura 73. Medicamentos pendientes: Próximos 7 días. ..................................... 151

Figura 74. Activación o desactivación de notificaciones ...................................... 152

6

Figura 75. Perfil de un usuario ............................................................................. 153

LISTA DE TABLAS

Tabla 1. Descripción de iteraciones del proyecto ................................................... 27

Tabla 2. Modelo descripción de iteraciones ........................................................... 28

Tabla 3. Modelo descripción de historias de usuario ............................................. 29

Tabla 4. Modelo descripción de casos de prueba .................................................. 29

Tabla 5. Resumen historias de usuario de la iteración 1 ....................................... 30

Tabla 6. Tareas de ingeniería historia de usuario 1 iteración 1 ............................. 31

Tabla 7. Tareas de ingeniería historias de usuario 2 iteración 1 ............................ 32

Tabla 8. Tareas de ingeniería historia de usuario 3 iteración 1 ............................. 34

Tabla 9. Resumen pruebas de aceptación iteración 1 ........................................... 35

Tabla 10. Historias de usuario iteración 2 .............................................................. 36

Tabla 11. Tareas de ingeniería historia de usuario 1 iteración 2 ........................... 36


Tabla 13. Herramientas ROC preseleccionadas. ................................................... 38

Tabla 14. Resultado pruebas con herramientas ROC ........................................... 38



Tabla 17. Pruebas de aceptación iteración 2 ......................................................... 43



Tabla 20. Tareas de ingeniería historia 2 iteración 3 ............................................. 46








Tabla 28. Pruebas de aceptación iteración 4. ........................................................ 59







7






Tabla 40. Resultados: tiempos de ejecución ......................................................... 95

Tabla 41. Resultados: pruebas ejecutadas ............................................................ 96

8

1. INTRODUCCIÓN

La medicina es una ciencia que constantemente está en progreso, la investigación en esta área es una de las tareas más importantes para la humanidad ya que permite conservarnos como especie al realizar análisis detallados de las enfermedades que nos atacan y tratar dichos problemas. Como parte de la medicina, la farmacología juega un rol principal siendo esta la encargada de estudiar todo aquello que se relacione a los medicamentos.

Como apoyo en los procesos investigativos en farmacología, existen diversos trabajos desde la computación e informática que buscan proveer modelos para el estudio y análisis de los medicamentos, entre los cuales destacan la creación de diferentes corpus y ontologías farmacéuticas que contribuyan a solucionar diferentes problemas en el área, tales como la búsqueda de los eventos adversos en medicamentos o proponer un modelo estándar para la representación digital de un medicamento. Sin embargo, la mayoría de estos trabajos están enfocados a la lengua inglesa.

Por otro lado, existen herramientas software que buscan brindar a las personas un apoyo durante el consumo de medicamentos, sin embargo, estas herramientas están orientadas en su gran mayoría a la gestión de posologías y no a hacer análisis de consumo, por ejemplo, la búsqueda de efectos nocivos en la salud al consumir cualquier medicamento.

Una de las directrices de las entidades del estado consiste en publicar los datos abiertamente con el fin de que la ciudadanía puede enterarse del accionar de las empresas gubernamentales, además de que estos puedan ser utilizados en la investigación y en la academia. En Colombia es aún incipiente la práctica de utilizar los datos abiertos con fines de investigación y desarrollo, problema que se ha querido atacar realizando estrategias de parte del Ministerio de Comunicaciones MINTIC para promover el acceso a información pública, en la cual destaca el portal https://www.datos.gov.co/ donde los ciudadanos pueden acceder a una compilación de datos de diferentes sectores del gobierno.

De modo que, en este proyecto se propone hacer uso de aquellos modelos ontológicos y de corpus, entre otros recursos lingüísticos, junto al procesamiento de lenguaje natural, bases de datos NoSQL y datos abiertos para la creación de un prototipo de herramienta que permita a las personas gestionar y supervisar su medicación de una manera más estricta.

9

2. MARCO TEÓRICO Y REFERENCIAL

En esta sección se describen todo los conceptos y elementos relacionados con el

desarrollo del proyecto.

2.1. MARCO TEÓRICO

Describe conceptos relacionados a ontología, corpus, tesauros, procesamiento del

lenguaje natural y farmacología.

2.1.1. ONTOLOGÍA

Concepto filosófico cuya finalidad es el estudio de lo que existe para conseguir una

descripción de la realidad [1]. En el área de informática y computación, se define

una ontología como un conjunto de representaciones con las cuales se modela un

dominio del conocimiento [2] y se obtiene un modelo semántico y abstracto que

conceptualiza datos e información de una o varias áreas del conocimiento [3]. A

gran escala una ontología está compuesta principalmente de los siguientes

elementos:

• Clases: representan objetos o conjuntos.

• Atributos: indican una característica o propiedad de un objeto o conjunto.

• Relaciones interacciones entre diferentes objetos.

Otros elementos pueden añadirse a una ontología tales como propiedades a las relaciones, implementación de reglas de construcción, individuos, etc. Sin embargo, un modelo básico incluye los tres elementos nombrados anteriormente. Estos elementos en su totalidad conforman una abstracción de la realidad y permite a medios informáticos tener un modelo para representar, almacenar, organizar y analizar el conocimiento [4].

2.1.2. CORPUS

Con diferentes acepciones del término, de manera simple y global, un corpus es un conjunto de textos o representaciones de una lengua almacenada de forma electrónica [5]. Generalmente, los textos de un corpus se relacionan a un área del conocimiento, pasan por un proceso de selección, son filtrados bajo algunos criterios, posteriormente estructurados y en su totalidad buscan formar un modelo al cual se le puedan realizar estudios lingüísticos [6]. Entre las características principales de un corpus se encuentra que: debe estar en un formato electrónico, contener datos autenticados o veraces, contar con uno o más criterios de selección, ser representativo y poseer un tamaño fijo [7].

10

De esta forma, un corpus es una herramienta lingüística que permite realizar todo un proceso que abarca desde la búsqueda, la recuperación, la clasificación, el almacenamiento, y el análisis de textos que se asocian a un área del conocimiento, un lenguaje y un dialecto.

2.1.3. TESAUROS

Un tesauro representa un sistema conformado por términos que guardan relación entre sí y que permiten formar una clasificación [1]. Siendo estos, entonces, una lista de palabras que sirven como “almacén de conocimiento”, por ejemplo, una enciclopedia [8], pero que no solo se limitan a ser esto. Para que un tesauro sea considerado como tal debe cumplir las siguientes condiciones:

• Definirse como un lenguaje especializado

• Presentar un formato normalizado

• Estar constituido por unidades lingüísticas o términos

• Especificar unas palabras clave, que estén relacionadas entre sí de forma jerárquica

Todos estos elementos conforman un lenguaje terminológico que generalmente son usados para fines de documentación. Su objetivo principal es convertir el lenguaje natural en un lenguaje estructurado o normalizado y poder utilizar dicho lenguaje para gestionar la información y el conocimiento [8]. El término nació en los años 50 cuando se realizaron algunas de sus implementaciones con el objetivo de clasificar el contenido de diferentes documentos, posteriormente desde el auge de la computadora y el Internet hasta la actualidad se generaron una gran cantidad de tesauros disponibles al público en formato electrónico, entre sus usos comunes es permitir a un usuario acceder a Bases de Datos y almacenar información de toda índole, desde la medicina hasta las ciencias sociales [9].

A continuación, se describe algunos ejemplos de tesauros pertenecientes a diferentes campos de investigación [9]:

• ATT: Lenguaje estructurado para gestionar documentación perteneciente al área de la Arquitectura y las Artes.

• Tesauro de Educación: Madrid, especializado para la educación

• TEE: Igual al anterior pero europeo

• EUROVOC: Multilingüe. Recopila información de entidades comunitarias

• ODCE: perteneciente al campo de la economía

• UMLS: contiene un tesauro de términos biomédicos.

11

2.1.4. FARMACOLOGÍA

Se define la farmacología como una ciencia que se encarga del estudio de las acciones y propiedades que tienen los fármacos sobre el organismo, entendiendo como fármaco una sustancia química que provoca una reacción sobre los organismos vivos. Dichos fármacos conforman lo que conocemos como medicamento, sustancias que se emplean como tratamiento en la curación o prevención de enfermedades [10].

Entre las tareas de la farmacología, la investigación abarca el estudio de la acción de un fármaco, su origen, su preparación, sus propiedades, sus reacciones a otros componentes, su consumo, su forma de administración, acciones tóxicas, etc. Por otro lado, esta ciencia se divide en tres partes: la primera es la Farmacodinamia encargada de estudiar efectos y reacciones de fármacos; la segunda es la farmacología terapéutica destinada al estudio de la aplicación de fármacos a seres humanos; y la tercera es la toxicología, quien estudia los efectos negativos de los fármacos [11].

Con esto, es fácil observar que modelos como los Corpus y las Ontologías han proporcionado herramientas de análisis lingüístico poderosas que permiten a la farmacología seguir avanzando en sus procesos investigativos. Las herramientas informáticas juegan un papel de gran importancia al facilitar las tareas de recopilación, análisis, almacenamiento y procesamiento de la información de forma casi que automática y crean una fuerte base de estudio para cualquier área de conocimiento, en este caso la medicina.

2.1.5. PROCESAMIENTO DE LENGUAJE NATURAL (PLN)

Área de la informática que permite realizar análisis lingüísticos a textos o información que usualmente carece de formalismo y está escrita en un lenguaje humano coloquial. Aplicando e integrando elementos como la Inteligencia Artificial, la lógica, la estadística y algoritmia busca que un sistema automatizado pueda comprender información en lenguaje humano con algún fin específico [12]. El PLN tiene los siguientes componentes [13]:

• Fonológico: cómo una palabra se puede relacionar con el sonido que representa.

• Morfológico: cómo las palabras se construyen.

• Sintáctico: cómo las palabras forman oraciones, dependiendo de su estructura.

• Semántico: significado de las palabras y oraciones.

• Pragmático: Uso de las oraciones en un contexto específico.

12

Algunas de las aplicaciones típicas del PLN son traducción automática, recuperación de la información, extracción de información y resúmenes, resolución cooperativa de problemas, tutores inteligentes, reconocimiento de voz, análisis de corpus y ontologías, análisis de textos, etc.

2.2. MARCO REFERENCIAL

Esta sección contiene el marco tecnológico, metodológico y legal.

2.2.1. MARCO TECNOLÓGICO

A continuación, se realiza una descripción de motores de bases de datos NoSQL y de aplicaciones móviles que existen actualmente para la gestión de la medicación.

2.2.1.1. BASES DE DATOS NOSQL

NoSQL son implementaciones de sistemas gestores de bases de datos que están basados en modelos diferentes al relacional, de esta forma no se centran en garantizar a cabalidad las propiedades ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad), sino en dar solución a alguna situación específica tratando de optimizar elementos como el rendimiento en búsquedas, el espacio de almacenamiento, la reducción en complejidad, optimización del procesamiento y del costo computacional [14], [15].

Existen una considerable cantidad de bases de datos NoSQL, las más representativas se pueden agrupar principalmente en documentales, clave-valor, orientadas a columnas y orientadas a grafos. Cada una de las cuales cuenta con una arquitectura específica y cuya implementación corresponde a contextos específicos donde algunas características de las bases de datos relacionales son mejoradas y las demás no son relevantes para cada caso.

2.2.1.1.1 DOCUMENTALES

Almacenan la información bajo una noción abstracta de “documento”. Un documento, es la recopilación de información en algún tipo de estructura, sin embargo, dicha estructura puede diferir entre documentos. Generalmente, estas bases de datos se organizan por medio de colecciones (varios documentos), por etiquetas, por la asignación de una clave específica a cada documento, por metadatos o por una jerarquía (directorios) [16].

Los formatos o estándares más comunes para almacenar un documento son XML, JSON, BSON, YAML, formatos binarios o de Microsoft Word. Algunas implementaciones de bases de datos documentales populares son MongoDB y CouchDB.

13

2.2.1.1.2 CLAVE-VALOR

Implementadas bajo el modelo simplista de un identificador y su correspondiente valor [17]. De esta forma, cada elemento posee una llave única que permite su recuperación durante transacciones, vistas entonces como diccionarios que almacenan grandes cantidades de información. Estas bases de datos se especializan en la eficiencia durante procesos de lectura-escritura, entre sus usos más populares están el almacenamiento de información estadística y el almacenamiento temporal de grandes cantidades de información provenientes de servidores WEB [15]. Entre los ejemplos de implementación destacan BigTable y DynamoDB.

2.2.1.1.3 ORIENTADAS A COLUMNAS

Su estructura se representa por columnas y familias de columnas en vez de filas y tuplas. Dicha característica permite que la lectura y recuperación de información sea de forma rápida y eficiente, pero los procesos de escritura no tanto. Por lo tanto, su uso principal es en DataWarehouse y en sistemas de inteligencia de negocios, donde el principal objetivo es el análisis de la información [18]. Cassandra e HiperTable son dos de sus principales exponentes.

2.2.1.1.4 ORIENTADAS A GRAFOS

Las bases de datos orientadas a grafos (BDOG) tienen bases en los fundamentos de la teoría de grafos. En estas, se usan vértices para representar un objeto y aristas para identificar relaciones entre ellos, a su vez ambos una arista y un objeto pueden tener propiedades [14]. El conjunto de nodos y atributos forman un grafo, que generalmente es visto a manera de red.

Una ventaja de las BDOG es que permiten realizar consultas complejas o anidadas de manera sencilla, dadas sus características las estructuras de información suelen ser dinámicas y pueden variar en el tiempo sin alterar la información previa de manera drástica. También evitan el desperdicio de espacio y el procesamiento de los datos es optimizado [14]. La BDOG cuyo uso es más popular es conocida como Neo4j.

2.2.1.2. OPTIMIZACIÓN ÓPTICA DE CARACTERES

La optimización óptica de caracteres (ROC) es un proceso en el cual un texto es digitalizado [19]. Una herramienta con esta funcionalidad es capaz de reconocer textos impresos o escritos a mano. El proceso consta de los siguientes pasos: 1) la adquisición de una imagen con texto, o a veces formato PDF, 2) pre procesamiento para “binarizar” la imagen y minimizar los imperfectos, 3) segmentación de imagen para ubicar el texto, 4) comparación y reconocimiento de patrones para asociar los

14

símbolos encontrados con un carácter [20]. Al finalizar el proceso se obtiene texto editable.

La aplicación de las herramientas ROC se destaca principalmente en el campo de la Inteligencia Artificial y el procesamiento del lenguaje natural, donde largas cantidades de información se encuentra en manuscritos, simplificando el proceso manual de entrada de datos y automatizándolo para poder procesar y analizar la información en menor tiempo.

2.2.1.3. ARQUITECTURA MODELO - VISTA - CONTROLADOR

En el desarrollo de software, la arquitectura modelo-vista-controlador (MVC) es un patrón que a grandes rasgos separa la construcción de un software en tres componentes los cuales permiten separar los datos, la lógica del negocio y la interfaz del usuario [21].

El componente del modelo se encarga de tener una representación de los datos y de gestionar el acceso a los mismos, el controlador es un componente que interpreta y ejecuta las órdenes de un usuario realizando peticiones al modelo y la vista genera una representación visual del modelo para que el usuario pueda interactuar con ellos [22]. De esta forma, el patrón MVC permite el desarrollo de aplicaciones con interfaces complejas, separando la lógica del negocio de los datos y obteniendo un diseño desacoplado. Su uso más común es en aplicaciones Web y en aquellas que la reusabilidad sea importante.

2.2.1.4. HERRAMIENTAS PARA LA GESTIÓN DE MEDICAMENTOS

Las siguientes son herramientas que permiten controlar, entre otras funcionalidades, la posología de medicamentos.

2.2.1.4.1 PILLMANAGER [23]

La aplicación posee:

• Planificación de medicamentos: Permite al usuario introducir sus propios medicamentos, incluyendo el nombre, número de dosis y tiempos de recordatorio. Cada Medicamento puede tener su frecuencia de dosificación, alterarse y la aplicación puede atribuir un cierto número de días para cada medicamento si el horario del usuario es indefinido

• Historial de medicamentos: Almacena el historial de la medicación del usuario, lo que les permite elegir y ver su consumo por fecha. Esta información también puede ser compartida a través de correo electrónico. También permite al usuario gestionar y realizar un seguimiento de la mayor parte de sus registros médicos críticos

15

• Reordenación de la medicación: La aplicación ofrece el primer sistema universal de reordenamiento integral de cualquier aplicación de utilidad médica. Alternativamente, los usuarios pueden enviar una foto de su prescripción de la misma manera, directamente a su médico o farmacéutico para su cumplimiento.

2.2.1.4.2 MEDHELPER [24]

La aplicación posee:

• Seguimiento de sus fórmulas médicas. Recordatorios con alarmas, alerta de citas médicas y cuando los medicamentos se están agotando o están a punto de expirar.

• Realizar seguimiento de signos vitales y PRN según se necesite medicación. Permite iniciar sesión y exportar o imprimir informes detallados para su doctor, enfermera o cuidador.

• Características gratuitas incluyen: Lista Prescripción, horario, inventario, contacto, informes exportables y para imprimir.

2.2.1.4.3 JMSOFT [25]

La aplicación tiene:

• Configurar una variedad de diferentes medicamentos para varios momentos del día. La toma del medicamento puede ser continua o no.

• Puede establecer el sonido de notificación

• Idiomas soportados: inglés, portugués y español

• Muestra todos los horarios en que va a sonar la alarma

2.2.1.4.4 DOSECAST [26]


• Notificaciones: Envío de recordatorios a su dispositivo, con posponer y repetición. Insiste hasta responder con alarma continua. Se ajusta a zonas horarias.

• Horario flexible: Tomar las dosis en un horario diario, semanal, mensual, cada X días o semana, sólo en determinados días de la semana o incluso después de un número preestablecido de horas o de días desde la última dosis.

16

• Dosis: Establecer el nombre del medicamento, información de dosificación, instrucciones y notas que aparecen en los avisos para cada dosis. También puede realizar un seguimiento de la fecha de vencimiento de cada fármaco.

• Información privada y encriptada.

Versión Pro:

• SYNC multidispositivo: Actualizar recordatorios en diferentes dispositivos.

• Tipos de Drogas: Seguimiento de medicamentos que se toman a través de inyecciones, inhaladores, gotas, aerosoles, ungüentos, parches, las dosis del líquido.

• Historial: Registra la fecha y hora de las dosis que toma, salta, o pospone.

• Seguimiento: Identifica la cantidad restante de cada fármaco se introduce y entrega una alerta de recarga cuando se ejecuta bajo.

• Soporte multi-PERSONA: Asignar medicamentos específicos para diferentes personas.

• Seguimiento doctor o farmacia

• Base de datos: Introducción de información sobre drogas.

• Fotos: Toma fotos de cada fármaco para identificarlo más fácilmente.

2.2.1.4.5 MANGO HEALTH [27]


• Programación de recordatorios para la ingesta de medicamentos o suplementos.

• Recordatorios de hábitos saludables: Configuración de recordatorios personalizados, tome la presión arterial, beber agua.

• Advertencias: Una vez se haya añadido un medicamento, alerta de los efectos e interacciones de medicamentos potencialmente peligrosas con otros medicamentos, suplementos o alimentos lado.

• Diario: Registra automáticamente el historial de salud para poder mirar hacia atrás y ver lo que se hizo y cuándo.

• Alerta: Recuento en tiempo real de medicamentos.

2.2.1.4.6 HEALTHY REMINDER [28]


17

• Recordatorio de medicación, alerta y contacto de emergencia en caso de olvido de medicamento. Alerta vía correo electrónico o mensaje de texto

• Alerta a otra persona vía mensaje o correo electrónico

2.2.1.4.7 PILLBOX [29]


• Añade cualquier medicamento a la aplicación

• Selección de imagen o subir foto del medicamento, cuando tomarla, añadir alarma y agregar notas, Aviso de cuando es el momento de tomar medicación.

2.2.1.4.8 PASTIMED LITE [30]


• Idiomas: Castellano, catalán, inglés, francés y alemán

• Programación de la toma de pastillas

• Aviso sonido o vibración.

• Posibilidad de fotografiar el medicamento para asociarlo al tratamiento.

• Historial de tratamientos.

• Consultar el número de tomas por medicamento, Tiempo transcurrido entre tomas.

• Localizador de Farmacias y sección de noticias

2.2.1.4.9 MEDISAFE [31]


• Sincronización de la medicación familiar

• Aviso y recordatorio de medicación

• Selección de sonidos

• Listado y marcado de medicamentos a tomar

• Función de recordatorio de reabastecimiento de medicamento

• Medicación PRN

• Informe de progreso y envíelo al médico como archivo Excel.

18

Todas las aplicaciones aquí descritas permiten gestionar las posologías de un medicamento a través de una notificación o recordatorio, pero solo Mango Health realiza análisis a eventos adversos de medicamentos y a las interacciones entre diferentes medicamentos, pero se encuentra exclusivamente en inglés. Cabe destacar que la versión pro de Dosecast posee una base propia de medicamentos. Se encuentra entonces, que no existe una herramienta en español, menos para Colombia, que realice estas actividades de análisis a efectos nocivos durante la medicación.

2.2.2. MARCO LEGAL

En el marco de la publicación de trabajos se establece el uso de licencias tipo Creative Commons (CC), las cuales brindan unos estándares y condiciones que permiten a un autor difundir y compartir su trabajo entre otros elementos que sean susceptibles a derechos de autor de manera pública, sin embargo, estas licencias cuentan con normativas que controlan el uso a dicha información [32].

Para el uso de datos abiertos, en Colombia, se estableció la Ley 1712 de 2014 de Transparencia y Acceso a la Información la cual establece que una entidad que publique sus datos debe contar con un Registro de Activos de Información el cual contiene información relacionada con los trámites, servicios y procesos del qué hacer de la entidad. Por otro lado, la ley también establece el Índice de Información Clasificada y Reservada, con el objetivo de preservar información de carácter privado. Todo lo anterior debe ser publicado en el sitio web www.datos.gov.co donde se encuentra todos los repositorios que contienen los datos abiertos de las entidades gubernamentales incluyendo el INVIMA [33].

De tal forma, el acceso a la información pública es un derecho fundamental que busca: 1) Garantizar la participación democrática y el ejercicio de los derechos políticos. 2) Ejercicio de otros derechos constitucionales. 3)Garantizar la transparencia de la gestión pública [33].

2.2.3. MARCO METODOLÓGICO

De acuerdo a los estudios preliminares que se realizaron en el anteproyecto se identificó que era necesario utilizar una metodología ágil para el desarrollo de la herramienta, en virtud a la flexibilidad que pueden tener frente a software de tipo experimental donde pueden incluirse o eliminarse componentes y no existen requerimientos explícitos de los clientes, por lo que, en esta sección se incluirá la definición de estas.

2.2.3.1. METODOLOGÍAS ÁGILES PARA EL DESARROLLO DE SOFTWARE

Las metodologías ágiles se conocen por ofrecer una alternativa para el desarrollo de proyectos de escalas pequeñas y cambiantes, para los cuales adaptar una metodología tradicional puede ser una tarea tediosa y una complicación innecesaria

19

[34]. Sin embargo, la implementación de estas metodologías no debe implicar una reducción en la calidad del desarrollo, por el contrario, el objetivo es poder reducir los tiempos de desarrollo manteniendo una alta calidad [35].

Las propuestas de las metodologías ágiles se basan en el Manifiesto Ágil [36], el cual enumera las características de un desarrollo ágil. A continuación, se hace una breve descripción de dichas características:

• Priorizar al equipo de desarrollo y sus interacciones ante el proceso y las herramientas.

• Más funcionalidad y menos documentación

• Fomentar colaboración de parte del cliente

• Rápida respuesta a cambios.

A partir de estas características, se describen los principios del manifiesto:

“I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.

II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva.

III. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.

IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.

V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.

VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.

VII. El software que funciona es la medida principal de progreso.

VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante.

IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. X. La simplicidad es esencial.

XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos.

XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento” [35].

20

2.2.3.2. METODOLOGÍA DE DESARROLLO DE SOFTWARE XP

La programación extrema, mejor conocida como XP, es una metodología ágil enfocada en el progreso interpersonal de equipo en el desarrollo de software. Se fundamenta en el cliente, especialmente en cómo retroalimenta el proyecto en las entregas parciales. Presenta simplicidad en las soluciones obtenidas dado el grado de adaptabilidad que debe respecto a requisitos imprecisos y cambiantes [35].

2.2.3.2.1 HISTORIAS DE USUARIO

Es la forma en la que el cliente da a conocer al equipo de desarrollo las características y funcionalidades del aplicativo. Las historias son flexibles y se representan en lenguaje común. Dentro de cada iteración del desarrollo se cumplirán algunos requerimientos inmersos en las historias de usuario [35].

2.2.3.2.2 PROCESO XP

El proceso que a grandes rasgos se ejecuta con el XP es:

• El cliente define qué se va a implementar.

• El desarrollador estima el esfuerzo necesario para su implementación.

• El cliente, de acuerdo a un nivel de importancia, define qué construir y los tiempos máximos de desarrollo.

• El desarrollador construye lo que se decidió implementar.

• Se retorna al paso 1.

Sin embargo, el ciclo ideal de vida de la Metodología tiene 6 pasos que se explican a continuación [35]:

Fase 1: Exploración. El cliente entrega las historias de usuario más relevantes para la entrega y el equipo desarrollador explora posibilidades relacionadas a la arquitectura del sistema.

Fase 2: Planificación de la entrega. El equipo establece la prioridad y estimación de esfuerzo de cada historia. Con base en eso, se define criterios de cada entrega y el cronograma de implementación.

Fase 3: Iteraciones. De acuerdo al plan de entrega se implementan los desarrollos parciales. Usualmente en la primera iteración, se define una arquitectura apta para el proyecto. Una vez las iteraciones se acaban, deberían continuar al siguiente paso.

Fase 4: Producción. Se requieren pruebas y revisiones que eviten que se haga un despliegue al cliente con errores.

21

Fase 5: Mantenimientos. Para cumplir la característica de agilidad, el sistema garantiza que mientras una versión está en producción, otra puede estar en iteración.

Fase 6: Muerte del proyecto. No se tienen más historias incluidas para iterar.

22

3. ESTADO DEL ARTE

En esta sección se describe trabajos relacionados al proyecto, en específico se realiza una revisión a diferentes ontologías y corpus farmacéuticos que han sido desarrollado bajo diferentes perspectivas, pero siempre relacionados a medicamentos.

3.1. ONTOLOGÍAS FARMACÉUTICAS

El trabajo más grande y representativo de ontologías en el campo de medicina es el sistema de lenguaje médico unificado (UMLS), el cual es una ontología compuesta esencialmente de conceptos biomédicos. Se define como un conjunto de archivos y software que une vocabularios y estándares biomédicos y de salud para permitir interoperabilidad entre sistemas computacionales [37]. Creada por la Biblioteca Nacional de Medicina en EE. UU. es constantemente actualizada desde el año 1986. También posee varias Bases de Datos disponibles en 20 idiomas, pero su lenguaje principal es el inglés. Posee tres herramientas básicas para acceder a la información: el Methatesaurus, que almacena términos y códigos de vocabulario de diferentes lenguas; Redes Semánticas que describen categorías y relaciones del Methatesaurus; Y el Specialist Lexicon, que son herramientas para el procesamiento del lenguaje natural [37].

UMLS provee una forma de acceso a las herramientas mencionadas por medio navegadores web, APIs web o simplemente descargando los archivos. De esta manera, muchos investigadores pueden analizar, procesar, clasificar y conceptualizar términos médicos. Además, el trabajo investigativo incluye identificar atributos, relaciones y patrones para dichos elementos.

Por otro lado, se han realizado trabajos que buscan formalizar los conceptos de medicamentos y recetas médicas por medio de Ontologías, a continuación, se muestra un resumen de dichos trabajos en el área

3.1.1. DE CRUANES VILAS [38]

Tesis doctoral se resalta que la aproximación léxico-semántica que se hace con base a la terminología internacional multilingüe SNOMED-CT. El trabajo consiste en establecer estar terminología como destino, y como origen de la ontología de medicamentos comercializados en España OntoFIS. El mapeado se hace con herramientas PLN basadas en la similitud léxica.

3.1.2. DE KHALILI & SEDAGHATI [39]

Se destaca que a pesar de que en alrededor del mundo ya se usan software para la prescripción de medicamentos, la heterogeneidad de información y de sus fuentes es muy amplia, lo que significa un reto para su representación. Propone entonces una prescripción semántica de medicamentos, que contienen metadatos

23

relacionados a medicamentos, y no solo sobre su contenido, sino sus relaciones con los demás medicamentos. Esto busca facilitar el proceso de toma de decisiones en los servicios farmacéuticos. Como fuentes de información para la extracción de metadatos se usaron DBpedia, DrugBank, DailyMed y RxNorm.

3.1.3. DE KOSTOPOULOS ET AL. [40]

Propone un framework basado en ontologías. Dicho framework tiene en cuenta el dominio de conocimiento requerido y el uso de lógica de inferencias para hacer sugerencias en la prescripción médica de acuerdo al perfil del paciente. La ontología se define con un enfoque orientado al paciente más que la estructura de la prescripción médica, teniendo en cuenta elementos como: diagnóstico, historial, perfil. Para la evaluación del modelo utilizan pacientes en rehabilitación cardiaca.

3.1.4. DE GRANDO, FARRISH, BOYD Y BOXWAL [41]

Exploran el uso y el potencial de las ontologías en el contexto de prescripción de múltiples medicamentos. La ontología que proponen la componen del conocimiento relacionado a los medicamentos y un repositorio de las principales prescripciones genéricas y seguras de medicamentos. Tiene en cuenta también un registro médico de prescripciones que se han hecho al paciente. La ontología incluye también características de los medicamentos como contraindicaciones y la interacción entre medicamentos

3.1.5. DE KHEMMARAT & GAO [42]

Como premisa considera que una prescripción médica presenta muchos aspectos a tener en cuenta como la interacción entre medicamentos y los efectos secundarios que se deben ajustar al perfil del paciente (sexo, edad, etc.). Propone una herramienta de consulta que permite facilitar las prescripciones médicas con base a los aspectos mencionados. La información sobre los medicamentos se adquiere de diversas fuentes, sin embargo, la información presenta distorsión y se encuentra incompleta. Por tanto, usan métodos tanto manuales como automáticos para la extracción y organización de datos de los medicamentos, que finalmente es representada en un grafo heterogéneo y el modelo de consultas como un problema de apareamiento en sub-grafos. La información del medicamento es puesta en una base de conocimientos unificada usando fuentes farmacológicas como: DrugBank, SIDER2, KEGG Drug y FDA.

3.1.6. DE ROMÁ-FERRI [43]

La Ontología Farmacoterapéutica e Información para el Seguimiento, OntoFIS es un desarrollo financiado por Fondo de Investigación Sanitaria (FIS), Instituto de Salud Carlos III. Esta ontología resuelve el problema general de carencia de una fuente específica de acceso y gestión de información de este conjunto temático. Se

24

usaron técnicas de PLN para la construcción de la ontología analizando historiales clínicos.

“La ontología OntoFIS está constituida por 23 conceptos, con un grado de abstracción intermedio. El modelo farmacoterapéutico incluido está descrito por medio de 647 interconexiones, a partir de una taxonomía de 36 tipos de relaciones semánticas. Además, incluye conocimiento multilingüe para la denominación de los conceptos e incorpora descripciones en lenguaje natural.

La ontología OntoFIS está poblada con casi 55.000 instancias. Entre éstas destacan, por su número y su valor terminológico, las correspondientes a las denominaciones de los medicamentos comercializados en España (17.204), los componentes farmacológicos (19.627), los nombres genéricos de principios activos (4.456), las denominaciones de grupos químicos (3.200) y las denominaciones de uso terapéutico (1.380).” [43]

3.1.7. DE RUBRICHI, QUAGLINI, SPENGLER, RUSSO, & GALLINARI [44]

Se plantea una metodología de reconocimiento automático de información relacionada a medicamentos en la descripción textual de cada uno de ellos, para la construcción de una ontología. Como base de representación de conocimiento se usa el resumen de características del producto (summary of product characteristics (SPC)). Debido a que la información no es de fácil extracción, utiliza un método de 2 etapas. La primera etapa consiste en aprender a clasificar la información en una estructura de predicción. El entrenamiento en esta etapa se da usando cientos de SPC. En la segunda etapa, la información o entidades extraídas se añaden a la ontología como nuevas instancias mediante un conjunto de reglas establecidas a priori.

3.1.8. DE SENGER, SEIDLING, QUINZLER, LESER, & HAEFELI [45]

Se desarrolla un modelo de aplicación de medicamentos para mejorar el soporte de decisiones clínico. El modelo comprende un esquema de atributos de medicamentos y una ontología que presenta los posibles valores de los atributos del esquema. Luego mediante el diseño de un algoritmo se calcula la similitud o compatibilidad entre las características de aplicación y el producto médico. Fuentes de información usadas para la construcción de la ontología: FDA, EuAB, European Directorate for the Quality of Medicines, MMI (Medizinische Medien Informations), y ABDATA (ABDATA Pharma-Daten-Service, Eschborn, Germany).

3.1.9. DE SOHN ET AL. [46]

Se desarrolla MedXN como sistema de extracción y normalización de información sobre medicación. Este sistema se crea bajo los lineamientos RxNorm, que es un estándar de nombres de medicamentos que además los enlaza a los vocabularios relacionados en la gestión de fármacos. MedXN específica al máximo la información

25

con base al RxCUI que es un identificador único usado para la lectura y semántica de los datos dentro del sistema. Respecto al método, se usaron las descripciones clínicas de los medicamentos para extraer nombre y atributos de cada uno con el fin de tratar y clasificar estos datos de acuerdo a RxNorm.

3.2. CORPUS FARMACEÚTICOS

El trabajo relacionado a corpus farmacéuticos se puede clasificar en tres enfoques. El primer enfoque es la extracción de información que se asocia a medicamentos desde medios sociales y literatura médica [47]–[50]. El segundo enfoque es la búsqueda y clasificación de eventos adversos de medicamentos en escritos médicos [51]–[53] y, por último, el tercer enfoque es la búsqueda y clasificación de interacciones entre medicamentos [54]–[57].

A continuación, se destaca algunos de los corpus farmacéuticos desarrollados

• CLEF [50]: Corpus que contiene información de reportes clínicos, compuesto de 565000 documentos. Aunque el trabajo realizado abarca aproximadamente el 5% del total de documentos.

• DDI [54]: Corpus para el estudio de interacciones entre medicamentos, compuesto por 273 resúmenes y 792 textos.

• ADE [51]: Corpus para la identificación de eventos adversos en medicamentos en reportes clínicos, compuesto de 2972 resúmenes.

• EU-ADR [55]: Corpus que contiene información de medicamentos, enfermedades y sus relaciones, compuesto de 300 resúmenes.

• CADEC [47]: Corpus similar a ADE cuya información proviene de medios sociales, compuesto de 1253 entradas.

• Roberts et. al [58]: Corpus semántico compuesto de reportes clínicos y registros de pacientes, compuesto de 150 documentos y 400 resúmenes.

26

4. OBJETIVOS

4.1. OBJETIVO GENERAL

Desarrollar un prototipo de herramienta que permita la gestión y control de la medicación mediante el uso Bases de Datos NoSQL.

4.2. OBJETIVOS ESPECÍFICOS

• Buscar o construir recursos lingüísticos para la estructuración de los datos abiertos de medicamentos.

• Recopilar y generar una colección de datos realizando tareas de preprocesamiento tales como limpieza, eliminación de ruido e implementar algoritmos de procesamiento de lenguaje natural para el almacenamiento de los datos en una base de datos NoSQL y su posterior análisis.

• Definir requerimientos funcionales y no funcionales, realizar el diseño de la arquitectura del sistema, definiendo componentes y la interoperabilidad entre ellos.

• Desarrollar el código necesario para la implementación del prototipo y diseñar e implementar pruebas de validación y ejecución.

27

5. METODOLOGÍA

Con base a la metodología de desarrollo de software XP se define una serie de etapas o iteraciones en las que se desarrolla el proyecto, cada iteración engloba un hito o componente del proyecto a desarrollar, en la Tabla 1 se especifica cada una de estas iteraciones y las 4 etapas que componen su desarrollo.

Iteraci

ón

Component

e

Etapas

Análisis Diseño Desarrollo Pruebas

1 Rastreo Identificar elementos necesarios

para el diseño,

desarrollo e implementación de pruebas correspondien

tes para cumplir los

objetivos de cada

iteración.

Elaboración de

diagramas de flujo,

arquitecturas,

documentación y

algoritmos para la

realización de cada iteración.

Implementación de código

fuente, elaboración de gráficos y herramientas

para cada iteración.

Validación y

análisis de

resultados

2 Reconocimiento óptico de caracteres

(ROC)

3 Gramática de posología

4 Repositorio de datos

5 App y servidor

Tabla 1. Descripción de iteraciones del proyecto [59]

De cada fase correspondiente a las iteraciones se obtienen las “Historias de usuario”, por cada fase puede haber una o más historias de usuario. El modelo para la especificación de cada iteración se observa en la Tabla 2

Identificador Iteración #: Nombre Iteración

Descripción general: Resumen de los objetivos y desarrollos realizados en la iteración.

Número Historia de usuario

Descripción Etapa Estado

28

1 Nombre de historia

Historia de la fase de análisis

Etapa a la que pertenece la historia de usuario

Define el resultado de la historia: Rechazada o Realizada.

2 Nombre de historia

Historia de la fase de diseño

3 Nombre de la historia

Historias de la fase de desarrollo

Responsables: Nombre de las personas responsables

Observaciones: Comentarios, notas o indicaciones con respecto a la Iteración.

Fecha inicio: Fecha en la que comienza el desarrollo de la iteración

Fecha fin: Fecha en la que finaliza el desarrollo de la iteración.

Tabla 2. Modelo descripción de iteraciones (Diseño propio con base en [59])

Las historias de usuario están compuestas de una serie de actividades a realizar

llamadas “Tareas de Ingeniería”, el formato para la descripción de estos elementos

se visualiza en la Tabla 3.

Identificador Historia de Usuario #: Nombre de historia de usuario

Descripción general: Resumen de las actividades realizadas.

Número Tarea Descripción Estado Puntos

1 Nombre tarea de ingeniería

Explicación de la actividad realizada

Define el resultado de la historia: Rechazada o Realizada.

Cantidad de semanas empleadas en la realización de la tarea

Responsable: Encargados del desarrollo de la historia

Prioridad: Nivel de impacto sobre el proyecto. Puede ser bajo, medio o alto.

29

Observaciones: Comentarios, notas o indicaciones con respecto a la Iteración.

Tabla 3. Modelo descripción de historias de usuario (Diseño propio con base en [59])

Con base en la metodología XP, en la Tabla 3 se describen las historias de usuario y las tareas de ingeniería. Dentro del modelo de descripción de historias de usuario, se explican a profundidad las tareas, razón por la cual se omiten tablas adicionales para las tareas, dado que el modelo diseñado es lo suficientemente descriptivo y específico respecto a la ejecución de cada historia de usuario.

Por último, la finalización de una iteración es en la fase de pruebas, donde se evalúan los resultados. Para esto se realiza una o varias pruebas de aceptación, la descripción de cada prueba se observa en la Tabla 4.

Identificador Caso de Prueba #: Nombre de prueba

Historias de usuario: Historias de usuario relacionadas a la prueba

Condiciones de ejecución: Serie de requisitos y circunstancias requeridas para la prueba

Número Paso de ejecución

1 Paso a realizar

Resultado esperado: Breve descripción del caso de éxito para la prueba.

Evaluación de la prueba: Resultado de la prueba.

Tabla 4. Modelo descripción de casos de prueba (Diseño propio con base en [59])

30

6. DESARROLLO DE LA PROYECTO

En la sección 6 se menciona previamente el uso de la metodología XP como guía de desarrollo, ahí también se especifican 5 iteraciones en las que se divide el proyecto, cada iteración corresponde a un componente del sistema. En esta sección se describe el trabajo realizado en cada iteración.

6.1. ITERACIÓN 1

En esta iteración se desarrolla el componente de rastreo, el objetivo de este es poder recopilar información asociada a medicamentos que se encuentre libre en la web. Su funcionamiento consiste en partir de una URL, acceder a un sitio Web y buscar y capturar aquellos elementos que correspondan a la información solicitada.

6.1.1. HISTORIAS DE USUARIO

En la Tabla 5 se observa las historias de usuarios que componen esta iteración.

Número Historia de usuario Descripción

1 Definición de Requerimientos

Identificar: ● Las posibles fuentes de información sobre

medicamentos. ● La tecnología necesaria para la

implementación del componente. ● Librerías o frameworks aplicables para el

procesamiento y almacenamiento de la información recopilada

2 Diseño de la herramienta

Definir la estructura y elementos básicos que requiere el componente

3 Implementación de la herramienta

Desarrollar del código necesario para que el componente sea capaz de obtener, procesar y almacenar

Tabla 5. Resumen historias de usuario de la iteración 1

6.1.1.1. DEFINICIÓN DE REQUERIMIENTOS

En esta historia de usuario se analizan y especifican diferentes elementos requeridos para el desarrollo de la herramienta de rastreo. Se define la construcción de una Crawler que obtendrá la información de medicamentos para Colombia. En la Tabla 6 se exponen las diferentes tareas de ingeniería realizadas.

31

Número Tarea Descripción

1 Identificación de fuentes de información

Identificar, analizar y evaluar aquellos sitios web con información pública de medicamentos cuyo código fuente permitiera la captura de datos de forma organizada.

2 Selección de plataforma de desarrollo

Escoger un lenguaje de programación para el desarrollo del código necesario que realice la búsqueda de URL, descarga de información y almacenaje.

3 Selección de librerías Reconocer las diferentes librerías o frameworks existentes en el desarrollo de Crawlers.

4 Definición de repositorio

Identificar herramientas disponibles para el almacenamiento y requerimientos de espacio en disco para los datos descargados por el Crawler.

Tabla 6. Tareas de ingeniería historia de usuario 1 iteración 1

Como resultado de esta historia de usuario se escogió de forma preliminar diccionarios farmacéuticos en línea, se destaca el portal www.vademecum.es, en el que hay una gran cantidad de información en español sobre medicamentos. Por otro lado, la página del Instituto Nacional de Vigilancia de Medicamentos y Alimentos (INVIMA) también se escoge como fuente principal de información de medicamentos, el motivo es que dicha página mensualmente publica un listado de medicamentos vigentes para Colombia con datos descriptivos de cada uno.

Para la construcción del Crawler se escogió el lenguaje de programación Python por sus facilidades y amplias herramientas para el procesamiento del lenguaje natural. Las librerías seleccionadas fueron Beautiful Soup y urllib2, las cuales nos permiten capturar información de páginas web y extraer datos de estas, además estas son de fácil uso y cuentan con amplia documentación.

Los datos obtenidos de los portales web son capturas de etiquetas HTML que se guardan en formato TXT mientras que los del portal INVIMA son un documento en formato .xls, por lo tanto, se opta por guardar este documento en formato .CSV. Una vez se descargan las diferentes actualizaciones de las páginas se vio la necesidad de almacenar dicha información de tal forma que conservará su estructura inicial, por lo que después de hacer una evaluación de los diferentes motores de bases de datos se escogió MongoDB.

http://www.vademecum.es/

32

Por último, los protocolos de interoperabilidad y comunicación definidos para el intercambio de información en el campo de la medicina tales como HL7 no son requeridos dado que es un proceso de extracción de información de páginas web en bruto, esto significa que el aplicativo debe someterse al diseño y arquitectura de los sitios fuente.

6.1.1.2. DISEÑO DE LA HERRAMIENTA

En esta historia de usuario se realizan esquemas para definir la estructura del Crawler, así como los procesos que involucran su flujo de trabajo desde la captura del URL hasta el almacenamiento en la base de datos. En la Tabla 7 se muestran las diferentes tareas de ingeniería realizadas.


1 Identificación de elementos

Detallar aquellos componentes que componen el Crawler y sus relaciones entre sí.

2 Definición de procesos y algoritmos requeridos

Determinar aquellos procesos y sus flujos de trabajo desde la captura de información hasta su almacenamiento.

3 Esquematización Realización en diagramas de la arquitectura, flujo de información y actividades.

Tabla 7. Tareas de ingeniería historias de usuario 2 iteración 1

Como resultado de esta historia observamos en la Figura 1 la arquitectura típica de un Crawler, la cual está compuesta por el “multi-hilo descargador” que obtiene texto y metadatos requeridos de una página web, el “programador” y la “cola” que gestionan una lista de peticiones URL a las cuáles se debe ingresar y finalmente los datos extraídos por el descargador se van guardando.

33

Figura 1. Arquitectura de un Crawler (Diseño propio con base en1)

En la Figura 2 observamos el diagrama de flujo del Crawler elaborado, donde a partir de una URL, si encuentra que es válida, se explora la página hasta encontrar los archivos o datos buscados, los cuales para nuestro caso son toda la información de medicamentos que disponga el sitio, posteriormente lo descarga, se almacena en formato CSV para un futuro procesamiento.

Figura 2. Diagrama de flujo del Crawler (diseño propio)

1 https://nlp.stanford.edu/IR-book/html/htmledition/crawler-architecture-1.html

34

6.1.1.3. IMPLEMENTACIÓN DE LA HERRAMIENTA

En esta historia de usuario se implementa en Python el código necesario para la construcción del Crawler, además se añade un procesamiento para limpieza de ruido en los datos antes de ser almacenados en la base de datos. En la Tabla 8 observamos las actividades realizadas.


1 Desarrollo del código fuente

Con base a la arquitectura y las librerías o frameworks propuestos implementar los algoritmos y módulos del Crawler.

2 Validación de la información

Añadir control de excepciones a los módulos del Crawler.

3 Procesamiento de la información

Implementación de algoritmos de limpieza de datos y posterior almacenamiento de la información.


Como resultado de esta historia primeramente se construyó en Python un algoritmo que entraba a los diccionarios en línea como vademecum.es y capturaba etiquetas HTML en busca de información previamente identificada, sin embargo, al estudiar las estructuras de las páginas web de estos portales se encontró que las mismas no tenían estructuras fijas y se construían arbitrariamente, es decir, los datos no eran uniformes entre diferentes medicamentos, lo cual dificultó la captura de información pues no fue posible automatizar de forma consistente la extracción de información.

Se opta entonces por utilizar la página de INVIMA como fuente de información primaria, pues allí los datos se encuentran estructurados y son uniformes entre sí. Se construye un script en Python el cual recibe la URL del portal web de INVIMA, localiza y almacena los datos de medicamentos con formato CSV en MongoDB. Para el desarrollo, se utilizó la librería urllib2 que permite acceder a un URL dado y la librería Beautiful Soup para capturar los datos, posteriormente al descargar el archivo este es pasado a formato CSV con el fin de poder ser procesado en otra iteración. Además, se añade excepciones para controlar URL vacíos o con accesos restringidos. En la Figura 3 se observa el pseudocódigo del Crawler.

35

Figura 3. Pseudocódigo del Crawler (diseño propio)

6.1.2. PRUEBAS DE ACEPTACIÓN

En la Tabla 9 se muestra un resumen de las dos pruebas de aceptación realizadas en esta iteración, en las cuáles se verifica el funcionamiento del Crawler (Ver Anexo I: Tabla P1I1HU1-2). Ambas pruebas finalizaron con éxito cumpliendo los criterios definidos.

Número Nombre Resultado

P1I1HU1 Validación de extracción de datos

Archivo con los datos recopilados.

P2I1HU3 Validación de almacenamiento de información

Documentos recopilados y almacenados sin ruido en un repositorio

Tabla 9. Resumen pruebas de aceptación iteración 1

6.2. ITERACIÓN 2

En esta iteración se desarrolla el componente de reconocimiento óptico de caracteres ROC, el objetivo de este componente es tomar una imagen y convertir el texto que contenga en texto digitalizado o editable por el ordenador, es decir, identificar los símbolos alfanuméricos que pueden contener la imagen.


En la Tabla 10 se observan las historias de usuario que componen esta iteración.

36

Número Historia de Usuario Descripción

1 Identificación de requerimientos

Identificar ● Herramientas ROC ● Librerías o frameworks ● Procesamiento requerido de

información

2 Selección de herramienta ROC

Realizar pruebas de desempeño, medir y comparar resultados. Escoger la herramienta óptima en cuanto a tiempo y cantidad de palabras reconocidas.

3 Implementación con recetas médicas

Realizar pruebas de la herramienta ROC con recetas o prescripciones médicas. Medir el desempeño.

4 Optimización de resultados

Implementar limpieza de datos y mejora de imagen.

Tabla 10. Historias de usuario iteración 2

6.2.1.1. IDENTIFICACIÓN DE REQUERIMIENTOS

En esta historia de usuario se definen una serie de parámetros y criterios para el desarrollo de este componente. En la Tabla 11 se especifican las actividades realizadas para esta historia de usuario.



Reconocer y parametrizar la información que se quiere obtener de una imagen o PDF, el caso específico una fórmula médica.

2 Identificación del tipo de herramienta ROC requerida según la información que se reconocerá

Validar parámetros como lenguaje, tiempo y plataformas.

3 Definición del flujo de procesamiento

Diseñar un flujo de trabajo con actividades a realizar con los resultados del proceso de reconocer una fórmula médica


37

Como resultado de esta historia se plantea como principal objetivo de la herramienta ROC la identificación de posologías a través de una imagen, lo que hace necesario que la herramienta reconozca archivos de imágenes, es decir, con extensión PNG y JPEG. También es requerido que cuente con lenguaje español o inglés y finalmente que sus tiempos de respuesta sean menores a 30 segundos, tiempo aceptable para identificar textos no mayores a 50 palabras. Un breve esquema del flujo de trabajo típico para el proceso ROC se define en la Figura 4.

Figura 4. Flujo de trabajo de proceso ROC (diseño propio con base en [20])

6.2.1.2. SELECCIÓN DE HERRAMIENTA ROC

En esta historia de trabajo se evalúan diferentes aplicaciones ROC y se selecciona aquella que cumple los requisitos predefinidos previamente. Las actividades realizadas se observan en la Tabla 12.


1 Preselección Escoger de forma preliminar aquellas herramientas ROC que funcionan con imágenes de extensión JPEG o PNG. Además, que tengan diccionarios en español.

2 Identificación de funcionalidades, y limitaciones

Documentación de cada herramienta, identificar su entorno de trabajo, sus ventajas y desventajas y descartar aquellas que no cumplan requisitos.

3 Construcción de scripts Definido el entorno de trabajo de cada una, construir código de prueba para validar el funcionamiento exitoso de las herramientas ROC.

4 Pruebas Agrupación de fórmulas médicas y conformación de datos de prueba base. Pruebas de cada herramienta ROC y consolidación de resultados.

38

5 Análisis y selección Analizar y definir la herramienta ROC con mejor desempeño con base a los siguientes parámetros: tiempo, cantidad de palabras correctas en español y capacidad de sugerencia ante palabra errada.


Como resultado de esta historia, en la Tabla 13 podemos ver un resumen de las aplicaciones OCR evaluadas y los criterios a tener en cuenta. Otro elemento a tener en cuenta fue su interoperabilidad con Python, lenguaje con cual se facilita los procesos que tienen que ver con el procesamiento del lenguaje natural.

Nombre Lenguajes Libre Tipo Compatible con Python

Teserract Múltiple Sí Software Sí

Asprise Múltiple Parcialmente Librería API y SDK

Sí

OCR Space Múltiple Parcialmente API web Sí

Tabla 13. Herramientas ROC preseleccionadas.

Posteriormente, se seleccionó una muestra pequeña de imágenes con texto y se construyó para cada herramienta ROC un script de Python de prueba. En la Tabla 14 podemos observar los resultados de desempeño de cada herramienta para la muestra, sin embargo, se descartó OCR Space debido a que es un servicio web muy limitado. Para las otras dos se utilizaron librerías correspondientes que permiten el uso de las herramientas como lo son PyTesseract y asprise_ocr_api.

Nombre Tiempo promedio por imagen (s)

Promedio de palabras por imagen

Promedio palabras reconocidas

Porcentaje de éxito

Tesseract 5,3 120 85 70,8%

Asprice 6,5 120 73 60.8%

Tabla 14. Resultado pruebas con herramientas ROC

39

Finalmente, la herramienta Tesseract se seleccionó porque satisface las condiciones y posee el mejor desempeño en términos de reconocer caracteres y tiempos, además de un amplio soporte de diversas fuentes especialmente Google.

6.2.1.3. IMPLEMENTACIÓN CON RECETAS MÉDICAS

En esta historia se construye un script en Python que tiene como parámetro de entrada una imagen y devuelve el texto reconocido. Este será usado posteriormente por la aplicación para capturar las posologías desde una foto de una receta médica. En la Tabla 15 podemos observar las actividades realizadas.


1 Esquematización de procesos Definir procesos y realizar diagramas de flujo.

2 Desarrollo funcionalidad conversión OCR

Implementación en código de herramienta ROC con parámetros de entrada y salida.

3 Implementación OCR con foto de fórmula

Evaluación de resultados de funcionalidad OCR con foto de fórmula médica.

4 Implementación con fotografía recortada

Evaluación de resultados de funcionalidad OCR con foto de fórmula médica recortada a solo las posologías.


Como resultados de esta historia, en la Figura 5 podemos observar el diagrama de flujo con los procesos definidos incluidos los de optimización de la siguiente historia, entre los procesos están la captura de la imagen, la extracción de caracteres, el filtro de palabras y el almacenamiento de la salida.

40

Figura 5. Diagrama de flujo herramienta ROC (diseño propio)

Posteriormente, en la Figura 6 observamos el pseudocódigo correspondiente.

41

Figura 6. Pseudocódigo herramienta ROC (diseño propio)

Al ejecutar se encuentra que las recetas médicas presentan muchos caracteres que afectan la salida del ROC y no aportan información relevante, es decir, no describen posologías sino elementos como datos de establecimientos médicos y del paciente, información no necesaria para los objetivos principales del proyecto, afectando de esta forma el desempeño del componente. Por lo que se opta por definir una nueva entrada, en la cual se solicita que la imagen esté recortada al texto que se quiere leer (las posologías), de esta forma se reduce el ruido y la identificación de elementos es mucho más sencilla.

6.2.1.4. OPTIMIZACIÓN DE RESULTADOS

Para mejorar el desempeño de la herramienta ROC se agregan procesos corrección de palabras mal identificadas a través de diccionarios y además un proceso de conversión de la imagen a blanco y negro. En la Tabla 16 se observan las actividades realizadas.


1 Análisis de resultados Analizar los resultados de ejecución de pruebas en cuanto a las características utilizadas en la selección de la herramienta. Establecer con ellos un % de éxito e identificar problemas comunes.

2 Definición de soluciones Identificar posibles soluciones a los

42

problemas hallados como mejoramiento de la imagen o utilización de diccionarios externos.

3 Implementación de soluciones

Implementación en código de las soluciones

Tabla 16. Tareas de ingeniería historia de usuario 4 iteración 2 Como resultado de esta historia, en primera medida se identifica que la conversión de imagen a texto no es óptima, en muchos casos se clasifica un símbolo con el patrón equivocado, por ejemplo, la letra “i” por una “l”, o una “u” por una “o” afectando los análisis y procesamientos posteriores que se le deseen realizar al texto. En consecuencia, se decide añadir dos procesos uno pre y otro post del reconocimiento óptico.

El pre-proceso agregado es la conversión de la imagen a una escala de blanco y negro, para lo cual la librería Image de Python presenta una función que es sencilla de implementar. Por último, el post-proceso agregado fue la utilización de la librería Enchant de Python para identificar palabras en español, aquellos textos que no fueran identificados como palabras se les asigna una lista de palabras sugeridas y una evaluación de similitud, implementada con la librería difflib de Python, dicha evaluación consiste en asignar un porcentaje entre el texto y cada palabra sugerida, el porcentaje nos indica qué tan iguales son ambos textos; si esta evaluación supera el 70% de similitud a una palabra de la lengua española, el texto se reemplaza con esta, en el caso que varias palabras sugeridas superen el umbral, se reemplaza el texto con la palabra que tenga mayor porcentaje de similitud o si varias tienen el mismo porcentaje, se examinan en un diccionario de palabras comunes para hallar la palabra aplicable.

A manera de ejemplo, el resultado de realizar el reconocimiento óptico de caracteres a unas fotos de recetas médicas transformaba “días” en “dlas”, por lo tanto se toma “dlas” y se sugiere palabras en español similares como “días”, “odias”, “dalas”, “dial”, “dilas”, entre otras y luego se les aplica un análisis de similitud, aquella palabra con mayor similitud es reemplazada en el texto, para el ejemplo aquellas palabras con mayor similitud fueron “días” y “dilas” con un porcentaje de similitud del 88%, luego en el diccionario de palabras comunes se encuentra “días”, finalmente está reemplaza a “dlas” en la salida. El pseudocódigo para el análisis de similitud se describe en la Figura 7.

43

Figura 7. Pseudocódigo análisis de similitud (diseño propio)


Las pruebas aplicadas en esta iteración se resumen en la Tabla 17. Ambas finalizaron con éxito cumpliendo los criterios de aceptación establecidos, (Ver anexo I: Tabla P1I2HU3-4).


P1I2HU3 Validación de herramienta ROC

Texto digitalizado obtenido a partir de la foto de una receta médica.

P2I2HU4 Validación de Optimización

Texto digitalizado con mayor porcentaje de palabras reconocidas que en el caso anterior.

Tabla 17. Pruebas de aceptación iteración 2

44

6.3. ITERACIÓN 3

En esta iteración se construye un componente capaz de tomar un texto, identificar las frases que describen posologías y clasificar sus elementos. Como entrada se recibe el texto y como salida un JSON.



Número Historia de Usuario Descripción

1 Identificación de componentes

Seleccionar las frases utilizadas en posologías comúnmente y categorizar las palabras.

2 Identificación de estructuras gramaticales y patrones

Analizar las frases en posologías e identificar diferentes órdenes de las palabras según la categoría asignada.

3 Construcción de algoritmo de clasificación

Implementación en código de un algoritmo capaz de identificar una frase que describa una posología dentro un texto. Tomar la frase, etiquetar las palabras y asociarla a un patrón.


6.3.1.1. IDENTIFICACIÓN DE COMPONENTES

En esta historia de usuario se realiza un análisis a un conjunto de ejemplos de recetas médicas, posteriormente se definen unas categorías para clasificar las palabras concurrentes en aquellas frases que representan posologías. En la Tabla 19 se observan las actividades realizadas.


1 Recolección de ejemplos Conformar un grupo de fórmulas médicas como base de prueba.

2 Análisis de similitudes y diferencias en frases

Identificar y clasificar las palabras en cada ejemplo de prueba. Analizar frecuencias y repeticiones de

45

palabras.

3 Definición de categorías Con base a los resultados establecer las categorías de las palabras frecuentes.


Como resultado de esta iteración, se analizaron alrededor de 50 ejemplos de recetas médicas. Se clasifican las palabras según su intención de descripción y se obtienen las siguientes categorías recurrentes y relevantes para el proyecto:

• Medicamento: nombre de un medicamento o en algunos casos de principios activos.

• Frecuencia: palabras que expresan frecuencias o repeticiones. Por ejemplo: cada, diario, antes.

• Presentación: palabras que identifican la forma física del medicamento, por ejemplo: pastas, tabletas, gotas, inyecciones.

• Tiempo: palabras que expresan una magnitud de medición de tiempo. Por ejemplo: hora, día, mes.

• Unidad: unidad de medida de la presentación del medicamento. Por ejemplo: miligramos (mg), mililitros (ml).

• Cantidad: números que cuantifican las categorías de Frecuencia, Presentación y Tiempo.

Entre la clasificación de palabras se descartan algunas preposiciones, verbos y artículos que no aportan mayor descripción a la posología. A manera de ejemplo podemos tomar la frase “Acetaminofén en pastas 500 mg tomar 1 cada 8 horas” y clasificarla de la siguiente forma: Acetaminofén-[medicamento], pastas-[presentación], 500-[cantidad], mg-[unidad], 1-[cantidad], cada-[frecuencia], 8-[cantidad], horas-[tiempo]. Tras realizar la clasificación, un sistema puede fácilmente automatizar la programación de alertas según la frecuencia especificada si se le da una fecha de inicio.

6.3.1.2. IDENTIFICACIÓN DE ESTRUCTURAS GRAMATICALES Y PATRONES

En esta historia se definen patrones de estructuras de posologías partiendo de la categorización realizada previamente y se propone una gramática. En la Tabla 20 se observan las actividades realizadas.

46


1 Recolección de ejemplos Seleccionar fórmulas médicas legibles con diferentes formatos.

2 Extracción de patrones Clasificar los ejemplos y comparar los órdenes existentes en cada posología.

3 Análisis y resultados Estructurar las categorías que componen las frases de una posología.

Tabla 20. Tareas de ingeniería historia 2 iteración 3

Como resultado de esta historia, se tomaron los ejemplos nuevamente y se extrajo el orden de las palabras categorizadas en cada posología obteniendo la estructura descrita en la Figura 8 donde se observa un árbol con las diferentes combinaciones en las que se describe una posología. Dicho árbol es la representación de la gramática definida, donde M significa medicamento, C-cantidad, P-presentación, T-tiempo, F-frecuencia y U-unidad

Figura 8. Gramática de posología (Diseño propio)

47

6.3.1.3. CONSTRUCCIÓN ALGORITMO DE CLASIFICACIÓN

En esta historia se construye en Python un script que realiza la clasificación de un texto según las categorías y estructura gramatical previamente hecha para identificar las posologías en él. En la Tabla 21 se observa las actividades realizadas.


1 Definición de plataforma de desarrollo

Escoger un lenguaje de programación y entorno de desarrollo para la implementación de la funcionalidad. El parámetro principal es la cantidad de librerías y Frameworks para el procesamiento del lenguaje natural.

2 Diseño de diagrama de flujo Esquematizar los pasos y entradas y salidas del algoritmo de clasificación.

3 Construcción de diccionarios Definir diccionarios con palabras de usos frecuentes en la descripción de posologías

34 Desarrollo del código Implementación en el lenguaje de programación seleccionado.


Como resultado, en la Tabla 21 se menciona el uso de Python para el desarrollo de este componente, en el proceso de clasificación se utiliza la librería Enchant para definir nuestros propios diccionarios de palabras usuales en la expresión de posologías, uno por cada categoría identificada en la historia anterior: medicamentos, frecuencia, presentación, unidades y tiempo. A manera de ejemplo, a continuación, se muestran palabras pertenecientes a cada diccionario.

• Medicamentos: Omeprazol, Paracetamol, Amoxicilina, Diclofenaco.

• Frecuencia: durante, hasta, cada, almuerzo, ayuno.

• Presentación: jarabe, tableta, polvo, gotas, ampolla.

• Unidad: k, mg, g, kg.

• Tiempo: minuto, semana, año, mes.

48

Partiendo de allí, se divide el texto en líneas y a cada línea se le clasifica sus palabras, posteriormente se construye el objeto de salida JSON, con la librería JSON de Python, solo con aquellas frases que contienen al menos una palabra de las siguientes categorías: medicamento, frecuencia y tiempo. Las demás categorías pueden o no estar presentes, además se rectifica que cumplan la gramática establecida. En la Figura 10 se observa el diagrama de flujo y en la Figura 9 el pseudocódigo.

Figura 9. Pseudocódigo de clasificación de posología (diseño propio)

49

Figura 10. Diagrama de flujo clasificación de posología (diseño propio)

50


Un resumen de las pruebas realizadas para esta iteración se observa en la Tabla 22. La prueba finalizó con éxito porque cumple los criterios definidos (Ver anexo I: Tabla P1I3HU3).

Número Nombre Resultados

P1I3HU3 Validación de la gramática definida

La frase de posología puede identificarse en un texto y categorizar sus palabras según la estructura definida


Como evidencia de las pruebas, la Figura 11 es un ejemplo en el cual podemos ver una foto de fórmula médica y su resultado tras pasar por el OCR y la clasificación.

Figura 11. Ejemplo clasificación de fórmula médica

6.4. ITERACIÓN 4

En esta iteración se construye el componente de repositorios de datos, donde se deben almacenar los datos correspondientes a medicamentos, para posteriores consultas y procesamiento de datos. Se definen las estructuras de los datos y la base de datos más acorde para su almacenamiento. Se automatiza el proceso para guardar y estructuras los datos.



51

Número Actividad Descripción

1 Definición de requerimientos

Identificar ● Necesidad de espacio de

almacenamiento ● Herramientas gestoras de Bases de

Datos ● Frameworks o componentes puente

entre Base de datos y aplicaciones ● Estructuras de datos

2 Estructuración de datos de datos

Diseñar el modelo de datos para Medicamentos y para Posologías. Identificar entidades y atributos relevantes y secundarios.

3 Desarrollo algoritmos para procesamiento y limpieza

Desarrollar en código algoritmo para limpieza y gestión de la información que se almacena.

4 Implementación de Base de Datos

Montaje de la Base de Datos, scripts de limpieza y almacenaje de información. Definir usuarios, roles y permisos.



En esta historia de usuario se analizan las necesidades y especificaciones para la construcción del repositorio de datos. En la Tabla 24 se observan las actividades realizadas.

Número Tarea de ingeniería Descripción

1 Especificación de necesidades

Definir necesidades de espacio y elementos requeridos para vinculación con desarrollo anterior. Definir modelo de almacenamiento con base a los datos obtenidos por el Crawler.

2 Recopilación y análisis de herramientas y frameworks

Análisis de las diferentes herramientas gestoras de base de

52

datos de uso libre y librerías y frameworks para trabajar con plataforma de desarrollo

3 Selección de herramienta Escoger herramienta que supla las necesidades especificadas.


Como resultado de esta historia, se especifica que en promedio los datos recopilados por el Crawler ocupan 60 MB, siendo estos publicados mensualmente, al año se requerirían aproximadamente 720 MB de espacio en disco.

A continuación, se define la estructura de grafos como el modelo base para el almacenamiento de la información, esto debido a que su paradigma permite encontrar relaciones entre diferentes elementos que otras bases de datos no pueden identificar fácilmente. Algunos de los gestores de bases de datos orientadas a grafos son Neo4j, Graphbase, OrientDB y HypergraphDB. Se opta por usar Neo4j debido a su amplia documentación y fácil interoperabilidad con la mayoría de los lenguajes de programación.

6.4.1.2. ESTRUCTURACIÓN DE DATOS

En esta historia de usuario se define el modelo con el cual se almacenarán los datos. Para la construcción del modelo, se evalúan los conceptos de corpus y ontologías y se toman como guía base utilizando estructuras en grafo para poder realizar actividades de control y gestión de la información. En la Tabla 25 se definen las actividades para esta historia de usuario.


1 Análisis de datos Descomposición de la información de medicamentos y posologías. Extracción de elementos relevantes para uso del proyecto.

2 Definir entidades, atributos y relaciones

Clasificación de los elementos identificados previamente. Describir relaciones entre diferentes elementos y sus características.

2 Elaboración de modelo Construcción del modelo para el almacenamiento de medicamentos y

53

posologías.


Como resultado de esta historia, primero se evaluaron los datos de los medicamentos obtenidos por el Crawler y se define que los siguientes elementos son de relevancia para el proyecto:

• Código ACT

• Principio activo

• Laboratorio

• Descripción comercial

• Fecha activa

• Fecha inactiva

• Forma farmacéutica

• Cantidad

• Descripción

• Expediente

• Fecha de expedición

• Unidad de medida

• Código identificador

• Estado en el mercado

• Registro sanitario

• Efecto adverso

Una vez identificados los elementos, se utilizó un modelo en grafo que permitiera definir nodos, atributos y relaciones con los lineamientos de una ontología para representar la información de forma abstracta y que, de la misma forma, con los datos se construya un corpus para almacenamiento y gestión de los mismos, en la Figura 12 se muestra la estructura final del modelo para un registro de medicamento.

54

Figura 12. Representación en grafo de los datos (diseño propio)

Las clases definidas, representadas por nodos (círculos), son Medicamento, ACT, Laboratorio, Efecto Adverso y Descripción Comercial. Las relaciones, representadas por flechas, especifican la relación de un medicamento con los demás nodos, de esta forma un medicamento está compuesto por un principio activo, se especifica con su descripción comercial y es fabricado por un laboratorio. Además, cada principio activo puede tener uno o más eventos adversos. Y cada nodo cuenta con una serie de atributos que describen sus características y propiedades.

Como parte de la especificación ontológica, se definen una serie de axiomas que restringen el modelo, los cuales son:

• No pueden existir individuos con el mismo nombre dentro de su clase.

• Cada descripción comercial debe tener una relación de mínimo un medicamento y puede tener varias.

• Un laboratorio puede fabricar uno o más medicamentos.

• Cada medicamento puede ser fabricado por uno o más laboratorios.

• Un medicamento está asociado exclusivamente a un principio activo.

• Un principio activo puede estar relacionado a varios medicamentos.

• Un efecto adverso puede pertenecer a varios principios activos y mínimo a uno.

55

• No todos los principios activos deben tener eventos adversos.

Como parte final, se reflexiona que a primera vista el modelo es simple y fácil de interpretar para un solo registro, sin embargo, juntos conforman una red extensa y compleja con grandes posibilidades de investigación. Otra ventaja del modelo en grafo es que este puede ser extensible sin necesidad de modificar lo construido, lo cual es clave en el futuro.

6.4.1.3. DESARROLLO ALGORITMOS PARA PROCESAMIENTO Y LIMPIEZA

En esta historia se realiza un script en Python que permite almacenar los en la base de datos con la estructura en grafo predefinida, teniendo así el nuevo corpus de medicamentos. Las tareas para esta historia de usuario se observan en la Tabla 26.


1 Selección de plataforma Definir el lenguaje de programación para la implementación de algoritmos y procesos.

2 Esquematización de funciones, procesos y flujos

Realizar diagramas de flujos especificando los procedimientos y secuencias a desarrollar.

3 Elaboración del código Implementación en código de algoritmos que permitan la transformación a modelo, limpiar ruido y almacenar en base de datos.


Como resultado de esta historia, en Python se desarrolla el script con el cual se realiza el procesamiento a los datos y transformación al modelo ontológico teniendo en cuenta las restricciones de axiomas. El diagrama de flujo se puede visualizar en la Figura 13 y el pseudocódigo se puede en la Figura 14.

56

Figura 13. Diagrama de flujo procesamiento y limpieza de datos (diseño propio)

57

Figura 14. Pseudocódigo de procesamiento y limpieza de datos (diseño propio)

Como parámetro de entrada el script recibe los datos recolectados por el Crawler en formato CSV y como salida se produce una serie de archivos que contiene sentencias Cypher, lenguaje con el cual se inserta los datos en Neo4j. Inicialmente se obtenía un solo archivo con todas las sentencias Cypher, sin embargo, dado el gran tamaño del archivo con frecuencia la base de datos se colgaba en memoria. Por lo tanto, se decide particionar la información con el fin de optimizar el proceso batch de inserción de datos.

58

Por último, la limpieza de datos consiste en remover caracteres especiales que con frecuencia estaban presentes en los datos, como por ejemplo “@”, “$”,” %”, “\”, entre otros.

6.4.1.4. IMPLEMENTACIÓN DE BASE DE DATOS

En esta historia se realiza la instalación, configuración e inserción final de datos. El repositorio de datos es nombrado como “Corpus Hampy Yachay”. Las actividades realizadas pueden observarse en la Tabla 27.


1 Instalación Realizar el proceso de instalación del motor de base de datos.

2 Despliegue Realizar las configuraciones para que el motor pueda recibir información y ser consultado por agentes externos.

3 Carga de datos Guardar la información recopilada por el Crawler.


Como resultado de esta historia, en la Figura 15 observamos un grafo que representa una fracción del total de nodos insertados junto a sus relaciones, aproximadamente 2000 nodos. El corpus queda funcional para consultar, insertar, eliminar o actualizar datos.

59

Figura 15. Parte de los datos almacenados en Neo4j


En la Tabla 28 se observa un resumen de las pruebas realizadas en esta iteración, ambas finalizaron exitosamente porque cumplen los criterios de aceptación. (Ver Anexo I: Tabla P1I4HU3-4)


P1I4HU3 Validación de algoritmos Se obtiene los datos esquematizados para ingresar en la base de datos.

P1I4HU4 Validación de repositorio de datos

Se puede consultar, actualizar y guardar datos. Existe una colección de datos de medicamentos.

Tabla 28. Pruebas de aceptación iteración 4.

6.5. ITERACIÓN 5

En esta iteración se construye un aplicativo para la gestión de posología y un servidor que provee servicios web.

60


En la Tabla 29 se observan las historias de usuario que conforman esta iteración.

Número Actividad Descripción


Especificar las plataformas de desarrollo móviles en la que se desarrollará la aplicación. Definir los entornos y plataformas para el servidor y servicios Web.

2 Definición de arquitectura

Esquematizar los diferentes componentes del proyecto, sus interacciones y definir una arquitectura para el mismo.

3 Esquematización de procesos y flujos

Definir los diferentes procesos y actividades de los componentes. Realizar diagramas de actividades y flujos.

4 Desarrollo de servicios web

Elaboración e implementación en el servidor de servicios para la gestión de información de la aplicación.

5 Creación servicio de sincronización de datos

Implementación de base de datos para sincronización de datos.

6 Creación módulo gestión de usuario

Elaboración e implementación de funcionalidades en la aplicación para que el usuario pueda gestionar su información.

7 Creación módulo gestión de posologías

Elaboración e implementación de funcionalidades en App para que el usuario pueda agregar, consultar y eliminar diferentes posologías en la aplicación.

8 Creación módulo historial y gráficos

Elaboración e implementación de funcionalidades en App para que el usuario pueda visualizar su historial de

61

posologías y gráficas de su consumo.



En esta historia se definen la plataforma de desarrollo y se examinan algunas librerías y Frameworks para la construcción de la aplicación. En la Tabla 30 se observan las actividades que conforman esta historia.


1 Selección de herramienta para App

Recopilación y análisis de herramientas para el desarrollo de aplicaciones. Selección de una.

2 Selección de entornos de ejecución

Recopilación y análisis de entornos de ejecución para servidores. Selección de uno.

3 Selección de librerías y frameworks

Recopilación y análisis de librerías y frameworks para el desarrollo de la aplicación, servicios web y de sincronización.


Como resultado de esta historia, y como consecuencia de las anteriores iteraciones, se precisa que la aplicación sea móvil, dadas las características que tienen los requerimientos, tales como: el reconocimiento óptico de las fórmulas médicas a partir de una fotografía de esta, y el sistema de notificaciones para el usuario relacionadas a la toma de medicamentos.

Con base en lo anterior, se define el uso del Framework Ionic para el desarrollo de la aplicación móvil, debido a la facilidad de desarrollo, comparado con las aplicaciones nativas, pues se basa en el Framework de desarrollo web Angular, y que además permite la construcción de aplicaciones híbridas, es decir, que, sin importar su construcción, el usuario final podrá usarla en múltiples plataformas como Android y iOS.

El entorno de ejecución escogido para los servicios REST es Node.js, el cual cuenta con un amplio portafolio de librerías para realizar una gran cantidad de tareas diferentes. Y como solución para la sincronización de datos del usuario con el servidor, se propone el uso de un módulo intermedio gestionado por la plataforma Firebase, que cuenta con diferentes herramientas de apoyo para el desarrollo de

62

aplicaciones móviles de las cuales en este proyecto se utiliza su servicio de base de datos.

6.5.1.2. DEFINICIÓN DE ARQUITECTURA

En esta historia se define una arquitectura para la aplicación y una para el sistema definiendo y especificando todos los componentes e interacciones involucrados en el desarrollo. Además, se esquematizan los flujos de trabajo de todas las funcionalidades que tendrá la aplicación. En la Tabla 31 se observan las actividades realizadas en esta historia.


1 Especificar componentes Describir y especificar los diferentes módulos del sistema, sus funciones y relaciones.

2 Especificar funciones y procesos

Definir las funcionalidades para los componentes de la aplicación

3 Diseño de arquitectura Definir una estructura para el desarrollo sistema.


Como resultado de esta historia, se definen todas las funcionalidades de la aplicación, tanto del cliente como del servidor. Las funcionalidades de la aplicación se describen a continuación:

• Registro, inicio y cierre de sesión.

• Añadir fórmula médica.

• Visualizar medicamentos pendientes para los próximos 7 días.

• Consultar historial de fórmulas médicas.

• Generar alertas para la toma de medicamentos.

• Visualización de gráficas, relacionadas al histórico de medicamentos consumidos.

• Visualización y actualización del perfil de usuario.

Por otro lado, el servidor cuenta con los siguientes servicios REST:

• Guardar, actualizar y consultar datos de usuario.

63

• Guardar, actualizar y consultar posologías asociadas a usuario.

• Identificar posología en una imagen.

• Listar los eventos adversos asociados a un medicamento.

Como resultado de la iteración 5, en la Figura 16, se observa la arquitectura en la que se basa la aplicación. El patrón Modelo-Vista-Controlador (MVC), constituye una manera robusta de construir sitios web, y dada la naturaleza del framework de desarrollo Ionic2 que está basado en AngularJS, representa una ventaja para el proceso de construcción del aplicativo.

Figura 16. Arquitectura MVC (Diseño propio con base en3)

El proyecto, al estar basado en AngularJS, tiene una característica en la comunicación entre modelo y vista. El enlace de datos cambiará los datos que se reflejan en la vista, en cualquier momento que cambien en el modelo. Esto significa un enlace de datos en doble sentido que permite la optimización de código, pues se evitan acciones como definir eventos, manejadores, incluso especificar el código para que los datos transiten de un lugar a otro, o se actualicen. Aunque la implementación del enlace por parte desarrollador no es compleja, y es posible hacerla por ejemplo con jQuery4, el doble enlace –double binding, en inglés- ahorra 2 Ionic Framework es un paquete de desarrollo de software, de código abierto que permite crear aplicaciones móviles utilizando tecnologías web como HTML, CSS y JavaScript. Está basado en Cordova que es el entorno de desarrollo móvil que encapsula la aplicación en una aplicación móvil; Y en Angular, un framework para desarrollo web en TypeScript. Tomado de https://ionicframework.com/docs/intro/concepts/ 3 https://dzone.com/articles/learn-basics-of-mvc-using-angularjs 4 Librería de JavaScript útil para facilitar la interacción con la vista en HTML

64

líneas de código al equipo desarrollo, lo que en consecuencia significa, ahorro en el mantenimiento y limpieza de este. Esa relación bidireccional también se muestra en la figura anterior.

Por último, a escala de todo el sistema se obtiene una arquitectura en 3 capas conformada por la capa de presentación, la de procesamiento y la de datos. La capa de presentación está compuesta por una página web y la aplicación móvil, la capa de procesamiento está conformada por el servidor de Node.js y los componentes de análisis lingüísticos; y por último la capa de datos está compuesta por 3 bases de datos donde se almacena la información consumida y/o producida por la aplicación. En la Figura 17 podemos observar la arquitectura y todos los componentes involucrados.

Figura 17. Arquitectura en 3 capas de todo el sistema.

6.5.1.3. ESQUEMATIZACIÓN DE PROCESOS Y FLUJOS

En esta historia de usuario se construyen diagramas de actividades para las diferentes funcionalidades de la aplicación definidas previamente. En la Tabla 32 se observa las tareas de esta iteración.


1 Especificación de procesos e interacciones

Definir todas las funcionalidades de la aplicación y los procesos que las

65

componen.

2 Esquematización de flujos de trabajo

Realizar diagramas de procesos, actividades e interacciones.


Como resultado de esta iteración, en la Figura 18, Figura 19, Figura 20, Figura 21 y Figura 22 se incluyen los diagramas de actividades para las funcionalidades de la aplicación.

Para el inicio de sesión, como explica la Figura 18, el aplicativo despliega la interfaz para el ingreso de correo y contraseña, que el usuario ingresa para que el sistema consulte con la tabla de usuarios de la base de datos para la verificación de credenciales y poder devolver toda la información de usuario y de sus fórmulas médicas en la interfaz de usuario de cada módulo.

La verificación de usuario incluye también la implementación del componente de recuperación de contraseña, que se habilita al ingresar el correo electrónico y presionar el botón destinado a este fin. Cuando el evento es ejecutado, a través del servicio manejador de la base datos, envía un correo electrónico con un enlace web donde el usuario define una nueva contraseña. Es importante destacar, que, al ser una aplicación móvil, el usuario no está obligado a pasar por este proceso de inicio de sesión cuando en alguna oportunidad anterior hizo uso de la aplicación sin haber cerrado su sesión de cuenta.

Para el registro, según lo explica la Figura 19, se despliega la aplicación en la interfaz de inicio de sesión, donde el usuario elige la opción de registro e ingresa la siguiente información: nombres, apellidos, edad, fecha de nacimiento, sexo, correo, teléfono, clave y confirmación de clave. La aplicación confirma que todos los campos estén llenos y envía a la base de datos la información para que sea almacenada y luego sincronizada cuando el usuario inicie sesión.

66

Figura 18. Diagrama de actividades inicio de sesión (diseño propio)

Figura 19. Diagrama de actividades registro de usuario (Diseño propio)

67

Figura 20. Diagrama de actividades fórmulas médicas. (Diseño propio)

El módulo de servicios relacionado a las fórmulas medicas es el más amplio, como lo representa la Figura 20, pues concentra los requerimientos centrales. Es importante destacar que el reconocimiento óptico de la formula medica es posible hacerlo a través de una fotografía tomada en el instante que se quiera agregar la posología a la aplicación, o puede ser una fotografía almacenada en memoria interna del dispositivo que se carga a la aplicación. En adición, el usuario tendrá la opción de ingresar manualmente toda la receta médica o añadir medicamentos adicionales a los reconocidos por el servidor.

Las acciones referentes al procesamiento de datos que menciona la Figura 20 y que ejecuta el servidor son:

• El reconocimiento óptico de caracteres de la fotografía. Con el texto reconocido, se identifican los posibles medicamentos de acuerdo al registro de medicamentos vigente del INVIMA.

68

• Se identifican gramáticas de posologías presentes en el texto, con el fin de determinar propiedades de la posología como frecuencia, cantidad o tiempo total. Con esto, se retorna a la aplicación un archivo JSON.

• Se identifica a través del modelo de grafo, el principio activo de cada medicamento y los eventos adversos asociados, si existen. Esta consulta retorna un JSON por medicamento.

• Se calcula el cronograma de consumo de cada medicamento y se guarda la agenda en la base de datos.

Con estas acciones realizadas, el paciente confirma la adición de medicamento a la receta médica de la aplicación y se actualiza la base de datos.

Figura 21. Diagrama de actividades visualizar gráfica de históricos (Diseño propio)

La visualización de gráficas de consumo de medicamentos, es otro servicio disponible para el usuario, que se explica en la Figura 21 y que pretende mediante una búsqueda en la base de datos, hacer una tabulación básica de información en la aplicación, para que el usuario pueda visualizar datos relacionados al consumo de medicamentos registrados en su historial.

Por último, la Figura 22 muestra el diagrama de actividades de la gestión de perfil dentro de la aplicación, que en esencia incluye los elementos básicos para su ejecución: Sincronización de la base de datos con la aplicación para la visualización y actualización de la información de usuario.

69

Figura 22. Diagrama de actividades gestión del perfil (Diseño propio)

6.5.1.4. DESARROLLO DE SERVICIOS WEB

En esta historia de usuario se desarrollan todos los servicios disponibles en el servidor y cómo estos son llamados y consumidos. Previamente se ha mencionado el uso del paradigma REST para la construcción de un API con servicios Web, dichos servicios se publican en un servidor Node.js y son consumidos por el aplicativo móvil con peticiones HTTP a través de URLs definidas. En la Tabla 33 observamos las actividades realizadas.


1 Desarrollo de servicio de ROC

Desarrollar servicio que permite tomar la foto de una posología y devuelve un JSON etiquetado con la gramática especificada.

2 Desarrollo de servicio guardar usuario

Desarrollar servicio que permite almacenar datos del usuario en repositorio.

3 Desarrollo de servicio guardar posología

Desarrollar servicio que permite almacenar datos de posologías en repositorio

4 Desarrollo de servicio de consulta eventos adversos

Desarrollar servicio que devuelve un JSON con todos los eventos adversos reportados de un

70

medicamento


Como resultado de esta historia, en Node.js se implementan las diferentes funcionalidades que consumirá la aplicación. Para el servicio de ROC de una fórmula médica, se utilizan las librerías Python-Shell, Express y Express-FileUpload de Node.js. Python-Shell permite ejecutar scripts de Python desde el entorno de Node.js permitiendo proveer parámetros de entrada con los cuales se llama el componente ROC y de etiquetado gramatical desarrollados en la iteración 2 de la sección 6.2 y la iteración 3 de la sección 6.3 respectivamente.

Express es un Framework que permite el manejo de sesiones en el servidor y con la librería FileUpload se realiza la transferencia de archivos desde el aplicativo móvil, al realizar la petición se envía la imagen y esta se almacena temporalmente en el servidor, posteriormente se pasa la imagen al componente ROC, cuando es invocado por el servidor, con una referencia a su ubicación. El resultado del componente ROC es texto plano, dicho texto es pasado como parámetro al hacer un llamado al componente de etiquetado gramatical y la salida es enviada a quien haya hecho la petición al servidor inicialmente.

En resumen, desde el aplicativo se envía la imagen de una receta médica, se descarga y guarda en el servidor, luego se llama los scripts de Python en forma secuencial, como salida se envía un JSON etiquetado a la aplicación quién lo interpretará para crear una nueva posología y finalmente se borra la imagen enviada del servidor. En la Figura 23 se muestra el esquema de la petición realizada y su resultado, aquí el dispositivo móvil llama al servicio con una petición HTTP post enviando la imagen y se queda en espera de una respuesta, el servidor recibe la imagen, la guarda e invoca los componentes ROC y de Etiquetado, el resultado final es un objeto JSON y este es devuelto al servidor, él se encarga de retornarlo al dispositivo, el cual finaliza la petición y continúa con sus funciones.

71

Figura 23. Esquema petición de etiquetado de imagen (diseño propio)

Los servicios de guardar usuario y posología son similares, se realiza una petición HTTP GET desde un dispositivo a través de una URL al servidor de Node.js, este se encarga de capturar los parámetros embebidos en la URL pertinentes a cada servicio, para el caso de guardar usuario estos son nombre, apellido, correo y clave; y para el caso de guardar posología son correo, medicamento, unidad de medida, cantidad, frecuencia, duración, fecha de inicio y presentación. Finalmente, el servidor construye un objeto con los parámetros extraídos e intenta almacenarlo en MongoDB en su correspondiente colección.

Ambos servicios de guardar posología y usuario utilizan la librería mongodb de Node.js como interfaz para conectar con la base de datos, se intenta realizar la conexión, si esta falla se envía al dispositivo un JSON informando el error de conexión, de lo contrario se procede a guardar los datos en la base de datos, si la colección no existe la librería se encarga de crearla y luego guardar los datos, por último se envía un JSON informando la finalización exitosa y el dispositivo da por finalizada la petición para continuar con sus funciones. En la Figura 24 se puede ver el esquema de todo lo explicado anteriormente.

72

Figura 24. Petición de almacenamiento en servidor (Diseño propio)

Finalmente, se crea el servicio para consultar los eventos adversos de un medicamento. Se realiza una petición HTTP GET a través de una URL, se captura como parámetro el nombre del medicamento, se ejecuta un script en Python que ejecuta una consulta a la base de datos en Neo4j y devuelve la lista de eventos adversos asociados al medicamento y el principio activo que lo conforma, solo si existe el medicamento, en la Figura 25 podemos ver el pseudocódigo del proceso en Python.

Figura 25. Pseudocódigo de consulta de efectos adversos

Adicionalmente, se envía también el principio activo del medicamento consultado, pues los eventos adversos están relacionados directamente a los principios activos. Para realizar la consulta se utiliza la librería Python-Shell de Node.js y la librería neo4j.v1 de Python junto al controlador neo4j-driver, los cuales se encargan de generar la conexión a Neo4j y permiten ejecutar tareas como escritura y lectura

73

sobre la base de datos. La consulta está descrita en un lenguaje de consulta llamado Cypher y tiene el siguiente formato:

“MATCH (a:Medicamento)-[r]-(b:ACT)-[r]-(c:Efectos Adversos) WHERE a.nombre CONTAINS ‘nombre’ RETURN c.descripción”,

Dicha estructura busca a través del principio activo ligado a un medicamento todos los eventos adversos reportados. En la Figura 26 se observa la petición realizada y su respuesta.

Figura 26. Petición de eventos adversos a servidor (Diseño propio)

6.5.1.5. CREACIÓN SERVICIO DE SINCRONIZACIÓN DE DATOS

En esta historia de usuario se define e integra un servicio intermedio en la aplicación con el fin de que el usuario pueda visualizar sus datos desde cualquier dispositivo donde inicie sesión. La lista de tareas de esta historia se describe en la Tabla 34.


1 Búsqueda y definición de un servicio web para sincronización de bases de datos

Definir una tecnología o un proveedor de servicios web que permita la sincronización en tiempo real de datos con aplicaciones móviles

3 Definición del modelo de datos

Modelar la estructura de datos acorde a las características de la sincronización de datos

4 Desarrollo del Proveedor de Desarrollar el módulo de conexión

74

servicios entre la aplicación y la base de datos


En el desarrollo de las tareas de ingeniería se evidenció la necesidad de buscar una alternativa para la ejecución de la sincronización de datos en tiempo real de la aplicación, pues se debe garantizar que en cualquier dispositivo pueda iniciar sesión algún usuario registrado y pueda tener acceso a la totalidad de información. Por otro lado, también se hace necesario porque la aplicación debe proveer un servicio de notificaciones locales, que ante cualquier cambio debe sincronizarse de inmediato para garantizar la coherencia e integridad en la información, por ejemplo, si se actualiza la hora de ejecución de una notificación que recibirá el usuario de manera local (es decir, el lanzador o trigger de la notificación está en el dispositivo y no en el servidor) directamente en la base de datos, la aplicación deberá estar en la capacidad de actualizar la información para hacer las modificaciones sobre el servicio de notificaciones de manera que sea consistente con el cambio en la base de datos. Lo mismo debería ocurrir en el caso contrario. Esto es importante para la ejecución en segundo plano de la aplicación, de forma tal que mantenga siempre activo el servicio de escucha a la base de datos a cambios del cronograma de notificaciones.

Con el fin de solucionar la sincronización se tienen en cuenta dos posibles bases de datos compatibles con consultas en tiempo real. Google Firebase Realtime Database y RethinkDB, esta última es una base de datos open source y orientada a documentos –en formato JSON-, tiene su propio lenguaje de consulta para las tablas de almacenamiento de datos: ReQL. Sin embargo, para su ejecución depende de la implementación en un servidor del desarrollador.

Como resultado de esta historia se definió el uso de Google Firebase que es una plataforma para desarrollo de aplicaciones web y móviles. Que dentro de los servicios que ofrece por proyecto tiene autenticación para la gestión completa de usuarios, que incluye creación, eliminación y edición de usuarios, además del servicio de verificación de credenciales al inicio de sesión de usuario. Esto trae como ventaja que toda la gestión de seguridad al acceso de aplicación ya se encuentra implementada en Google Firebase y no depende de la aplicación.

El otro servicio que provee la plataforma es la base de datos en tiempo real que guarda la información en formato JSON, pero no es orientada a documentos, y que fue necesaria para el desarrollo de la sincronización de datos y almacenamiento de la información de los usuarios. Las razones que respaldan esta decisión son:

• Al elegir un desarrollo híbrido para aprovechar la ejecución multiplataforma de la aplicación, ya que Firebase permite sin desarrollo adicional, la ejecución sin fallos sobre iOS y Android.

75

• No es necesario la construcción de servicio web o web-servicio, de uso de API REST o incluso de la configuración de servidores.

• Permite la sincronización de datos en tiempo real, por lo que no es necesario implementar una infraestructura específica en un servidor, pues su servicio está preparado para responder a cambios en los datos en cualquier momento.

• Google Firebase trae integrado un servicio autenticación de usuarios, que requiere una implementación en código bastante corta y que incluye de manera implícita mecanismos de seguridad y recuperación.

• Para la implementación de módulos de administración o mandos de control de aplicaciones, Google Firebase solo permite la ejecución sobre un servidor. De forma que desde el cliente no se puedan hacer modificaciones, por ejemplo, a la tabla de usuarios, pues esta una función de administrador.

Es fundamental la facilidad de uso de los servicios de Firebase, pues para la implementación de las consultas en tiempo real facilita el uso de sus tipos de alerta a cambios. Para manejarlas, usa 3 funciones que se usan una vez se ha referenciado la ubicación de datos de la que se pretende estar atento a cambios.

En la Figura 27 se muestra el pseudocódigo de implementación de las consultas en tiempo real con Firebase. La función ON se usa mantener activa la escucha sobre el objeto referenciado, que puede ser todo el objeto usuario y cualquier cambio derivado en la información que contiene. La función OFF para desactivar la alerta a cambios en la ubicación especificada. Y la función ONCE para consultar una única vez en la ubicación referenciada. Todas estas 3 funciones trabajan sobre toda la ubicación de datos referenciada, incluso si el objeto JSON tiene más ramificaciones.

Figura 27. Pseudocódigo funciones Firebase para consultas en tiempo real

76

El pseudocódigo que se muestra en la Figura 28 representa la simplicidad en la construcción del proveedor dentro de la aplicación para la sincronización de datos. Su ejecución depende de los parámetros que recibe el constructor, que determinan la credencial de acceso al servicio de Google. A partir de allí solo se deben construir funciones regulares de escritura y lectura de datos, donde es necesario saber el directorio donde se pretende leer o escribir datos, y el identificador de usuario asignado por Firebase que hace parte del directorio, y que sin su conocimiento se dificulta acceder a los datos almacenados.

Figura 28. Pseudocódigo proveedor de acceso a servicios de base de datos

6.5.1.6. CREACIÓN MÓDULO DE GESTIÓN DE USUARIOS

En esta historia se construye la interfaz, las funciones y la conexión a servicio de Firebase necesarias para que el usuario pueda registrarse, iniciar sesión y gestionar su información. Las actividades realizadas pueden verse en la Tabla 35.


1 Desarrollar componente de autenticación

Implementar los servicios de inicio de sesión, cierre de sesión y registro de usuario para la aplicación.

2 Desarrollar gestor de Perfil de usuario

Implementar la gestión de perfil dentro de la aplicación para que el usuario pueda ver y editar su información

3 Desarrollo de la interfaz Desarrollar la interfaz gráfica del

77

gráfica de usuario del módulo servicio de autenticación y de gestión de perfil


Figura 29. Diagrama de colaboración: Gestión de usuarios.

Como resultado de esta iteración, se desarrolla otro proveedor dentro de la aplicación, que proporcione los servicios de autenticación de usuario (registro, inicio y cierre de sesión), que está separado del módulo de sincronización de datos, debido a que Firebase almacena datos y usuarios de manera independiente. La dependencia de los datos con un usuario sucede con la asignación de un identificador por parte de Firebase. Las relaciones existentes se muestran en la Figura 29 y en la Figura 30 se observa la interfaz de este módulo.

Figura 30. Interfaz de gestión de usuarios.

Este módulo usa el servicio de autenticación de Google Firebase, que es independiente al de la base de datos en tiempo real. Este servicio permite

78

implementar en la aplicación el registro e inicio de sesión de usuario básicos. Sin embargo, también permite la recuperación de cuentas, que se activa una vez el usuario completa el campo Correo Electrónico y presiona el botón Olvidé mi contraseña. Al activarse, a través de Firebase, se envía al usuario un mensaje de correo electrónico con un enlace para reestablecer su contraseña. Cabe anotar también que los servicios de autenticación de Google usados en la aplicación cuentan ya con la gestión de excepciones, de forma tal que su implementación en la aplicación sea reducida. El uso de este módulo en la aplicación se explica en el manual de usuario (Ver 12. Anexo II).

6.5.1.7. CREACIÓN MÓDULO DE GESTIÓN DE POSOLOGÍAS

En esta historia se construye la interfaz, las funciones y la conexión tanto al servicio web ROC como al de Firebase para que el usuario pueda añadir una posología de manera manual o a través de una foto.

Las tareas de ingeniería para esta historia se definen en la Tabla 36. La implementación de esta historia es fundamental para la entrega del prototipo de aplicación porque su desarrollo pretende crear el enlace Aplicación-Servidor de forma que el diagrama de secuencia para mostrado en la Figura 20, pueda llevarse a cabo.

La importancia de esta historia, y la causa de creación para el desarrollo del proyecto, radica en la imposibilidad de ejecutar los procesos de reconocimiento óptico de caracteres para el reconocimiento de las gramáticas posológicas y de consultar el corpus para la búsqueda de relaciones asociadas a la posología. También existe una dificultad respecto al posible rendimiento de la aplicación en el dispositivo móvil al momento de enviar múltiples peticiones de escritura a la base datos de manera simultánea, como ocurre al momento de guardar la agenda de consumo de un medicamento. La historia surge entonces, con el fin de maximizar el rendimiento de la aplicación a nivel local, y con el fin de ejecutar de forma adecuada los servicios de procesamiento de imagen y de datos para que el usuario tenga una experiencia de calidad usando la aplicación (Ver Anexo I: Tabla H7I5).


1 Desarrollo de conexión entre Aplicación y Servidor

Desarrollo e implementación del módulo de conexión entre la aplicación móvil y el servidor remoto para el envío de peticiones y recepción de sus respuestas

2 Componente de generación y temporizador de alertas

Desarrollar un componente de uso de las respuestas del servidor, para generar un sistema de notificaciones

79

locales, para todos los medicamentos

3 Desarrollo de la interfaz gráfica de usuario del módulo

Desarrollar la interfaz gráfica del servicio de envío de posologías (conexión aplicación-servidor) y de generación de alertas


Figura 31. Diagrama de colaboración: Gestión de Posologías.

Como resultado de esta historia, es importante destacar el servicio creado para enviar al servidor la fotografía, para que el proceso OCR y de tratamiento de datos se lleve a cabo y retorne una respuesta en formato JSON que la aplicación pueda reconocer. El proceso descrito se explica en la Figura 31.

Para la construcción de ese servicio, fue necesario la creación de un último proveedor en la aplicación, que se encarga a través de las librerías HTTP y FileTransfer, de enviar una petición a la URL: “http://186.154.95.101/ocrpastillero/formula” junto a un objeto con todos los parámetros requeridos, como el tipo de transferencia, clave de archivo y otros adicionales si se requieren (descripción, valor, entre otros). En la Figura 32, se ve el flujo que sigue un cliente ante de enviar la fotografía al servidor.

80

Figura 32. Interfaz para la creación de posologías

Una vez el servidor retorna el JSON, la aplicación procede a separar la posología, medicamento por medicamento, y lo va desplegando en un formulario editable para el usuario, de forma tal, que este pueda confirmar, actualizar y/o corregir la información de cada fármaco. Esto resulta útil cuando la información en la fórmula médica está incompleta o si el componente ROC no reconoció correctamente alguno de los campos.

Figura 33. Interfaz para la confirmación y edición de información posológica

En el JSON etiquetado, se encuentran los posibles medicamentos que la receta incluye y que son retornados producto del análisis de reconocimiento óptico de caracteres (ROC) y de la comparación con el registro de medicamentos oficiales en

81

el servidor. Con esto, el usuario elige el medicamento correcto. Por ejemplo, si el servicio ROC reconoce “Losartan”, el servidor retorna una lista de posibles medicamentos, como Karplan (Losartan Potasico) o Losartan 100 MG Tableta recubierta. Y dado a que cada medicamento tiene una descripción comercial distinta, puede contener cantidades diferentes del principio activo o ser fabricado por diferentes laboratorios, es el usuario quien define el medicamento que desea registrar.

En caso de que el servicio ROC, no retorne nada en la etiqueta medicamento, porque no reconoció ninguna palabra dentro del registro de medicamentos, el usuario tiene también la posibilidad de escribir el medicamento. Luego de la definición del medicamento, a partir del JSON retornado se predefinen los demás campos: Cantidad total del medicamento, presentación del medicamento, frecuencia y unidad de tiempo de consumo, fecha y hora de inicio de consumo. Teniendo todos los campos editables para el usuario. Parte del flujo de funciones descrito anteriormente, se evidencia en la Figura 33, en forma de interfaz gráfica de usuario.

Al confirmar cada medicamento, la aplicación envía una petición al servidor para que, de acuerdo al medicamento elegido por el usuario, se haga una búsqueda del principio activo y los efectos asociados a su consumo, y también para que se calcule el cronograma de consumo de acuerda a la frecuencia y cantidad total. Esta petición retorna un archivo JSON, con el que se complementa la información del medicamento antes de proceder a guardarlo en la base de datos.

En el último medicamento que reconoce el servidor, el usuario tendrá la oportunidad de añadir medicamentos, ya sea porque el servidor no reconoció la totalidad o porque el usuario decide añadirlo. El usuario, como se ha mencionado, puede confirmar cada medicamento y su información, sin embargo, también podrá descartar cualquier medicamento para evitar su registro.

Al terminar de ingresar la formula, el usuario es dirigido a la página inicial de la aplicación, como se ve en la primera parte de la Figura 35. En ese proceso, el método Constructor de esa página se ejecuta y actualizará desde Firebase el cronograma de consumo de medicamentos, agendando los nuevos registros. Cada registro de consumo dentro del cronograma en la base de datos tiene un identificador único, de forma que sea posible editar las tomas individuales de cada medicamento, y se asegure la ejecución de las notificaciones locales en cada medicamento por cada toma registrada. Por ejemplo, una notificación por cada una de las 30 tabletas de Losartan que el usuario planea consumir.

82

Figura 34. Ejemplo notificaciones locales

Las notificaciones5 se agendan al iniciar sesión, o al registrar una posología. Y se eliminan al cierre de sesión de usuario. Un ejemplo de cómo se visualizan las notificaciones para la toma periódica de medicamentos, se observa en la Figura 34.

Figura 35. Interfaz seguimiento semanal de medicamentos

5 Las notificaciones son alertas que aparecen en la barra de estado del dispositivo móvil. Según el tipo de notificación, tienen como objetivo informar, recordar o requerir algún tipo de información al usuario. En los dispositivos móviles se ejecutan aun cuando la aplicación a la que están asociadas no se esté ejecutando. Suelen ir acompañadas de la activación del dispositivo, una alerta de sonido y una alerta vibratoria.

83

Existen dos tipos de notificaciones para implementar:

1. Las notificaciones push: son mensajes que se envían directamente desde un servidor que provea esta función. Pueden programarse, activarse con un evento en específico, configurar su tipo (solo mostrar mensaje, mostrar botones de acción, requerir un texto de entrada, entro otros), sin embargo, necesitan de conexión a internet para que el servidor pueda hacer efectiva la notificación. Ejemplos de notificaciones push son: un mensaje de WhatsApp, un nuevo correo electrónico en la bandeja entrada, descuentos limitados de una aplicación de venta de productos o servicios.

2. Las notificaciones locales, tienen las mismas características que las push, sin embargo, son agendadas desde la misma aplicación. Por tanto, no son asignadas de manera remota, y en consecuencia pueden ser entregadas al usuario sin requerir conexión a internet

Para la implementación de la aplicación, dada la posibilidad de que un cliente no cuente con internet pero que, a pesar de eso, desee recibir el recordatorio de consumo de cada medicamento, se decidió usar las notificaciones locales.

Es importante resaltar que este módulo concentra gran parte de las funciones principales, debido a esto, la cantidad de procesos que se ejecutan es alta y podrían afectar el tiempo de ejecución. Por ejemplo, cuando el usuario confirma cada medicamento se realizan las siguientes actividades: Se hace un registro en Firebase del Medicamento, así como un registro del cronograma de consumo. También consulta en el servidor los eventos adversos, para luego guardarlos en el registro de datos del medicamento en Firebase. Por último, se agendan todas las notificaciones diferenciando cada una con un identificador único para evitar la sobre escritura.

El uso de este módulo en la aplicación se explica en el manual de usuario (Ver 12. Anexo II).

6.5.1.8. CREACIÓN MÓDULO DE HISTORIAL Y GRÁFICAS

En esta historia de usuario se desarrolla la interfaz, funciones y acceso a servicios tanto de servidor como de Firebase para que el usuario pueda ver su historial de posologías y una gráfica de consumo. Las actividades realizadas se observan en la Tabla 37.


1 Desarrollo componente de normalización de datos para graficar

Desarrolle de componente que ajuste los datos de las historias médicas de forma que calcule

84

tiempos y frecuencias de consumo, asegurando que las dimensiones de las gráficas están estandarizadas


Desarrollar la interfaz para graficar y vista del historial de fórmulas médicas de cada usuario


Figura 36. Diagrama de colaboración: Gestión de historial y gráficos

En esta historia, se implementan las relaciones que muestra la Figura 36. La implementación de este módulo es importante en el rendimiento de la aplicación, pues los servicios ejecutados son los de mayor procesamiento. Esto se muestra también, en el diagrama de actividades en la Figura 21.

Figura 37. Interfaz para la visualización de posologías y eventos adversos

85

Para este módulo, es fundamental destacar dos aspectos: El primero, una vez el cliente selecciona una de las fórmulas que históricamente ha registrado, podrá ver la información de los medicamentos, frecuencias y tiempos de consumo. Sin embargo, adicionalmente podrá descargar su fórmula médica en formato JSON, de forma que pueda hacer uso de esta, en otras aplicaciones del ámbito de la salud, si es posible o si el usuario de manera individual lo requiere. Estas funcionalidades pueden ser vistas en la Figura 37.

A continuación, se detallan algunas funciones, y sus características para el desarrollo en la aplicación:

• Generación estadísticas y gráficas: la estructuración de los datos en Firebase, al estar en formato JSON, representan un factor importante en la recolección de los datos farmacéuticos para la construcción de la tabla de datos y la normalización de esta. Una vez se construye la tabla, se usa la librería chart.js, que está basada en JavaScript y es de código abierto, para representar el conteo de tomas de medicamentos o de un medicamento en particular que tuvo o tendrá el usuario mensualmente, de acuerdo a los registros almacenados. Lo anteriormente descrito se refleja en el seudocódigo de la Figura 38 y visualizarse en Figura 39.

Figura 38. Seudocódigo Gráficas de Usuario

86

Figura 39. Interfaz de gráficos de posologías

• Eventos adversos: hay un aspecto crucial en el desarrollo de la aplicación que es la búsqueda de los eventos adversos de los medicamentos. Funcionalidad que es posible usando las bondades del modelo de grafos construido, pues como se mencionó anteriormente, el lenguaje Cypher de Neo4j permite consultar a través de las relaciones que tiene el medicamento con posibles eventos adversos, a una distancia igual a 1 o más, entre nodos relacionados.

• Descarga de historial de medicación: es necesario decir que el prototipo de aplicación que el proyecto pretende desarrollar no requiere la interoperabilidad con instituciones o entes de salud, es decir, la aplicación no busca crear vínculos de la información de las fórmulas médicas del usuario con una entidad prestadora de salud, o alguna otra entidad, por tanto, no hay intercambio de información electrónica.

La única interacción que existe es con el usuario, pues se provee un servicio que solicita únicamente su fórmula médica para activar un sistema gestor de notificaciones que recuerde el consumo de los medicamentos. Por tanto, un estándar integral como HL7, a pesar de sus amplias aplicaciones, no es requerido en este proyecto, debido a la carencia de transferencia e interoperabilidad con datos clínicos o farmacológicos de otras instituciones. Sin embargo, el usuario, si así lo desea, podrá descargar el archivo JSON de su historial de fórmulas y adjuntarlo en los canales electrónicos, diferentes a este proyecto, para acceder a otros servicios relacionados a los que puede acceder a partir de esa información. El proceso de

87

descarga del archivo JSON correspondiente a cada formula medica ingresada por el usuario puede verse en la Figura 40.

Figura 40. Interfaz de descarga JSON de formula médica

El uso de este módulo en la aplicación se explica en el manual de usuario (Ver 12. Anexo II).

6.5.1.9. CREACIÓN MÓDULO DE ADMINISTRACIÓN

En esta historia de usuario se desarrolla el módulo que permite al administrador de la aplicación conocer cálculos y/o estadísticas básicas acerca del consumo farmacéutico de los usuarios registrados, incluyendo la gestión de usuarios (agregar, editar, eliminar) y la visualización de recetas, medicinas y efectos adversos. Las actividades realizadas se observan en la Tabla 38.


1 Desarrollo componente de visualización de gráficas

Desarrollo de componente que ajusten los datos de todos los usuarios de forma que calcule tiempos y frecuencias de consumo, asegurando que las dimensiones de las gráficas están estandarizadas.

2 Desarrollo de gestión de usuarios

Desarrollar la gestión de usuarios de forma que se pueda agregar, eliminar y editar usuarios, así mismo visualizar las recetas médicas de los usuarios de forma integral.

88


Como resultado de esta iteración, se desarrolla un módulo web independiente de la aplicación móvil, pero que aprovechando la ventaja de Ionic, al ser basado en el framework de desarrollo web Angular, este módulo se construyó usando esta herramienta. Por consiguiente, para la conexión a Google Firebase solo fue necesario instalar la misma librería de conexión (Firebase) y replicar de la aplicación móvil, el código de verificación de la base de datos.

Para el ingreso al módulo, se construye una página web de acceso público (Ver Figura 41), alojada en el servidor, y que tiene como objetivo: informar al público acerca de la aplicación móvil, permitir su descarga y permitir el acceso al administrador a este modulo

Figura 41. Página Web de información - Aplicación móvil

Para el ingreso al módulo, se construye una página de inicio de sesión, como se ve en la Figura 42, bajo el mismo modelo de autenticación de la aplicación móvil, es decir, usando el servicio destinado para este fin de Google Firebase. Sin embargo, se habilita la entrada al módulo a un solo correo definido por el desarrollador.

89

Figura 42. Interfaz de inicio de sesión al Módulo de Administración

Al iniciar sesión, y para dar cumplimiento a la primera tarea de ingeniería de esta historia, se desarrolla una página dentro del módulo para la visualización de datos que resuman la actividad de los usuarios actuales de la aplicación móvil, tal como lo muestra la Figura 44 y Figura 45.

Para la consolidación de los datos posteriormente graficados, se implementa la misma metodología de consulta y tratamiento de datos usada para la gestión de gráficos de usuario en la aplicación móvil. El diagrama de colaboración en la Figura 43 explica el proceso que se lleva a cabo. Sin embargo, para consolidar el total de usuarios, y no solo los registros individuales, solo fue necesario cambiar la ruta de ubicación de los datos que referencia al usar el objeto Firebase. Es decir, la referencia ya no es /Usuarios/$ID_Usuario/, sino solamente /Usuarios/. Con esta referencia, el objeto JSON retornado, contiene toda la información registrada para la tabulación.

Figura 43. Diagrama de colaboración Módulo Administración: Gráficas

90

La librería para la construcción de las gráficas, igual que en la aplicación móvil, es ChartJs. Para su uso, solo es necesario crear un objeto tipo Chart con las series de datos como parámetros, y opciones de visualización opcionales. Una desventaja de esta librería, es que, si la cadena de la leyenda de datos es extensa, reduce el tamaño de los gráficos, por ejemplo, el gráfico de barras. En este módulo, se usan 2 tipo de gráficos adicionales: Gráficos de barras y grafico tipo torta. En resumen, en este parte del módulo se puede consultar:

• Número de usuarios registrados.

• Número de medicamentos registrados.

• Número de recetas médicas registrados.

• Número de notificaciones agendadas.

• Gráfica de dispersión Meses vs Cantidad tomas de medicamentos.

• Porcentaje de usuarios con fórmulas registradas.

• Porcentaje de tomas de medicamentos pendientes por consumir.

• Porcentaje de recetas médicas con medicamentos pendiente de consumo.

• Tomas por medicamento

• Consumo comparativo de medicamentos

Figura 44. Interfaz visualización de gráficas del Módulo de Administración I

91

Figura 45. Interfaz visualización de gráficas del Módulo de Administración II

En la segunda parte de la implementación de este módulo correspondiente a la gestión de usuarios y sus recetas, se usa el componente para Angular especializado en tablas: Ng2 Smart Table, que es en esencia una librería de tablas de datos inteligentes con funciones de clasificación, filtrado, paginación y funciones de agregar, editar y eliminar. Son precisamente estas funciones que por defecto pueden configurarse en las tablas, las que permitieron condensar toda la gestión en una sola página. De forma tal, que se crearon 4 tablas de este tipo en la misma página (Usuarios, Recetas Médicas, Medicamentos y Efectos Adversos), en las que el contenido es dependiente de las acciones del usuario. El flujo de acciones se puede ver en el diagrama de colaboración de la Figura 46.

Figura 46. Diagrama de colaboración. Módulo de administración: Gestión usuarios

92

De este modo, si el administrador hace clic sobre el registro de datos de un usuario, la tabla de recetas médicas se actualizará con los datos de ese usuario. Al hacer clic en una receta, se actualizará la tabla medicamentos con los registros de la receta. Por último, al elegir un medicamento la tabla de efectos adversos se actualizará. Todo lo anterior, gracias al manejo de eventos de la librería Ng2 Smart Table que activa la consulta a Firebase y activa la actualización de datos a cada tabla.

Figura 47. Interfaz gestión de usuarios del Módulo de Administración

Una característica importante en la construcción del módulo de gestión de usuario, donde es posible editar un usuario, incluyendo su correo y contraseña, es que únicamente estos servicios están disponibles si se cumplen dos condiciones:

• Se usa una librería alternativa para la conexión con el servicio de autenticación de Google Firebase: FirebaseAdmin. La configuración debe estar acompañada de clave privada otorgada en formato JSON por Google.

• La librería únicamente puede ser implementada del lado del servidor. Si se implementa del lado del cliente, no genera errores, pero su funcionamiento es nulo. Por esta razón, los servicios de acceso a modificaciones de datos de autenticación de usuarios se hacen mediante una petición HTTP al servidor.


En la Tabla 39 se realiza un resumen de las pruebas de aceptación realizadas. Para ampliar su información (Ver Anexo I: Tabla P1I5HU4-6-7-8).

93


P1I5HU4 Prueba servicio web captura de posología

Se envía una imagen y se retorna un objeto JSON que define una lista de posologías a través del etiquetado de palabras.

P2I5HU4 Prueba servicio web guardar datos de usuario y posologías

Se envían los datos y se recibe un mensaje de confirmación con informe de resultado. Datos almacenados en base de datos.

P3I5HU6 Prueba módulo gestión de usuarios

Los casos de error en inicio y registro tratados exitosamente (clave incorrecta, usuario ya existe, campo vacío). Al sincronizar datos se garantiza integridad en los mismos.

P4I5HU7 Prueba módulo gestión de posologías

Retorno en consola del objeto JSON con la lectura y etiquetado de la fórmula médica

P5I5HU8 Prueba módulo historial y gráficos

Impresión en consola de la tabla de datos normalizada para vista de gráficas preliminares


94

7. PRUEBAS DE RENDIMIENTO DE LA APLICACIÓN MOVIL

En la Tabla 40 se observan los resultados de realizar diferentes pruebas con la aplicación. El objetivo de esta etapa del proyecto es determinar factores que afectan la ejecución de los servicios de la aplicación de acuerdo a la dinámica que cada usuario desempeñe en el uso de esta. Por ejemplo, el tamaño de la fotografía o la longitud del texto, determinan en gran medida el tiempo de ejecución total, que se concentra en el proceso de reconocimiento óptico de caracteres.

También es importante medir el tiempo de ejecución del inicio de sesión, porque después de validar los datos de autenticación, se ejecuta un servicio que actualiza los medicamentos a consumir por el usuario en los próximos 7 días. Por lo que se concluye, que los procesos que más generan demoras en ejecución tienen que ver en mayor proporción con acceso a servicios del servidor, y luego, a la sincronización de datos con Firebase.

Resultados Parciales: Tiempos de Ejecución

Aspecto por medir Tiempo

promedio en milisegundos

Lanzador tiempo

Finalizador tiempo

Inicio de sesión 868 Al elegir Iniciar

Sesión Carga completa

del Inicio

Inicio de sesión automático 772 Al iniciar la aplicación

Carga completa del Inicio

Carga de medicamentos día específico

259 Al elegir un día de la semana

del Inicio

Carga completa de Cronograma

Carga del listado de posologías

257 Al elegir pestaña

Formulas Médicas

Carga completa de Formulas

Medicas

Respuesta servidor al enviar fotografía de

posología. Tamaño 400 kb 12106

Al elegir Cargar luego de

capturar imagen

Confirmación del Servidor

Confirmación medicamento con cantidad: 30 (Ej. 30

tabletas) 23458

Al elegir Confirmar en la

ventana de

Confirmación de la aplicación o

cambio al

95


tabletas) 9562

confirmación de medicamentos

siguiente medicamento


tableta) 1341

Carga de una historia, formula o posología

148

Al elegir una posología en

Fórmulas Médicas

Carga completa de Fórmula

Carga de una lista de eventos adversos de un

medicamento 115

Al elegir medicamento en

Fórmulas

Carga completa de Efectos

Tabla 40. Resultados: tiempos de ejecución

De la anterior tabla, es relevante resaltar dos aspectos. Primero, el tiempo de inicio de sesión automático es menor al inicio regular, y aunque la fracción de tiempo diferenciador puede considerarse insignificante, el usuario se ahorra otra fracción de tiempo importante en la entrada manual de credenciales de acceso.

Segundo, el tiempo de ejecución de la confirmación de medicamentos es mucho más alta que la respuesta del servidor al procesar la fotografía de la posología. Esto se debe básicamente a la cantidad de procesos que ejecuta la aplicación en un mismo momento (Registro y consulta de datos, comparación y agenda de eventos a nivel local). Este retraso se debe también a que el framework de desarrollo Ionic no es robusto ante operaciones simultaneas. Esta diferencia de tiempo es notable también al comparar la capacidad de respuesta según la cantidad de unidades de medicina que tenga cada fármaco.

Finalmente, en la Tabla 41 se aprecian, el número de casos de prueba expuestos en el desarrollo del aplicativo, y que determinaron la capacidad de repuesta que tiene la aplicación en diferentes situaciones.

Resultados parciales: Pruebas ejecutadas

Aspecto por medir Cantidad

Usuarios creados 4

96

Posologías creadas en la aplicación

23

Fotografías disponibles de posologías

35

Notificaciones agendadas En promedio

90 por usuario

Tabla 41. Resultados: pruebas ejecutadas

97

8. CONCLUSIONES

Las iniciativas que promueven a las instituciones publicar sus datos bajo la filosofía de datos abiertos han puesto a disposición de muchos investigadores millones de datos para sus tareas cotidianas. Si bien contienen un elemento implícito de organización según el experto, en su caso las organizaciones, la obtención de la información no siempre es sencilla e implica tareas de limpieza y tratamiento de datos para poder eventualmente analizarlos. Lo descrito anteriormente conlleva al uso de técnicas computacionales que automaticen aquellos procesos.

La complementariedad existente entre corpus y ontologías, desde la perspectiva semántica y léxica, genera una ventaja en la construcción de modelos como el desarrollado en este proyecto, debido a que el estudio de las ontologías conlleva inevitablemente al análisis de una terminología, para posteriormente formalizarla y conceptualizarla, de allí que los corpus bajo su filosofía y razón de ser, pueden proveer una base y un dominio para dicha tarea.

El proceso de reconocimiento óptico de caracteres permite simplificar tareas de captura de información que suelen hacerse de forma manual, sin embargo, es un procedimiento que requiere de diferentes técnicas para poder mejorar sus resultados. La transformación de una imagen a blanco y negro simplifica el paso de binarización y permite al ROC ser más preciso al identificar patrones. Por otro lado, los usos de diccionarios junto a un análisis de similitud ayudan a reemplazar en el resultado aquellos textos que contienen caracteres erróneamente clasificados al compararlos con palabras pertenecientes a alguna lengua.

Las aplicaciones híbridas suponen un desarrollo ágil, pues al estar basadas en tecnologías web, representan ventajas para el usuario, en términos de mayor velocidad, y menor almacenamiento en ejecución de la aplicación. De otra parte, al estar constituidos sobre Frameworks de desarrollo web, facilitan el uso de servicios remotos, como peticiones a servidores y sincronización en tiempo real.

98

9. TRABAJO FUTURO

Dada la naturaleza de la aplicación, la información de los usuarios puede ser recolectada para posteriores tareas de análisis e investigación. Por el lado del corpus, este puede seguir ampliándose y complementarse con información de otros portales médicos web.

Las funciones de la aplicación móvil pueden extenderse para que el usuario pueda ingresar eventos adversos tras tomar un medicamento, actividad que puede complementarse con un segundo Crawler que busque la misma información en portales web. Cruzando la información de ambas fuentes se podrían implementar nuevos análisis de consumo en contraste con las posologías para realizar modelos predictivos de eventos adversos.

99

10. REFERENCIAS

[1] F. J. G. Marco, “Ontologías, taxonomía y tesauros: manual de construcción y uso (Emilia Currás),” El Profesional de la Informacion, vol. 15, no. 4. pp. 317–318, 2006.

[2] T. R. Gruber, “Toward principles for the design of ontologies used for knowledge sharing,” Int. J. Hum. Comput. Stud., vol. 43, no. 5–6, pp. 907–928, 1995.

[3] N. Guarino, “Understanding, building and using ontologies,” Int. J. Hum. Comput. Stud., vol. 46, no. 2, pp. 293–310, 1997.

[4] T. R. Gruber, “A translation approach to portable ontology specifications,” Knowl. Acquis., vol. 5, no. 2, pp. 199–220, 1993.

[5] C. Jones and D. Waller, Corpus Linguistics for Grammar. London and New York: Routledge, 2015.

[6] M. Tony and W. Andrew, Corpus Linguistics An Introduction, 2nd ed. Manchester: Advisory Board, 2001.

[7] M. (Universidad de L. Villayandre Llamazares, “Internet como corpus: el caso de bibidí,” Contextos, vol. XXI–XXII, no. 41–44, pp. 205–231, 2003.

[8] E. Currás, Tesauros manual de construcción y uso. España, Madrid: Kaher II, S.A., 1998.

[9] J. L. Laguens García, “Tesauros y lenguajes controlados en internet,” An. Doc., no. 9, pp. 105–121, 2006.

[10] B. Soediono, Farmacología Humana, Tercera., vol. 53. España, Santander: Masson, S.A., 1998.

[11] M. L. T. Cossio et al., Goodman & Gilman. Las bases farmacológicas de la terapéutica, Undécima., vol. XXXIII, no. 2. Mexico DF: MC Graw Hill, 2007.

[12] M. Bates and R. M. Weischedel, Challenges in Natural Language Processing, vol. 23, no. 1. New: Cambridge University Press, 2006.

[13] A. Cortez, H. Vega, and J. Pariona, “Procesamiento de lenguaje natural,” Rev. Investig. Sist. e Informática, vol. 6, no. 2, pp. 45–54, 2009.

[14] G. Harrison, Next generation databases: NoSQL, NewSQL, and Big Data. New York: Springer Science+Business Media, 2015.

[15] I. Matías, J. Antiñanco, and M. J. Bazzocco, “Bases de Datos NoSQL : Escalabilidad y alta disponibilidad a través de patrones de diseño,” Universidad Nacional de La Plata, 2013.

100

[16] J. Celko, Complete Guide To NoSQL, First. Elsevier Inc., 2014.

[17] S. J. Valbuena and J. M. Londoño, “Sistemas Para Almacenar Grandes Volúmenes De Datos,” Rev. Gti, vol. 13, no. 37, pp. 17–28, 2015.

[18] A. Garcete, “Base de Datos Orientado a Columnas.” Universidad Católica “Nuestra Señora de la Asunción,” Asunción, Paraguay, 2012.

[19] S. K. Singla and R. K. Yadav, “Optical character recognition based speech synthesis system using LabVIEW,” J. Appl. Res. Technol., vol. 12, no. 5, pp. 919–926, 2014.

[20] R. Mithe, S. Indalkar, and N. Divekar, “Optical Character Recognition,” Int. J. Recent Technol. Eng., vol. 2, no. 1, pp. 72–75, 2013.

[21] D. G. Y. Fernández Romero Yenisleidy, “Patrón Modelo-Vista-Controlador,” Rev. Telem@tica, vol. 11, no. 1, p. 11, 2012.

[22] J. S. Castejón Garrido, “Arquitectura y diseño de sistemas web modernos,” Rev. Ing. Informáctica del CIIRM, pp. 1–6, 2004.

[23] Healthnet Ltd, “PillManager.” App Store, Google Play, United Kingdom, 2014.

[24] “MedHelper _ Mobile Prescription App.” [Online]. Available: http://medhelperapp.com/.

[25] JMSoft Brazil, “JMSoft.” Google Play, Brazil, 2015.

[26] Montuno Software, “Dosecast.” App Store, Google Play, Amazon, EE.UU., 2015.

[27] Mango Health, “Mango Health.” App Store, Google Play, San Francisco, 2014.

[28] “Healthy Reminder- Index.” [Online]. Available: http://www.healthyreminder.org/.

[29] J. A. Fernandez, “PillBox.” Google Play, 2011.

[30] Mediaexpander, “PastiMed Lite.” App Store, 2012.

[31] “medisafe.” [Online]. Available: http://www.medisafe.com/.

[32] “Creative Commons Colombia,” 2017. [Online]. Available: http://co.creativecommons.org/.

[33] G. de C. Ministerio de las TIC, “Guía de datos abiertos en Colombia.” Colombia, p. 35, 2016.

[34] J. H. Canós, P. Letelier, C. Penadés, and D. P. De Valencia, “Métodologías Ágiles en el Desarrollo de Software,” in Grupo ISSI, 2003, pp. 1–8.

[35] S. D. Amaro Calderón and J. C. Valverde Rebaza, “Metodologías Ágiles.”

101

Universidad Nacional de Trujillo, Perú, pp. 1–37, 2007.

[36] Ward Cunningham, “Agile Manifiesto.” 2001.

[37] N. L. of Medicine, “UMLS,” 2016. [Online]. Available: https://www.nlm.nih.gov/research/umls/.

[38] J. Cruanes Vilas, “Una aproximación léxico-semántica para el mapeado automático de medicamentos y su aplicación al enriquecimiento de ontologías farmacoterapéuticas,” Universidad de Alicante, 2014.

[39] A. Khalili and B. Sedaghati, “Semantic medical prescriptions - Towards intelligent and interoperable medical prescriptions,” Proc. - 2013 IEEE 7th Int. Conf. Semant. Comput. ICSC 2013, pp. 347–354, 2013.

[40] K. Kostopoulos, I. Chouvarda, V. Koutkias, A. Kokonozi, M. Van Gils, and N. Maglaveras, “An ontology-based framework aiming to support personalized exercise prescription: Application in cardiac rehabilitation,” Proc. Annu. Int. Conf. IEEE Eng. Med. Biol. Soc. EMBS, pp. 1567–1570, 2011.

[41] A. Grando, S. Farrish, C. Boyd, and A. Boxwala, “Ontological approach for safe and effective polypharmacy prescription.,” AMIA Annu. Symp. Proc., vol. 2012, pp. 291–300, 2012.

[42] S. Khemmarat and L. Gao, “Supporting Drug Prescription via Predictive and Personalized Query System,” Pervasive Comput. Technol. Healthc. (PervasiveHealth), 2015 9th Int. Conf., pp. 9–16, 2015.

[43] M. T. Romá-Ferri, “OntoFIS: tecnología ontológica en el dominio farmacoterapéutico,” Universidad de Alicante, 2009.

[44] S. Rubrichi, S. Quaglini, A. Spengler, P. Russo, and P. Gallinari, “A system for the extraction and representation of summary of product characteristics content,” Artif. Intell. Med., vol. 57, no. 2, pp. 145–154, 2013.

[45] C. Senger, H. M. Seidling, R. Quinzler, U. Leser, and W. E. Haefeli, “Design and evaluation of an ontology-based drug application database,” Methods Inf. Med., vol. 50, no. 3, pp. 273–284, 2011.

[46] S. Sohn, C. Clark, S. R. Halgrim, S. P. Murphy, C. G. Chute, and H. Liu, “MedXN: an open source medication extraction and normalization tool for clinical text.,” J. Am. Med. Inform. Assoc., pp. 1–8, 2014.

[47] S. Karimi, A. Metke-Jimenez, M. Kemp, and C. Wang, “Cadec: A corpus of adverse drug event annotations,” J. Biomed. Inform., vol. 55, pp. 73–81, 2015.

[48] R. Ginn et al., “Mining Twitter for Adverse Drug Reaction Mentions : A Corpus and Classification Benchmark,” in proceedings of the Fourth Workshop on Building and Evaluating Resources for Health and Biomedical Text Processing

102

(BioTxtM), 2014, no. 1.

[49] A. Coden, D. Gruhl, N. Lewis, M. Tanenblatt, and J. Terdiman, “SPOT the drug! An unsupervised pattern matching method to extract drug names from very large clinical corpora,” Proc. - 2012 IEEE 2nd Conf. Healthc. Informatics, Imaging Syst. Biol. HISB 2012, pp. 33–39, 2012.

[50] A. Roberts et al., “The CLEF corpus: semantic annotation of clinical text.,” AMIA Annu. Symp. Proc., pp. 625–629, 2007.

[51] H. Gurulingappa, A. M. Rajput, A. Roberts, J. Fluck, M. Hofmann-Apitius, and L. Toldo, “Development of a benchmark corpus to support the automatic extraction of drug-related adverse effects from medical case reports,” J. Biomed. Inform., vol. 45, no. 5, pp. 885–892, 2012.

[52] H. Gurulingappa, A. Mateen‐Rajpu, and L. Toldo, “Extraction of potential adverse drug events from medical case reports,” J. Biomed. Semantics, vol. 3, no. 1, pp. 1–10, 2012.

[53] D. Sánchez-Cisneros, S. Lana, A. Moreno, P. Martínez, L. Campillos, and I. Segura-Bedmar, “Prototipo buscador de información médica en corpus multilingües y extractor de información sobre fármacos,” Proces. Leng. Nat., vol. 49, pp. 209–212, 2012.

[54] M. Herrero-Zazo, I. Segura-Bedmar, P. Martínez, and T. Declerck, “The DDI corpus: An annotated corpus with pharmacological substances and drug-drug interactions,” J. Biomed. Inform., vol. 46, no. 5, pp. 914–920, 2013.

[55] E. M. van Mulligen et al., “The EU-ADR corpus: Annotated drugs, diseases, targets, and their relationships,” J. Biomed. Inform., vol. 45, no. 5, pp. 879–884, 2012.

[56] M. Herrero-Zazo, “Semantic Resources in Pharmacovigilance: a Corpus and an Ontology for Drug-Drug Interactions,” Universidad Carlos II, 2015.

[57] A. Duque, J. Martínez-Romo, and L. Araujo, “Extracción no supervisada de relaciones entre medicamentos y efectos,” Proces. del Leng. Nat., vol. 55, pp. 83–90, 2015.

[58] A. Roberts et al., “Building a semantically annotated corpus of clinical texts,” J. Biomed. Inform., vol. 42, no. 5, pp. 950–966, 2009.

[59] S. M. M. Valladarez, M. E. Gaitan, and N. N. P. Reyes, “Metodologia Ágil De Desarrollo De Software Programacion Extrema.,” vol. 1, p. 146, 2016.

103

11. ANEXO I: HISTORIAS DE USUARIO POR ITERACIÓN

11.1. ITERACIÓN 1

I1 Iteración 1: Componente de rastreo

Descripción general: Desarrollar un módulo capaz de recopilar la información que se encuentre en la web relacionada con medicamentos que se comercialicen en Colombia. Su objetivo es a partir de una URL encontrar y guardar documentos relacionados al tema, siendo este un Crawler Web.

Número Historia de usuario

Descripción Estado Fase

1 Definición de Requerimientos

Identificar:

● Las posibles fuentes de información sobre medicamentos.

● La tecnología necesaria para la implementación del componente.

● Librerías o Frameworks aplicables para el procesamiento y almacenamiento de la información recopilada

Realizada Análisis

2 Diseño de la herramienta

Definir la estructura y elementos básicos que requiere el componente

Realizada Diseño

3 Implementación de la herramienta

Desarrollar del código necesario para que el componente sea capaz de obtener,

Realizada

Desarrollo

104

procesar y almacenar

Responsable: Cristian Bravo

Observaciones: La identificación de las fuentes de información se realizó de manera manual.

Fecha inicio:

15/11/2018

Fecha fin:

30/12/2018


I1HU1 Historia de Usuario 1:

Definición de requerimientos del componente

Descripción general: Definir aquellos elementos como fuentes de información, arquitectura, lenguaje de programación, entre otros componentes tecnológicos necesarios para el funcionamiento del Crawler.

Número Tarea Descripción Puntos Estado


Identificar, analizar y evaluar aquellos sitios web con información pública de medicamentos cuyo código fuente permitiera la captura de datos de forma organizada.

0,2 Realizada

2 Selección de plataforma de desarrollo

Escoger un lenguaje de programación para el desarrollo del código necesario que realice la búsqueda de URL, descarga de información y almacenaje.

0,2 Realizada

3 Selección de Reconocer las diferentes 0,3 Realizada

105

librerías librerías o Frameworks existentes en el desarrollo de Crawlers.

4 Definición de repositorio

Identificar herramientas disponibles para el almacenamiento y requerimientos de espacio en disco para los datos descargados por el Crawler.

0,3 Realizada

Responsable: Cristian Bravo y Sebastián Otálora

Prioridad: Media

Observaciones: Se opta por escoger una fuente de información que actualice sus datos y que pueda ser consultada periódicamente.


Diseño de la herramienta de rastreo

Descripción general: Planear y esquematizar la arquitectura del Crawler. Identificar posibles módulos y sus diferentes funciones.


1 Identificación de elementos

Detallar aquellos componentes que componen el Crawler y sus relaciones entre sí.

0,3 Realizada

2 Definición de procesos y algoritmos requeridos

Determinar aquellos procesos y sus flujos de trabajo desde la captura de información hasta su almacenamiento.

0,3 Realizada

106

3 Esquematización Realización en diagramas de la arquitectura, flujo de información, actividades y comunicación.

1 Realizada

Riesgo: Bajo


Observaciones: La herramienta debe ser flexible para cambiar las fuentes de información de ser necesario.


Implementación de la herramienta de rastreo

Descripción general: Elaborar el código fuente necesario para la implementación del Crawler


1 Desarrollo del código fuente

Con base a la arquitectura y las librerías o Frameworks propuestos implementar los algoritmos y módulos del Crawler.

2 Realizada

2 Validación de la información

Añadir control de excepciones a los módulos del Crawler.

0,2 Realizada

3 Procesamiento de la información

Implementación de algoritmos de limpieza de datos y posterior almacenamiento de la información.

1 Realizada

107


Prioridad: Alta

Observaciones: El almacenamiento de información no necesariamente es con un motor de base de datos.

11.1.2. CASOS DE PRUEBA

P1I1HU1 Caso de Prueba 1: Validación de extracción de datos

Historias de usuario: I1HU1

Condiciones de ejecución: La URL de entrada debe estar habilitada


1 Preparación de datos de prueba

2 Entrar URL base

3 Correr script del Crawler

4 Comprobar descarga de datos

Resultado esperado: Archivo con los datos recopilados.

Evaluación de la prueba: Finalizó exitosamente.

P2I1HU3 Caso de Prueba 2: Validación de almacenamiento de información

Historias de usuario: HU3

108

Condiciones de ejecución: La URL de entrada debe estar habilitada


1 Preparación de datos de prueba

2 Entrar URL base

3 Correr script del Crawler

4 Comprobar correcto almacenamiento

Resultado esperado: Documentos recopilados y guardados en un repositorio.


11.2. ITERACIÓN 2

I2 Iteración 2: Componente de reconocimiento óptico de caracteres (ROC)

Descripción general: Desarrollar un módulo que permita tomar una imagen de una receta o prescripción médica y digitalizar los textos contenidos en ella.

Número Historia de Usuario


1 Identificación de requerimientos para herramientas ROC

Identificar

● Herramientas ROC ● Librerías o Frameworks ● Procesamiento

requerido de información

Análisis y Diseño

Realizada

2 Selección de herramienta

Realizar pruebas de desempeño, medir y

Análisis Realizada

109

ROC comparar resultados. Escoger la herramienta óptima en cuanto a tiempo y cantidad de palabras reconocidas.

3 Implementación con recetas médicas

Realizar pruebas de la herramienta ROC con recetas o prescripciones médicas. Medir el desempeño.

Desarrollo Realizada

4 Optimización de resultados

Implementar limpieza de datos y mejora de imagen.

Desarrollo

Riesgo: medio


Observaciones:

Fecha Inicio:

1/01/2018

Fecha fin:

28/01/2018



Identificación de requerimientos para herramientas ROC

Descripción general: Definir aquellos elementos como fuentes de información, arquitectura, lenguaje de programación, entre otros componentes tecnológicos necesarios para el funcionamiento del ROC.


110


Reconocer y parametrizar la información que se quiere obtener de una imagen o PDF, el caso específico una fórmula médica.

0,3 Realizada

2 Identificación del tipo de herramienta ROC requerida según la información que se reconocerá

Validar parámetros como lenguaje, tiempo y plataformas.

0,3 Realizada

3 Definición del flujo de procesamiento

Diseñar un flujo de trabajo con actividades a realizar con los resultados del proceso de reconocer una fórmula médica

0,3 Realizada

Riesgo: bajo


Observaciones: La selección de la herramienta debe tener como principal característica ser de uso libre.


Selección de herramienta ROC

Descripción general: Conocer las diferentes herramientas ROC de uso libre, identificar sus características y seleccionar aquella que se adecúe a los requerimientos definidos en la historia I2HU1


111

1 Preselección Escoger de forma preliminar aquellas herramientas ROC que funcionan con imágenes de extensión JPEG o PNG. Además, que tengan diccionarios en español.

0,2 Realizada

2 Identificación de funcionalidades, y limitaciones

Documentación de cada herramienta, identificar su entorno de trabajo, sus ventajas y desventajas y descartar aquellas que no cumplan requisitos.

0,3 Realizada

3 Construcción de scripts

Definido el entorno de trabajo de cada una, construir código de prueba para validar el funcionamiento exitoso de las herramientas ROC.

1 Realizada

4 Pruebas Agrupación de fórmulas médicas y conformación de datos de prueba base. Pruebas de cada herramienta ROC y consolidación de resultados.

0,5 Realizada

5 Análisis y selección Analizar y definir la herramienta ROC con mejor desempeño con base a los siguientes parámetros: tiempo, cantidad de palabras correctas en español y capacidad de sugerencia

0,2 Realizada

112

ante palabra errada.

Riesgo: Alto


Observaciones: Un criterio para la selección de las herramientas ROC es que de alguna forma pudieran implementarse con el lenguaje de programación Python.


Implementación con recetas médicas

Descripción general: Desarrollar el código necesario para implementar herramienta ROC con fotografía de fórmula médica.


1 Esquematizar procesos

Definir procesos y realizar diagramas de flujo.

0,2 Realizada

2 Desarrollo funcionalidad conversión OCR

Implementación en código de herramienta ROC con parámetros de entrada y salida.

1 Realizada

3 Implementación OCR

con foto de fórmula

Evaluación de resultados de funcionalidad OCR con foto de fórmula médica.

0,2 Rechazada

4 Implementación con fotografía recortada

Evaluación de resultados de funcionalidad OCR con foto de fórmula médica recortada a solo las posologías.

0,2 Realizada

113

Riesgo: Medio


Observaciones: La historia de usuario 2 fue rechazada por la cantidad de ruido en la salida de herramienta ROC con una foto completa de la fórmula.


Optimización de resultados

Descripción general: Mejorar el desempeño del módulo ROC


1 Análisis de resultados

Analizar los resultados de ejecución de pruebas en cuanto a las características utilizadas en la selección de la herramienta. Establecer con ellos un % de éxito e identificar problemas comunes.

0,2 Realizada

2 Definición de soluciones

Identificar posibles soluciones a los problemas hallados como mejoramiento de la imagen o utilización de diccionarios externos.

0,2 Realizada

3 Implementación de soluciones

Implementación en código de las soluciones

0,6 Realizada

Riesgo: bajo

114


Observaciones:


P1I2HU3 Caso de Prueba 1: Validación de herramienta ROC


Condiciones de ejecución: La foto debe tener frases legibles en español


1 Seleccionar ejemplo

2 Correr Script

3 Validar resultados

Resultado esperado: Texto digitalizado obtenido a partir de la foto de una receta médica.


P2I2HU4 Caso de Prueba 2: Validación de Optimización


Condiciones de ejecución: La foto debe tener frases legibles en español


115


2 Correr Script


Resultado esperado: Texto digitalizado con mayor porcentaje de éxito del anterior.


11.3. ITERACIÓN 3

I3 Iteración 3: Gramática de posología

Descripción general: A partir del texto obtenido de una receta médica con el módulo ROC se identifican los diferentes elementos que lo componen. El proceso consta de etiquetar las palabras y analizar las estructuras y patrones del texto para posteriormente capturar, por medio de un algoritmo, las posibles posologías que pueda haber en él.

Número

Historia de Usuario


1 Identificación de componentes

Seleccionar las frases utilizadas en posologías comúnmente y categorizar las palabras.

Análisis Realizada

2 Identificación de estructuras gramaticales y patrones

Analizar las frases en posologías e identificar diferentes órdenes de las palabras según la categoría asignada.

Diseño Realizada

3 Construcción de algoritmo de clasificación

Implementación en código de un algoritmo capaz de identificar una frase que


116

describa una posología dentro un texto. Tomar la frase, etiquetar las palabras y asociarla a un patrón.

Riesgo: medio


Observaciones: Los datos de prueba serán los mismos utilizados en el módulo ROC.

Fecha Inicio:

01/02/2018

Fecha fin:

28/02/2018



Identificación de componentes en gramáticas posológicas

Descripción general: Estructurar las palabras que componen una posología según unas categorías.


1 Recolección de ejemplos

Conformar un grupo de fórmulas médicas como base de prueba.

0,3 Realizada

2 Análisis de similitudes y diferencias en frases

Identificar y clasificar las palabras en cada ejemplo de prueba. Analizar frecuencias y repeticiones de palabras.

0,3 Realizada

117

3 Definición de categorías

Con base a los resultados establecer las categorías de las palabras frecuentes.

0,3 Realizada

Riesgo: medio


Observaciones: Los ejemplos deben ser de diferentes entidades de salud para garantizar una mejor cobertura en los diferentes casos.


Identificación de estructuras gramaticales y patrones en posologías

Descripción general: Identificar el orden común y diferentes combinaciones de las categorías escogidas en la historia I3HU1.


1 Recolección de ejemplos

Seleccionar fórmulas médicas legibles con diferentes formatos.

0,3 Realizada

2 Extracción de patrones

Clasificar los ejemplos y comparar los órdenes existentes en cada posología.

0,3 Realizada

3 Análisis y resultados

Estructurar las categorías que componen las frases de una posología.

0,3 Realizada

Riesgo: medio


118

Observaciones: Los patrones deben aplicar a cualquier fórmula médica que no se encuentre representada en los ejemplos recolectados.


Construcción de algoritmo de identificación de la gramática

Descripción general: Desarrollar código con funcionalidad que permite tomar una frase de posología y clasificarla según la estructura definida.


1 Definición de plataforma de desarrollo

Escoger un lenguaje de programación y entorno de desarrollo para la implementación de la funcionalidad. El parámetro principal es la cantidad de librerías y frameworks para el procesamiento del lenguaje natural.

0,2 Realizada

2 Diseño de diagrama de flujo

Esquematizar los pasos y entradas y salidas del algoritmo de clasificación.

0,8 Realizada

3 Desarrollo del código

Implementación en el lenguaje de programación seleccionado.

2 Realizada

Riesgo: alto


Observaciones: El tiempo de ejecución y de retorno de respuesta debe ser optimizado en lo posible.

119


P1I3HU3 Caso de Prueba 1: Validación de la gramática definida


Condiciones de ejecución: Los datos de prueba deben ser exclusivamente fórmulas médicas



2 Correr script

3 Evaluar resultados

Resultado esperado: La frase de posología puede identificarse en un texto y categorizar sus palabras según la estructura definida.


11.4. ITERACIÓN 4

I4 Iteración 4: Creación de repositorio de datos

Descripción general: Implementación de Base de Datos que almacene la información obtenida del componente rastreo (Medicamentos comercializados en Colombia) y por la propia aplicación (Posologías).

Número Actividad Descripción Puntos Estado

1 Definición de requerimientos del Repositorio

Identificar

● Necesidad de

Análisis Realizada

120

de datos espacio de almacenamiento

● Herramientas gestoras de Bases de Datos

● Frameworks o componentes puente entre Base de datos y aplicaciones

● Estructuras de datos

2 Estructuración de datos

Diseñar el modelo de datos para Medicamentos y para Posologías. Identificar entidades y atributos relevantes y secundarios.

Diseño Realizada

3 Desarrollo de algoritmos para procesamiento y limpieza

Desarrollar en código algoritmo para limpieza y gestión de la información que se almacena.


4 Implementar Base de Datos

Montaje de la Base de Datos, scripts de limpieza y almacenaje de información. Definir usuarios, roles y permisos.


Riesgo: Alto


Observaciones: El gestor de base de datos seleccionado debe ser capaz de almacenar diferentes estructuras del tipo NoSQL.

Fecha inicio:

1/03/2018

Fecha fin:

30/03/2018

121



Definición de requerimientos del repositorio de datos

Descripción general: Definir necesidades para la identificación de la herramienta para la gestión de la información de medicamentos y posologías.


1 Especificación de necesidades

Definir necesidades de espacio y elementos requeridos para vinculación con desarrollo anterior. Definir modelo de almacenamiento con base a los datos obtenidos por el Crawler.

0,3 Realizada

2 Recopilación y análisis de herramientas y frameworks

Análisis de las diferentes herramientas gestores de base de datos de uso libre y librerías y frameworks para trabajar con plataforma de desarrollo

0,3 Realizada

3 Selección de herramienta

Escoger herramienta que supla las necesidades especificadas.

0,3 Realizada

Riesgo: Bajo

Responsable: Sebastián Otálora y Cristian Bravo

Observaciones: La utilización de más de una herramienta puede ser requerido.

122

Las herramientas seleccionadas deben ser compatibles con las plataformas de desarrollo utilizadas previamente, específicamente Python.


Estructuración de datos

Descripción general: Realizar un modelo para la estructuración y el almacenamiento de la información correspondiente a medicamentos y posologías.


1 Análisis de datos Descomposición de la información de medicamentos y posologías. Extracción de elementos relevantes para uso del proyecto.

0,3 Realizada

2 Definir entidades, atributos y relaciones

Clasificación de los elementos identificados previamente. Describir relaciones entre diferentes elementos y sus características.

0,3 Realizada

2 Elaboración de modelo

Construcción del modelo para el almacenamiento de medicamentos y posologías.

0,4 Realizada

Riesgo: Medio


123

Observaciones: Es posible que se obtengan varios modelos.


Desarrollar algoritmos para procesamiento, limpieza de datos y almacenamiento de datos

Descripción general: Desarrollo de código para procesar los datos, transformarlos al modelo definido y almacenarlos en repositorio.


1 Selección de plataforma

Definir el lenguaje de programación para la implementación de algoritmos y procesos.

0,2 Realizada

2 Esquematización de funciones, procesos y flujos

Realizar diagramas de flujos especificando los procedimientos y secuencias a desarrollar.

0,5 Realizada

3 Elaboración del código

Implementación en código de algoritmos que permitan la transformación a modelo, limpiar ruido y almacenar en base de datos.

1,5 Realizada

Riesgo: Alto

Responsable: Sebastián Otálora

Observaciones: El lenguaje de programación seleccionado debe contar con librerías o frameworks para el procesamiento del lenguaje natural.

124

I4HU Historia de Usuario 4:

Implementar Base de Datos

Descripción general: Instalación y despliegue de la Base de Datos.


1 Instalación Realizar el proceso de instalación del motor de base de datos.

0,5 Realizada

2 Despliegue Realizar las configuraciones para que el motor pueda recibir información y ser consultado por agentes externos.

0,5 Realizada

3 Carga de datos Guardar la información recopilada por el Crawler.

0,5 Realizada

Riesgo: medio


Observaciones: La base de datos debe quedar funcional para seguir recibiendo información periódicamente.


P1I4HU3 Caso de Prueba 1: Validación de algoritmos


Condiciones de ejecución: Deben existir datos de prueba.

125


1 Ejecutar Script


Resultado esperado: Se obtiene los datos esquematizados para ingresar en la base de datos.


P1I4HU4 Caso de Prueba 2: Validación de repositorio de datos


Condiciones de ejecución: La base de datos debe estar funcional.


1 Ejecutar Script

2 Validar datos almacenados

Resultado esperado: Se puede consultar, actualizar y guardar datos. Existe una colección de datos de medicamentos.


11.5. ITERACIÓN 5

I5 Iteración 4: Construcción de aplicación y servidor

Descripción general: Desarrollo de una aplicación móvil que permite la gestión de posologías. Construcción de servidor con servicios Web para el procesamiento

126

y almacenamiento de la información de la aplicación móvil.

Número Actividad Descripción Etapa Estado


Especificar las plataformas de desarrollo móviles en la que se desarrollará el App. Definir los entornos y plataformas para el servidor y servicios Web.

Análisis Realizada

2 Definición de arquitectura

Esquematizar los diferentes componentes del proyecto, sus interacciones y definir una arquitectura para el mismo.

Diseño Realizada

3 Esquematización de procesos y flujos

Definir los diferentes procesos y actividades de los componentes. Realizar diagramas de actividades y flujos.

Diseño Realizada

4 Desarrollo de servicios web

Elaboración e implementación en el servidor de servicios para la gestión de información del App.


5 Creación servicio de sincronización de datos

Implementación de base de datos para sincronización de datos.


6 Creación módulo gestión de usuario

Elaboración e implementación de funcionalidades en App para que el usuario pueda


127

gestionar su información.

7 Creación módulo gestión de posologías

Elaboración e implementación de funcionalidades en App para que el usuario pueda agregar, consultar y eliminar diferentes posologías en la aplicación.


8 Creación módulo historial y gráficos

Elaboración e implementación de funcionalidades en App para que el usuario pueda visualizar su historial de posologías y gráficas de su consumo.


9 Creación módulo de administración

Construcción de una interfaz web que permita realizar actividades de administrador sobre la aplicación como consultar estadísticas y editar usuarios.


Riesgo: Alto


Observaciones: Las plataformas para el desarrollo deben contar con frameworks o librerías que faciliten el desarrollo de aplicaciones móviles y servicios REST en corto tiempo.

Fecha inicio:

01/04/2018

Fecha fin:

30/05/2018

128



Definición de requerimientos

Descripción general: Describir los entornos, herramientas y plataformas requeridas en el desarrollo del App y los servicios del servidor.


1 Selección de herramienta para App

Recopilación y análisis de herramientas para el desarrollo de aplicaciones móviles. Selección de una.

0,3 Realizada

2 Selección de entornos de ejecución

Recopilación y análisis de entornos de ejecución para servidores. Selección de uno.

0,2 Realizada

3 Selección de librerías y frameworks

Recopilación y análisis de librerías y frameworks para el desarrollo de la aplicación y de servicios en servidor.

0,2 Realizada

Riesgo: alto


Observaciones:


Definición de arquitectura

129

Descripción general: Definir la arquitectura para el proyecto.


1 Especificación de componentes

Describir y especificar los diferentes módulos del sistema, sus funciones y relaciones.

0,5 Realizada

2 Especificar funciones y procesos

Definir las funcionalidades para los componentes de la aplicación

0,53 Realizada

3 Diseño de arquitectura

Definir una estructura para el desarrollo sistema.

0,2 Realizada

Riesgo: medio


Observaciones: La arquitectura especificada debe funcionar a través de componentes que desacoplen los procesos de front-end y back-end


Esquematización de procesos y flujos

Descripción general: Realizar diagramas para especificar las diferentes funcionalidades y actividades del sistema.


1 Especificación de procesos e interacciones

Definir todas las funcionalidades de la aplicación y los procesos

0,3 Realizada

130

que las componen.

2 Esquematización de flujos de trabajo

Realizar diagramas de procesos, actividades e interacciones.

1 Realizada

Riesgo: Bajo


Observaciones:


Desarrollo de servicios web

Descripción general: Desarrollo e implementación de funcionalidades requeridas por el sistema en el servidor a través de un API REST.


1 Desarrollo de servicio de ROC

Desarrollar servicio que permite tomar la foto de una posología y devuelve un JSON etiquetado con la gramática especificada.

0,6 Realizada

2 Desarrollo de servicio guardar usuario

Desarrollar servicio que permite almacenar datos del usuario en repositorio.

0,6 Realizada

3 Desarrollo de servicio guardar posología

Desarrollar servicio que permite almacenar datos de posologías en repositorio

0,6 Realizada

131

4 Desarrollo de servicios de eventos adversos

Desarrollar servicio que permita la consulta de eventos adversos asociados a un medicamento

0,6 Realizada

Riesgo: Alto


Observaciones: La plataforma seleccionada debe contar con librerías que soporte procesos asíncronos para los diferentes llamados al tiempo que se podrían hacer a los servicios.


Creación servicio de sincronización de datos

Descripción general: Desarrollo e implementación del módulo de conexión entre aplicación y base de datos, de forma tal, que garantice sincronización de datos


1 Búsqueda y definición de un servicio web para sincronización de bases de datos

Definir una tecnología o un proveedor de servicios web que permita la sincronización en tiempo real de datos con aplicaciones móviles

0,3 Realizada

3 Definición del modelo de datos

Modelar la estructura de datos acorde a las características de la sincronización de datos

0,3 Realizada

4 Desarrollo del Proveedor de servicios

Desarrollar el módulo de conexión entre la aplicación y la base de datos

1 Realizada

132

Riesgo: Alto


Observaciones: Se debe escoger una herramienta que automatice lo más posible la sincronización de los datos.


Creación módulo gestión de usuario

Descripción general: Desarrollo e implementación del módulo gestor de clientes, para que los procesos de autenticación y gestión de información personal puedan ser administrados.


1 Desarrollar componente de autenticación

Implementar los servicios de inicio de sesión, cierre de sesión y registro de usuario para la aplicación.

0,5 Realizada

2 Desarrollar gestor de Perfil de usuario

Implementar la gestión de perfil dentro de la aplicación para que el usuario pueda ver y editar su información

0,5 Realizada


Desarrollar la interfaz gráfica del servicio de autenticación y de gestión de perfil

0,5 Realizada

Riesgo: Alto


Observaciones: La interfaz desarrollada debe ser de uso intuitivo para el usuario.

I5HU7 Historia de Usuario 7: Creación módulo gestión de posologías

133

Descripción general: Desarrollar un módulo capaz de generar peticiones al servidor remoto, obtener la respuesta y transformarla en la generación de alertas o notificaciones locales para el usuario


1 Desarrollo de conexión entre Aplicación y Servidor

Desarrollo e implementación del módulo de conexión entre la aplicación móvil y el servidor remoto para el envío de peticiones y recepción de sus respuestas

0,5 Realizada

2 Componente de generación y temporizador de alertas

Desarrollar un componente de uso de las respuestas del servidor, para generar un sistema de notificaciones locales, para todos los medicamentos

0,5 Realizada


Desarrollar la interfaz gráfica del servicio de envío de posologías (conexión aplicación-servidor) y de generación de alertas

1 Realizada

Riesgo: Alto



I5HU8 Historia de Usuario 8: Creación módulo historial y gráficos

Descripción general: Desarrollo de un módulo que permita al cliente, conocer cálculos y/o estadísticas básicas acerca de su consumo farmacéutico usando el historial de fórmulas médicas procesados con la aplicación.


134

1 Desarrollo componente de normalización de datos para graficar

Desarrolle de componente que ajuste los datos de las historias médicas de forma que calcule tiempos y frecuencias de consumo, asegurando que las dimensiones de las gráficas están estandarizadas

0,5 Realizada


Desarrollar la interfaz gráfica de graficar y vista del historial de fórmulas médicas de cada usuario

1 Realizada

Riesgo: Medio



I5HU9 Historia de Usuario 9: Creación módulo de administración

Descripción general: Desarrollo de un módulo que permita al administrador de la aplicación conocer cálculos y/o estadísticas básicas acerca del consumo farmacéutico de los usuarios registrados, incluyendo la gestión de usuarios (agregar, editar, eliminar) y la visualización de recetas, medicinas y efectos adversos.


1 Desarrollo componente de visualización de gráficas

Desarrolle de componente que ajuste los datos de todos los usuarios de forma que calcule tiempos y frecuencias de consumo, asegurando que las dimensiones de las gráficas están estandarizadas

0,5 Realizada

135

2 Desarrollo de gestión de usuarios

Desarrollar la gestión de usuarios de forma que se pueda agregar, eliminar y editar usuarios, así mismo visualizar las recetas médicas de los usuarios de forma integral

1 Realizada

Riesgo: Medio


Observaciones: La interfaz desarrollada debe ser de uso intuitivo para el administrador.


P1I5HU4 Caso de Prueba 1: Prueba servicio web captura de posología


Condiciones de ejecución: Las imágenes usadas de prueba deben contener posologías. Los servicios están disponibles en servidor.


1 Construir página web con formulario de prueba

2 Abrir página web y seleccionar imagen

3 Enviar formulario


Resultado esperado: Objeto JSON que define una lista de posologías a través del etiquetado de palabras.


P2I5HU4 Caso de Prueba 2: Prueba servicio web guardar datos de usuario y posologías

136


Condiciones de ejecución: Los servicios están disponibles en servidor


1 Abrir navegador

2 Ingresar URLs con parámetros


Resultado esperado: Mensaje de confirmación con informe de resultado. Datos almacenados en base de datos.


P3I5HU6 Caso de Prueba 3: Prueba módulo gestión de usuarios


Condiciones de ejecución: El servicio de sincronización de datos está disponible para lectura y escritura


1 Ejecución del emulador en navegador del framework

2 Usar el servicio de inicio y cierre de sesión

3 Comparar datos de autenticación con datos almacenados

4 Evaluar Resultados

Resultado esperado: Los casos de error en inicio y registro tratados exitosamente (clave incorrecta, usuario ya existe, campo vacío). Al sincronizar datos se garantiza integridad en los mismos.


137

P4I5HU7 Caso de Prueba 4: Prueba módulo gestión de posologías


Condiciones de ejecución: Servidor corriendo de en red local


1 Ejecución del emulador en dispositivo Android del framework

2 Enviar imágenes de fórmulas médicas al servidor de manera local

3 Evaluar Resultados

Resultado esperado: Retorno en consola del objeto JSON con la lectura y etiquetado de la fórmula médica


P5I5HU8 Caso de Prueba 5: Prueba módulo historial y gráficos


Condiciones de ejecución: No tener historial médico nulo


1 Ejecución del emulador en navegador del framework

2 Elegir la opción de gráficas dentro del aplicativo


Resultado esperado: Impresión en consola de la tabla de datos normalizada para vista de gráficas preliminares


138

12. ANEXO II: MANUAL DE USUARIO

12.1. ¿QUÉ ES ISKA?

Iska es un aplicativo móvil que permite a los usuarios gestionar sus fórmulas o prescripciones médicas.

Consta de un repositorio de datos con información de todos los medicamentos aprobados y vigentes por el Instituto Nacional de Vigilancia de Medicamento (INVIMA) en Colombia, dichos datos contienen información de medicamentos tales como forma de presentación, principio activo, laboratorio que lo fabricó, fechas de vigencia, eventos adversos reportados, entre otros.

Por otro lado, Iska cuenta con un componente de identificación óptico de caracteres, funcionalidad que facilita al usuario ingresar los datos a partir de una foto de su fórmula médica. Junto a este servicio, se define una gramática que especifica los componentes de una posología y su estructura; la cual se usa para reconocer las posologías dentro una fórmula médica que provea el usuario. Sin embargo, si el usuario lo desea puede hacer el ingreso de sus medicamentos de forma manual.

Finalmente, los usuarios de Iska reciben alertas programadas automáticamente las cuales indican la hora oportuna para tomar un medicamento dada la posología prescrita por su médico. También pueden consultar su historial de fórmulas médicas, descargarlo en formato JSON y ver gráficas resumen de su consumo

12.2. DESCARGA E INSTALACIÓN

Para la descarga de la aplicación, se debe ingresar a la siguiente URL desde el navegador de internet del dispositivo móvil.

http://186.154.95.101/ocrpastillero

Figura 48. Página Web Principal

http://186.154.95.101/ocrpastillero

139

Estando en el sitio web, se debe descargar el archivo APK, que es el instalador de aplicaciones en dispositivos Android, haciendo clic en Descargar, como lo muestra la Figura 48

Figura 49. Ubicación de instalador ISKA

Paso seguido, a través del gestor de archivos instalado, se debe ingresar a la carpeta de descargas, donde se ubica el archivo APK (Ver Figura 49). Al encontrar la ubicación, se deberá abrir el instalador. Una vez abierto, el usuario debe elegir la opción instalar del menú, como se ve en la Figura 50.

Figura 50. Instalador ISKA

En la Figura 51 se puede observar el menú de aplicaciones del dispositivo Android, donde se puede ver el botón de acceso a la aplicación. Este botón se debe presionar para iniciar la aplicación.

140

Figura 51. Aplicación ISKA instalada

12.3. REGISTRO

Al abrir la aplicación, se despliega el formulario de inicio de sesión, sin embargo, para el registro se debe elegir la opción “¿no tienes cuenta? Regístrate aquí”, como lo muestra la Figura 52.

Figura 52. Opción de registro

Con esto, la aplicación desplegará el formulario de registro (Ver Figura 53). El usuario debe ingresar la totalidad de la información, y elegir el botón Registrar al terminar de diligenciar los campos. De no llenarse los campos, el registro se rechaza y un mensaje de error será ejecutado.

141

Figura 53. Formulario de registro

12.4. USO DE LA APLICACIÓN

Los siguientes ejes temáticos, explican las funciones a las que puede acceder cualquier usuario registrado en la aplicación.

12.4.1. INICIO DE SESIÓN

Figura 54. Inicio de sesión aplicación

142

Una vez se despliega la aplicación (Figura 54), el usuario deberá ingresar el correo y contraseña válidos con el que realizó su registro. Al elegir Iniciar sesión, y la autenticación es exitosa. La página de inicio de la aplicación (Ver Figura 55) carga la información del usuario.

Figura 55. Página principal aplicación

12.4.2. AÑADIR RECETA MÉDICA

Figura 56. Pestaña acceso a fórmulas medicas

143

Si se quiere añadir una receta, estando en la página principal, se debe elegir la pestaña Fórmulas Medicas, en el panel de navegación inferior (Ver Figura 56). Con esto, la vista de la Figura 57 se despliega para el usuario.

Figura 57. Listado de fórmulas médicas del usuario

Si se quiere añadir una nueva receta médica, el usuario hará clic en el botón +, para que el menú del servicio sea mostrado. Así se muestra en la Figura 58.

Figura 58. Menú para añadir formula

144

Si el usuario elige Cargar la formula o tomar la fotografía de la misma, se recomienda que la imagen de la receta médica contenga únicamente la sección que nombra los medicamentos. Un ejemplo claro de esto es la Figura 59.

Figura 59. Ejemplo ideal de fotografía de formula médica

Para estas dos opciones, se deberá elegir una imagen de la galería o tomar la fotografía, como se muestra en la Figura 60. De cualquier modo, luego de este proceso, se muestra una ventana para confirmar el envío de la imagen (ver Figura 61).

Figura 60. Opciones carga de fotografía

Una vez se cargue esta ventana, el usuario, en caso de continuar el proceso deberá elegir la opción Cargar. Con esta acción, un mensaje de espera se activa (ver Figura 61) que termina con la confirmación de éxito de la operación.

145

Figura 61. Ventanas confirmación envío de fotografía.

Una vez el mensaje de éxito es aceptado, se desplegará un formulario de confirmación por cada medicamento que el servidor haya logrado reconocer (ver Figura 62). El usuario deberá complementar o cambiar la información presentada, pero, en cualquier caso, deberá llenar todos los campos.

Figura 62. Ventana confirmación de medicamento

Como se muestra en la Figura 63, el usuario deberá escoger el medicamento de las posibles opciones que el servidor estableció. Para cualquier medicamento, el

146

usuario podrá descartar el registro de ese medicamento y en el último de ellos, podrá añadir un medicamento de forma manual, completando el formulario de la Figura 64¡Error! No se encuentra el origen de la referencia..

Figura 63. Proceso de confirmación de medicamentos.

Figura 64. Medicamento adicional

Cuando el usuario finalice el proceso de adición del medicamento, la aplicación cargará la ventana principal y reestablecerá el calendario de notificaciones para el consumo de los medicamentos adicionados en los pasos anteriores.

147

Notificaciones

Las notificaciones han sido programadas para que sean automáticamente activadas en cada toma del medicamento (por ejemplo, cada 8 horas, recuerda el consumo de un medicamento. Lo hace 30 veces, que es la cantidad total de tabletas). La Figura 65 muestra un ejemplo de cómo un usuario puede reconocer una notificación de la aplicación.

Figura 65. Notificación: Recordatorio consumo de medicamento

12.4.3. VER RECETA MÉDICA

148

Figura 66. Formulas Medicas

Para ver el contenido o los medicamentos de una receta médica registrada, el usuario deberá ingresar a la pestaña Fórmulas Medicas (ver Figura 66). Allí se cargarán todas las recetas registradas hasta el momento. Las fórmulas estarán enumeradas y con la fecha en la que fue registrada.

Una vez, el usuario elige una de las fórmulas, la aplicación cargará la información de cada uno de los medicamentos registrados. Así se muestra en la Figura 67.

Figura 67. Vista formula médica de usuario

Gráficas

Para acceder a los gráficos que muestran en histórico de consumo general y por medicamento de las recetas registradas, el usuario deberá ingresar a la pestaña Formulas Médicas mediante el panel de navegación, tal como lo muestra la Figura 67, y elegir el botón azul que tiene un icono de una gráfica en su interior.

Este botón, despliega el gráfico principal que contiene el consumo total de medicamentos, representando la cantidad de tomas registradas mes a mes (Ver Figura 69). Así mismo, aparece una lista de los diferentes medicamentos que ha sido registrados históricamente, para que el usuario al elegir cualquier de ellas, puede ver el consumo total para ese fármaco en específico.

149

Figura 68. Acceso al módulo de graficas

Figura 69. Gráficos disponibles para el usuario

Efectos Adversos

Para visualizar los efectos adversos de un medicamento, el usuario deberá ingresar a cualquiera de las fórmulas médicas registradas y elegir la opción “Ver posibles efectos adversos” de cualquier medicamento. La información se desplegará como en la Figura 70.

150

Figura 70. Efectos adversos de un medicamento

Descarga JSON

Para descarga la información de una receta médica, el usuario ingresa a cualquiera de las fórmulas registradas y elige la opción Descargar JSON. Un mensaje de confirmación se despliega, y el usuario podrá encontrar el archivo en la carpeta /Pastillero de la memoria interna de su dispositivo móvil (Ver Figura 71).

Figura 71. Proceso descarga de JSON de formula médica

151

Una vez el usuario a través de su gestor de archivos, podrá visualizar el archivo JSON de la formula médica y usarlo, si es posible, para cargar la información en otra aplicación.

Figura 72. Archivo JSON fórmula médica

12.4.4. VER PRÓXIMOS MEDICAMENTOS

Figura 73. Medicamentos pendientes: Próximos 7 días.

152

Para visualizar los medicamentos pendientes, el usuario deberá ir a la ventana principal de la aplicación, donde se encontrará un listado de los próximos 7 días calendario, como se ve en la Figura 73.

Allí el usuario podrá elegir cualquiera de los días de la semana, eligiendo el botón Ver del día en específico. La información se despliega como lo muestra la Figura 74.

Activar o Desactivar notificaciones

Para activar o desactivar una notificación de forma individual, el usuario podrá ingresar a cualquiera de los días desplegados en la ventana principal. Allí dependiendo el medicamento podrá elegir la opción “Desactivar notificación” o “Activar notificación” dependiendo del estado actual de cada medicamento para ese día.

En cualquiera de los dos casos, el cronograma del medicamento para ese día no se modifica, ni altera el proceso de conteo para generar los gráficos de consumo. Este proceso únicamente activa o desactiva la notificación local en el dispositivo móvil para el día y hora indicado.

Figura 74. Activación o desactivación de notificaciones

153

12.4.5. VER PERFIL

Para visualizar la información personal asociada a la cuenta, el usuario deberá elegir la pestaña Perfil en el panel de navegación. La información puede ser vista como se muestra en la Figura 75

Figura 75. Perfil de un usuario

Documents

Prototipo de Gestor de Medicación Utilizando Bases de ...repository.udistrital.edu.co/bitstream/11349/13829/... · cristian alejandro bravo mora proyecto de grado directora: ph.d