Sistema de control de medicación

Sistema de Gestión y Control de Medicación Enero 2015 TRABAJO FINAL DE GRADO GRADO EN INGENIERÍA INFORMÁTICA SISTEMAS DE INFORMACIÓN FACULTAT D’INFORMÀTICA DE BARCELONA (FIB) UNIVERSITAT POLITÈCNICA DE CATALUNYA (UPC) – BARCELONA TECH Directora: Claudia Ayala Martínez Enginyeria de Serveis i Sistemes d’Informació Autor: David Castro Villena Agradezco a Claudia haber aceptado ser la directora de mi Trabajo Final de Grado, sus consejos, ayuda y supervisión durante todas las fases del proyecto, y el tiempo que ha dedicado para atenderme en las reuniones. Agradezco a Joan Subirats su colaboración durante la fase de gestión del proyecto que ha hecho que este documento siga sus pautas para ser más correcto, uniforme, estructurado y profesional. Agradezco a la Dra. Cristina Núñez, y a Juan Pablo de la Farmacia Moreno Murillo por haber resuelto mis dudas y darme más información sobre el sector en el que se enmarca este trabajo. Finalmente, agradezco a toda mi familia su apoyo y confianza durante todo el período académico, y especialmente todos los años de la carrera. Este trabajo parte de la idea inicial de conseguir hacer una mejor gestión de la toma de medicamentos por parte de las personas que tienen recetado un número considerable de fármacos. Se pretende conseguir la conexión entre el proceso de prescripción de recetas, y el posterior desarrollo del tratamiento por los pacientes. Concretamente, el sistema está dividido en dos partes, por un lado, el personal médico dispone de una aplicación web para gestionar las recetas de sus pacientes, y en la que también pueden observar cómo el paciente ha seguido o está siguiendo el tratamiento. Por otro lado, gracias a una aplicación para dispositivos móviles, los pacientes pueden activar notificaciones para sus medicamentos e ir marcando las tomas, así como tener un acceso fácil y rápido a la información de sus recetas, que automáticamente se descargan del sistema médico, entre otras muchas características. Actualmente, ya existen aplicaciones que notifican al paciente, pero ninguna de ellas está conectada con un sistema que utilice el personal médico, y los procesos de introducción de la información son largos e implican riesgos de equivocación. ---------- Aquest treball parteix de la idea inicial d’aconseguir fer una millor gestió de la presa de medicaments per part de les persones que tenen receptats un número considerable de fàrmacs. Es pretén aconseguir la connexió entre el procés de prescripció de receptes, i el posterior desenvolupament del tractament pels pacients. Concretament, el sistema està dividit en dues parts, d’una banda, el personal mèdic disposa d’una aplicació web per gestionar les receptes dels seus pacients, i en la que també poden observar com el pacient ha seguit o ha estat seguint el tractament. D’altra banda, gràcies a una aplicació per dispositius mòbils, els pacients poden activar notificacions pels seus medicaments i anar marcant les preses, així com tenir un accés fàcil i ràpid a la informació de les seves receptes, que automàticament es descarreguen del sistema mèdic, entre altres moltes característiques. Actualment, ja existeixen aplicacions que notifiquen al pacient, però cap d’elles està connectada amb un sistema que utilitzi el personal mèdic, i els processos d’introducció de la informació son llargs i impliquen riscos d’equivocació. ---------- This project arises out of an initial idea to achieve a better management of taking medications by people who have a considerable number of medicines. The intention is to obtain a connexion between the prescription process, and subsequent development of the treatment by patients. Specifically, the system is divided in two parts, on the one hand, medical staff have a web application to manage patient prescriptions, and they can also view how the patient has followed or is following the treatment. On the other hand, through a mobile-application, patients can activate notifications for their medicines and mark it as taken, as well as having an easy and fast access to the prescription data, which automatically is downloaded from the medical system, among other features. Nowadays, already exist more applications that send notifications to the patient, but none of them is connected with a system used by medical staff, and information input processes are very long and involves risk of errors. 4 Índice 1. Introducción y estado del arte .................................................................................................. 7 1.1. Formulación del problema ................................................................................................ 7 1.2. Contexto ............................................................................................................................ 8 1.2.1. Partes interesadas .................................................................................................. 8 1.2.2. Situación y funcionamiento actual ......................................................................... 9 1.3. Estado del arte ................................................................................................................ 10 1.3.1. Aplicaciones móviles ............................................................................................ 10 1.3.2. Aplicaciones web .................................................................................................. 15 1.3.3. Software ............................................................................................................... 24 1.3.4. Conclusión del estado del arte ............................................................................. 28 2. Alcance del proyecto ............................................................................................................... 29 2.1. Obstáculos ....................................................................................................................... 29 2.2. Metodología de trabajo .................................................................................................. 30 2.3. Herramientas de seguimiento y análisis ......................................................................... 31 2.4. Adecuación a Sistemas de Información .......................................................................... 31 2.4.1. Competencias técnicas a desarrollar .................................................................... 33 2.4.2. Conocimientos aplicados ...................................................................................... 34 3. Planificación temporal............................................................................................................. 35 3.1. Descripción de las tareas y recursos ............................................................................... 35 Fase I: Análisis previo ..................................................................................................... 35 Fase II: Gestión de proyectos ......................................................................................... 35 Fase III: Análisis de Requisitos ........................................................................................ 35 Fase IV: Especificación .................................................................................................... 35 Fase V: Diseño, Implementación y Pruebas ................................................................... 36 Fase VI: Final ................................................................................................................... 36 3.2. Diagrama de Gantt .......................................................................................................... 37 3.3. Recursos humanos .......................................................................................................... 38 3.4. Valoración de alternativas y plan de acción ................................................................... 38 4. Gestión económica .................................................................................................................. 39 4.1. Identificación y estimación de los costes ........................................................................ 39 4.1.1. Recursos humanos ............................................................................................... 39 4.1.2. Software ............................................................................................................... 39 4.1.3. Hardware .............................................................................................................. 40 4.1.4. Gastos generales .................................................................................................. 40 4.1.5. Costes imprevistos ............................................................................................... 41 5 4.1.6. Coste total del proyecto ....................................................................................... 41 4.2. Control de gestión ........................................................................................................... 41 5. Análisis inicial .......................................................................................................................... 43 5.1. Estudio de viabilidad ....................................................................................................... 43 5.1.1. Análisis de las partes interesadas (stakeholders) ................................................. 43 5.1.2. Limitaciones legales implicadas............................................................................ 44 5.2. Análisis de riesgos ........................................................................................................... 45 5.2.1. Estrategia de mitigación ....................................................................................... 45 5.2.2. Plan de contingencia ............................................................................................ 46 5.3. Visión global de las funcionalidades del sistema ............................................................ 47 5.4. Análisis de tecnologías candidatas .................................................................................. 48 5.5. Conclusiones del análisis inicial ....................................................................................... 49 6. Requisitos ................................................................................................................................ 50 6.1. Propiedades e hipótesis sobre el dominio ...................................................................... 50 6.2. Restricciones ................................................................................................................... 50 6.3. Diagrama de casos de uso ............................................................................................... 52 6.4. Casos de uso .................................................................................................................... 53 6.5. Requisitos no funcionales ............................................................................................... 61 6.5.1. Requisitos de percepción ..................................................................................... 61 6.5.2. Requisitos de usabilidad y humanidad ................................................................. 62 6.5.3. Requisitos de rendimiento ................................................................................... 63 6.5.4. Requisitos de funcionamiento y ambientales ...................................................... 65 6.5.5. Requisitos de mantenimiento y soporte .............................................................. 66 6.5.6. Requisitos de seguridad ....................................................................................... 67 6.5.7. Requisitos legales ................................................................................................. 68 7. Especificación .......................................................................................................................... 69 7.1. Esquema conceptual ....................................................................................................... 69 7.1.1. Restricciones de clave externa ............................................................................. 69 7.1.2. Restricciones de integridad textuales .................................................................. 70 7.1.3. Información derivada ........................................................................................... 70 7.1.4. Descripción de las entidades ................................................................................ 71 7.2. Esquema del comportamiento ........................................................................................ 75 8. Diseño ...................................................................................................................................... 91 8.1. Arquitectura .................................................................................................................... 91 8.1.1. Tecnología utilizada .............................................................................................. 91 8.1.2. Patrón Model – View – Controller ........................................................................ 93 8.1.3. Patrón Model – View – Presenter ......................................................................... 93 8.2. Capa de presentación (Wireframes) ............................................................................... 94 6 8.3. Cambios en las restricciones ......................................................................................... 102 8.4. Diagrama de clases de diseño ....................................................................................... 103 8.5. Modelo de datos ........................................................................................................... 104 8.6. Diagramas de secuencia ................................................................................................ 106 9. Implementación .................................................................................................................... 130 9.1. Desarrollo con CodeIgniter............................................................................................ 130 9.2. Desarrollo con Android ................................................................................................. 134 10. Pruebas ................................................................................................................................ 139 10.1. Pruebas de desarrollo ................................................................................................. 139 10.2. Pruebas finales ............................................................................................................ 142 11. Informe de sostenibilidad ................................................................................................... 144 12. Conclusión ........................................................................................................................... 147 12.1. Justificación del desarrollo de las competencias técnicas .......................................... 147 12.2. Desviaciones en la planificación y presupuesto .......................................................... 149 12.3. Diagrama de Gantt final .............................................................................................. 151 12.4. Limitaciones y dificultades .......................................................................................... 152 12.5. Trabajo futuro ............................................................................................................. 152 13. Bibliografía .......................................................................................................................... 154 Glosario ..................................................................................................................................... 156 Anexo I: Entrevistas a personal sanitario .................................................................................. 158 Anexo II: Capturas de las aplicaciones ...................................................................................... 160 Índice de figuras ........................................................................................................................ 166 Índice de tablas .......................................................................................................................... 169 7 1. Introducción y estado del arte 1.1. Formulación del problema Cada vez hay más personas que toman medicación con mucha frecuencia, ya sea por una enfermedad crónica, o por problemas temporales de salud. El olvido o uso inadecuado de los medicamentos puede provocar graves consecuencias en el estado de salud del paciente dependiendo de la enfermedad que padezca. La finalidad de este Trabajo Final de Grado es facilitar el acceso por parte del paciente a la información recetada por el personal médico, para poder consultarla cuando sea necesario, e incorporar mecanismos para que el paciente siga el tratamiento correctamente, así como ofrecerle al personal médico herramientas para comprobar si se han producido errores. España es el segundo país del mundo, por detrás de Estados Unidos, que consume más fármacos; el número de recetas prescritas, no ha parado de crecer en los últimos años. A continuación se muestra una tabla con datos relevantes sobre el tema a tratar: Prescripciones de recetas (España, 2010) 958 millones 20,4 por habitante [1] Pacientes que incumplen el tratamiento 44% [2] Pacientes con dificultades para seguir el tratamiento 11% [2] Pacientes que olvidan instrucciones del médico 14% [3] Pacientes que olvidan con frecuencia tomar la medicación 10,9% [3] Pacientes que confunden los medicamentos 5,9% [3] Tabla 1: Datos sobre la toma de medicamentos en España Se definen dos objetivos principales que van a formar parte del conjunto del sistema:  Desarrollo de una aplicación web: el personal médico será capaz de recetar medicamentos, para cada paciente que visite, con las indicaciones e instrucciones a seguir, que se incluirán en el plan de medicación (un documento con la información de todos los medicamentos que se deben tomar) que ya está siguiendo el paciente. Además, le proporcionará herramientas de gestión sobre esas recetas, para modificarlas, archivarlas, y también poder hacer un seguimiento sobre el desarrollo que están teniendo los pacientes del tratamiento que se les ha diagnosticado, gracias a la información que el sistema recibirá.  Desarrollo de una aplicación móvil: el paciente podrá recibir notificaciones de los diferentes medicamentos que incluya su plan de medicación en las horas en las que sea necesario hacer uso de alguno de ellos. Estas notificaciones incluirán una serie de información relevante como la imagen del medicamento, su nombre y la dosis que se debe utilizar o comentarios del propio paciente. También se informará cuando se detecte que escasea la cantidad disponible de algún fármaco, y será posible consultar toda la información introducida por el personal médico sobre el plan de medicación, de una forma fácil y clara. 8 Asimismo, pensando en pacientes poco familiarizados con las últimas tecnologías o con algún impedimento físico, se incluirán configuraciones especiales para simplificar el aspecto de la aplicación y una funcionalidad para permitir el acceso a terceras personas (supervisores) que puedan gestionar la configuración de la aplicación y recibir avisos en caso de que se cometan errores, olvidos o algún otro tipo de incidencia. Tal y como se ha mencionado anteriormente, el paciente cuando reciba una notificación, deberá informar al sistema que ha tomado la medicación que se le notificaba. Con esta información, el médico puede consultar, a posteriori, cómo se ha seguido el tratamiento y si se ha cometido algún error. La aplicación será lo más flexible posible para el usuario, aunque en ciertos casos será necesario poner ciertas limitaciones para evitar causar problemas de salud al paciente, por ejemplo, en el caso de que un paciente retrase mucho la toma de un medicamento, la aplicación preguntará si quiere re-programar las siguientes notificaciones para separar las siguientes tomas. 1.2. Contexto En este apartado se analiza el contexto donde se va a situar el producto una vez finalizado el proyecto. Concretamente, se determinan cuáles van a ser las partes interesadas a las que va dirigido, qué uso van a hacer del sistema y qué beneficios les aportará. También se describe cómo es el funcionamiento actual del entorno en el que se pretende implantar, y las carencias que se desea suplir. 1.2.1. Partes interesadas A continuación, se describen qué partes interesadas están implicadas en el proyecto que se va a desarrollar y qué uso van a hacer del sistema: Usuarios del sistema Médicos: La introducción y modificación de datos estará a cargo de personal médico cualificado. Accederán al sistema mediante una aplicación web para definir planes de medicación y poder visualizar el seguimiento que el paciente ha realizado del tratamiento diagnosticado. Pacientes: Son los que obtendrán mayor beneficio del proyecto si llega a ponerse en funcionamiento. Utilizará el sistema para consultar la información introducida por el médico, que les permite realizar un seguimiento correcto y adecuado de la medicación recetada, gracias a avisos que recuerdan a unas horas determinadas qué fármaco es necesario ingerir, entre otra información relevante. Interaccionan con el sistema mediante una aplicación móvil para dispositivos Android, que estará adaptada para su utilización por personas mayores. Supervisores: El paciente puede permitir a una persona de su círculo de confianza que asuma el rol de supervisora, y vele por el cumplimiento del tratamiento. Su función en el sistema es similar a la del paciente: reciben avisos si el supervisado olvidase demasiado tiempo la toma de una medicación, y también se les permite acceder al perfil del paciente en su nombre para hacer modificaciones. 9 El desarrollador Inicialmente se encarga de la creación del sistema, y posteriormente se dedica a añadir nuevas funcionalidades, realizar cambios, solucionar errores técnicos, etc. Otras partes interesadas Administrador: Da las altas o bajas de usuarios del sistema y trata con ellos en caso de que se produzcan problemas de acceso al sistema. Institución/empresa privada: No se descarta una colaboración con terceras partes una vez finalizado el proyecto, ya que la adquisición del producto final provocaría un aumento de la calidad del servicio de la institución o empresa compradora. 1.2.2. Situación y funcionamiento actual Actualmente, el Servei Català de la Salut (CatSalut) dispone del sistema Rec@t, también conocido como receta electrónica, que integra procesos de prescripción y dispensación de medicamentos mediante las TIC, con el objetivo de realizar un uso racional de los fármacos por parte de la ciudadanía, facilitar la cohesión de diferentes niveles asistenciales, proporcionar vías de comunicación a los profesionales sanitarios o disminuir tareas burocráticas para dedicar el tiempo a tareas asistenciales, entre otros objetivos. La receta electrónica ya es un sistema consolidado en Catalunya, que sigue optimizando la gestión sanitaria en términos de medicamentos y procedimientos, y aumentando la seguridad para los usuarios [4]. Después de una visita con el profesional médico, este le proporciona al paciente un plan de medicación, un documento con la información necesaria para poder seguir correctamente el tratamiento. Está compuesto de una serie de medicamentos, donde para cada uno, se especifica la dosis y la frecuencia con la que debe ser tomado, el médico y centro donde ha sido prescrito, la duración del tratamiento, las fechas de vigencia para adquirir los medicamentos en las farmacias, y comentarios del propio médico [5]. En un contexto donde, según datos de la Generalitat de Catalunya, en el año 2012 se ha proporcionado una media de 18,5 recetas por habitante [6], es importante que el paciente disponga de la información actualizada, accesible de manera fácil, fiable e instantánea. Por otro lado, 35 de cada 100 personas han declarado padecer un problema de salud crónico [7], este tipo de personas manejan muchos medicamentos diariamente y es fácil que puedan cometer algún error. Con el uso de las nuevas tecnologías se pretende acercar al máximo este tipo de información hasta el punto de que el paciente pueda generar información interesante para el propio médico sobre cómo va siguiendo su tratamiento; recibiendo avisos y marcando la toma de medicamentos en las horas que sea necesario hacer uso de ellos. El sistema de salud pública se beneficiaría con una reducción del coste del servicio y un aumento de la calidad ofrecida porque evitaría visitas innecesarias a los centros de atención primaria de pacientes que han extraviado el documento que les proporcionó su médico o visitas de urgencia por intoxicación debido a un uso indebido de la medicación. 16 Figura 14: Pantalla de definición de las características del tratamiento (MyMedSchedule) En el último paso (Figura 15) se muestra un resumen del tratamiento, y aquí es dónde se deben configurar los avisos (por e-mail o SMS) para recordar los medicamentos a tomar en la hora fijada. Figura 15: Resumen del tratamiento y configuración de los avisos (MyMedSchedule) También hay diferentes versiones imprimibles del tratamiento (con letras grandes, tamaño de bolsillo, por horas) y listas de control (por semana y mes) para marcar manualmente si se sigue el tratamiento y apuntar otros datos como: el peso, la temperatura corporal, el pulso, la presión arterial, azúcar, etc. Por último, hay un apartado con las indicaciones especiales que el laboratorio recomienda para su producto. 17 En mi opinión, el sitio web necesita un cambio de estructura, sería más útil y fácil de usar si todo el formulario estuviese en una única página; también modificaría el aspecto de los botones y su localización ya que en la mayoría de páginas se ubican en la parte superior derecha. El apartado para crear recordatorios cuando la medicación se esté acabando no es muy visible, y es fácil que el usuario desconozca la existencia de la funcionalidad. En cuanto al idioma, se ofrecen partes en español, y estaría bien que toda la web fuese traducida. Finalmente, como puntos positivos hay que mencionar la incorporación de las imágenes de las pastillas y el buscador predictivo que ayudan al usuario en el proceso. RememberItNow! Es un servicio eHealth basado en la web y centrado en el paciente que está disponible online, es decir, no hay software que se tenga que instalar, actualizar y manejar, excepto las aplicaciones móviles. Tiene sus oficinas en el condado de Orinda, en el estado de California (EEUU) y ha sido posible gracias a financiación privada [12]. El equipo ejecutivo está formado por Pamela Swingley, la fundadora de la empresa, y Phil Wang, ambos con experiencia en el mundo del desarrollo de software. Según los datos que proporciona la empresa, la información está centralizada y es accesible a través de Internet desde cualquier ordenador o dispositivo en cualquier momento; el acceso es seguro y protegido por contraseña. Cada día realizan una copia de seguridad de los datos en los servidores de la empresa en un centro de datos de alta seguridad. Tienen aplicaciones móviles para iOS y Android aunque cuentan con pocas descargas y ninguna dispone de valoraciones de usuarios. Tanto el servicio web como las aplicaciones únicamente están disponibles en inglés y son gratuitas. Disponen de un vídeo de presentación accesible en este enlace [13]. Una vez nos hemos registrado, el servicio nos proporciona una URL única para acceder directamente a nuestro perfil. Mediante el nombre de usuario y la contraseña que hemos introducido anteriormente accedemos a nuestro ‘Dashboard’. En la Figura 16 podemos ver el aspecto de la página principal. 18 Figura 16: Dashboard de RememberItNow! Desde este panel de control podemos acceder a todas las secciones que nos ofrece y podemos consultar rápidamente la información de los avisos que hemos introducido. Dispone de las siguientes secciones:  Contactos: Para encontrar fácilmente información de contacto de doctores, farmacias, número de cuenta, mutua, cuidadores, etc.  Medicamentos: La sección más importante, aquí podemos añadir el tratamiento a seguir. Se dan más detalles a continuación.  Calendario: Para programar recordatorios eventos, medicamentos y tareas.  Estadísticas: Aquí podemos hacer un seguimiento de diferentes aspectos, previamente definidos. Cada día podemos evaluar en una escala de 1 a 5 estrellas nuestro estado de: humor, ansiedad, rampas, picores, nauseas, dolores, agarrotamiento, descanso o marcar afirmativamente o negativamente si: hemos realizado ejercicio, hemos hecho meditación, hemos fumado, hemos seguido la dieta y muchas más opciones. También podemos establecer objetivos y hacer un seguimiento de la presión arterial, peso o los niveles de azúcar.  Agenda: Para escribir un diario sobre el estado de salud o un sitio donde el cuidador pueda escribir sus notas sobre el trabajo realizado.  Recursos: Información genérica sobre temas de salud de páginas específicas.  Repositorio de documentos médicos. 19 Figura 17: Formulario para añadir un nuevo medicamento (RemembetItNow!) En la sección de medicamentos podemos añadir y gestionar el tratamiento médico que se nos ha diagnosticado. Como se puede ver en la Figura 17, hemos de introducir diferentes campos: nombre, objetivo de la medicación, dosis, instrucciones, inicio y fin del período de medicación, programación de las dosis, activar los recordatorios y otra información útil. El diseño es agradable a la vista y es usable, en la mayoría de campos podemos ver una pequeña ayuda para saber qué información se tiene que introducir que se puede expandir si movemos el cursor encima. Incluye elementos que facilitan la inserción de los datos, por ejemplo, para introducir el nombre del medicamento podemos abrir una ventana emergente para buscarlo en una lista filtrada alfabéticamente, también se abre un pequeño calendario en los campos que hay que introducir fechas, y desplegables para datos que suelen repetirse como el doctor o la farmacia donde hemos adquirido el producto. Una vez introducidos los medicamentos, podemos ver toda la información resumida (Figura 18) que podemos imprimir o exportar a Excel o filtrarla según la medicación actual, la medicación histórica o todos los medicamentos introducidos. Se incluye un calendario y un buscador para consultar la medicación que hay que tomar en una determinada fecha y para navegar por los medicamentos. En la Figura 19 vemos los medicamentos que hay que tomar en el día y la información mínima que necesitamos. Se puede seleccionar la vista según horas, días, semanas o meses. Se pueden añadir otros eventos, así como editar o eliminar los que ya se han introducido. En referencia a los avisos, se permiten configurar en las opciones del perfil de usuario. El servicio hace uso de las notificaciones de las aplicaciones móviles, el e-mail y de los SMS para enviar los recordatorios (los SMS tienen el coste que establezca el operador móvil). 20 Figura 18: Pestaña de gestión de medicamentos (RememberItNow!) Figura 19: Pestaña de calendario y medicación programada (RememberItNow!) Finalmente, el servicio incluye una opción para dar acceso a la cuenta a como máximo 15 personas. Se pueden definir diferentes permisos para cada usuario invitado. MedSimpleApp MedSimple es una plataforma desarrollada por el Dr. Anuj Bhargava con la ayuda de un equipo de farmacéuticos. Inicialmente fue pensada para personas diabéticas, pero durante el desarrollo, decidieron que podría darle uso cualquier persona que necesite tomar más de dos medicaciones al día [14]. Está disponible en versión web y en aplicaciones gratuitas para iOS y Android que permiten recibir recordatorios. En cuanto a la versión web, hay diferentes modalidades para utilizarla. Por un lado, la versión que incluye todas las funcionalidades tiene un precio de $9,99 al año (7,30€ anuales), por otro, cuando nos registramos se nos activa el período de prueba de 90 días que incluye algunas funcionalidades de la modalidad de pago como poder introducir alergias, farmacias, imprimir la lista de medicación o alertas cuando se acaba algún medicamento. Finalmente, la opción más básica, que es gratuita, permite únicamente la gestión de los medicamentos, recibir recordatorios y tener un perfil de paciente. En la Figura 20 podemos ver la lista de medicamentos introducidos con las instrucciones para ingerirlos, modificar la información, consultar información del medicamento, descargar la lista, imprimirla, etc. Los datos introducidos serán los que la plataforma utilice para enviar los recordatorios a la aplicación móvil. En las demás opciones accesibles (algunas gracias a la versión de prueba), encontramos un buscador de medicamentos que contiene información sobre la medicina: porqué tomarlo, efectos secundarios, instrucciones, imágenes y efecto al combinarla con otros medicamentos. En las otras secciones podemos añadir información de contacto de los doctores que nos han atendido y de las farmacias donde hemos adquirido los medicamentos. 21 Figura 20: Pantalla principal de MedSimple Finalmente, en otro apartado podemos introducir información personal, alergias y consultar información de la cuenta. La Figura 21 muestra el formulario para añadir un medicamento. Para introducir el nombre, el sistema incluye un buscador que muestra resultados a medida que se van escribiendo letras; hay que indicar la forma de tomar el medicamento, la cantidad, la frecuencia de la dosis, el objetivo por el cual se toma e instrucciones varias. También permite añadir qué médico ha recetado el medicamento y en qué farmacia se ha comprado, el número de veces que puede ser adquirido, los días que quedan de medicamento y configurar notificaciones cuando se esté acabando el medicamento. En general, el sitio web es fácil de usar y utiliza una combinación de colores agradable para el usuario. El buscador de medicamentos predictivo y los desplegables hacen que sea más fácil y rápido el proceso de inserción. Como aspectos negativos, la página no aprovecha el ancho de la pantalla y tampoco incluye ayuda sobre los campos del formulario. 22 Figura 21: Formulario para añadir un nuevo medicamento (MedSimple) HealthVault Aunque HealthVault no es una plataforma que permita enviar recordatorios, al estar creada y desarrollada por Microsoft, he creído conveniente explicar brevemente su utilidad y funcionamiento. Es una plataforma web que empezó a funcionar en 2007 y que se expandió en 2010; ahora ya está disponible en español [15]. Permite almacenar, manejar y compartir datos de salud y estado físico sin ningún coste. También es posible autorizar a otras personas para que puedan acceder a la información personal y que la puedan gestionar. En cuanto al tipo de acceso, se realiza con una cuenta Windows Live ID, Facebook o de proveedores OpenID. La plataforma permite tratar con los datos desde el propio sitio web, pero también permite que el usuario interactúe con aplicaciones externas (sitios web, aplicaciones móviles o software informático) que almacenan la información en el sitio (Figura 22). Estas aplicaciones deben ser autorizadas previamente por los usuarios y deben informar sobre los datos que van a utilizar. 23 La aplicación oficial HealthVault sólo está disponible para Windows, Windows Phone e iPhone, pero existen aplicaciones de terceros para otros sistemas operativos que permiten almacenar los datos, tal y como se ha explicado anteriormente. Los dispositivos de medición de última generación también pueden guardar los datos en HealthVault, por ejemplo: básculas, pulseras de fitness, medidores de presión arterial, glucemia, etc. El objetivo es centralizar las historias médicas de familias para que dispongan de la información siempre que deseen. Entrando en los diferentes apartados de Healthvault encontramos [16] [17]:  Mediciones: Seguimiento de la altura, colesterol, peso, presión arterial, ejercicios físicos realizados, datos sobre la comida y bebida, glucemia y resultados de análisis de laboratorio.  Historial de salud: Afecciones, alergias, antecedentes familiares, citas con médicos, contactos médicos, dispositivos médicos, vacunas, medicamentos (Figura 23), información de la mutua.  Documentos: Archivos, documento de asistencia continua (CCD), registro de asistencia continua (CCR), estudio de imágenes médicas.  Vistas de salud: Perfil de emergencia (datos básicos para personal médico de urgencias), control de peso (gráficas de: peso, duración del ejercicio, pasos, calorías ingeridas, carbohidratos, proteínas y grasas). Figura 22: Funcionamiento de HealthVault 24 Figura 23: Formulario de introducción de datos de medicamentos (HealthVault) 1.3.3. Software My Medications List Es un software de distribución libre y sin coste (freeware) que se puede utilizar tantas veces como se quiera sin un tiempo límite. En el programa aparece como creador ‘JCMatt Software’ pero ha dejado de darle soporte, ya que la página web oficial que aparece en About corresponde a un blog donde no se menciona el software (posiblemente ahora pertenezca a otra persona). Se puede descargar de páginas como Softonic en la versión 6.0.1 y que según la información que se puede encontrar, fue lanzada el 10 de septiembre de 2009 [18]. Únicamente está disponible en inglés y sirve para gestionar los medicamentos, no incluye un sistema de avisos y notificaciones. 25 Figura 24: Ventana principal de My Medications List Desde la ventana principal podemos acceder a todas las opciones e introducir la información necesaria. En la Figura 24 podemos ver un ejemplo de utilización facilitado por el autor en la sección de ayuda del programa. Para cada medicamento se han de indicar una serie de campos: nombre, dosis, forma de medicamento, cantidad total, número de dosis al día, instrucciones para tomarlos, coste, finalidad del uso, número de referencia y fechas con la última y próxima vez que habrá que comprar el medicamento, etc. En el menú encontramos las clásicas opciones de abrir archivo, crear uno nuevo, guardar y guardar como, imprimir, acerca de, ayuda y botones para rellenar y renovar el medicamento seleccionado automáticamente, ver información sobre el medicamento en la página Drugs.com, hacer/restaurar una copia de seguridad y salir. También podemos ver información sobre el coste mensual, cuatrimestral y anual que gastamos en el medicamento seleccionado o todos los que hay en la lista, así como información más visual sobre el medicamento seleccionado como la fecha en la que hay que comprar más medicamentos. Sobre la lista podemos realizar una serie de acciones como añadir nuevos medicamentos, modificarlos (ya sea a través del botón o directamente en la lista), eliminarlos (permanentemente o moverlos al historial), cambiarlos de orden, poner separadores, ver el historial de medicamentos utilizados, y una utilidad para gestionar fechas. En cuanto al aspecto, es notable que la aplicación no ha recibido muchas actualizaciones y la interfaz se ha quedado desfasada; los botones no son actuales ni atractivos y la combinación de colores no es moderna. 32 Aplicando la definición al proyecto que se va a desarrollar, por un lado, el sistema recoge los datos introducidos por el médico de la medicación que un paciente debe tomar, los almacena, algunos de esos datos son procesados o generan una serie de cálculos y, finalmente, se distribuye la información en la aplicación móvil que utilizará el paciente o a través de otros profesionales médicos que la consultan cuando visitan al paciente. Por otro lado, el paciente realiza una función similar dentro del sistema, envía datos sobre si ha tomado la medicación, el sistema los recoge y almacena y cuando el médico quiere consultarlos, se procesan y se muestra la información extraída de los datos. Valorando el impacto que supone tener en funcionamiento el sistema, podemos destacar aspectos que obtienen ambos usuarios del sistema cuando lo usan 2 : Los pacientes pueden gestionar su medicación de forma más eficiente. Los pacientes pueden consultar información de su tratamiento y los medicamentos que incluye en cualquier momento. Los pacientes pueden ejercer un control y supervisión de sus medicamentos conociendo la cantidad restante de cada uno de ellos. Permite a los pacientes minimizar riesgos de interrupción del tratamiento al poder ver el aspecto o envase del medicamento que deben tomar. Reduce el riesgo de cometer errores por los pacientes. Los pacientes se sienten más seguros al no tener que introducir ellos mismos gran parte de la información de sus recetas, y saben que el sistema controla y supervisa toda la información que ellos deben completar (fechas, horas, cambiar la cantidad restante, etc.). Los médicos obtienen información de los pacientes que hasta ahora era imposible de conocer, cómo han seguido el tratamiento, las interrupciones que ha habido, y la gravedad de estas. Los médicos pueden realizar un mejor diagnóstico. Se minimizan problemas informáticos al utilizar una aplicación web ya que es prácticamente independiente del hardware y del sistema operativo de los equipos utilizados. El uso del sistema es fácil y apenas requiere formación, utiliza nuevos elementos que aumentan la eficiencia del trabajo de los médicos y la usabilidad del propio sistema. Con la información generada se permite ajustar y distribuir mejor el presupuesto económico de los centros (afluencia de personas, visitas, etc.). En referencia al trabajo que debe realizar un ingeniero informático especialista en sistemas de información, este debe actuar de puente entre las necesidades de gestión que el entorno necesita y las posibilidades que la tecnología ofrece, analizando los requisitos, diseñando y construyendo un sistema con las herramientas más adecuadas para cada caso. También debe ser capaz de identificar oportunidades de mejora de procesos e introducir innovaciones para competir estratégicamente [21]. 2 Como en cualquier situación, habrá usuarios del sistema que harán un uso fraudulento o incorrecto del sistema, y en esos casos se puede generar información falsa o manipulada. Inevitablemente, al implicar a personas de características muy diversas, este problema puede aparecer con bastante frecuencia. 33 Durante este Trabajo Final de Grado se trabajan todas esas tareas, se empieza definiendo cuáles son los requisitos de las diferentes partes interesadas, se sigue con la especificación y diseño del sistema, seleccionando las herramientas que se quieren utilizar y diferenciando los usos del sistema de cada usuario, y se acaba implementando, obteniendo un sistema con más información que los otros sistemas competidores y por tanto, obteniendo una ventaja. Finalmente, una vez se ponga en marcha el sistema, se empezarán a recibir muchos datos. Estos datos pueden ser analizados y procesados para conocer más información que hasta ahora se desconocía 3 :  Saber el porcentaje real de personas que olvida algún medicamento durante el tratamiento.  Detectar en qué momentos del día se producen más olvidos.  Conocer el número de recetas prescritas, por paciente, centro médico y médico especialista.  Cuantificar el número de visitas por paciente, en las que se genera alguna receta, por especialidad médica, etc.  Saber qué medicamentos se recetan con más frecuencia.  Detectar si se están prescribiendo medicamentos no genéricos.  Conocer la distribución de medicamentos (tipo y/o cantidad) por edad del paciente. 2.4.1. Competencias técnicas a desarrollar  CSI2.2: Concebir, desplegar, organizar y gestionar sistemas y servicios informáticos, en contextos empresariales o institucionales, para mejorar sus procesos de negocio, responsabilizarse y liderar su puesta en marcha, y su mejora continua; y valorar su impacto económico y social. [Un poco] Este propio documento describirá todo el proceso de concepción, organización, gestión y despliegue de un sistema informático con mejoras que pueden ser incorporadas a los sistemas actuales del contexto. También se hará una valoración del impacto económico, social y ambiental que puede generar.  CSI3.1: Demostrar comprensión de los principios de la evaluación de riesgos y aplicarlos correctamente en la elaboración y la ejecución de planes de actuación. [Bastante] Se realizará un análisis de riesgos en los que puede caer el sistema una vez se ponga en funcionamiento, la estrategia de mitigación para prevenir daños y el plan de contingencia asociado para minimizar el efecto. También se describirán los riesgos asociados al propio desarrollo del proyecto.  CSI4.1: Participar activamente en la especificación de los sistemas de información y de comunicación. [En profundidad] 3 No se dispone de la información sobre qué datos se analizan actualmente en los sistemas existentes. 34 Se seguirán todos los pasos necesarios en la especificación de un sistema software: identificar las partes interesadas, realizar la ingeniería de requisitos (casos de uso y requisitos no funcionales), el esquema conceptual y el esquema del comportamiento.  CSI4.2: Participar activamente en el diseño, la implementación y el mantenimiento de los sistemas de información y de comunicación. [En profundidad] Se realizará el diseño del sistema mediante la arquitectura en capas, se establecerán las funciones que deberán adoptar cada capa y el patrón que utilizará, los diagramas de secuencia de cada caso de uso, y el modelo de la base de datos que utilizará el sistema. Se implementarán los casos de uso y se irán haciendo pruebas de manera iterativa hasta que ambas aplicaciones estén finalizadas. 2.4.2. Conocimientos aplicados Este trabajo requiere aplicar los conocimientos adquiridos en las diferentes asignaturas cursadas del Grado. De las asignaturas troncales, se obtienen los conocimientos básicos e iniciales que debe tener un ingeniero informático, sin embargo, se ven ampliadas en algunos campos con la elección de la especialidad. En este caso, al ser un proyecto de Sistema de Información, las asignaturas de la especialidad de las que se espera aplicar algunos conocimientos son: Por un lado, en ER (Enginyeria de Requisits) se aprendió, de manera práctica, a definir los objetivos de un sistema a desarrollar, describir de manera precisa los requisitos funcionales (casos de uso) y no funcionales (de calidad), a realizar un estado del arte completo, realizar un esquema conceptual y un esquema del comportamiento. Todos estos conocimientos se utilizarán para este proyecto. Por otro lado, de DSI (Disseny de Sistemes d’Informació) se pueden extraer conocimientos teóricos de: cómo desarrollar un proyecto de software (metodologías de desarrollo) y de cómo estructurar un sistema de información: la arquitectura en capas y el diseño y toma de decisiones de las funciones que debe asumir cada capa. De ABD (Administració de Bases de Dades) se podrán aplicar conocimientos de optimización de consultas, indexación de tablas (si fuese necesario), criterios de seguridad y control de acceso, y aspectos avanzados de SQL. Finalmente, PSI (Projecte de Sistemes d’Informació) me ha servido para saber cómo enfocar y gestionar un proyecto desde el punto de vista empresarial (presupuesto, planificación, procesos de negocio) y también ver cómo se une todo lo aprendido en las asignaturas mencionadas anteriormente. 35 3. Planificación temporal El proyecto tiene una duración aproximada de cinco meses, desde Julio hasta Diciembre, ambos incluidos. Se comenzó a trabajar en el proyecto el 8 de julio de 2014 y se ha planificado su finalización para la cuarta semana de Diciembre. Durante el mes de agosto el proyecto ha sido paralizado debido a las vacaciones de verano. 3.1. Descripción de las tareas y recursos Se ha dividido el trabajo del proyecto en diferentes fases. Para cada una de ellas se especifica la duración aproximada en semanas y el rol que el autor deberá ejercer. Fase I: Análisis previo [Rol: Jefe de proyecto] En esta fase se trabaja la viabilidad del proyecto con entrevistas a las diferentes partes interesadas y estudiando las limitaciones legales, se describen y evalúan los riesgos en los que puede verse implicado el proyecto una vez entre en funcionamiento, y las acciones para mitigar los riesgos o minimizar los daños. También se realiza un estado del arte de aplicaciones similares ya existentes, y una visión global de un sistema con todas las funcionalidades que han sido pensadas para él, pero que algunas han sido descartadas por la limitación temporal de este proyecto, o por ser poco relevantes. Fase II: Gestión de proyectos [Rol: Jefe de proyecto] Los contenidos de esta fase se van generando a medida que se cursa la asignatura semipresencial de Gestión de Proyectos (GEP), que tiene una duración de cinco semanas. Se deberán realizar y entregar los siguientes documentos:  Definición del alcance  Planificación temporal  Gestión económica y sostenibilidad  Contextualización y bibliografía  Pliego de condiciones (especialidad Sistemas de Información)  Presentación y documento final Fase III: Análisis de Requisitos [Rol: Analista] En esta fase se definen las partes interesadas en el sistema, se establecen los requisitos no funcionales, las propiedades e hipótesis del dominio y restricciones en las que se verá envuelto el proyecto. Fase IV: Especificación [Rol: Analista] Descripción de los casos de uso (requisitos funcionales) y realización del esquema conceptual y del modelo de comportamiento del sistema. 36 Fase V: Diseño, Implementación y Pruebas [Rol: Diseñador / Programador / Tester] En cuanto al diseño, se definirá la arquitectura del sistema, la distribución y función de cada capa, los diagramas de secuencia de cada caso de uso, el diagrama de clases y la estructura de la Base de Datos. La implementación se dividirá en dos partes, por un lado, se implementará la aplicación web, y una vez esté terminada, se desarrollará la aplicación para Android. Dado que esta fase será iterativa, las pruebas se harán al final de cada iteración, donde cada una de ellas significa una funcionalidad implementada. Al final de la fase se probará todo el sistema conjuntamente mediante un plan de pruebas para depurar errores y aumentar la calidad del producto final. Fase VI: Final [Rol: Jefe de proyecto] Finalmente, se revisa todo el trabajo realizado, se redactan las conclusiones y se muestran las desviaciones de la planificación inicial. El peso de tiempo de cada fase en el proyecto es el siguiente: Fases Duración % I. Análisis previo 68h 15,7% II. Gestión de proyectos 85h 19,7% III. Análisis de Requisitos 24h 5,5% IV. Especificación 47h 10,9% V. Diseño, Implementación y Pruebas 196h 45,4% VI. Final 12h 2,8% TOTAL 432h 100% Tabla 5: Duración y porcentaje de tiempo empleado por cada fase del proyecto A continuación se muestra el diagrama de Gantt de la planificación inicial. NOTAS SOBRE EL DIAGRAMA Hay un período previo en el que se trabajó en la Gestión de proyectos, donde se hizo una primera aproximación a las entregas. El período en el que se trabajará en la especificación es un proceso que implica iteraciones en las tareas que engloba ya que, por ejemplo, si se descubre un error en el mapa conceptual es posible que afecte a los casos de uso. La etapa de diseño, implementación y pruebas se hacen de forma iterativa, es decir, se irá diseñando, implementando y probando cada funcionalidad de forma individualizada. 37 Figura 30: Diagrama de Gantt de la planificación inicial 3.2. Diagrama de Gantt 38 3.3. Recursos humanos A continuación se describen, de forma resumida, qué tareas se llevan a cabo cuando se ejerce uno de los siguientes roles que estarán implicados en este proyecto:  Jefe de proyecto: Encargado de la planificación y supervisión de las tareas a desarrollar en un proyecto así como de la organización, coordinación y mediación de un equipo de recursos humanos.  Analista: Estudian los problemas actuales para proponer una solución óptima y acorde a los recursos disponibles. Proporcionan las funcionalidades que tendrá el sistema mediante el modelo de casos de uso, entre otra documentación.  Diseñador: En base a la documentación proporcionada por los analistas, se estructura y se define una arquitectura para el sistema que se debe desarrollar.  Programador: Se encargan de implementar el diseño propuesto por los diseñadores de una forma eficiente.  Tester: Prueban el sistema para detectar errores o recomendar modificaciones, deben realizar un informe después de cada prueba ejecutada. 3.4. Valoración de alternativas y plan de acción En la planificación inicial se han tenido en cuenta dos aspectos. Por un lado, se ha decidido dar más tiempo de lo que le suele corresponder a la fase de implementación ya que es la parte en la que creo que pueden aparecer problemas debido a la inexperiencia con la tecnología que se va a trabajar (aplicaciones web). Por otro lado, se ha acotado la realización del trabajo hasta la cuarta semana de Diciembre por lo que hay un margen de maniobra de hasta cuatro semanas más, en caso de que alguna tarea se desfasara. A continuación se muestran los posibles obstáculos que se pueden encontrar una vez se empiece a trabajar en el proyecto: Riesgo Gravedad Plan de contingencia Poca experiencia con tecnologías, herramientas de desarrollo y lenguajes de programación nuevos Media Se consultará información disponible en webs y se implementarán primero las funcionalidades menos complejas para adquirir experiencia. Aparición de nuevas funcionalidades (o cambios) Media Se intentarán definir todas las funcionalidades en la fase de requisitos. Si aparecieran nuevas, se valoraría el coste de incluirlas. Mala planificación Baja En las diferentes reuniones con el director, se evaluará si ha habido desviaciones y cómo se pueden corregir. Tabla 6: Valoración de riesgos y plan de contingencia En el caso de que se tenga que dedicar más tiempo de lo inicialmente planificado para alguna tarea, se realizará alguna de las siguientes acciones con el fin de no provocar una desviación muy grande de la planificación inicial: 1. Priorizar el trabajo imprescindible: Se dedicará más tiempo a solucionar problemas que afecten al conjunto del proyecto y se reducirán o suprimirán tareas secundarias. 2. Aumentar dedicación: Se aumentará el número de horas diarias dedicadas al proyecto. 39 4. Gestión económica 4.1. Identificación y estimación de los costes En esta sección se hace una estimación de los elementos que componen el presupuesto del proyecto teniendo en cuenta los recursos que se han utilizado. Dentro de los recursos, se incluyen las horas de trabajo dedicadas y el coste del hardware y software que se ha utilizado, entre otras partidas. 4.1.1. Recursos humanos Dado que este proyecto será desarrollado por una única persona, será necesario adoptar diferentes roles. A continuación se muestra una tabla con el precio por hora que cobra cada perfil implicado en el proyecto, las horas estimadas que se ejercerá el rol y el coste total. Recursos Rol €/h Estimación horas Total estimado David Castro Jefe de proyecto 50 €/h 165h 8.250€ Analista 40 €/h 71h 2.840€ Diseñador 35 €/h 60h 2.100€ Programador 25 €/h 104h 2.600€ Tester 20 €/h 32h 640€ TOTAL 432h 16.430€ Tabla 7: Presupuesto de recursos humanos Para la estimación de las horas de trabajo de cada rol, se han tenido en cuenta los días en los que el rol estará implicado en el proyecto (estableciendo un porcentaje de dedicación para etapas donde hay roles solapados) y asumiendo un trabajo diario de aproximadamente 4 horas. 4.1.2. Software Para realizar el proyecto ha sido necesario el uso de herramientas de software, la mayoría de ellas son gratuitas y son las que se han utilizado en diferentes asignaturas durante el Grado. 40 Producto Coste Vida útil Amortización total (5 meses) Windows 8.1 0€ (versión estudiante) - 0€ Microsoft Office 2013 119€ 3 años 16,53€ Eclipse 0€ - 0€ Google Chrome 0€ - 0€ Google Drive 0€ - 0€ Dropbox 0€ - 0€ OneDrive 0€ - 0€ Gantter 0€ - 0€ Enterprise Architect 0€ (versión Prueba) - 0€ Justinmind Prototyper 0€ (versión Prueba) - 0€ Balsamiq Mockups 0€ (versión Prueba) - 0€ TOTAL 16,53€ Tabla 8: Presupuesto de software 4.1.3. Hardware Para el desarrollo del software y la realización de la memoria, se ha utilizado un ordenador convencional, y para las pruebas de la aplicación móvil, un smartphone. Producto Coste Vida útil Amortización total estimada (5 meses) Ordenador sobremesa 500€ 5 años 41,67€ Smartphone 100€ 3 años 33,33€ TOTAL 75€ Tabla 9: Presupuesto de hardware 4.1.4. Gastos generales En este apartado se tienen en cuenta costes asociados a la realización del proyecto como pueden ser la energía eléctrica consumida o el acceso a Internet, la solicitud de una licencia para poder publicar las aplicaciones de Android en Google Play, la necesidad de contratar un servicio de hosting con una base de datos remota y un dominio para alojar la aplicación desarrollada y finalmente el coste de transporte para el desplazamiento a la Facultad para reuniones y presentaciones. 41 Producto/Servicio Coste Período Total estimado Energía eléctrica 0,15€/kWh*0,15kW 450h 10,13€ Transporte 6€ 5 meses 30€ Licencia desarrollador Android 19€ Indefinido 19€ Servidor y dominio (Hostinger.es) 2,26€ 2 meses 4,52€ Acceso a Internet 25€ 5 meses 125€ TOTAL 188,65€ Tabla 10: Gastos generales del desarrollo proyecto 4.1.5. Costes imprevistos El único coste imprevisto que podría surgir es un fallo en el ordenador utilizado para el desarrollo del proyecto; habría que añadir el coste de reparación que aproximadamente sería de 150€, y mientras estuviera inactivo se utilizaría un segundo ordenador para no retrasar las actividades planificadas. El riesgo de que ocurra este imprevisto es de un 15%. 4.1.6. Coste total del proyecto Concepto Coste Costes directos 16.430€ Costes indirectos 280,18€ Contingencia (5%) 835,51€ Costes imprevistos 22,50€ TOTAL (IVA incluido) 17.568,19€ Tabla 11: Resumen de costes del proyecto 4.2. Control de gestión Tal y como se ha explicado en apartados anteriores, diariamente se irá actualizando una tabla con las tareas realizadas en el día y el tiempo de dedicación. Con el fin de llevar un control de las horas que trabaja un rol concreto en un día; se creará una segunda tabla que se actualizará diariamente, tal y como muestra la siguiente tabla de ejemplo: Horas dedicadas Día Jefe de proyecto Analista Diseñador Programador Tester 18/09/2014 4h - - - - Tabla 12: Control de horas trabajadas por cada rol 48 o Pausar el tratamiento: si se interrumpe el tratamiento (debido a un accidente, hospital, urgencias, etc), se ha de poder pausar por cualquier parte interesada. o Programación de visitas: se podrán programar visitas para cualquier personal médico. o Programación de pruebas médicas: se programarán pruebas médicas y se deberá introducir el protocolo a seguir, en caso que sea necesario. o Información sobre el medicamento: enlaces al prospecto. 5.4. Análisis de tecnologías candidatas Para el sistema que se va a desarrollar, van a estar implicadas diferentes tecnologías. En este apartado se analizan las ventajas e inconvenientes de estas tecnologías y se detalla cuál es la mejor para cada tipo de usuario. Podemos agrupar a las partes involucradas en el sistema en dos grupos, por un lado, el personal sanitario que modifica datos del sistema constantemente, y por otro, los usuarios finales, pacientes y familiares de estos, que únicamente consultan la información disponible en el sistema y reciben avisos. 4 Los dispositivos móviles suelen usarse con un carácter lúdico y entretenimiento más que como una herramienta de trabajo. Además, suele haber otras aplicaciones que distraen la atención (juegos, notificaciones, etc). Tecnología Aspectos positivos Aspectos negativos Aplicación de escritorio Rendimiento Estabilidad Seguridad Compatibilidad con diferentes SO Requisitos hardware Actualización y mantenimiento Movilidad Concurrencia de usuarios Fragmentación Necesaria descarga e instalación Aplicación web Actualización y mantenimiento Consumen pocos recursos Movilidad Concurrencia de usuarios Acceso inmediato Independiente del SO No hay fragmentación Compatibilidad con navegadores Requiere conexión permanente Dependencia del servidor o BD Aplicación móvil Movilidad Fácil de usar Útil para consultar información Información unificada Requiere conexión permanente Tamaño de pantalla limitado Introducción intensiva de datos Compatibilidad con diferentes SO Dependencia de batería Dispositivos de entretenimiento4 Tabla 16: Aspectos positivos y negativos de diferentes tecnologías informáticas 49 Personal sanitario Dado que su función será introducir, modificar, eliminar y consultar datos e información de los pacientes, queda descartado el uso de una aplicación móvil para la interacción con el sistema. El uso de tablets y smartphones para manejar la información del sistema no sería eficiente, constantemente se reciben notificaciones y es fácil distraerse con otros elementos, además, la introducción de texto intensiva no es cómoda debido al tamaño de la pantalla, al alto número de errores tipográficos que se producen con un teclado virtual y al no tener un feedback de un dispositivo físico como el teclado tradicional. Una aplicación de escritorio o web serían ideales para interaccionar con el sistema, sin embargo, como hemos visto en la Tabla 16, el software tradicional de escritorio suele dar problemas a la hora de instalarlo y en el posterior mantenimiento. La presencia de múltiples usuarios concurrentes en el sistema también podría afectar si una de las partes no guarda los cambios en el servidor, que nutre a las diferentes partes interesadas y sus correspondientes aplicaciones de los datos. Por lo tanto, la aplicación web funcionará mejor permitiendo un acceso rápido, fácil y desde cualquier ordenador únicamente utilizando un navegador, manteniendo los datos siempre actualizados y con la posibilidad de solucionar errores (bugs) con mayor rapidez y eficiencia. Usuario final Las características de este tipo de usuarios hacen que cualquiera de las tecnologías sea útil para su rol dentro del sistema, no obstante, la única tecnología que permite recibir notificaciones en cualquier momento es una aplicación móvil. Para hacerlo en una aplicación de escritorio es necesario que el ordenador de sobremesa o portátil esté permanentemente encendido; en la aplicación web ocurre algo similar, y además debe estar el navegador en ejecución e identificado en la aplicación. Es cierto que se pueden desviar las notificaciones por correo electrónico o por SMS para que sean recibidas en un dispositivo móvil, pero la primera opción implica que el usuario tenga una aplicación de correo instalada, y para la segunda el usuario debería cargar con el coste del servicio. Para consultar información y recibir avisos hoy en día se utilizan las tablets y smartphones que suelen estar en funcionamiento permanente y cerca del usuario, por lo tanto, la mejor opción para los pacientes y los familiares de éste es una app. 5.5. Conclusiones del análisis inicial Teniendo un conocimiento más amplio del sector y funcionamiento actual de este, y considerando cómo se ha planteado el proyecto (como una mejora del servicio público de salud actual), el personal farmacéutico no intervendrá porque no será necesario. Por otra parte, se ha comprobado que el proyecto puede tener éxito si se tienen en cuenta los factores negativos (uso de nuevas tecnologías por colectivos no acostumbrados a usarlas, legalidad, etc.). 50 6. Requisitos 6.1. Propiedades e hipótesis sobre el dominio Para poder desarrollar este proyecto, se ha considerado necesario definir una serie de hipótesis, propiedades y expectativas sobre el uso del sistema. Hipótesis del dominio  Acceso a internet: Los usuarios tienen acceso a una conexión de Internet ADSL o móvil. Expectativas  Uso del sistema: Los usuarios utilizarán el sistema para la finalidad que ha sido creado sin hacer un mal uso o emprendiendo acciones maliciosas para romper la integridad del sistema. De todas formas, se implementarán medidas de seguridad para que agentes externos intervengan.  Introducción de datos correcta: El personal médico tendrá la responsabilidad de revisar la información que han introducido en el plan de medicación del paciente, ya que un error puede causar consecuencias graves en la salud del paciente.  Realizar el seguimiento del plan de medicación: El objetivo principal por el que ha sido creado el sistema es para que los pacientes minimicen los olvidos y los errores al ingerir medicamentos, por lo tanto se espera que colaboren manteniendo actualizados los datos marcando la medicación como tomada cuando lo indique la aplicación.  Veracidad de los datos: Es responsabilidad del paciente (y del supervisor) introducir datos verídicos en la aplicación (Ej. Marcar como tomada una medicación que realmente no se ha llegado a ingerir) dado que el sistema no dispone de mecanismos suficientes de validación de datos para controlar este aspecto.  El supervisor lleva a cabo su rol correctamente: La tarea del supervisor es velar por el cumplimiento del tratamiento diagnosticado por el médico a la persona supervisada. Dado que recibirá notificaciones cuando se considere que el paciente está olvidando la medicación, debe tomar las medidas necesarias para asegurarse que finalmente el paciente sigue correctamente el tratamiento. 6.2. Restricciones Restricción de solución Descripción La versión del sistema para el personal médico será desarrollada como una aplicación web. Justificación Únicamente es necesario un ordenador con navegador, los requisitos para funcionar son mínimos y no hay que hacer una inversión para instalar el producto. Tabla 17: Restricción de solución (personal médico) 51 Restricción de solución Descripción La versión del sistema para los pacientes será desarrollada como una aplicación móvil Android. Justificación Los dispositivos móviles suelen estar las 24h encendidos y disponibles para su uso, además en los últimos años se ha extendido el uso de internet móvil por lo que son capaces de recibir avisos externos. En cuanto al sistema operativo, dado la limitación temporal de este trabajo y a que tiene una cuota de mercado muy grande en España se ha optado por la implementación en Android, aunque no se descartan otros sistemas en el futuro. Tabla 18: Restricción de solución (paciente) Restricción temporal Descripción El sistema tiene que estar acabado la primera quincena de Enero. Justificación Se establece una fecha límite para presentar el proyecto. Tabla 19: Restricción temporal Restricción de presupuesto Descripción El desarrollo del proyecto se realiza sin ningún coste económico. Justificación Como no se dispone de ninguna inversión económica y el proyecto se desarrolla en un entorno académico las herramientas y servicios utilizados supondrán un coste muy bajo. Tabla 20: Restricción de presupuesto 52 6.3. Diagrama de casos de uso Figura 31: Diagrama de casos de uso 5 5 Los casos de uso marcados con una línea azul pertenecen únicamente al usuario paciente. uc Modelo casos uso Paciente Médico Supervisor Login médico Login paciente Logout Consultar próximas visitas Consultar pacientes visitados Consultar tratamiento Entrar al modo edición Consultar historial Consultar seguimiento medicamento Consultar plan medicación Activar notificaciones medicamento Desactivar notificaciones medicamento Añadir supervisor Eliminar supervisor Login supervisor Sustituir línea receta Archivar línea receta Añadir línea receta Intercambiar interfaz Silenciar notificaciones medicamento Desactivar silencio notificaciones medicamento Consultar notificaciones desatendidas Indicar cantidad restante medicamento 53 6.4. Casos de uso Caso de uso #01 Login médico Actor principal Médico Precondición El usuario está registrado en el sistema. Disparador El usuario quiere iniciar sesión en el sistema. Escenario principal de éxito 1. El usuario introduce el nombre de usuario, su DNI y la contraseña e indica al sistema que quiere identificarse. 2. El sistema valida los datos, identifica al usuario y le pide que introduzca el nombre del centro médico y la especialidad que va a trabajar en la sesión. 3. El usuario selecciona el centro médico y la especialidad. 4. El sistema valida los datos y redirige al usuario a la pantalla de próximas visitas. Extensiones 2.a El sistema detecta algún error en los campos introducidos. 2.a.1 El sistema notifica al usuario que hay datos incorrectos. 2.a.2 Se vuelve al paso 1. 4.a El sistema detecta alguna incoherencia en los campos introducidos. 4.a.1 El sistema notifica al usuario que hay datos incorrectos. 4.a.2 Se vuelve al paso 3. Tabla 21: Definición del caso de uso Login médico Caso de uso #02 Login paciente Actor principal Paciente Precondición El usuario está registrado en el sistema. Disparador El usuario quiere iniciar sesión en el sistema. Escenario principal de éxito 1. El usuario introduce su código de identificación personal (CIP) de su tarjeta sanitaria y la contraseña. 2. El sistema valida los datos, identifica al usuario y lo redirige a la pantalla principal. Extensiones 1.a El usuario inicia sesión por primera vez en el sistema y no dispone de contraseña. 1.a.1 El sistema pide que el usuario defina una contraseña para acceder al sistema. 1.a.2 El usuario introduce el contraseña. 1.a.3 El sistema guarda los datos y acaba el caso de uso. 2.a El sistema detecta algún error en los campos introducidos. 2.a.1 El sistema notifica al usuario que algún campo es incorrecto o está vacío. 2.a.2 Se vuelve al paso 1. Tabla 22: Definición del caso de uso Login paciente 54 Caso de uso #03 Login supervisor Actor principal Supervisor Precondición El usuario tiene un código activo. Disparador El usuario quiere iniciar sesión en el sistema. Escenario principal de éxito 1. El usuario introduce su DNI y el código de acceso. 2. El sistema valida los datos, identifica al usuario y lo redirige a la pantalla principal. Extensiones 2.a El sistema detecta algún error en los campos introducidos. 2.a.1 El sistema notifica al usuario que algún campo es incorrecto o está vacío. 2.a.2 se vuelve al paso 1. Tabla 23: Definición del caso de uso Login supervisor Caso de uso #04 Logout Actor principal Médico, Paciente, Supervisor Precondición El usuario está identificado en el sistema. Disparador El usuario quiere cerrar sesión en el sistema. Escenario principal de éxito 1. El usuario indica al sistema que quiere cerrar sesión. 2. El sistema elimina todos los datos del usuario, cierra la sesión del usuario y lo redirige a la correspondiente pantalla de identificación (login). Tabla 24: Definición del caso de uso Logout Caso de uso #05 Consultar próximas visitas Actor principal Médico Precondición El usuario está identificado en el sistema. Disparador El usuario quiere ver los próximos pacientes a los que debe visitar en el día de hoy. Escenario principal de éxito 1. El usuario quiere ver las próximas visitas del día. 2. El sistema busca la información de los próximos pacientes y la muestra. Extensiones 2.a El sistema no encuentra ninguna visita. 2.a.1 El sistema muestra un aviso al usuario y acaba el caso de uso. Tabla 25: Definición del caso de uso Consultar próximas visitas Caso de uso #06 Consultar pacientes visitados Actor principal Médico Precondición El usuario está identificado en el sistema. Disparador El usuario quiere ver los pacientes que ha visitado en el día de hoy. Escenario principal de éxito 1. El usuario quiere ver los pacientes que ha visitado durante el día. 2. El sistema busca la información de los pacientes y la muestra. Extensiones 2.a El sistema no encuentra ninguna visita. 2.a.1 El sistema muestra un aviso al usuario y acaba el caso de uso. Tabla 26: Definición del caso de uso Consultar pacientes visitados 55 Caso de uso #07 Consultar tratamiento Actor principal Médico Precondición El usuario está identificado en el sistema y el médico tiene una visita programada con el paciente para el día de hoy. Disparador El usuario quiere ver el tratamiento que está siguiendo el paciente. Escenario principal de éxito 1. El usuario selecciona la visita de un paciente. 2. El sistema muestra los datos del tratamiento actual del paciente. Tabla 27: Definición del caso de uso Consultar tratamiento Caso de uso #08 Entrar al modo edición Actor principal Médico Precondición El usuario está identificado en el sistema y está consultando el tratamiento actual de un paciente. Disparador El usuario quiere entrar al modo edición para hacer modificaciones en el tratamiento actual del paciente. Escenario principal de éxito 1. El usuario indica que quiere entrar al modo edición del tratamiento que está visualizando. 2. El sistema muestra la pantalla donde se muestran los controles para editar el tratamiento de un paciente. Tabla 28: Definición del caso de uso Entrar al modo edición Caso de uso #09 Consultar historial Actor principal Médico Precondición El usuario está identificado en el sistema y está consultando el tratamiento actual de un paciente. Disparador El usuario quiere consultar el historial de medicamentos que el paciente ha tomado durante un período de tiempo. Escenario principal de éxito 1. El usuario indica que quiere consultar el historial de medicamentos recetados. 2. El sistema muestra los medicamentos, la fecha, el prescriptor y centro donde fueron recetados desde el 1 de Enero del año actual hasta la fecha de hoy (por defecto). Extensiones 2.a El sistema no encuentra ningún dato. 2.a.1 El sistema muestra un aviso al usuario y se acaba el caso de uso. 2.b El usuario modifica el rango de fechas. 2.b.1 El sistema comprueba que el rango de fechas es válido y muestra los medicamentos que se le han recetado al paciente durante ese período. 2.c. El usuario indica que quiere ver más detalles de algún medicamento del historial. 2.c.1 El sistema muestra un diálogo emergente con todos los datos disponibles para el medicamento indicado. 2.d El usuario quiere ver el seguimiento del paciente de un medicamento del historial. 2.d.1 El sistema muestra la pantalla de seguimiento del medicamento seleccionado. Tabla 29: Definición del caso de uso Consultar historial 56 Caso de uso #10 Consultar seguimiento medicamento Actor principal Médico Precondición El usuario está identificado en el sistema y está consultando el tratamiento actual de un paciente o el historial de medicamentos recetados. Disparador El usuario quiere ver el seguimiento que un paciente ha hecho de un determinado medicamento. Escenario principal de éxito 1. El usuario indica al sistema que quiere consultar el seguimiento del paciente de un medicamento. 2. El sistema muestra un calendario con la información de seguimiento hasta el momento de la consulta. Tabla 30: Definición del caso de uso Consultar seguimiento de un medicamento Caso de uso #11 Sustituir línea receta Actor principal Médico Precondición El usuario está identificado en el sistema y está en el modo edición. Disparador El usuario quiere modificar los datos de un medicamento recetado previamente. Escenario principal de éxito 1. El usuario indica que quiere modificar los datos de la receta de un medicamento. 2. El sistema muestra los campos de la receta de un medicamento en formato editable. 3. El usuario modifica los datos que considera necesarios e indica que quiere guardar los datos. 4. El sistema comprueba la información introducida, la actualiza y deja los campos en un formato no editable. Extensiones 4.a El sistema detecta que algún dato es incorrecto o está vacío. 4.a.1 El sistema muestra un aviso al usuario y se vuelve al paso 2. Tabla 31: Definición del caso de uso Sustituir línea receta Caso de uso #12 Archivar línea receta Actor principal Médico Precondición El usuario está identificado en el sistema y está en el modo edición. Disparador El usuario quiere archivar un medicamento del tratamiento actual del paciente. Escenario principal de éxito 1. El usuario indica que quiere archivar un medicamento del tratamiento actual del paciente. 2. El sistema muestra un diálogo de confirmación de la eliminación. 3. El usuario confirma la eliminación. 4. El sistema archiva el medicamento y actualiza su fecha de vigencia. Extensiones 3.a El usuario cancela la eliminación 3.a.1 Se acaba el caso de uso Tabla 32: Definición del caso de uso Archivar línea receta 57 Caso de uso #13 Añadir línea receta Actor principal Médico Precondición El usuario está identificado en el sistema y está en el modo edición. Disparador El usuario quiere añadir un medicamento al tratamiento actual del paciente. Escenario principal de éxito 1. El usuario indica que quiere añadir un nuevo medicamento. 2. El sistema añade una nueva línea de receta con los campos vacíos en formato editable. 3. El usuario rellena los datos e indica que quiere guardarlos. 4. El sistema comprueba los datos y los guarda. Extensiones 4.a El sistema detecta que algún dato es incorrecto o está vacío. 4.a.1 El sistema muestra un aviso al usuario y se vuelve al paso 2. Tabla 33: Definición del caso de uso Añadir línea receta Caso de uso #14 Consultar plan medicación Actor principal Paciente, Supervisor Precondición El usuario está identificado Disparador El usuario quiere consultar los medicamentos y la información de su plan de medicación o realizar cambios en la configuración de las notificaciones. Escenario principal de éxito 1. El usuario indica que quiere consultar los datos de su plan de medicación. 2. El sistema muestra los medicamentos del plan de medicación vigente. 3. El usuario selecciona uno de los medicamentos para ver más información. 4. El sistema muestra los datos. Tabla 34: Definición del caso de uso Consultar plan de medicación 64 Requisito no funcional #9 Descripción La aplicación para dispositivos móviles mostrará las notificaciones con un desfase de menos de cinco minutos en condiciones normales. Justificación Para no provocar errores en el sistema hay que asegurar que los usuarios reciben las notificaciones en el tiempo justo sin demasiada demora. Criterio de satisfacción Se realizarán tests para medir el tiempo de recepción de las notificaciones. Satisfacción del usuario 3 Insatisfacción del usuario 5 Prioridad Alta Tabla 52: Requisito de latencia para mostrar las notificaciones Requisitos de disponibilidad y fiabilidad Requisito no funcional #10 Descripción El sistema estará disponible las 24 horas del día, los 365 días del año. Justificación Dado que el sistema recibe modificaciones constantemente y se espera un uso masivo, debe poder responder las solicitudes y estar disponible en cualquier momento. Criterio de satisfacción El sistema tiene que tener una tasa de tiempo en funcionamiento mayor al 95%. Satisfacción del usuario 3 Insatisfacción del usuario 5 Prioridad Alta Tabla 53: Requisito de disponibilidad y fiabilidad Requisitos de capacidad Requisito no funcional #11 Descripción El sistema tendrá que ser escalable para atender solicitudes según la demanda. Justificación Si el uso empieza a ser masivo, el servidor tendrá que soportar gran cantidad de peticiones sin que se colapse. Criterio de satisfacción Se efectuarán tests de fuerza para comprobar la capacidad del servidor y buscar alternativas en caso de que no cumpliera los requisitos mínimos. Satisfacción del usuario 1 Insatisfacción del usuario 5 Prioridad Media Tabla 54: Requisito de escalabilidad 65 Requisito no funcional #12 Descripción El sistema tiene que tener capacidad para almacenar 1TB de información. Justificación Si el uso es masivo, se espera que el tamaño de los datos de cada usuario aumente progresivamente. Criterio de satisfacción El servidor tendrá capacidad para almacenar 1TB de información. Satisfacción del usuario 1 Insatisfacción del usuario 1 Prioridad Baja Tabla 55: Requisito de capacidad 6.5.4. Requisitos de funcionamiento y ambientales Requisitos de producción Requisito no funcional #13 Descripción Estadísticas de uso del sistema. Justificación Se debe poder visualizar la cantidad de usuarios del sistema. Criterio de satisfacción El sistema registrará cuantos usuarios lo utilizan. Satisfacción del usuario 1 Insatisfacción del usuario 1 Prioridad Baja Tabla 56: Requisito de producción Requisitos de lanzamiento Requisito no funcional #14 Descripción Se informará de los períodos de mantenimiento del sistema. Justificación Para que los usuarios tengan conocimiento de los períodos en que el sistema no podrá ser usado, se les avisará previamente. Criterio de satisfacción Se enviará/publicará un aviso para todos los usuarios informando del tiempo en que no será posible utilizar el sistema. Satisfacción del usuario 4 Insatisfacción del usuario 4 Prioridad Media Tabla 57: Requisito de información de mantenimiento Requisito no funcional #15 Descripción El sistema no causará fallos cuando se actualice. Justificación Es importante que cuando la aplicación web o móvil se actualice siga funcionando correctamente. Criterio de satisfacción Se realizarán pruebas previas a la liberación de la actualización para asegurar que no se producen errores. Satisfacción del usuario 1 Insatisfacción del usuario 4 Prioridad Media Tabla 58: Requisito de lanzamiento de actualizaciones 66 Requisitos ambientales Requisito no funcional #16 Descripción El proyecto y el sistema final son sostenibles. Justificación La realización de este trabajo debe tener un impacto positivo en el entorno (ambientalmente, socialmente y económicamente). Criterio de satisfacción Se realizará un informe de sostenibilidad basado en las ideas de ‘La economía del bien común’ de Christian Felber. Satisfacción del usuario 1 Insatisfacción del usuario 2 Prioridad Media Tabla 59: Requisito ambiental de sostenibilidad 6.5.5. Requisitos de mantenimiento y soporte Requisitos de mantenimiento Requisito no funcional #17 Descripción El sistema lo mantendrá un administrador. Justificación El sistema tiene que estar supervisado por un administrador para prevenir y resolver incidencias, registrar usuarios, etc. Criterio de satisfacción El sistema está gestionado por un administrador. Satisfacción del usuario 1 Insatisfacción del usuario 2 Prioridad Alta Tabla 60: Requisito de mantenimiento Requisito no funcional #18 Descripción El sistema debe ser flexible a futuros cambios y a la incorporación de nuevas funcionalidades. Justificación Se tienen que poder añadir nuevas funciones o modificar las actuales para mejorar el sistema. Criterio de satisfacción El sistema dispone de documentación para administradores y desarrolladores con toda la información necesaria para facilitar el soporte del sistema. Satisfacción del usuario 2 Insatisfacción del usuario 1 Prioridad Alta Tabla 61: Requisito de flexibilidad a cambios Requisitos de soporte Requisito no funcional #19 Descripción El sistema dispone de una sección de ayuda. Justificación Siempre es necesario facilitarle una sección de ayuda al usuario para que resuelva dudas, conozca el funcionamiento del sistema o disponga de datos de contacto con el soporte técnico o los desarrolladores. Criterio de satisfacción Se incluye una sección de ayudas en las aplicaciones del sistema. Satisfacción del usuario 1 Insatisfacción del usuario 2 Prioridad Baja Tabla 62: Requisito de soporte 67 Requisitos de adaptabilidad Requisito no funcional #20 Descripción La aplicación web se podrá utilizar correctamente en los navegadores web más utilizados: Internet Explorer, Mozilla Firefox y Google Chrome. Justificación El sistema debe funcionar correctamente en los navegadores web más populares para permitir a los usuarios usar su software preferido sin causarle ningún problema. Criterio de satisfacción Se comprobará que se pueda utilizar y visualizar correctamente. Satisfacción del usuario 1 Insatisfacción del usuario 5 Prioridad Media Tabla 63: Requisito de adaptabilidad 6.5.6. Requisitos de seguridad Requisitos de integridad Requisito no funcional #21 Descripción El sistema tiene que definir restricciones para garantizar la integridad de los datos y del propio sistema. Se realizarán copias de seguridad y un dietario para una posible recuperación de los datos. Justificación El sistema debe poder recuperarse de un fallo ejecutando las últimas acciones que ha recibido en la copia de seguridad restaurada. Criterio de satisfacción El sistema realiza copias de seguridad diarias y mantiene un dietario de las acciones recibidas por el sistema. Satisfacción del usuario 1 Insatisfacción del usuario 1 Prioridad Alta Tabla 64: Requisito de integridad Requisitos de privacidad Requisito no funcional #22 Descripción El sistema informará a los usuarios de la política de privacidad de los datos que se tiene. Justificación Los usuarios tienen que saber que los datos que introducen en el sistema se guardan de forma segura y pueden confiar en el uso del sistema. Criterio de satisfacción El sistema permitirá a los usuarios consultar la política de privacidad del sistema. Satisfacción del usuario 2 Insatisfacción del usuario 5 Prioridad Alta Tabla 65: Requisito de privacidad 68 Requisitos de inmunidad Requisito no funcional #23 Descripción El sistema estará protegido contra ataques informáticos como SQL Injection, DDoS, Brute Force, etc. Justificación Los ataques informáticos ponen en riesgo el correcto funcionamiento del sistema por lo que se deben establecer medidas de seguridad para evitarlos. Criterio de satisfacción El sistema no presentará trazas que indiquen la infección mientras se está efectuando un ataque. Satisfacción del usuario 1 Insatisfacción del usuario 1 Prioridad Alta Tabla 66: Requisito de inmunidad 6.5.7. Requisitos legales Requisitos de cumplimiento Requisito no funcional #24 Descripción Todos los datos de carácter personal de los usuarios serán tratados según establece la LOPD y la Directiva de Protección de Datos 95/46 de la Unión Europea. Justificación El sistema tiene que respetar las leyes de protección de datos al manejar datos muy sensibles. Criterio de satisfacción Un abogado se encargará de asesorar las medidas que hay que tomar y confirmar que el sistema cumple las leyes de protección de datos. Satisfacción del usuario 1 Insatisfacción del usuario 5 Prioridad Alta Tabla 67: Requisito de cumplimiento 69 7. Especificación 7.1. Esquema conceptual Figura 32: Esquema conceptual 7.1.1. Restricciones de clave externa  (Paciente: cipPaciente)  (Médico: numCol)  (Especialidad: nombreEspecialidad)  (CentroMédico: nombreCentro)  (Fecha: fecha, hora)  (Medicamento: idMedicamento)  (ImagenMedicamento: idImagen) class Esquema conceptual ffg aaa Legend Usuario - idioma :Idioma Supervisor - dniSupervisor :string - códigoSupervisor :string Paciente - cipPaciente :string - password :string [0..1] - nombrePaciente :string - fechaNacimiento :Date - interfazEspecial :boolean Médico - numCol :int - username :string - dni :string - password :string - nombreMédico :string Medicamento - idMedicamento :int - nombreMedicamento :string - cantidadEnvase :int CentroMédico - nombreCentro :string LíneaReceta - dosis :int - formaDosis :string - frecuencia :int - tipoFrecuencia :Frecuencia - fechaInicioVigencia :Date - fechaFinVigencia :Date - /duraciónVigencia :int - comentarios :string - crónico :bool Alarma - fecha :Date - hora :Time - tomado :boolean - fechaTomado :Date [0..1] - horaTomado :Time [0..1] «enumeration» Idioma Español Català English «enumeration» Frecuencia Horas Días ImagenMedicamento - idImagen :int - imagen :BLOB «enumeration» NombreEspecialidad Alergología Anestesiología y reanimación Cardiología Gastroenterología Endocrinología Geriatría Hematología y hemoterapia Hidrología médica Infectología Medicina aeroespacial Medicina del deporte Medicina del trabajo Medicina de urgencias Medicina familiar y comunitaria Medicina intensiva Medicina interna Medicina legal y forense Medicina preventiva y salud pública Nefrología Neumología Neurología Nutriología Odontología Oftalmología Oncología médica Oncología radioterápica Otorrinolaringología Pediatría Proctología Psiquiatría Rehabilitación Reumatología Traumatología Toxicología Urología Fecha - fecha :Date - hora :Time Notificación - fechaActivación :Date - horaActivación :Time - fechaInicioTratamiento :Date - horaInicioTratamiento :Time - /fechaFinTratamiento :Date - /horaFinTratamiento :Time - comentario :string - /cantidadRestante :int Especialidad - nombreEspecialidad :NombreEspecialidad MédicoEspecialista MédicoCentro TieneVisita Visita - visitado :bool 1 Genera * * * TrabajaEn * * * TieneAsociado 1 1 Tiene 0..1 * EsDe 1 1 TieneAsociada * * Tiene 1..* * {disjoint, complete} 0..1 SupervisaA 1..* 70 7.1.2. Restricciones de integridad textuales  Una línea-receta sólo puede existir si el paciente tiene una visita con el médico.  Un paciente no puede tener visita con distintos médicos en una misma fecha y hora.  Un médico sólo puede tener una visita con un paciente en una misma fecha y hora.  No puede haber una visita con un mismo paciente, fecha y hora y médico-centro con una línea-receta de un mismo medicamento.  Sólo puede haber una línea-receta 'vigente' de un mismo medicamento. (La línea-receta 'vigente' es la que tiene la fecha y hora más actual).  La fechaInicioVigencia de una línea-receta tiene que ser anterior a la fechaFinVigencia.  Una fechaInicioTratamiento tiene que ser igual o posterior a la fechaInicioVigencia.  Una horaInicioTratamiento tiene que ser igual o posterior a la hora de la visita.  No puede haber una alerta con fecha y hora posterior a fechaFinTratamiento y horaFinTratamiento.  Una alerta sólo puede tener valor definido en los atributos fechaTomado y horaTomado si el atributo tomado es true.  Si la línea-receta es de un medicamento crónico la fechaFinTratamiento es fechaFinVigencia.  La fechaInicioTratamiento sólo puede ser 5 días posterior a fechaInicioVigencia para un medicamento no crónico.  La fechaFinTratamiento sólo puede ser 5 días posterior a fechaFinVigencia para un medicamento no crónico. 7.1.3. Información derivada  /duraciónVigencia: El número de días que se debe tomar un medicamento recetado. Se calcula en base a fechaInicioVigencia y fechaFinVigencia.  /cantidadRestante: La cantidad restante de un medicamento se calcula a partir de la cantidadEnvase de un medicamento y se va decrementando según la dosis de la líneareceta asociada al medicamento cuando se marca como tomado. Su valor se restablece a cantidadEnvase cuando llega a 0 (se envía un aviso informativo al paciente cuando el valor es inferior a 5).  /fechaFinTratamiento: La fecha en la que se dejará de recibir notificaciones se calcula a partir de la duraciónVigencia de una línea-receta y la fechaInicioTratamiento.  /horaFinTratamiento: La hora en la que se dejará de recibir notificaciones se calcula a partir de la fechaFinTratamiento y la horaInicioTratamiento. 71 7.1.4. Descripción de las entidades Usuario Usuario del sistema. Atributo Descripción idioma Idioma en el que se mostrará la información (Español, Catalán o Inglés) Tabla 68: Atributos de la clase Usuario Paciente Usuario del sistema con rol de paciente. Atributo Descripción cipPaciente Código de Identificación Personal de la tarjeta sanitaria del paciente password Contraseña definida por el paciente para entrar al sistema nombrePaciente Nombre del paciente fechaNacimiento Fecha de nacimiento del paciente interfazEspecial Indica si el paciente ha activado o no la interfaz especializada para personas mayores en la aplicación móvil. Tabla 69: Atributos de la clase Paciente Supervisor Usuario del sistema con rol de supervisor de un paciente. Atributo Descripción dniSupervisor DNI del supervisor códigoSupervisor Código de acceso de un supervisor al sistema Tabla 70: Atributos de la clase Supervisor Médico Usuario del sistema con rol de médico. Atributo Descripción numCol Número de colegiado username Nombre de usuario del médico dni DNI del médico password Contraseña nombreMédico Nombre y apellidos del médico Tabla 71: Atributos de la clase Médico 72 CentroMédico Representa el centro donde trabaja un médico. Atributo Descripción nombreCentro Nombre del centro médico Tabla 72: Atributos de la clase CentroMédico Especialidad Representa la especialidad médica que ejerce un médico. Atributo Descripción nombreEspecialidad Nombre de la especialidad médica Tabla 73: Atributos de la clase Especialidad MédicoEspecialista Representa la especialidad con la que un médico va a realizar las visitas. MédicoCentro Representa la especialidad y el centro médico donde un médico va a realizar las visitas. Fecha Representa la fecha y hora de una visita. Visita Representa una visita de un paciente con un médico en un día y hora. Atributo Descripción visitado Indica si un paciente ha sido ya visitado Tabla 74: Atributos de la clase Visita 73 LíneaReceta Representa la receta hecha por un médico de un medicamento y las instrucciones del tratamiento a seguir por el paciente. Atributo Descripción dosis Cantidad de medicamento que se debe utilizar (Ej. 3, 1y ½…) formaDosis Tipo de dosis (Ej. Unidad, Aplicación, Cucharada…) frecuencia Número de veces que se debe utilizar un medicamento. tipoFrecuencia Período entre cada dosis (Ej. Horas, Días…) fechaInicioVigencia Fecha en la que empieza la vigencia del tratamiento fechaFinVigencia Fecha en la que finaliza la vigencia del tratamiento /duraciónVigencia Duración de la vigencia del tratamiento expresada en días comentarios Instrucciones del médico adicionales para el paciente crónico Indica si la medicación es crónica (tiene un período de vigencia de 12 meses) Tabla 75: Atributos de la clase LíneaReceta Notificación Representa el momento en que se activa la notificación de un medicamento. Atributo Descripción fechaActivación Fecha en la que se han activado por primera vez las notificaciones de un medicamento horaActivación Hora en la que se han activado por primera vez las notificaciones de un medicamento fechaInicioTratamiento Fecha en la que se ha empezado/se va a empezar a tomar un medicamento horaInicioTratamiento Hora en la que se ha empezado/se va a empezar a tomar un medicamento. /fechaFinTratamiento Fecha límite en la que se dejará de tomar un medicamento y de recibir alertas /horaFinTratamiento Hora límite en la que se dejará de tomar un medicamento y de recibir alertas comentario Comentarios personales del usuario sobre un medicamento activo7 Indica si las alertas están activadas silencio7 Indica si las alertas están silenciadas /cantidadRestante Cantidad de medicamento restante Tabla 76: Atributos de la clase Notificación 7 Atributo utilizado en la base de datos local (sqlite) del dispositivo Android 80 Consultar historial context Sistema::consultarHistorial(cip: string, fI: Date, fF: Date) :Set(TupleType(idMed: int, f: Date, mc: MédicoCentro, d: int, fD: string, fr: int, tF: string, fIVig: Date, fFVig: Date, dur: int, c: string, cr: bool) pre El usuario está identificado en el sistema fI no está vacío fF no está vacío post El usuario ve la pantalla y los datos del historial de medicamentos recetados al Paciente con cipPaciente = cip en el período de fechas definido por fI y fF. Consultar seguimiento medicamento context Sistema::seguimientoMedicamento(cip: string, idMed: int) : TupleType(n: Notificación, Set(a: Alarma)) pre El usuario está identificado en el sistema El usuario ve la pantalla de consultar plan de medicación o el historial post El usuario ve la pantalla y los datos de seguimiento de un medicamento. sd Consultar historial :Médico :Sistema consultarHistorial(cip, fI, fF) :Set(TupleType(idMed, f, mc, d, fD, fr, tF, fIVig, fFVig, dur, c, cr) sd Ver seguimiento medicamento :Médico :Sistema seguimientoMedicamento(cip, idMed) :TupleType(n, Set(a)) 81 Sustituir línea receta context Sistema::sustituirLíneaReceta(cip: string, mc: MédicoCentro, f: Fecha, idMed: int, nuevomc: MédicoCentro, nuevaf: Fecha, d: int, fD: string, fr: int, tF: string, fIVig: Date, fFVig: Date, c: string, cr: bool) pre El usuario está identificado en el sistema El usuario ha entrado en el modo edición post Se ha creado una instancia de LíneaReceta nuevaLR con dosis = d, formaDosis = fD, frecuencia = fr, tipoFrecuencia = tF, fechaInicioVigencia = fIVig, fechaFinVigencia = fFVig, comentarios = c y crónico = cr LR se ha asociado con la Receta (cip, nuevomc.numCol, nuevomc.nombreEspecialidad, nuevomc.nombreCentro, nuevaf.fecha, nuevaf.hora) LR se ha asociado con el Medicamento idMedicamento = idMed La instancia de LíneaReceta LR identificada por (cip, mc.numCol, mc.nombreEspecialidad, mc.nombreCentro, f.fecha, f.hora) tiene el atributo fechaFinVigencia = Date.today() sd Sustituír línea receta :Médico :Sistema sustituirLíneaReceta(cip, mc, f, idMed, nuevomc, nuevaf, d, fD, fr, tF, fIVig, fFVig, c, cr) 82 Archivar línea receta context Sistema::archivarLíneaReceta(cip: string, f: Fecha, mc: MédicoCentro, idMed: int) pre El usuario está identificado en el sistema El usuario ha entrado en el modo edición post La LíneaReceta LR identificada por (cip, f.fecha, f.hora, mc.numCol, mc.nombreEspecialidad, mc.nombreCentro, idMed) tiene LR.fechaFinVigencia = Date.today() Añadir línea receta context Sistema::añadirLíneaReceta(cip: string, mc: MédicoCentro, f: Fecha, idMed: int, d: int, fD: string, fr: int, tF: string, fIVig: Date, fFVig: Date, c: string, cr: bool) pre El usuario está identificado en el sistema El usuario ha entrado en el modo edición idMed no está vacío d no está vacío fD no está vacío fr no está vacío tF no está vacío fIVig no está vacío fFVig no está vacío sd Archivar línea receta :Médico :Sistema archivarLíneaReceta(cip, f, mc, idMed) sd Añadir línea receta :Médico :Sistema añadirLíneaReceta(cipPaciente, mc, f, nMed, d, tD, fr, tF, dur, fIVig, fFVig, c) 83 cr no está vacío post Se ha creado una instancia de LíneaReceta LR con dosis = d, formaDosis = fD, frecuencia = fr, tipoFrecuencia = tF, fechaInicioVigencia = fIVig, fechaFinVigencia = fFVig, comentarios = c, crónico = cr LR se ha asociado con el Medicamento idMedicamento = idMed LR se ha asociado con la Receta (cip, nuevomc.numCol, nuevomc.nombreEspecialidad, nuevomc.nombreCentro, nuevaf.fecha, nuevaf.hora) Consultar plan medicación context Sistema::consultarPlanMedicación(cip: string) :TupleType(idMed: int, d: int, fD: string, fr: int, tF: string, mc: MédicoCentro, dur: int, fIVig: Date, fFVig: Date, c: string, cr: bool) pre El usuario está identificado en el sistema post El usuario ve la pantalla y los datos de su plan de medicación. sd Consultar plan medicación :Paciente :Sistema consultarPlanMedicación(cip) :TupleType(idMed, d, tD, fr, tF, mc, dur, fIVig, fFVig, c, cr) 84 Activar notificaciones medicamento sd Activar notificaciones medicamento :Paciente :Sistema opt [not exists Notificación] [exists Notificación] loop [activo == true and fechaFinTratamiento válida and horaFinTratamiento válida] opt [descartar] [posponer] [tomar medicación] opt [hora - horaTomado <= 2 or hora - horaTomado > 2 and reprogramar == false] [hora - horaTomado > 2 and reprogramar == true] activarNotificacionesMedicamento(lr, fA, hA, fIT, hIT, c) reActivarNotificacionesMedicamento(lr, c) alarmaMedicaciónProgramada(a) descartarNotificación(aD) posponerNotificación(aP) tomarMedicación(aT) tromarMedicaciónReprogramar(aTR) 85 context Sistema::activarNotificacionesMedicamento(lr: LíneaReceta, fA: Date, hA: Time, fIT: Date, hIT: Time, c: string) pre El usuario está identificado en el sistema No existe ninguna instancia de Notificación asociada a la LíneaReceta lr post Se ha creado una nueva instancia de Notificación N asociada a la LíneaReceta lr con fechaActivación = fA, horaActivación = hA, fechaInicioTratamiento = fIT, horaInicioTratamiento = hIT, comentario = c, activo = true, silencio = false context Sistema::reActivarNotificacionesMedicamento(lr: LíneaReceta, c: string) pre El usuario está identificado en el sistema Existe una instancia de Notificación asociada a la LíneaReceta lr post La instancia de Notificación asociada a la LíneaReceta lr, tiene comentario = c, activo = true, silencio = false context Sistema::alarmaMedicaciónProgramada(a: Alarma) pre El usuario está identificado en el sistema El usuario tiene las notificaciones activadas de alguna línea-receta válida La fechaFinTratamiento y horaFinTratamiento son válidas post El sistema envía una notificación al dispositivo del usuario con los datos de la medicación context Sistema::descartarNotificación(aD: Alarma) pre Se ha recibido una notificación Se ha seleccionado la opción de descartar notificación post El sistema almacena la información de la Alarma aD context Sistema::posponerNotificación(aP: Alarma) pre Se ha recibido una notificación Se ha seleccionado la opción de posponer notificación post El temporizador se ajusta para emitir la notificación en un período de tiempo definido internamente de la Alarma aP 86 context Sistema::tomarMedicación(aT: Alarma) pre Se ha recibido una notificación Se ha seleccionado la opción de tomar medicación No se ha sobrepasado el límite temporal para tomar la medicación o se ha sobrepasado el límite temporal para tomar la medicación pero no se confirma la reprogramación de notificaciones post La instancia de Alarma A con atributos aT.fecha y aT.hora tiene A.fechaTomado = aT.fechaTomado y A.horaTomado = aT.horaTomado y tomado = true context Sistema::tomarMedicaciónReprogramar(aTR: Alarma) pre Se ha recibido una notificación Se ha seleccionado la opción de tomar medicación Se ha sobrepasado el límite temporal para tomar la medicación y se ha confirmado la reprogramación de las próximas notificaciones post La instancia de Alarma A identificada por aTR.fecha y aTR.hora tiene A.fechaTomado = aTR.fechaTomado y A.horaTomado = aTR.horaTomado y tomado = true Desactivar notificaciones medicamento context Sistema::desactivarNotificacionesMedicamento(lr: LíneaReceta) pre El usuario está identificado en el sistema Las notificaciones están activas post La Notificación N asociada a la LíneaReceta lr tiene el atributo activo = false. sd Desactivar notificaciones medicamento :Paciente :Sistema desactivarNotificacionesMedicamento(lr) 87 Añadir supervisor context Sistema::añadirSupervisor(cip: string, dniS: string, cAcceso: string) pre El usuario está identificado en el sistema El dniS no está vacío El password no está vacío post Se ha creado una instancia de Supervisor s con s.dniSupervisor = dniS, s.códigoSupervisor = cAcceso asociada a la instancia de Paciente identificada por cip. Eliminar supervisor context Sistema::eliminarSupervisor(cip: string) pre El usuario está identificado en el sistema El usuario tiene asignado un supervisor post Se ha eliminado la instancia de Supervisor asociada a la instancia de Paciente identificada por cip. sd Añadir supervisor :Paciente :Sistema añadirSupervisor(cip, dniS, cAcceso) sd Eliminar supervisor :Paciente :Sistema eliminarSupervisor(cip) 88 Consultar notificaciones desatendidas context Sistema::consultarNotificacionesDesatendidas(cip: string) :Set(a: Alarma) pre El usuario está identificado en el sistema post El sistema muestra la pantalla del historial de avisos con la información de las notificaciones desatendidas en las últimas 24 horas. Intercambiar interfaz context Sistema::intercambiaInterfaz(cip: string) pre El usuario está identificado en el sistema post La instancia de Paciente P identificada por cip ha intercambiado el valor del atributo interfazEspecial Se ha intercambiado la interfaz de la aplicación sd Consultar notificaciones desatendidas :Paciente :Sistema consultarNotificacionesDesatendidas(cip) :Set(a) sd Intercambiar interfaz :Paciente :Sistema intercambiaInterfaz(cip) 89 Silenciar notificaciones medicamento context Sistema::silenciarNotificaciones(lr: LíneaReceta) pre El usuario está identificado en el sistema post La Notificación N asociada a la LíneaReceta lr tiene el atributo silencio = false Desactivar silencio notificaciones medicamento context Sistema::desactivarSilencio(lr: LíneaReceta) pre El usuario está identificado en el sistema post La Notificación N asociada a la LíneaReceta lr tiene el atributo silencio = true sd Silenciar notificaciones medicamento :Paciente :Sistema silenciarNotificaciones(lr) sd Desactivar silencio notificaciones medicamento :Paciente :Sistema desactivarSilencio(lr) 96 Consultar pacientes visitados Figura 36: Diseño de la pantalla de pacientes visitados Las pantallas de próximas visitas (Figura 35) y pacientes visitados (Figura 36) son muy similares, en la primera, se muestran las visitas programadas para el médico identificado con los datos del paciente y de la propia visita; una vez el usuario interactúe con alguna de las visitas estas se trasladan a la pantalla de pacientes visitados, donde se pueden realizar las mismas acciones que en la pantalla que le precede. Si no hay visitas programadas o no se ha visitado a ningún paciente hasta el momento, se muestra un aviso en la parte superior. Consultar tratamiento Figura 37: Diseño de la pantalla de consultar tratamiento La Figura 37 muestra la pantalla donde el usuario puede ver el tratamiento de un paciente, desde aquí puede acceder al historial de recetas prescritas, ver el seguimiento que está teniendo un medicamento o acceder a la página para realizar modificaciones. Si el paciente no está tomando ningún medicamento actualmente, se muestra un mensaje informativo en la parte superior de la pantalla. 97 Modo edición Figura 38: Diseño de la pantalla de modificar tratamiento (modo edición) La pantalla de modificación del tratamiento o el modo edición (Figura 38) es similar a la de consultar tratamiento, únicamente aparecen botones para realizar las acciones que se deseen: modificar receta, archivar la receta y añadir una nueva. En el diálogo que se muestra a continuación, se puede ver el aspecto que tendrá cuando se quiera crear una nueva receta; para la modificación de una receta existente, se utilizará el mismo diálogo, aunque con el campo de búsqueda de medicamentos desactivado. Figura 39: Diseño del diálogo de inserción de una receta 98 Consultar historial Figura 40: Diseño de la pantalla del historial de recetas prescritas En la pantalla de la Figura 40 se muestran las recetas prescritas en el período de fechas indicado; el usuario puede modificar el período y puede actuar sobre la lista de recetas mostradas viendo los detalles o consultando la información de seguimiento. Consultar seguimiento Figura 41: Diseño de la pantalla de seguimiento de la toma de un medicamento 99 En la consulta del seguimiento de un medicamento, se mostrará un calendario marcando los días en los que ha habido algún tipo de interrupción del tratamiento, ya sea por olvido o por hacer la toma con retraso. Para ver los detalles de las interrupciones se muestra una tabla con los detalles. A continuación, se muestran los diseños previos al desarrollo de la aplicación Android. Login paciente El proceso de identificación en la aplicación móvil es sencillo (Figura 42), el usuario deberá introducir el CIP que tenga asignado en su tarjeta sanitaria junto a una contraseña que previamente habrá definido. En el caso de que aún no disponga de contraseña deberá dejar ese campo vacío para acceder a la pantalla de creación de contraseña (Figura 43). Nota: Será necesario la presencia de un administrador en el sistema para atender dudas de los pacientes y resolver sus problemas en el caso de que no puedan acceder a la aplicación por olvido de contraseña o por otro tipo de razones. Figura 42: Diseño de la pantalla de login de un paciente Figura 43: Diseño de la pantalla de login de un paciente (creación de contraseña) 100 Consultar plan de medicación – Silenciar/Desactivar silencio notificaciones Activar/Desactivar notificaciones – Indicar cantidad restante Figura 44: Diseño de la pantalla principal de la aplicación Figura 45: Diseño de la pantalla de selección de receta Figura 46: Diseño de la pantalla de consulta del plan de medicación La pantalla principal es muy sencilla (Figura 44), únicamente hay dos botones que inician dos procesos y un menú de configuración para acceder a otras opciones menos relevantes para la actividad del usuario. Para poder visualizar los detalles de la receta es necesario acceder a la pantalla donde aparecen todos los medicamentos (Figura 45) que en ese momento están vigentes, y que han sido prescritos por cualquier médico que haya visitado al paciente. Al seleccionar un medicamento de la lista, se muestra la información introducida por el médico, así como dos interruptores para gestionar las opciones de notificación, y otro botón adicional ‘Indicar cantidad restante’ que sólo será accesible cuando las notificaciones estén activadas para definir exactamente qué cantidad de dosis se dispone (Figura 46). 101 Añadir/Eliminar supervisor – Login supervisor Figura 47: Diseño de la pantalla para añadir un supervisor Figura 48: Diseño de la pantalla para eliminar un supervisor Figura 49: Diseño de la pantalla de login de un supervisor Un supervisor puede acceder a la aplicación para consultar datos o ver si hay alguna incidencia. El paciente, desde su dispositivo debe introducir el DNI de la persona a la que concede el derecho de acceder a su información y asignarle un código de acceso (Figura 47). De la misma forma en la Figura 48 únicamente se muestra un botón para denegar el acceso al supervisor que ya está registrado. La pantalla de identificación de un supervisor es similar a la del paciente y para acceder a la aplicación debe introducir los datos que anteriormente se habrán registrado. Consultar notificaciones desatendidas Cuando se descarta o desatiende una notificación, se almacena en el historial de notificaciones desatendidas (Figura 50) y el paciente puede marcar la medicación como tomada en un plazo de 24 horas. 102 Figura 50: Diseño de la pantalla de notificaciones desatendidas Figura 51: Diseño de un diálogo de confirmación Figura 52: Diseño de una notificación La Figura 51 muestra un ejemplo de diálogo de confirmación que aparece cuando se supera el límite de 2 horas para tomar un medicamento, al silenciar las notificaciones, al desactivarlas o al intercambiar la interfaz. La Figura 52 es el diseño de una notificación, donde se pueden realizar tres acciones, marcar como tomada, posponerla o descartar la notificación deslizando hacia cualquier lateral de la pantalla. 8.3. Cambios en las restricciones La restricción de clave externa: (Fecha: fecha, hora) se elimina. Se añaden las restricciones de integridad:  No pueden existir dos visitas con los mismos Paciente, MédicoCentro y misma fecha y hora.  No puede existir dos MédicoEspecialista con los mismos Médico y Especialidad.  No puede existir dos MédicoCentro con los mismos MédicoEspecialista y CentroMédico. Acciones en la información derivada: se materializan los atributos duraciónVigencia, cantidadRestante, fechaFinTratamiento y horaFinTratamiento. 103 8.4. Diagrama de clases de diseño Figura 53: Diagrama de clases de diseño class Diagrama clases diseño Usuario - idioma :Idioma Supervisor - dniSupervisor :string - códigoSupervisor :string Paciente - cipPaciente :string - password :string [0..1] - nombrePaciente :string - fechaNacimiento :Date - interfazEspecial :boolean Médico - numCol :int - username :string - dni :string - password :string - nombreMédico :string Medicamento - idMedicamento :int - nombreMedicamento :string - cantidadEnvase :int CentroMédico - nombreCentro :string LíneaReceta - dosis :int - formaDosis :string - frecuencia :int - tipoFrecuencia :Frecuencia - fechaInicioVigencia :Date - fechaFinVigencia :Date - duraciónVigencia :int - comentarios :string - crónico :bool Alarma - fecha :Date - hora :Time - tomado :boolean - fechaTomado :Date [0..1] - horaTomado :Time [0..1] «enumeration» Idioma Español Català English «enumeration» Frecuencia Horas Días ImagenMedicamento - idImagen :int - imagen :BLOB «enumeration» NombreEspecialidad Alergología Anestesiología y reanimación Cardiología Gastroenterología Endocrinología Geriatría Hematología y hemoterapia Hidrología médica Infectología Medicina aeroespacial Medicina del deporte Medicina del trabajo Medicina de urgencias Medicina familiar y comunitaria Medicina intensiva Medicina interna Medicina legal y forense Medicina preventiva y salud pública Nefrología Neumología Neurología Nutriología Odontología Oftalmología Oncología médica Oncología radioterápica Otorrinolaringología Pediatría Proctología Psiquiatría Rehabilitación Reumatología Traumatología Toxicología Urología Notificación - fechaActivación :Date - horaActivación :Time - fechaInicioTratamiento :Date - horaInicioTratamiento :Time - fechaFinTratamiento :Date - horaFinTratamiento :Time - comentario :string - cantidadRestante :int Especialidad - nombreEspecialidad :NombreEspecialidad MédicoEspecialista MédicoCentro Visita - fecha :Date - hora :Time - visitado :bool 0..1 SupervisaA 1..* 1 * {disjoint, complete} 1 PuedeSer 1..* * EsDe 1 1 PuedeSerDe * * TieneAsociada 1 * TieneAsociado 1 1 Tiene 0..1 1 Genera * 1 EsDe * 1 Tiene * 1 EsDe * 104 8.5. Modelo de datos Figura 54: Modelo de datos del sistema La jerarquía de especialización se transforma como Concrete Table Inheritance.  Paciente(cipPaciente, password, nombrePaciente, fechaNacimiento, interfazEspecial, idioma) PK 8 : cipPaciente  Supervisor(idSupervisor, dniSupervisor, códigoSupervisor, idioma, cipPaciente) PK: idSupervisor Clave alternativa: UNIQUE(dniSupervisor, códigoSupervisor), UNIQUE(cipPaciente) cipPaciente referencia a Paciente(cipPaciente)  Médico(numCol, username, dni, password, nombreMédico, idioma) PK: numCol Clave alternativa: UNIQUE(username, dni, password)  Especialidad(nombreEspecialidad) PK: nombreEspecialidad 8 PK: Primary Key (Clave Primaria) 105  MédicoEspecialista(numCol, nombreEspecialidad) PK: numCol, nombreEspecialidad numCol referencia a Médico(numCol) nombreEspecialidad referencia a Especialidad(nombreEspecialidad)  CentroMédico(nombreCentro) PK: nombreCentro  MédicoCentro(numCol, nombreEspecialidad, nombreCentro) PK: numCol, nombreEspecialidad, nombreCentro numCol+nombreEspecialidad referencia a MédicoEspecialista(numCol, nombreEspecialidad) nombreCentro referencia a CentroMédico(nombreCentro)  Visita(fecha, hora, cipPaciente, numCol, nombreEspecialidad, nombreCentro, visitado) PK: fecha, hora, cipPaciente, numCol, nombreEspecialidad, nombreCentro, fecha, hora cipPaciente referencia a Paciente(cipPaciente) numCol+nombreEspecialidad+nombreCentro referencia a MédicoCentro(numCol, nombreEspecialidad, nombreCentro)  Medicamento(idMedicamento, nombreMedicamento, cantidadEnvase, idImagen) PK: idMedicamento idImagen referencia a ImagenMedicamento(idImagen)  LíneaReceta(idLíneaReceta, dosis, formaDosis, frecuencia, tipoFrecuencia, fechaInicioVigencia, fechaFinVigencia, duraciónVigencia, comentarios, crónico, idMedicamento, cipPaciente, numCol, nombreEspecialidad, nombreCentro, fecha, hora) PK: idLíneaReceta idMedicamento referencia a Medicamento(idMedicamento) cipPaciente+numCol+nombreEspecialidad+nombreCentro+fecha+hora referencia a Visita(cipPaciente, numCol, nombreEspecialidad, nombreCentro, fecha, hora) Clave alternativa: UNIQUE(cipPaciente, numCol, nombreEspecialidad, nombreCentro, fecha, hora, idMedicamento)  ImagenMedicamento(idImagen, imagen) PK: idImagen  Notificación(idNotificación, fechaActivación, horaActivación, fechaInicioTratamiento, horaInicioTratamiento, fechaFinTratamiento, horaFinTratamiento, comentario, cantidadRestante, idLíneaReceta) PK: idNotificación idLíneaReceta referencia a LíneaReceta(idLíneaReceta)  Alarma(idAlarma, fecha, hora, tomado, fechaTomado, horaTomado, idNotificación) PK: idAlarma idNotificación referencia a Notificación(idNotificación) 112 Consultar historial Figura 67: Acceso a la pantalla de historial Figura 68: Diagrama de secuencia del caso de uso Consultar historial de recetas fInicio tiene como valor el 1 de enero del año actual y fFin tiene como valor la fecha de hoy, si el usuario no define otras fechas. sd consultarHistorialForm Médico :historial_view :historial_controller :form_validation alt [ok] [not ok] consultarHistorial_data() consultarHistorialForm() run() :ok consultarHistorial(fInicio, fFin) show_warning(validation_error) sd consultarHistorial_page Médico :tratamiento_view :historial_controller :session :lineareceta_model :medico_model :medicamento_model :historial_view :tratamiento_controller :notificacion_model i = 0 loop [i < count(data)] data[i].nombreMedico = nombreMedico data[i].nombreMedicamento = nombreMedicamento data[idNotificacion] = idNotificacion consultarHistorial_page() consultarHistorial_page() consultarHistorial() all_userdata() :cipPaciente getHistorial(fInicio, fFin, cipPaciente) :data getNombreMedico(data[i][numCol]) :nombreMedico getNombreMedicamento(data[i][idMedicamento]) :nombreMedicamento existsNotificacion(data[i][idLineaReceta]) :idNotificacion load_view(data) 113 Consultar seguimiento medicamento Figura 69: Acceso a la página de seguimiento de un medicamento Para evitar la duplicidad de diagramas la función seguimiento_page_data() puede ser invocada desde tratamiento_view o historial_view que provoca una llamada a la función seguimiento_page() del controlador que corresponda a cada vista. ‘page’ se utiliza para registrar desde qué vista se ha accedido a la función y así poder realizar la acción que corresponda cuando se pulse el botón de volver. Figura 70: Diagrama de secuencia del caso de uso Consultar seguimiento medicamento sd seguimiento_page Médico :session :seguimiento_controller :tratamiento_controller OR :historial_controller :tratamiento_view OR :historial_view seguimiento_page() seguimiento_page() set_userdata(idNotificacion, idMedicamento, page) consultarSeguimiento_page() sd consultarSeguimiento :seguimiento_controller :session :notificacion_model :seguimiento_view :alarma_model :medicamento_model alt [not alarmas] [alarmas] data.alarmas = alarmas data.notif = notif consultarSeguimiento() all_userdata() :idNotificacion, idMedicamento getNombreMedicamento(idMedicamento) :nombreMedicamento getNotificacion(idNotificacion) :notif getAllAlarma(notif[idNotificacion]) :alarmas show_error(no_alarmas) load_view(data) 114 Archivar línea receta Figura 71: Diagrama de secuencia del caso de uso Archivar línea receta El parámetro booleano de archivarReceta indica si es necesario archivar una receta, o si se debe eliminar de la base de datos porque ha sido creada y eliminada en una misma visita. Si es true, únicamente se ejecuta la parte ‘else’ del segundo fragmento alt. No se ha añadido otro fragmento para no sobrecargar de elementos el diagrama. sd archivarReceta Médico :edicion_view :tratamiento_controller :lineareceta_model notificacion_model :session alt [ok] [not ok] opt [if idNotificacion] alt [res.f == f and res.h == h] [else] archivarReceta(idLineaReceta) show_confirmation_dialog() dialog(ok) archivarReceta(idLineaReceta, b) existsLineaRecetaVisita(idLineaReceta) :res userdata(fecha, hora) :f, h deleteLineaReceta(idLineaReceta) archivarLineaReceta(idLineaReceta) existsNotificacion(idLineaReceta) :idNotificacion desactivaNotificacion(idNotificacion) edicion_page() close_dialog() 115 Añadir línea receta Figura 72: Diagrama de secuencia del caso de uso Añadir línea receta data = dosis, formaDosis, frecuencia, tipoFrecuencia, fechaInicioVigencia, fechaFinVigencia, duracionVigencia, comentarios, cronico, idMedicamento, cipPaciente, numCol, nombreEspecialidad, nombreCentro, fecha, hora. sd añadirReceta Médico :edicion_view :tratamiento_controller :lineareceta_model :medicamento_model :form_validation loop [letter typed] alt [not exists] [exists] alt [ok] [not ok] addReceta() show_dialog() searchMedicamento(letters) searchMedicamento(letters) :array(idMedicamento, nombreMedicamento) dialog_data(data) addReceta(data) run() :ok existsLineaRecetaVigente(session[cipPaciente], data.idMedicamento) :exists addLineaReceta(data) edicion_page() show_error(existsMedicamento) show_warning(validation_error) 116 Sustituir línea receta Figura 73: Diagrama de secuencia del caso de uso Sustituir línea receta En updateLineaReceta y addLineaReceta: data = dosis, formaDosis, frecuencia, tipoFrecuencia, fechaInicioVigencia, fechaFinVigencia, duracionVigencia, comentarios, cronico, idMedicamento, cipPaciente, numCol, nombreEspecialidad, nombreCentro, fecha, hora. En las siguientes páginas se muestran los diagramas de secuencia de la aplicación Android. En alguno de ellos se han omitido las partes menos relevantes (mostrar errores, diálogos, etc.) para facilitar la comprensión. sd sustituirReceta Médico :edicion_view :tratamiento_controller :lineareceta_model :session :form_validation alt [res.f == f and res.h == h] [else] alt [ok] [not ok] sustituirReceta() show_dialog() dialog_data(data) sustituirReceta(data) run() :ok existsLineaRecetaVisita(data.idLineaReceta) :res userdata(fecha, hora) :f, h updateLineaReceta(data) addLineaReceta(data) archivarReceta(data.idLineaReceta, true) edicion_page() show_warning(validation_error) 117 Login paciente Figura 74: Diagrama de secuencia del caso de uso Login paciente Si la función checkForm() detecta que el password está vacío, se inicia la activity NewPasswordActivity Figura 75: Proceso de login alternativo – crear de contraseña de paciente sd TabLoginPaciente :Paciente :TabLoginPaciente «new» :UserLogin <AsyncTask> «new» :JSONParser «new» :Intent alt [not ok] [ok] params = {cip, MD5(pass)} alt [not success] [success] form_data(cip, pass) checkForm() :ok show_error() :error execute() makeHttpRequest(urlCheckLogin, params) :success show_error() :error_incorrect_login putExtra(cip) putExtra(modoSupervisor = false) startActivity(SplashScreenActivity) sd NewPasswordActivity :NewPasswordActivity :Paciente «new» :NewPasswordLogin <AsyncTask> «new» :JSONParser «new» :Intent alt [not ok] [ok] params = {cip, MD5(pass)} params = {cip, MD5(pass)} alt [not nullPassword] [nullPassword] alt [not success] [success] form_data(cip, pass, confirmation) checkForm() :ok show_error() :error execute() makeHttpRequest(urlCheckNullPassword, params) :nullPassword show_error() :error_have_password makeHttpRequest(urlSetPassword, params) :success show_error() :error putExtra(cip) putExtra(modoSupervisor = false) startActivity(SplashScreenActivity) finish() 118 Figura 76: Proceso de login – Descarga de datos Cuando se inicia esta activity se descarga a una base de datos local en el dispositivo, la información necesaria para que la aplicación funcione. Si el resultado retornado por DatabaseHelper o JSONParser es false, se ha producido un error, y por lo tanto, se para la ejecución. Si el booleano existsRecetas es false, significa que el paciente no tiene ningún plan de medicación. Se deniega el acceso a la aplicación, redirigiéndolo a la activity de Login. sd SplashScreenActivity :SharedPreferences «new» :DownloadData <AsyncTask> :SplashScreenActivity «new» :DatabaseHelper «ne... :Paciente «new» :LineaReceta «new» :JSONParser «new» :Medicamento «new» :Medico «new» :ImagenMedicamento «new» :Intent «new» :Notificacion params = cip loop [foreach(data[lineareceta]] loop [foreach(data[medicamento])] loop [foreach(data[medico])] loop [foreach(data[imagenes])] loop [foreach(data[nottificacion]) and existsNotificacion] Intent(cip, modoSupervisor) putString(cip) putBoolean(modoSupervisor) execute() makeHttpRequest(url_getAllData, params) :data, existsRecetas, existsNotificaciones, existsSupervisor putBoolean(existsSupervisor) Paciente(data[paciente]) :p insertPaciente(p) :ok LineaReceta(data[lineareceta[i]]) :lr insertLineaReceta(lr) :ok Medicamento(data[medicamento[i]]) :m insertMedicamento(m) :ok Medico(data[medico][i]) :med insertMedico(med) :ok ImagenMedicamento(data[imagenes][i]) :i insertImagenMedicamento(i) :ok Notificacion(data[notificacion][i]) :n insertNotificacion(n) :ok closeDB() startActivity(MainActivity) 119 Figura 77: Diagrama de secuencia de las acciones en la pantalla principal Si existsSupervisor es true, se muestra el botón de menú como "Eliminar supervisor". Si modoSupervisor es true, se oculta el botón de menú "Añadir/Eliminar supervisor". sd MainActivity Paciente :MainActivity «new» :Intent :SharedPreferences alt [button = Plan medicación] [button = Historial notificaciones] [menuButton = Logout] [menuButton = Añadir/Eliminar supervisor] [menuButton = Ayuda] onClick(button) getBoolean(existsSupervisor) :eS getBoolean(modoSupervisor) :mS startActivity(MedicationListActivity) startActivity(LastNotificationsActivity) logout() startActivity(GestionSupervisorActivity) show_help_dialog() 120 Logout (Android) Figura 78: Diagrama de secuencia del caso de uso logout (para paciente y supervisor) Consultar plan de medicación Figura 79: Diagrama de secuencia del caso de uso Consultar plan de medicación (paso 1) sd logout Paciente :MainActivity «new» :DatabaseHelper «new» :Intent «new» :AlarmManagerBroadcastReceiver «new» :DesactivaNotificaciones opt [notif.length > 0] loop [i < notif.length] i = 0 alt [do] [not do] click_logout() showDialogLogout() :do getIdNotificacionesActivadas() :notif[] cancelAlarm(notif[i]) execute(notif) :ok deleteAllData() closeDB() startActivity(LoginActivity) dialog.cancel() sd MedicationListActivity «new» :MedicationListActivity «new» :DatabaseHelper Paciente «new» :Intent «new» :AdapterMedicationList loop [foreach(meds)] nombres, idMeds, imagenes = null nombres.add(meds.nombreMedicamento idMeds.add(meds.idMedicamento) imagenes.add(i) getMedicamentos() :meds getImagenMedicamento(meds[i].idImagen) :i closeDB() AdapterMedicationList(nombres, idMeds, imagenes) clickOnItem(it) putExtra(it.idMedicamento) startActivity(MedicationActivity) 121 Figura 80: Diagrama de secuencia del caso de uso Consultar plan de medicación (paso 2) Si el usuario es un supervisor, no se muestran los switches. Si las notificaciones están desactivadas no se muestra el botón para indicar la cantidad restante. sd MedicationActivity :MedicationActivity «new» DatabaseHelper Paciente alt [changeSwitch = Notificaciones] [changeSwitch = Silencio] [clickButton = Indicar cantidad restante] Intent(idMedicamento) getLineaReceta(idMedicamento) :lr: LineaReceta getMedico(lr.numCol) :m: Médico getMedicamento(idMedicamento) :med: Medicamento getImagenMedicamento(med.idImagen) :i: ImagenMedicamento getNotificacion(lr.idLineaReceta) :n: Notificacion closeDB() changeSwitchNotificaciones(isChecked) switchNotificaciones(isChecked) changeSwitchSilencio(isChecked) switchSilencio(isChecked) indicarCantidadRestante() openDialog() 128 Consultar notificaciones desatendidas Figura 89: Diagrama de secuencia del caso de uso Consultar notificaciones desatendidas sd LastNotificationsActivity :LastNotificationsActivity «new» :DatabaseHelper Paciente «new» :Intent :SharedPreferences «new» :GetAlarmasNoTomadas <AsyncTask> «new» :JSONParser «new» :Alarma «new» :AdapterAlarmList alt [dialog.clickPositiveButton] [dialog.clickNegativeButton] opt [notif.length > 0] params = notif loop [foreach(data[alarma])] loop [foreach(alarmas)] map = null map.add(n.idNotificacion, {m.nombreMedicamento, i}) opt [not mS] getBoolean(modoSupervisor) :mS getIdNotificaciones() :notif[] closeDB() execute(notif) makeHttpRequest(url_getAlarmasNoTomadas, params) :data Alarma(data[i].{idAlarma, fecha, hora}) :al insertAlarma(al) :ok getAlarmasNoTomado() :alarmas getNotificacionById(alarmas[i].id) :n getLineaRecetaById(n.idLineaReceta) :lr getMedicamento(lr.idMedicamento) :m getImagenMedicamento(m.getIdImagen) :i closeDB() AdapterAlarmList(alarmas, map) clickOnItem(it) open_warning_dialog() putExtra(it.idAlarma) putExtra(it.idNotificacion) putExtra(action = TOMAR) startActivity(NotificationActionActivity) dialog.cancel() 129 Silenciar/Desactivar silencio notificaciones medicamento Figura 90: Diagrama de sec. de los CU Silenciar/Desactivar silencio notificaciones Indicar cantidad restante Figura 91: Diagrama de secuencia del caso de uso Indicar cantidad restante sd switchSilencio(isChecked) :MedicationActivity «new» :DatabaseHelper opt [isChecked] opt [not isChecked or dialog.clickPositiveButton] [else] switchSilencio(isChecked) open_warning_dialog() updateSetSilencio(isChecked) closeDB() dialog.cancel() sd Indicar cantidad restante :MedicationActivity «new» :DatabaseHelper Paciente «new» JSONParser «new» UpdateCantidadRestante <AsyncTask> alt [dialog.clickPositiveButton and cantidadRestante <= cantidadEnvase] [dialog.clickNegativeButton] [cantidadRestante > cantidadEnvase or cantidadRestante.empty] params = idNotificacion, cantidadRestante openDialog() setValue(cantidadRestante) updateCantidadRestante(idNotificacion, cantidadRestante) closeDB() execute(idNotificacion, cantidadRestante) makeHttpRequest(url_updateCantRes, params) :ok dialog.cancel() dialog.cancel() show_error(error_msg) 130 9. Implementación En este apartado se explica de qué forma se han utilizado las diferentes tecnologías utilizadas para el desarrollo explicando de forma resumida su funcionamiento. Por un lado, el framework CodeIgniter trae consigo diferentes librerías y helpers que ayudan a que se trabaje de manera más rápida, sin tener que implementar funciones suplementarias para tratar con la base de datos, las sesiones del usuario; y en el caso de Android, diferentes elementos que almacenan datos, los transforman o los muestran. 9.1. Desarrollo con CodeIgniter 9 Sesiones de usuario La clase Session realiza acciones similares a las sesiones nativas de PHP. Esta clase permite almacenar el estado de un usuario, los datos relevantes para que el sistema funcione correctamente en cualquier momento y página que el usuario visite y seguir su actividad dentro de la aplicación. Cada usuario tiene su identificador de sesión y su porción de información que es guardada en la base de datos de la que se nutre la aplicación y también en una cookie con los datos serializados. Para evitar la manipulación de los datos de la sesión, CodeIgniter obliga a definir una clave de encriptación en los ficheros de configuración y también es posible encriptar todos los datos usando la extensión Mcrypt. A modo de ejemplo, si queremos guardar el número de colegiado y el nombre del médico que se ha identificado en la aplicación deberemos: inicializar la clase Session y usar set_userdata(); para recuperar nuevamente los datos se tiene que usar la función userdata(‘nombreDato’). $this->load->library('session'); $this->session->set_userdata('numCol', '123456'); $this->session->set_userdata('nombreMedico', 'Doctor'); $numCol = $this->session->userdata('numCol'); $nombreMedico = $this->session->userdata('nombreMedico'); También permite añadir múltiples parejas nombre-valor si se define un array asociativo. Si necesitamos almacenar un dato para un determinado momento disponemos de las funciones flashdata, que sirven para autodestruir datos una vez se han usado. Para eliminar datos concretos de sesión o suprimir toda la sesión podemos hacerlo de la siguiente forma: $this->session->unset_userdata('numCol'); $this->session->sess_destroy(); Si en los archivos de configuración de CodeIgniter especificamos la creación de la base de datos para las sesiones, automáticamente se creará la siguiente tabla, cuyo nombre (ci_sessions) también se puede cambiar; la columna user_data contiene todos los datos que se almacenen de forma serializada. 9 Documentación para desarrolladores disponible en: http://www.codeigniter.com/user_guide/ [25] 131 CREATE TABLE IF NOT EXISTS `ci_sessions` ( session_id varchar(40) DEFAULT '0' NOT NULL, ip_address varchar(45) DEFAULT '0' NOT NULL, user_agent varchar(120) NOT NULL, last_activity int(10) unsigned DEFAULT 0 NOT NULL, user_data text NOT NULL, PRIMARY KEY (session_id), KEY `last_activity_idx` (`last_activity`) ); Validación de formularios En desarrollo web es muy usual utilizar formularios para recoger datos del usuario, pero estos no siempre vienen escritos en la forma en la que queremos guardarlos, con la clase Form Validation podemos definir reglas, tanto estándares como personalizadas para los formularios y manejar los errores, advertencias o mensajes informativos que se deben mostrar. <body> <?php echo validation_errors(); ?> <php echo form_open('formulario'); ?> <!-- Elementos del formulario--> </form> </body> En el código anterior que se debe introducir en un archivo de Vista, se define en el cuerpo del archivo HTML fragmentos de PHP en las que se ‘abre’ el formulario, y un espacio para mostrar los posibles errores de validación en la parte superior del formulario. Se cargan los helpers url, form y la librería form_validation: $this->load->helper(array('form', 'url')); $this->load->library('form_validation'); $this->form_validation->set_rules('password', 'Contraseña', 'trim|xss_clean|htmlspecialchars|md5|max_length[32]'); if ($this->form_validation->run() == FALSE) { $this->load->view('login'); } else [...] En el código anterior, se define un conjunto de reglas para el campo de la contraseña del formulario: se eliminan los espacios en blanco, se hace un filtrado XSS se convierten los caracteres especiales de HTML, se encripta bajo MD5, y se comprueba que el tamaño es de 32 caracteres. Hay muchas más opciones que se pueden encadenar e incluso definir callbacks personalizados para validar el campo. Se ejecuta la validación y si no se supera se cargará de nuevo la vista que contiene el formulario (o una página de error, según decida el desarrollador) para mostrar los errores; en caso contrario se realizan las acciones pertinentes. También hay funciones auxiliares que mejoran la usabilidad de la aplicación haciendo que los campos que han superado la validación conserven los datos introducidos previamente, mostrar otro tipo de mensajes, soportar diferentes idiomas, etc. 132 Datos de entrada La clase Input hace un pre-procesado de los datos de entrada y pone a disposición funciones auxiliares para recuperar esos datos. Para recuperar datos de un formulario se usa: $password = $this->input->post('password'); Esta línea de código ahorra el trabajo habitual en PHP de comprobar si el campo está vacío o no, automáticamente devuelve el valor del campo del formulario o un booleano con valor false si no está definido. Esta clase se inicializa automáticamente y no es necesario hacerlo manualmente. Base de datos CodeIgniter aporta la clase abstracta Database, rápida y completa que soporta tanto las estructuras tradicionales como los patrones Active Record. Existen múltiples formas de realizar consultas a la base de datos, en el fragmento de código siguiente se muestran algunas de ellas: $this->load->database(); $sql = "SELECT idLineaReceta FROM LineaReceta WHERE cipPaciente = ? AND idMedicamento = ? AND fechaInicioVIgencia <= CURDATE() AND fechaFinVigencia >= CURDATE()"; $consulta = $this->db->query($sql, array($cipPaciente, $idMedicamento)); $sql = "DELETE FROM LineaReceta WHERE idLineaReceta = ?"; $consulta = $this->db->query($sql, $idLineaReceta); $sql = "UPDATE LineaReceta SET fechaFinVigencia = CURDATE() WHERE idLineaReceta = ?"; $consulta = $this->db->query($sql, $idLineaReceta); $this->db->close(); Sobre la variable $consulta que contiene el resultado de la consulta se pueden aplicar también funciones como:  num_rows() para conocer el número de filas del resultado.  num_fields() para saber el número de columnas del resultado.  result() retorna el resultado como un vector de objetos o vacío si no hay resultados.  result_array() retorna el resultado de la consulta en forma de vector (array) o vacío si no hay resultados.  row()/row_array() únicamente devuelve la primera fila del resultado que puede ser de tipo object o array. Si se especifica un número en el parámetro se devolverá la fila seleccionada. Además si se devuelve un array se puede recorrer con más funciones first_row(), last_row(), next_row(), previous_row(). 133 Otra de las formas de realizar consultas de forma más simplificada es mediante el patrón Active Record, que gracias a él se puede tener independencia del tipo de base de datos que se usa y obtener mayor seguridad por acciones que realiza automáticamente el sistema. $this->db->select('fecha, hora, tomado, fechaTomado, horaTomado'); $this->db->from('Alarma'); $this->db->where('idNotificacion', $idNotificacion); $consulta = $this->db->get(); $this->db->insert('LineaReceta', $data); $this->db->where('idLineaReceta', $data['idLineaReceta']); $this->db->update('LineaReceta', $data); En el código anterior se puede ver la forma en la que se realiza un SELECT, INSERT y UPDATE a la base de datos con los datos parametrizados, algunos de ellos dentro de un vector que contiene toda la información que se debe actualizar. Es una forma más ordenada y simple de realizar las consultas. Vistas, Modelos y Controladores Las vistas siempre deben ser controladas por el controlador, según marca el patrón MVC; para cargar una vista desde el controlador se puede utilizar alguna de las siguientes líneas de código: $this->load->view('nombreVista'); $datos = array( 'titulo' => 'Mi Titulo', 'encabezado' => 'Mi Encabezado', 'mensaje' => 'Mi Mensaje' ); $this->load->view('nombreVista', $datos); Se puede cargar una vista pasando una serie de datos en forma de array, o simplemente cargar la página entera especificando en el archivo de la vista todos los datos. Además se pueden cargar fragmentos de vistas para formar la página, lo único que hay que hacer es escribir múltiples líneas de carga de vista, una por cada fragmento (encabezado, menú, pie de página, etc.). Los modelos contienen todas las funciones que se comunican con la base de datos, para que CodeIgniter entienda que el archivo PHP que se está creando es de tipo modelo, se debe especificar que hereda de CI_Model y crear el constructor que llame manualmente a la clase padre. 134 class Nombre_modelo extends CI_Model { function __construct() { parent::__construct(); } } /* Y en el controlador */ $this->load->model('Nombre_modelo'); $this->load->model('Nombre_modelo', '', TRUE); $this->Nombre_modelo->nombreFuncion(); Para cargar el modelo se realiza de forma similar a la de cargar las vistas; opcionalmente, se puede añadir el tercer parámetro booleano para especificar si se debe abrir una conexión con la base de datos de forma automática al cargar el modelo. Una vez cargado ya se pueden hacer las llamadas a las funciones que contenga en el código del controlador. Finalmente, los controladores son el núcleo de la aplicación; de la misma forma que el modelo, un controlador hereda de CI_Controller y se debe llamar manualmente al constructor de la clase padre para no ser anulado por el del controlador local. La URL que veremos cuando estemos viendo la página en el navegador está muy relacionada con los controladores: www.sitioweb.com/index.php/productos/pantalones/jeans/4289 La URL anterior contiene datos del controlador que está detrás de la vista, por ejemplo, el controlador tiene el nombre ‘Productos’, hemos llamado a la función ‘pantalones’ y a continuación pueden haber múltiples segmentos que actúan como parámetros de la función, en este caso habremos seleccionado un pantalón de tipo jean con un identificador ‘4289’. 9.2. Desarrollo con Android 10 SharedPreferences La clase SharedPreferences permite almacenar y recuperar pares clave-valor de forma persistente de tipos de datos primitivos tales como: booleanos, floats, ints, longs y strings. Los datos permanecen sin tener en cuenta el cierre de sesión o incluso el cierre la aplicación. En las siguientes líneas hay un ejemplo de uso de esta clase: SharedPreferences prefs = getSharedPreferences('Nombre_Prefs', 0); boolean modoSup = prefs.getBoolean("modoSupervisor", false); SharedPreferences prefs = getSharedPreferences('Nombre_Prefs', 0); SharedPreferences.Editor editor = prefs.edit(); editor.putBoolean("modoSupervisor", false); editor.commit(); 10 Documentación para desarrolladores disponible en: http://developer.android.com/intl/es/index.html [24] 135 Para obtener los datos ya guardados debemos inicializar la clase, y con el método getBoolean() solicitar la clave del dato que se quiere recuperar, el segundo parámetro indica qué valor devolver si no se encuentra el dato solicitado. En el segundo caso, se está almacenando o modificando una pareja clave-valor, únicamente hay que llamar el ‘Editor’ de SharedPreferences, utilizar la función putTipoDeDato() y aplicar los cambios con commit(). AsyncTasks Para ejecutar tareas en segundo plano sin bloquear el hilo principal (main thread) de la aplicación que provocaría lentitud, mal funcionamiento o el típico mensaje de “La aplicación no responde” de bloqueo, se deben utilizar AsyncTasks. Debemos crear una clase que herede de AsyncTask y sobrescribir los métodos:  onPreExecute() acciones a ejecutar antes del código principal de la tarea en segundo plano  onProgressUpdate() se ejecuta cada vez que se llama a publishProgress(params)  doInBackground() contiene el código principal de la tarea  onPostExecute() se ejecuta al finalizar doInBackground()  onCancelled() acciones a realizar cuando se cancela la ejecución antes de que termine la tarea En el siguiente ejemplo de código se muestra la estructura de una tarea que se ejecuta en segundo plano y que utiliza JSON para comunicarse con el servidor, y la base de datos: class DownloadData extends AsyncTask<Void, Void, Void> { JSONParser jsonParser = new JSONParser(); final String url_getAllData = "http://10.0.2.2/sgcmserver/getAllData.php"; @Override protected void onPreExecute() { super.onPreExecute(); } @Override protected void onProgressUpdate(String... values) { super.onProgressUpdate(values); } @Override protected String doInBackground(String... args) { List<NameValuePair> params = new ArrayList<NameValuePair>(); params.add(new BasicNameValuePair("cip", cip)); try { JSONObject json = jsonParser.makeHttpRequest(url_getAllData, params); if (json.getInt("error") == 0) return "1"; } catch (JSONException e) { e.printStackTrace(); } return "0"; } protected void onPostExecute(final String res) {} } La lista de clave-valor ‘params’ contiene los parámetros necesarios de la URL destino y el resultado se obtiene mediante un JSONObject para posteriormente analizar su contenido. 136 Gestión de errores en formularios Android también tiene una forma nativa de mostrar errores en los formularios, con setError(msg) mostraremos de forma muy simple un error en el campo que deseemos. public void checkForm() { dniSupervisor.setError(null); String dni = dniSupervisor.getText().toString(); boolean cancel = false; View focusView = null; if (TextUtils.isEmpty(dni)) { dniSupervisor.setError(getString(R.string.error_field_required)); focusView = dniSupervisor; cancel = true; } if (cancel) { focusView.requestFocus(); } else { //Continuar ejecución } } Mostrar imágenes de la base de datos Las imágenes se almacenan en las bases de datos como datos de tipo BLOB o como un vector de bytes, sin embargo, para mostrar una imagen sólo hacen falta unas pocas líneas de código para convertirla a Bitmap y asignarla a un ImageView. byte[] imagen = db.getImagenMedicamento(0); if(imagen != null) { Bitmap bmap = BitmapFactory.decodeByteArray(imagen, 0, imagen.length); img.setImageBitmap(bmap); } Acceso a la base de datos SQLite Como se ha mencionado en apartados anteriores, en Android es posible crear una base de datos ligera mediante el SGBD SQLite. Se debe crear una clase que herede de SQLiteOpenHelper y sobrescribir los métodos onCreate() que se ejecuta cuando es necesario crear la base de datos y onUpgrade() que se utiliza para actualizar la estructura de la base de datos si esta ha cambiado. Para ejecutar consultas sobre la base de datos podemos hacer uso de execSQL(“Consulta SQL”) de la clase SQLiteDatabase, pero de forma alternativa, se pueden utilizar otras funciones: public long insertMedicamento(Medicamento m) { SQLiteDatabase db = this.getWritableDatabase(); ContentValues values = new ContentValues(); values.put("idMedicamento", m.getIdMedicamento()); [...] return db.insert("medicamento", null, values); } public long updateCantidadResante(int idNotificacion, float cantidadRestante) { SQLiteDatabase db = this.getWritableDatabase(); String[] args = new String[] {Integer.toString(idNotificacion)}; ContentValues values = new ContentValues(); values.put("cantidadRestante", cantidadRestante); 137 return db.update("notificacion", values, "idNotificacion = ?", args); } public byte[] getImagenMedicamento(int idImagen) { SQLiteDatabase db = this.getReadableDatabase(); String[] args = new String[] {Integer.toString(idImagen)}; String selectQuery = "SELECT imagen FROM imagenmedicamento WHERE idImagen = ? "; Cursor c = db.rawQuery(selectQuery, args); if (c.moveToFirst()) { return c.getBlob(c.getColumnIndex("imagen")); } return null; } public int deleteNotificacion(int idNotificacion) { SQLiteDatabase db = this.getWritableDatabase(); String[] args = new String[] {Integer.toString(idNotificacion)}; return db.delete("notificacion", "idNotificacion = ?", args); } Mostrar notificaciones Para mostrar notificaciones se hace uso de la clase Notification.Builder en la que se deben definir el aspecto y las acciones que va a recibir la notificación tales como el título, el mensaje, la imagen, el icono que aparece en la barra de notificaciones, el sonido, los botones interactivos, etc. Para dichos botones, se deben crear PendingIntents que gestionarán las acciones del usuario y lo redirigirán a la Activity de la aplicación conveniente con los datos necesarios que pueda contener la propia notificación. En el siguiente código se muestra cómo se programa la notificación que permite posponer o tomar un medicamento (se han omitido algunos fragmentos del código original para reducir la extensión): Intent posponerIntent = new Intent(getApplicationContext(), NotificationActionActivity.class); posponerIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK); PendingIntent piPosponer = PendingIntent.getActivity(getApplicationContext(), 0, posponerIntent, PendingIntent.FLAG_UPDATE_CURRENT); Intent tomarIntent = new Intent(getApplicationContext(), NotificationActionActivity.class); tomarIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK); PendingIntent piTomar = PendingIntent.getActivity(getApplicationContext(), 0, tomarIntent, PendingIntent.FLAG_UPDATE_CURRENT); Notification.Builder ncb = new Notification.Builder(getApplicationContext()); ncb.setContentTitle(notificationTitle); ncb.setContentText(notificationContent); ncb.setLargeIcon(bmap); ncb.setSmallIcon(R.drawable.ic_launcher); ncb.setDefaults(Notification.DEFAULT_SOUND); ncb.addAction(R.drawable.ic_action_data_usage, "Posponer", piPosponer); ncb.addAction(R.drawable.ic_action_accept, "Tomar", piTomar); NotificationManager nm = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE); nm.notify(0, ncb.build()); Calendar Para tratar con tipos de datos como fechas y horas, es recomendable utilizar la clase abstracta Calendar; obteniendo una instancia podremos conocer la fecha y hora actuales, y también se puede utilizar para hacer programaciones de notificaciones en el tiempo. El único inconveniente que tiene esta clase es que cuando se quiere obtener el mes de alguna fecha, devuelve un valor entre 0 y 11, y da lugar a múltiples errores. 144 11. Informe de sostenibilidad Con el fin de identificar y tener en cuenta la sostenibilidad del proyecto, se evalúa el impacto de tres aspectos: económico, social y ambiental, que pueda tener el proyecto en el entorno donde se enmarca. La siguiente matriz está basada en las ideas de ‘La economía del bien común’ de Christian Felber; estos han sido los valores que he otorgado: ¿Sostenible? Económica Social Ambiental Planificación Viabilidad Económica Mejora en calidad de vida Análisis de recursos 23 7 9 7 Resultados Coste final versus previsión Impacto en entorno social Consumo de recursos 5 0 5 0 Riesgos Adaptación a cambios de escenario Daños sociales Daños ambientales -5 -5 0 0 Valoración total 23 puntos Tabla 81: Matriz de sostenibilidad del TFG En la fase de planificación, se analizó detalladamente cada una de las tres dimensiones del concepto de ‘Planificación’. A continuación, se muestra el conjunto de razonamientos que justifican la puntuación. Planificación - Dimensión económica Para este proyecto se ha realizado una evaluación de costes, tanto de recursos y materiales, aunque no se han tenido en cuenta los costes de ajustes, actualizaciones o reparaciones que pudieran surgir en la vida útil del proyecto debido a que ha sido desarrollado en un entorno académico. El tiempo dedicado a cada una de las tareas del proyecto ha sido planificado según la importancia que suele tener la misma tarea en proyectos similares. En cuanto al coste total del proyecto, en comparación a otros proyectos de software que realizan las empresas del sector, este tiene un coste muy ajustado y por lo tanto sería competitivo y viable. En cuanto a la realización del mismo, sería posible acabarlo en menos tiempo si se dispusiera de más recursos humanos con más experiencia profesional. Actualmente, sería difícil reducir la utilización de recursos debido a que se han utilizado muy pocos (un único desarrollador y costes indirectos muy reducidos). Para este proyecto no se utilizarán partes de otras tecnologías, proyectos o conocimientos existentes. En cuanto a una posible colaboración con otros proyectos (académicos, empresariales, etc.), este proyecto pretende mostrar mejoras en los sistemas actuales de la sanidad pública, por lo que si alguna institución o empresa privada del sector estuviese interesada, podría realizarse algún tipo de colaboración. 145 Planificación - Dimensión social En referencia a la situación social y política del entorno, es un contexto donde se han realizado muchos recortes en todos los sectores públicos y hay un porcentaje alto de personas en situación de desempleo; las familias han perdido poder adquisitivo y los servicios públicos han sufrido una reducción de calidad. En concreto, el sector sanitario ha sido de los más perjudicados. La realización del proyecto puede favorecer la situación, ya que optimizaría los recursos: menos visitas a urgencias por intoxicación o por seguir incorrectamente el tratamiento (menor coste), mayor satisfacción de los pacientes con la calidad del servicio sanitario, etc. La realización de este proyecto cubre una necesidad real y mejora la calidad de vida de los consumidores, ya que cada vez hay más personas que toman medicación debido a que la población de la tercera edad está aumentando, y es el colectivo que suele cometer más errores durante el seguimiento del tratamiento recetado por el médico. Una vez puesto en marcha el producto, los pacientes podrán consultar la información introducida por el médico de sus tratamientos de forma rápida y sencilla, y recibir avisos para poder seguir el tratamiento médico sin preocupaciones y sin equivocaciones. Además podrán tener supervisores para asegurar el cumplimiento del tratamiento. Por otro lado, el personal médico tendrá información de cómo el paciente ha seguido su plan de medicación. Planificación - Dimensión ambiental La elaboración del proyecto provoca la utilización de diferentes recursos que afectan al medio ambiente. En las diferentes fases del proyecto se utilizará energía eléctrica para poder trabajar y el coste de producir la energía tiene un impacto ambiental. Concretamente, se tendrán que mantener alimentados un ordenador para el desarrollo, y un servidor para mantener el sistema (no se dispone de información de consumo eléctrico ni de la contaminación producida por ambos aparatos). Actualmente, previamente a desarrollar el proyecto, ya se consume energía eléctrica debido a que los sistemas utilizados están informatizados. Este TFG informatiza la parte que afecta al usuario, esto supone consumir menos papel, pero por otro lado, consumir más energía eléctrica al tener que acceder a la información a través de dispositivos móviles. Aproximadamente, para realizar el proyecto se estima un consumo de 67,5 kW del ordenador utilizado para el desarrollo. Justificación de la valoración del resto de celdas En el concepto de ‘Resultados’, en la dimensión económica se considera que el coste final es prácticamente igual al previsto (tal y como se especifica en el apartado de conclusiones, de ahí que la valoración sea de 0 en un rango de entre 10 y -10. El impacto del sistema final en el entorno social es importante ya que supone la incorporación de nuevos mecanismos que hasta ahora no se utilizaban; dicho impacto es positivo ya que si su utilización es correcta aporta muchos beneficios. En cuanto al consumo de recursos, tal y como se planificó, se ahorra en consumo de papel, pero se gasta más en energía eléctrica. Se otorga una puntuación de 0 en la escala mencionada anteriormente ya que no se podría saber el resultado de esta dimensión hasta que el sistema estuviese en funcionamiento y fuese utilizado por un número considerable de personas. 146 En el concepto de ‘Riesgos’ se valora (entre -20 y 0) si hay algún riesgo no contemplado en la planificación que pueda ser peligroso desde el punto de vista de la sostenibilidad. Se considera que el uso del sistema no causa ningún daño social ni ambiental de gravedad considerable; sin embargo, se puede intuir una cierta rigidez del sistema a posibles cambios de escenario (legislación, funcionamiento, etc), aunque tampoco sea de extrema gravedad. Resultado del informe de sostenibilidad El resultado final de este proyecto es de 23 puntos de sostenibilidad (en una escala de valores entre -90 y 60), que extrapolada a un rango entre 0 y 10 puntos, obtiene un 7,5. En mi opinión, es un resultado bastante positivo. 147 12. Conclusión Todo este trabajo ha partido de una idea inicial que presenté al coordinador de la especialidad de Sistemas de Información y propuse a Claudia, la directora del trabajo. He podido ver que de aproximadamente 150 palabras escritas sobre papel se puede desarrollar un proyecto informático de gran envergadura y extensible en muchas de sus partes. En cuanto al desarrollo general del proyecto, se llega al final habiendo implementado prácticamente todas las funcionalidades que se definieron y de acuerdo con el alcance del proyecto. En apartados posteriores, se detalla con más profundidad lo que ha quedado pendiente, una evaluación de la planificación temporal y económica, y se proponen otras mejoras de cara a un desarrollo posterior. En cuanto a las conclusiones personales, dado que nunca me había enfrentado a un proyecto grande en el que yo mismo tomaba mis decisiones y el camino a seguir, han sido muchas las veces que he pensado que no podría acabarlo, o que me quedaría bloqueado en alguna de las partes. Según he ido avanzando en las diferentes fases del trabajo, he visto que podía resolver los problemas que aparecían de manera aceptable, y aunque ha habido momentos de estancamiento, al final he encontrado la solución o he modificado algunos aspectos para poder continuar. Posiblemente todas las decisiones que he tomado no serán las mejores, y el documento y ambas aplicaciones desarrolladas son mejorables en muchos aspectos, pero el Trabajo Final de Grado, en mi caso, me ha ayudado a aprender y a hacer cosas nuevas, así como recordar algunas que había olvidado por no poner en práctica. Algunos de los nuevos conocimientos adquiridos son: En primer lugar, el aprendizaje de nuevos lenguajes de programación y entornos de trabajo. Al iniciar el trabajo, no tenía experiencia con el desarrollo web, tenía conocimientos muy básicos de HTML. Al acabarlo, he aprendido a usar PHP, más aspectos de HTML, CSS, jQuery, JavaScript y trabajar con CodeIgniter y Bootstrap, que pese a que son frameworks para principiantes en desarrollo web, consiguen que el resultado final sea lo más parecido posible a un trabajo profesional. En segundo lugar, he ampliado conocimientos de Android (Java), utilizando por primera vez el servicio de notificaciones, el de programación de alarmas y utilizando conexiones con un servidor remoto. También he tratado con más profundidad las etapas de especificación, diseño y la de planificación y gestión de proyectos que ya se habían tratado en diversas asignaturas. Finalmente, el seguir una metodología general de realización del trabajo, cómo estructurar un documento: apartados, tamaños, fuentes, diferencia entre párrafos, gestión de las referencias, e implicar a las partes interesadas para conocer su opinión y recibir sugerencias de mejora, etc. 12.1. Justificación del desarrollo de las competencias técnicas  CSI2.2: Concebir, desplegar, organizar y gestionar sistemas y servicios informáticos, en contextos empresariales o institucionales, para mejorar sus procesos de negocio, responsabilizarse y liderar su puesta en marcha, y su mejora continua; y valorar su impacto económico y social. [Un poco] 148 El desarrollo no ha estado asociado a un contexto empresarial, pero se ha simulado estarlo, al conocer qué carencias hay que suplir o que mejoras hay que introducir para que los sistemas del entorno mejoren. En cuanto al impacto económico y social, en el informe de sostenibilidad del apartado anterior, se razona en bastante profundidad estos aspectos.  CSI3.1: Demostrar comprensión de los principios de la evaluación de riesgos y aplicarlos correctamente en la elaboración y la ejecución de planes de actuación. [Bastante] En el apartado 5.2 se ha realizado un análisis de riesgos en el que se han identificado los más relevantes, se ha elaborado una estrategia de mitigación para cada uno de ellos y el plan de contingencia asociado. Además, en cuanto a riesgos en los que se incurre en el desarrollo, en los apartados de alcance y planificación también aparecen.  CSI4.1: Participar activamente en la especificación de los sistemas de información y de comunicación. [En profundidad] Se ha seguido todo el proceso de especificación y toma de requisitos de manera minuciosa. Debido a que la temática del proyecto tiene su origen en una idea inicial muy básica, ha sido necesario un esfuerzo extra en obtener y recolectar información sobre las partes interesadas, el contexto y funcionamiento actual del sector. Durante la fase de requisitos y especificación, se ha generado documentación como: las propiedades e hipótesis del dominio, las restricciones, los casos de uso, los requisitos de calidad, el esquema conceptual, las restricciones de integridad asociadas, las entidades que intervienen en el esquema y el esquema del comportamiento, tal y como se ha hecho en las asignaturas del Grado.  CSI4.2: Participar activamente en el diseño, la implementación y el mantenimiento de los sistemas de información y de comunicación. [En profundidad] El sistema que se ha desarrollado requería cierto esfuerzo para integrar las dos aplicaciones; se decidió seguir una metodología iterativa para ir revisando que todo fuese correcto. La documentación generada se hizo de manera progresiva, y en cada iteración se obtenía un diagrama de secuencia del caso de uso asociado, ya implementado y probado. En el diseño hubo que tomar decisiones en cuanto a la arquitectura y la responsabilidad de ciertas partes o elementos dentro de las aplicaciones, realizar los wireframes para definir el aspecto de las aplicaciones, transformar el esquema conceptual en el diagrama de clases de diseño, definir el modelo y el esquema de la base de datos y los diagramas de secuencia de cada caso de uso. La implementación fue compleja ya que intervenían diferentes lenguajes de programación y tecnologías que debían ser integradas. En cuanto al mantenimiento, en apartados posteriores se proponen nuevas ideas, cambios y correcciones para obtener un sistema más completo. 149 12.2. Desviaciones en la planificación y presupuesto Se da por acabado el proyecto el 16 de enero de 2015, con una suma de 465 horas y con una pequeña desviación temporal respecto la planificación inicial. A continuación se muestra una tabla con la suma de horas alcanzada por cada fase del proyecto: Fases Duración % I. Análisis previo 45h 9,7% II. Gestión de proyectos 65h 14% III. Análisis de Requisitos 17h 3,6% IV. Especificación 65h 14% V. Diseño, Implementación y Pruebas 247h 53,2% VI. Final 26h 5,5% TOTAL 465h 100% Tabla 82: Distribución de horas reales y porcentaje de trabajo en las fases del proyecto Por lo tanto, hay una desviación de 33 horas, un 8% más según lo que se había planificado. En mi opinión, son datos muy positivos que indican que la planificación fue correcta y el alcance del proyecto ajustado al tiempo disponible. Tal y como se especificó en el apartado de control de gestión, una vez acabado el proyecto se contabilizan las horas de trabajos que cada rol ha dedicado, y se comparan con las que se había planificado; el resultado obtenido es el siguiente. Rol Horas estimadas (HE) Coste estimado (CE) Horas reales (HR) Coste real (CR) Jefe de proyecto 165h 8.250€ 136h 6.800€ Analista 71h 2.840€ 82h 3.280€ Diseñador 60h 2.100€ 37h 1.295€ Programador 104h 2.600€ 173h 4.325€ Tester 32h 640€ 37h 740€ Tabla 83: Relación entre las horas estimadas y horas reales de trabajo, y el coste asociado En el caso concreto de los roles de diseñador, programador y tester, se han tenido que distribuir las horas según una ponderación aproximada del porcentaje de tiempo que han estado implicados; la contabilización del tiempo en la fase iterativa es complejo ya que uno mismo cambia de rol muchas veces para programar, probar, revisar, y volver a probar el trabajo realizado. El porcentaje ha sido de un 15% para el rol de diseñador, 70% para el de programador ya que era el que realizaba los cambios según se iban haciendo pruebas, y un 15% para el rol de tester. 150 El gasto real de recursos humanos asciende a 16.440€, un coste económico extra de 10€, según lo planificado; esto es debido a que se ha trabajado más horas con un rol con menos retribución económica, y por contra, se han trabajado menos horas en roles como jefe de proyecto o analista que tenían un mejor salario. En cuanto a gastos generales, se ha consumido más energía eléctrica y un período de días más de acceso a internet, con un aumento de aproximadamente 26€. Quitando la partida del nivel de contingencia y gastos imprevistos que se especificaron en el presupuesto y actualizando el importe de las partidas mencionadas, el coste real del proyecto ha sido de 16.745,18€. A continuación se muestra el diagrama de Gantt final, los cambios aparecen en la fase de diseño, programación y pruebas, donde se ha dedicado más tiempo de trabajo, tal y como se ha visto en las tablas anteriores. La fase final también se ha extendido más días de los que estaba previsto y se ha solapado con la última parte de las pruebas. 151 Figura 92: Diagrama de Gantt final 12.3. Diagrama de Gantt final 152 12.4. Limitaciones y dificultades Debido a la escasez de tiempo, complejidad y prioridad he tenido que modificar o recortar algunas funcionalidades que inicialmente se habían diseñado. En primer lugar, no se implementará el cambio de interfaz para personas mayores, es necesario añadir muchas reglas de control para que la aplicación se comporte correctamente, ya que habría que automatizar prácticamente toda la aplicación para que requiera muy pocas acciones por parte del usuario. Además, sería necesaria la colaboración de un diseñador gráfico para saber con exactitud cuáles son las necesidades de este colectivo para adaptar la interfaz. Por otra parte, el modo de supervisor se ha implementado pero con menos funciones que se había pensado. Estaba previsto permitir que este tipo de usuarios recibiera avisos cuando ocurrieran errores en el dispositivo del supervisado; he decidido no implementar estos avisos porqué requerirían utilizar la plataforma GCM (Google Cloud Messaging) con la cual no estoy familiarizado y supondría un esfuerzo grande para funciones poco relevantes. 12.5. Trabajo futuro El proyecto ha cumplido con los objetivos que se plantearon en el inicio, pero el sistema puede adquirir muchas más funcionalidades a partir de las existentes y modificaciones en diversos aspectos. A continuación se describen alguna de ellas: En cuanto al diseño gráfico, la aplicación web necesitaría una evaluación por parte de diseñadores gráficos y expertos en usabilidad para implementar mejoras, al igual que la aplicación Android, que si hubiera habido más tiempo se habría utilizado las nuevas guías de diseño que propone Google, Material Design, que muchas aplicaciones están adoptando. En segundo lugar, dados mis pocos conocimientos en seguridad informática sería necesario auditar y valorar qué cambios se deben hacer para minimizar riesgos ya que, por ley, es necesario proteger este tipo de datos, que además son muy sensibles. Las medidas de seguridad actuales seguramente son insuficientes y muy estándar. A nivel de funcionalidades de la aplicación web, se debe acoplar un sistema de gestión de visitas y la historia clínica de cada paciente (no únicamente el historial de recetas) para empezar a ser un sistema más completo. El sistema está preparado para soportar los idiomas Catalán e Inglés, además del Castellano, por lo que para hacerlo más accesible, se podría traducir. La aplicación Android es la que más funcionalidades podría incorporar, los supervisores deberían tener un rol más importante y poder envíar notificaciones al dispositivo de su supervisado, recibir automáticamente alertas en sus dispositivos cuando se hacen cambios o hay un retraso, y una forma de activar las notificaciones de forma semi-remota (haciendo que el paciente únicamente acepte las configuraciones que ha introducido su supervisor para así poder programar su teléfono). También estudiar alternativas para evitar un uso fraudulento de la aplicación, incorporar información de las próximas visitas con recordatorios, abrir un canal de comunicación online con los médicos que han prescrito los medicamentos para solucionar dudas, etc. 153 Otro de los aspectos que habría que mejorar son las imágenes de los medicamentos, se ha conseguido una base de datos bastante grande de los envases, pero es difícil mantenerla si los laboratorios farmacéuticos van haciendo cambios. También se podría implementar la funcionalidad de que los usuarios hagan ellos mismos las fotografías, aunque lo ideal sería contar con una base de datos de las imágenes de cada medicamento como ha hecho el gobierno de Estados Unidos con Pillbox. Finalmente, uno de los temas más relevantes y problemáticos es cómo introducir a las personas mayores en el uso de nuevas tecnologías, no es tarea fácil conseguirlo, aún menos si el paciente no está predispuesto. Sería necesario incorporar, pulseras, relojes inteligentes, despertadores, televisiones de última generación y otros dispositivos que se conectaran con el sistema para simplificar al máximo el problema y conseguir que lo utilicen mediante comandos de voz u otras alternativas.