Aplicación web para la creación y revisión de historias clínicas online

Grado en Ingenier´ıa Inform´atica Trabajo Fin de Grado Aplicaci´on web para la creaci´on y revisi´on de historias cl´ınicas online Ismael Romero Rando Tutor: Javier S´anchez P´erez Las Palmas de Gran Canaria 12 de julio de 2017 ´ Indice general 1. Introducci´on 1 1.1. Motivaci´on............................. 2 1.2. Objetivos ............................. 3 1.2.1. Objetivos generales del proyecto . . . . . . . . . . . . . 3 1.2.2. Objetivos acad´emicos . . . . . . . . . . . . . . . . . . . 4 1.3. Aportaciones al entorno social . . . . . . . . . . . . . . . . . . 4 1.4. Estructura del Documento . . . . . . . . . . . . . . . . . . . . 5 2. Estado actual del tema 7 2.1. La iniciativa eSalud . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Iniciativas en Europa . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. Plan de acci´on de eSalud 2004-2011 . . . . . . . . . . . 8 2.2.2. Plan de acci´on de eSalud 2012-2020 . . . . . . . . . . . 9 2.3. Iniciativas en Espa˜na . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. Convenio Marco . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2. Esquema de Interoperabilidad . . . . . . . . . . . . . . 11 2.4. Estado de las historias cl´ınicas . . . . . . . . . . . . . . . . . . 12 2.5. Alternativas Software . . . . . . . . . . . . . . . . . . . . . . . 13 2.5.1. ClinicCloud........................ 13 2.5.2. KlinCloud ........................ 14 2.5.3. Historias Cl´ınicas Online . . . . . . . . . . . . . . . . . 15 2.5.4. Doctoralia......................... 16 2.5.5. InfoM´edicos........................ 17 ´ INDICE GENERAL 3. Recursos utilizados 19 3.1. Hardware ............................. 19 3.2. Software.............................. 19 3.2.1. Netbeans 8.1 . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.2. Apache Derby (Java DB) . . . . . . . . . . . . . . . . . 20 3.2.3. GlassFish Server 4.1.1 . . . . . . . . . . . . . . . . . . 20 3.2.4. Sistema Operativo: Windows 10 . . . . . . . . . . . . . 21 3.3. Librer´ıas.............................. 21 3.3.1. JavaEE.......................... 22 3.3.2. Librer´ıa javax.servlet . . . . . . . . . . . . . . . . . . . 22 3.4. Otras herramientas utilizadas . . . . . . . . . . . . . . . . . . 23 3.4.1. Adobe Phothoshop CC . . . . . . . . . . . . . . . . . . 23 3.4.2. LaTex/TeXstudio . . . . . . . . . . . . . . . . . . . . . 23 4. Plan de trabajo y temporizaci´on 25 4.1. Planificaci´on del proyecto . . . . . . . . . . . . . . . . . . . . 25 4.1.1. Modelo del proyecto . . . . . . . . . . . . . . . . . . . 25 4.1.2. Metodolog´ıa Scrum . . . . . . . . . . . . . . . . . . . . 27 4.2. PlandeNegocio.......................... 29 4.2.1. Costes Hardware . . . . . . . . . . . . . . . . . . . . . 29 4.2.2. Costes Software . . . . . . . . . . . . . . . . . . . . . . 29 4.2.3. Costes Personal . . . . . . . . . . . . . . . . . . . . . . 30 4.2.4. Otros Costes . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.5. Costes Totales y posibles modelos de negocio . . . . . . 30 5. Desarrollo del Proyecto 33 5.1. Requisitos............................. 33 5.1.1. Product Backlog . . . . . . . . . . . . . . . . . . . . . 33 5.1.2. Requisitos del Software . . . . . . . . . . . . . . . . . . 36 5.2. Dise˜no............................... 39 5.2.1. Modelos de Base de Datos . . . . . . . . . . . . . . . . 39 5.2.2. Dise˜no de la Interfaz de Usuario . . . . . . . . . . . . . 40 5.3. Sprint0 .............................. 42 ´ INDICE GENERAL 5.3.1. Objetivo del Sprint . . . . . . . . . . . . . . . . . . . . 42 5.4. Sprint1 .............................. 43 5.4.1. Objetivo del Sprint . . . . . . . . . . . . . . . . . . . . 43 5.4.2. Funcionalidades implementadas . . . . . . . . . . . . . 44 5.4.3. Retrospectiva del Sprint . . . . . . . . . . . . . . . . . 45 5.5. Sprint2 .............................. 45 5.5.1. Objetivo del Sprint . . . . . . . . . . . . . . . . . . . . 45 5.5.2. Funcionalidades implementadas . . . . . . . . . . . . . 47 5.5.3. Retrospectiva del Sprint . . . . . . . . . . . . . . . . . 48 5.6. Sprint3 .............................. 48 5.6.1. Objetivo del Sprint . . . . . . . . . . . . . . . . . . . . 48 5.6.2. Funcionalidades implementadas . . . . . . . . . . . . . 50 5.6.3. Retrospectiva del Sprint . . . . . . . . . . . . . . . . . 50 6. Conclusiones y trabajo futuro 51 6.1. Conclusiones............................ 51 6.2. TrabajoFuturo .......................... 52 A. Competencias espec´ıficas cubiertas 55 B. Manual de Usuario 57 B.1.General .............................. 57 B.1.1. Registro .......................... 57 B.1.2. Inicio y Cierre de Sesi´on . . . . . . . . . . . . . . . . . 58 B.1.3. Buscar M´edicos . . . . . . . . . . . . . . . . . . . . . . 60 B.2.Paciente.............................. 61 B.2.1. Informaci´on Cl´ınica . . . . . . . . . . . . . . . . . . . . 62 B.2.2. Perfil............................ 62 B.2.3. Historial Cl´ınico . . . . . . . . . . . . . . . . . . . . . . 63 B.2.4. Notificaciones . . . . . . . . . . . . . . . . . . . . . . . 64 B.2.5. Consentimientos . . . . . . . . . . . . . . . . . . . . . . 65 B.3.M´edico............................... 65 B.3.1. Historias Cl´ınicas . . . . . . . . . . . . . . . . . . . . . 65 ´ INDICE GENERAL B.3.2. Pacientes ......................... 66 B.4.Administrador........................... 67 B.4.1. Administrar Usuarios . . . . . . . . . . . . . . . . . . . 67 C. Normativa y Legislaci´on 69 C.1. Ley de Protecci´on de Datos . . . . . . . . . . . . . . . . . . . 69 ´ Indice de figuras 2.1. Logo de Clinic Cloud . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. Aplicaci´on de Clinic Cloud . . . . . . . . . . . . . . . . . . . . 14 2.3. Logo de Klin Cloud . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. Aplicaci´on Klin Cloud . . . . . . . . . . . . . . . . . . . . . . 15 2.5. Logo de Historias Cl´ınicas . . . . . . . . . . . . . . . . . . . . 15 2.6. Aplicaci´on Historias Cl´ınicas . . . . . . . . . . . . . . . . . . . 16 2.7. Logo de Doctoralia . . . . . . . . . . . . . . . . . . . . . . . . 16 2.8. Aplicaci´on Doctoralia . . . . . . . . . . . . . . . . . . . . . . . 17 2.9. Logo de InfoM´edicos . . . . . . . . . . . . . . . . . . . . . . . 17 2.10. Aplicaci´on InfoM´edicos . . . . . . . . . . . . . . . . . . . . . . 18 3.1. LogodeNetbeans......................... 19 3.2. Logo de Apache Derby (Java DC) . . . . . . . . . . . . . . . . 20 3.3. Logo de GlassFish Server . . . . . . . . . . . . . . . . . . . . . 20 3.4. Logo de Windows 10 . . . . . . . . . . . . . . . . . . . . . . . 21 3.5. LogodeJavaEE ......................... 22 3.6. Logo de Adobe Photoshop CC . . . . . . . . . . . . . . . . . . 23 3.7. Logo de TeXstudio . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1. Proceso de del desarrollo por iteraciones incrementales . . . . 26 4.2. Tabla de las actividades desarrolladas en cada fase . . . . . . . 26 4.3. Proceso de la metodolog´ıa Scrum . . . . . . . . . . . . . . . . 28 5.1. Product Backlog, primera parte . . . . . . . . . . . . . . . . . 33 5.2. Product Backlog, segunda parte . . . . . . . . . . . . . . . . . 34 ´ INDICE DE FIGURAS 5.3. Product Backlog, tercera parte . . . . . . . . . . . . . . . . . . 35 5.4. Casos de uso del paciente . . . . . . . . . . . . . . . . . . . . . 36 5.5. Casos de uso del m´edico . . . . . . . . . . . . . . . . . . . . . 37 5.6. Casos de uso del administrador . . . . . . . . . . . . . . . . . 38 5.7. Modelo de la Base de Datos . . . . . . . . . . . . . . . . . . . 39 5.8. Prototipo del perfil de usuario . . . . . . . . . . . . . . . . . . 40 5.9. Prototipo de historias cl´ınicas . . . . . . . . . . . . . . . . . . 41 5.10. Prototipo de listados . . . . . . . . . . . . . . . . . . . . . . . 41 5.11. Prototipo de las notificaciones . . . . . . . . . . . . . . . . . . 42 5.12. Sprint backlog del primer sprint . . . . . . . . . . . . . . . . . 43 5.13. Sprint backlog del segundo sprint . . . . . . . . . . . . . . . . 46 5.14. Sprint backlog del tercer sprint . . . . . . . . . . . . . . . . . 49 B.1. Acceso a registrarse . . . . . . . . . . . . . . . . . . . . . . . . 57 B.2. Formulario de Registro . . . . . . . . . . . . . . . . . . . . . . 58 B.3.Iniciodesesi´on .......................... 58 B.4. P´agina principal tras iniciar sesi´on . . . . . . . . . . . . . . . 59 B.5.Cierredesesi´on.......................... 60 B.6. B´usqueda de m´edicos por especialidad . . . . . . . . . . . . . 60 B.7. Listado de m´edicos . . . . . . . . . . . . . . . . . . . . . . . . 61 B.8. Perfil de un m´edico . . . . . . . . . . . . . . . . . . . . . . . . 61 B.9. Acceso a la informaci´on cl´ınica . . . . . . . . . . . . . . . . . . 62 B.10.Formulario de la informaci´on cl´ınica . . . . . . . . . . . . . . . 62 B.11.Accesoalperfil .......................... 62 B.12.Formulario para modificar el perfil . . . . . . . . . . . . . . . . 63 B.13.Acceso a las historias cl´ınicas . . . . . . . . . . . . . . . . . . 63 B.14.Listado de historias cl´ınicas . . . . . . . . . . . . . . . . . . . 63 B.15.Acceso al env´ıo de notificaciones . . . . . . . . . . . . . . . . . 64 B.16.Acceso a las notificaciones . . . . . . . . . . . . . . . . . . . . 64 B.17.Listado de notificaciones . . . . . . . . . . . . . . . . . . . . . 64 B.18.Acceso a los consentimientos . . . . . . . . . . . . . . . . . . . 65 B.19.Listado de consentimientos . . . . . . . . . . . . . . . . . . . . 65 ´ INDICE DE FIGURAS B.20.Acceso a historias cl´ınicas creadas por el propio usuario . . . . 65 B.21.Listado de historias cl´ınicas . . . . . . . . . . . . . . . . . . . 66 B.22.Acceso a pacientes . . . . . . . . . . . . . . . . . . . . . . . . 66 B.23.Listado de pacientes con el estado de los consentimientos . . . 66 B.24.Opci´on para la creaci´on de una nueva historia cl´ınica . . . . . 67 B.25.Acceso a la administraci´on de usuarios . . . . . . . . . . . . . 67 B.26.Listado de usuarios . . . . . . . . . . . . . . . . . . . . . . . . 68 ´ INDICE DE CUADROS Abstract The field of healthcare has long been introducing new technologies little by little.As part of this trend are born concepts such as e-health, which is an initiative that encourages the use of ICT in the world of medicine. Thanks to this type of initiative, the field of health care has aroused the interest of many developers, who see in this area an opportunity to create tools that help the health workers perform their tasks, as well as open the way to new methods of consulting the clinical information by the patients. All this has motivated the final project of this document. This project aims to create a web application that allows to manage the clinical history, from its creation to its subsequent consultation. Finally, this project has been developed with agile methodologies (Scrum), allowing the student to produce a functional product with the required quality. This project has been developed with the idea of being the basis for the incorporation of more functionalities in a future. ´ INDICE DE CUADROS “No es el m´as fuerte de las especies el que sobrevive, tampoco es el m´as inteligente el que sobrevive. Es aquel que es m´as adaptable al cambio.” Charles Darwin. Cap´ıtulo 1 Introducci´on Actualmente, la inform´atica tiene una gran importancia en todos los ´ambitos de nuestra sociedad. Esto se debe a las numerosas herramientas que ofrece, las cuales han cambiado por completo la realizaci´on de determinadas tareas o la manera en que nos comunicamos. En el ´ambito laboral la inform´atica ha supuesto la evoluci´on de muchas profesiones e incluso la creaci´on de otras totalmente nuevas. Dentro de la medicina esta tendencia ha provocado la aparici´on de conceptos como la eSalud. La eSalud trata de incorporar las ventajas que proporciona las TICs al entorno sanitario. Esto ha supuesto un impacto y revoluci´on en la forma en que se desarrolla el sector salud, incrementando la eficiencia, lo que se refleja en reducci´on de costos y una mejora en la calidad del servicio. Por otro lado, la aparici´on de la eSalud ha motivado una serie de iniciativas europeas. Para la implantaci´on de las medidas e iniciativas se ha a cabo mediante dos planes de acci´on. El primero de ellos se desarroll´o entre 2004 y 2011 teniendo como principal objetivo la incorporaci´on de las tarjetas sanitarias y las recetas electr´onicas entre otros servicios. El segundo plan se est´a llevando a cabo actualmente, ya que engloba el periodo comprendido entre 2012 y 2020. Este plan de acci´on pretende realizar mejoras en la investigaci´on, desarrollo e innovaci´on, una mayor interoperabilidad de los servicios de cibersalud y garantizar un mayor despliegue de la eSalud. A nivel nacional, siguiendo los planes de acci´on establecidos por Europa, se ha llevado a cabo varias mejoras en sus servicios pertenecientes a la cibersalud con la creaci´on de un Convenio Marco con el objetivo de mejorar la atenci´on sanitaria que se presta a los pacientes, utilizando para ello las ventajas que aportan las nuevas tecnolog´ıas. A ra´ız de este convenio se ha dado paso a la incorporaci´on de nuevos servicios en l´ınea y el desarrollo de 1 2CAP´ ITULO 1. INTRODUCCI ´ ON sistemas de interoperabilidad Dentro de todas estas medidas est´a la creaci´on de historias cl´ınicas electr´onicas, la cuales son el motivo principal de la creaci´on de nuestro TFG. En este proyecto se tiene por objetivo la realizaci´on de un software que permita la creaci´on y gesti´on de historias cl´ınicas online contribuyendo as´ı a las iniciativas que promueve la eSalud, tratando de incorporar las ventajas que proporciona las TICs al entorno sanitario. El desarrollo de esta aplicaci´on tiene como fin facilitar la labor del personal sanitario a la hora de elaborar la documentaci´on perteneciente a las historias cl´ınicas. Por otra parte, esta aplicaci´on proporcionar´a al paciente un acceso sencillo a sus historias cl´ınicas, favoreciendo la interacci´on entre m´edico y paciente, la cual es de vital importancia para ayudar a la mejora del servicio sanitario. Para poder desarrollar esta aplicaci´on se ha seguido la metodolog´ıa Scrum, adem´as de la utilizaci´on de varias herramientas y librer´ıas como Java EE. Por otra parte, se han aplicado los conocimientos adquiridos durante la carrera como los obtenidos en la programaci´on con lenguajes como Java o HTML 5 con el objetivo de proporcionar el mejor resultado posible de la aplicaci´on 1.1. Motivaci´on La principal motivaci´on para el desarrollo de este TFG es la realizaci´on de un proyecto mediante metodolog´ıas ´agiles como Scrum, adem´as de poner en pr´actica los conocimientos adquiridos durante la carrera, especialmente los obtenidos en la especificaci´on de Software. Una vez establecidos los criterios, procedimos a reunirnos con nuestro tutor Javier S´anchez P´erez con la finalidad de buscar un proyecto el cual se adaptara y permitiera desarrollar los conocimientos marcados como objetivo previamente. A ra´ız de esa reuni´on, se propuso la realizaci´on del software ((Aplicaci´on web para la creaci´on y revisi´on de historias cl´ınicas online)). Por otro lado la pertenencia del proyecto al ´ambito de la salud refuerza nuestro inter´es por el software a desarrollar, ya que permite investigar y ampliar horizontes en los que poder desarrollarse debido a las particularidades propias que ofrece el mundo de la medicina. 1.2. OBJETIVOS 3 1.2. Objetivos 1.2.1. Objetivos generales del proyecto El proyecto ((Aplicaci´on web para la creaci´on y revisi´on de historias cl´ınicas online)) tiene como objetivo principal facilitar el acceso al historial m´edico de los usuarios, tanto por parte del paciente como del m´edico. Para ello el software cumple una serie de objetivos m´as espec´ıficos los cuales dividiremos entre los que pertenecen a los pacientes y los m´edicos. Por parte del paciente el software contiene las siguientes caracter´ısticas: Visualizaci´on de su historial m´edico, el cual contiene todas las historias cl´ınicas creadas por los diferentes m´edicos en cada consulta realizada al paciente. Sistema de consentimientos que no permite la visualizaci´on de su historial a ning´un m´edico que no haya solicitado el consentimiento previo del paciente. Por otro lado, el m´edico tendr´a las siguientes funcionalidades disponibles: Visualizaci´on del historial m´edico de un paciente, el cual contiene todas las historias cl´ınicas creadas por los diferentes m´edicos en cada consulta realizada al paciente. Creaci´on de historias cl´ınicas con las que recoger los datos relevantes de una consulta. Sistema de consentimientos que nos permite solicitar el acceso al historial m´edico de un paciente. Adem´as de las caracter´ısticas particulares de pacientes y m´edicos, el software contiene una serie de funcionalidades generales para todos los usuarios registrados en el sistema: Enviar y recibir notificaciones referentes a las diferentes historias cl´ınicas, permitiendo una comunicaci´on entre los pacientes y m´edicos. Gesti´on de la cuenta de usuario con un perfil modificable. B´usqueda de pacientes o m´edicos por diferentes par´ametros. Por ´ultimo, el software contiene un tercer tipo de usuario que corresponde al administrador, el cual tiene unas breves funcionalidades que le permite gestionar los usuarios del sistema. 4CAP´ ITULO 1. INTRODUCCI ´ ON 1.2.2. Objetivos acad´emicos Uno de los objetivos principales es el de aplicar con ´exito la metodolog´ıa ´agil Scrum en el desarrollo de un proyecto real, sirviendo para poner en pr´actica lo aprendido durante la especializaci´on de ingenier´ıa del software. La aplicaci´on de Scrum tambi´en se ver´a reflejada en la planificaci´on y gesti´on del proyecto. Para dicho proyecto se crear´a una base de datos relacional, la cual nos ayudar´a a poner en pr´actica los conocimientos adquiridos sobre SQL. Por otro lado los lenguajes de programaci´on que se usar´an son Java y HTML5, adem´as de hojas de estilo para el dise˜no de la web. La aplicaci´on de esto lenguajes durante el desarrollo nos permitir´a aplicar los conocimientos sobre programaci´on obtenidos durante la carrera, incluyendo los pertenecientes al dise˜no de interfaces. Por ´ultimo, el proyecto ser´a desarrollado mediante el patr´on de dise˜no FrontController, el cual establece un controlador que manejara todas las peticiones que se realicen desde la aplicaci´on web ofreciendo una serie de ventajas descritas a continuaci´on: Control centralizado de las peticiones Mayor reusabilidad del c´odigo. Mejoras en la gesti´on de la seguridad. 1.3. Aportaciones al entorno social Las aportaciones que ofrece la aplicaci´on en el entorno social van de la mano con la iniciativa eSalud, la cual quiere introducir las ventajas de las TICs en el ´ambito de la sanidad. Esta aplicaci´on se ha desarrollado con el objetivo de ofrecer una alternativa a uno de los procesos tan importante en la sanidad como la elaboraci´on de las historias cl´ınicas y el acceso posterior a ellas. Dicha aplicaci´on ofrece facilidades tanto a los pacientes como a los m´edicos para gestionar las historias cl´ınicas. Por otro lado, la naturaleza web de la propia aplicaci´on facilita el acceso desde cualquier lugar, quitando la necesidad de visitar un centro sanitario para poder revisar tu historial m´edico. Finalmente, podemos considerar que esta aplicaci´on pretende aportar su granito de arena a mejorar el servicio sanitario, el cual es uno de los pilares de la sociedad. 1.4. ESTRUCTURA DEL DOCUMENTO 5 1.4. Estructura del Documento En esta secci´on se har´a un breve resumen de cada uno de los cap´ıtulos, con la intenci´on de facilitar la lectura de este documento. Tambi´en es recomendable seguir la estructura establecida para el orden de lectura de los cap´ıtulos, ya que muchos de ellos se desarrollan en base a lo visto en cap´ıtulos anteriores. Cap´ıtulo 2 Estado del Arte: En este cap´ıtulo se hablar´a sobre el ´ambito en el que se desarrolla este proyecto, haciendo hincapi´e en la iniciativa eSalud, adem´as de las diferentes alternativas existentes a la aplicaci´on desarrollada. Cap´ıtulo 3 Recursos Utilizados: En este cap´ıtulo se explicar´an las diferentes herramientas y tecnolog´ıas usadas para la elaboraci´on de este proyecto. Cap´ıtulo 4 Plan de trabajo y temporizaci´on: En este cap´ıtulo se hablar´a del modelo y metodolog´ıa escogidos para la elaboraci´on de este proyecto. Por otro lado, tambi´en se explicar´a el plan de negocio escogidos, incluyendo costes y los posibles m´etodos de financiaci´on estudiados Cap´ıtulo 5 Desarrollo del proyecto: Este cap´ıtulo explicar´a de manera extensa todo lo referente a la elaboraci´on del proyecto. Se mostrar´an diagramas y prototipos, adem´as de la explicaci´on del trabajo realizado en cada una de las diferentes iteraciones realizadas durante el desarrollo de la aplicaci´on Cap´ıtulo 6 Conclusiones y trabajo futuro: En este cap´ıtulo se expondr´a las conclusiones tras la elaboraci´on de este proyecto y la explicaci´on de futuras l´ıneas de trabajo disponibles para la mejora y ampliaci´on de la aplicaci´on. Anexos: Por ´ultimo, los anexos contendr´an informaci´on sobre las competencias cubiertas durante el proyecto, un manual de usuario, adem´as de la normativa y legislaci´on necesaria para el correcto desarrollo de este proyecto. 12 CAP´ ITULO 2. ESTADO ACTUAL DEL TEMA Intercambio de mensajes cifrados y firmados: Las comunicaciones entre los sistemas cliente y el n´ucleo del SNS se realiza encriptada mediante el protocolo SSL v3, adem´as de que los mensajes enviados ser´an firmados digitalmente por el emisor y comprobados por el emisor. Usuarios registrados: La autentificaci´on de los sistemas cliente (los Servicios de Salud) se realiza mediante la utilizaci´on de certificados digitales X509v3. Con dichos certificados se identifican a cada uno de los servidores que acceden al sistema y al servidor propio del SNS. Independencia de las plataformas: Al usar XML como est´andar de intercambio, el sistema permite una r´apida integraci´on con otras aplicaciones o sistemas que operen con el mismo est´andar. Esto se puede aplicar no solo a nivel nacional, sino tambi´en Europeo o mundial. Inclusi´on de nuevos servicios: La inclusi´on de nuevos servicios se realiza mediante la definici´on de nuevos mensajes XML, lo que permite la prestaci´on de nuevas funcionalidades reutilizando la plataforma existente. sin necesidad de cambiar el modo de operaci´on. Implementaci´on de procedimientos de calidad: Con esto se busca garantizar la calidad de la informaci´on y los procesos que se incorporen al SNS. 2.4. Estado de las historias cl´ınicas En la actualidad, existen proyectos como el de ((Historia Cl´ınica Digital del Sistema Nacional de Salud(HCDSNS))) promovido por el Ministerio de Sanidad, Servicios Sociales e Igualdad en el cual se tiene como objetivo poder proporcionar a pacientes y personal sanitario acceder a documentaci´on cl´ınica, adem´as de restringir el acceso a dicha documentaci´on s´olo a quien est´e autorizado para ello. Por otra parte, existen varias alternativas que permiten gestionar las historias cl´ınicas. Pese a esta variedad, la mayor´ıa de ellas enfocan su aplicaci´on hacia el personal sanitario, excluyendo la posibilidad de que los pacientes puedan consultar su historial m´edico o realizar cualquier otro tipo de funcionalidad como hace el HCDSNS. En este apartado se har´a un breve estudio de varias de las alternativas, estudiando las funcionalidades que ofrecen al usuario de la aplicaci´on. 2.5. ALTERNATIVAS SOFTWARE 13 2.5. Alternativas Software 2.5.1. Clinic Cloud Figura 2.1: Logo de Clinic Cloud Clinic Cloud es un gestor de cl´ınicas en la nube, el cual permite tener usuarios con diferentes niveles de permisos controlando as´ı las funcionalidades a las que tiene acceso cada usuario. Adem´as de la gesti´on de historias cl´ınicas, Clinic Cloud tambi´en posee otras funcionalidades como agendas con las que gestionar las citas e incluso un servicio de marketing con el que informar a sus clientes de novedades en la cl´ınica. Por otro lado, tambi´en ofrece soporte a otras ´areas con funcionalidades para la gesti´on estrat´egica, organizativa o administrativa de la cl´ınica. Por ´ultimo, este servicio es de pago, limitando algunas de las funcionalidades disponibles para las tarifas de pago mayores. 14 CAP´ ITULO 2. ESTADO ACTUAL DEL TEMA Figura 2.2: Aplicaci´on de Clinic Cloud 2.5.2. Klin Cloud Figura 2.3: Logo de Klin Cloud Klin Cloud al igual que la aplicaci´on anterior, es un gestor de cl´ınicas en la nube, la cual permite gestionar las historias cl´ınicas de pacientes. Tambi´en ofrece funcionalidades para gestionar citas y organizar la agenda de los usuarios. Este software tambi´en ofrece gesti´on econ´omica y organizativa de la cl´ınica. Por ´ultimo dicho servicio es de pago aunque en este caso no hay funcionalidades exclusivas de las tarifas que pagues, ofreciendo diferentes tipos de suscripciones en funci´on del tiempo que contrates el servicio. 2.5. ALTERNATIVAS SOFTWARE 15 Figura 2.4: Aplicaci´on Klin Cloud 2.5.3. Historias Cl´ınicas Online Figura 2.5: Logo de Historias Cl´ınicas Esta aplicaci´on ofrece un gestor de historias cl´ınicas en la nube y una gran cantidad de funciones extra. Entre estas funciones podemos encontrar un gestor de agendas y citas, acceso a la base de datos CIE 10, organizar grupos de terapias... Por otro lado, el software ofrece funcionalidades como la gesti´on de facturaci´on o del personal sanitario. Por ´ultimo este servicio ofrece tarifas en las que var´ıa el n´umero de usuarios y pacientes con los que podr´a trabajar la aplicaci´on, as´ı como limitar otras caracter´ısticas como el almacenamiento de archivos o algunas funcionalidades. 16 CAP´ ITULO 2. ESTADO ACTUAL DEL TEMA Figura 2.6: Aplicaci´on Historias Cl´ınicas 2.5.4. Doctoralia Figura 2.7: Logo de Doctoralia Este portal web nos ofrece informaci´on sobre una amplia cantidad de especialistas sanitarios. Esta aplicaci´on incorpora un sistemas de citas que sumado a lo anterior, permite al usuario reservar una cita online de manera f´acil y sencilla una vez encuentre un especialista adecuado. Por otro lado tambi´en tiene un servicio que permite que los diferentes expertos responda a preguntas relacionadas con la salud. 2.5. ALTERNATIVAS SOFTWARE 17 Figura 2.8: Aplicaci´on Doctoralia 2.5.5. InfoM´edicos Figura 2.9: Logo de InfoM´edicos Esta web al igual que la anterior, permite la b´usqueda de especialistas sanitario. Estas b´usquedas pueden ser realizadas mediante provincias o especialidades. Una vez encontrado el especialista, se nos mostrar´a su informaci´on de contacto, al contrario del portal anterior que nos permit´ıa realizar la reserva de una cita online. Por ´ultimo este web tambi´en tiene un sistema de preguntas sobre salud, el cual ofrecer´a un buscador que permitir´a encontrar preguntas similares o de realizar la nuestra en caso de no encontrar la respuesta que buscamos en las preguntas ya realizadas por otros usuarios. 18 CAP´ ITULO 2. ESTADO ACTUAL DEL TEMA Figura 2.10: Aplicaci´on InfoM´edicos Cap´ıtulo 3 Recursos utilizados 3.1. Hardware Las principales especificaciones del hardware del port´atil utilizado para el desarrollo del proyecto son una CPU Intel Core i7-4510U, 4 Gb de RAM y una tarjeta gr´afica Nvidia Geforce 820m 3.2. Software 3.2.1. Netbeans 8.1 Figura 3.1: Logo de Netbeans Este proyecto ha sido desarrollado en Netbeans 8.1 el cual es un entorno de desarrollo gratuito y de c´odigo abierto. Netbeans da soporte a diferentes tecnolog´ıas como Java, C/C++, HTML5, PHP,... Otra de las caracter´ısticas de Netbeans es que nos permite el acceso a distintos gestores de bases de 19 20 CAP´ ITULO 3. RECURSOS UTILIZADOS datos como Oracle o MySql, permiti´endonos modificar, consultar y visualizar el contenido de la base de datos desde el propio IDE de Netbeans. Por ´ultimo, Netbeans permite la integraci´on con diversos servidores de aplicaciones como el GlassFish, el cual es utilizado durante el desarrollo del proyecto. 3.2.2. Apache Derby (Java DB) Figura 3.2: Logo de Apache Derby (Java DC) Apache Derby es una base de datos relacional la cual est´a programada en Java completamente. Actualmente Oracle distribuye el proyecto Apache Derby como Java DB. Java DB nos ofrece una gran variedad de caracter´ısticas. A continuaci´on pasaremos a enumerar las m´as importantes: Basada en los est´andares SQL y JDBC. Proporciona un driver JDBC que el cual se puede incrustar directamente en aplicaciones Java. Soporte de funcionamiento cliente/servidor Est´a escrita completamente en Java 3.2.3. GlassFish Server 4.1.1 Figura 3.3: Logo de GlassFish Server 3.3. LIBRER´ IAS 21 GlassFish es un servidor de aplicaciones de software libre que implementa y permite ejecutar aplicaciones que siguen las especificaciones definidas en Java EE. GlassFish soporta Enterprise JavaBeans, JPA, Java Server Pages, servlets,... Esto permite crear aplicaciones portables y escalables. 3.2.4. Sistema Operativo: Windows 10 Figura 3.4: Logo de Windows 10 El sistema operativo usado para el desarrollo de este proyecto ha sido Windows 10, el sistema operativo m´as reciente de Microsoft. Este SO introdujo una arquitectura de aplicaciones ((universales)), la cual permite que dichas aplicaciones puedan ser dise˜nadas para ejecutarse en todos los sistemas operativos pertenecientes a Microsoft. Tambi´en cabe destacar que Windows 10 viene con un ((modo programador)) el cual ofrece funciones pensadas para desarrolladores, como permitir la instalaci´on de aplicaciones universales que no pertenece a la tienda de Windows o facilitar el acceso a ciertas opciones del explorador de archivos que permanecen escondidas para usuarios normales. 3.3. Librer´ıas En esta secci´on haremos una breve descripci´on de las librer´ıas menos comunes utilizadas dentro de la aplicaci´on. 28 CAP´ ITULO 4. PLAN DE TRABAJO Y TEMPORIZACI ´ ON Retrospectiva: Reuni´on posterior al sprint en el que se analizan las cosas que han funcionado bien y cu´ales deben mejorarse. Refinamiento y modificaciones de la lista de requisitos y el proyecto: Este es un proceso que se hace durante el desarrollo del software, en el cual se ir´a trabajando con la lista de requisitos a˜nadiendo, eliminando, modificando o incluso cambiando la prioridad de los ya existentes. Figura 4.3: Proceso de la metodolog´ıa Scrum Con Scrum como metodolog´ıa pasamos a realizar una lista inicial con todas las historias de usuario que se iban a desarrollar para el proyecto, esta lista fue revisada tras cada iteraci´on o sprint. Una vez establecido esto, se estim´o que el proyecto ser´ıa desarrollado en tres sprint de unas tres semanas de duraci´on cada uno. A continuaci´on se expone un breve resumen del contenido de cada sprint: Primer Sprint: En este sprint se desarrolla las funcionalidades comunes a todos los usuarios permitiendo crear una base s´olida en la que seguir desarrollando el resto de historias de usuarios. En este sprint tambi´en se hace un primer dise˜no de la base de datos. Segundo Sprint: En este sprint se a˜naden las historias de usuario pertenecientes a los pacientes y los m´edicos. Las funcionalidades implemen- 4.2. PLAN DE NEGOCIO 29 tadas corresponden al manejo de las historias cl´ınicas y los antecedentes cl´ınicos. Tambi´en se a˜naden funciones de b´usqueda para todos los usuarios. Tercer Sprint: En este ´ultimo sprint se a˜nade la figura del administrador al sistema junto a una serie de funcionalidades que permiten gestionar usuarios. Tambi´en se a˜nade los consentimientos a la aplicaci´on, los cuales se apoyan en historias de usuarios desarrolladas en el sprint anterior. Por ´ultimo se trabaja en el dise˜no visual de la p´agina adem´as de unos ´ultimos detalles en la base de datos con este fin. 4.2. Plan de Negocio A continuaci´on se expondr´a los costes necesarios para la elaboraci´on de este proyecto incluyendo futuras actualizaciones durante el periodo de 3 a˜nos, adem´as de posibles modelos de negocio para financiar el proyecto. 4.2.1. Costes Hardware En los costes de Hardware vendr´an incluidos todo el equipo necesario para el trabajo de las 4 personas designadas en los costes de personal. Para ello se ha buscado equipos de gama media-alta los cuales puedan tener una duraci´on de entre 3-5 a˜nos antes de su renovaci´on en caso de ser necesario. Por ´ultimo tambi´en se a˜nade una impresora para el manejo de los documentos necesarios en papel. Hardware Coste(euros) Ordenador de sobremesa 4x800=3200 Monitor 4x100=400 Teclado+Rat´on 4x30=120 Impresora 100 Total 3820 Cuadro 4.1: Tabla de costes del hardware 4.2.2. Costes Software Los costes relacionados con el Software son 0, ya que se ha usado en todo momento herramientas gratuitas en todos y cada uno de los aspectos de la aplicaci´on. 30 CAP´ ITULO 4. PLAN DE TRABAJO Y TEMPORIZACI ´ ON Cabe destacar que si en un futuro se necesitase alguna herramienta de pago con el objetivo de obtener el mejor resultado posible en el desarrollo de la aplicaci´on, podr´ıa incluirse sin problemas en el presupuesto. 4.2.3. Costes Personal A continuaci´on se mostrar´a los costes relacionados a los sueldos del personal involucrado en el desarrollo de la aplicaci´on, adem´as como el equipo desarrollar´a en una oficina, se requerir´a servicios de limpieza los cuales se han incluido en la tabla. Personal Sueldo(euros) Jefe de proyecto 4000 Analista 2500 Dise˜nador 1600 Programador 2200 Limpiadora 900 Total 11260 Cuadro 4.2: Tabla de costes del personal 4.2.4. Otros Costes En este apartado se incluyen otros gastos necesarios como el alquiler de una oficina o el de suministros, que no entran en las categor´ıas de costes anteriormente descritas. Descripci´on Coste(euros) Alquiler de oficina 1200 Material de oficina 200 Internet 100 Agua 30 Luz 80 Total 1610 Cuadro 4.3: Tabla de otros costes 4.2.5. Costes Totales y posibles modelos de negocio En la siguiente tabla se mostrar´a el total de los costes durante el periodo de un a˜no para financiar el equipo de desarrollo y todos los costes necesarios. 4.2. PLAN DE NEGOCIO 31 Tambi´en se mostrar´a las cantidades necesarias para financiar todos los gastos necesarios en funci´on a 3 o 5 a˜nos de desarrollo. Dichos gastos corresponden al acumulado durante el periodo establecido. Costes 1 a˜no 3 a˜nos 5 a˜nos Hardware 3820 3820 3820 Software 0 0 0 Personal 11260x12=135120 135120x3=405360 135120x5=675600 Otros costes 1610x12=19320 19320x3=57960 19320x5=96600 Total 158260 467140 776020 Cuadro 4.4: Tabla costes totales A ra´ız de estos resultados tenemos que los gastos mensuales son aproximadamente unos 13.500 euros. Para poder financiar esto se han estudiado varios modelos de negocios, que pasaremos a enumerar. Publicidad: Este modelo tratar´ıa de conseguir la financiaci´on mediante la inclusi´on de publicidad de empresas interesadas en la p´agina. Suscripci´on mensual: Con esta opci´on se tratar´ıa de cubrir los costes mediante el cobro de una tarifa mensual a nuestros posibles clientes. Estudiando las alternativas, la cuota adecuada rondar´ıa los 30 euros. Este modelo requerir´ıa de un inversi´on inicial hasta poder autofinanciarse lo cual nos llevar´ıa a necesitar unas 450 suscripciones activas. KickStarter: La ´ultima opci´on ser´ıa la de promocionar nuestro proyecto en la plataforma de financiamientos KickStarter. En esta plataforma se establecer´ıa el coste total que llevar´ıa crear la aplicaci´on durante los 5 a˜nos con el objetivo de recibir la financiaci´on suficiente para cubrir todo el proceso de desarrollo de la aplicaci´on. Por otro lado, se ha estudiado el posible uso de un pr´estamo. Suponiendo que los ingresos anuales son de 175000 euros(cantidad m´ınima para abarcar todos los costes de un a˜no de desarrollo), el pr´estamo del que dispondremos ser´ıa de 61.250 euros que deber´ıa devolverse en el transcurso de los 5 a˜nos. Dicho pr´estamo incrementar´ıa los costes en 1160 euros mensuales, adem´as de una comisi´on de apertura de 307 euros dejando los costes totales como veremos a continuaci´on: 32 CAP´ ITULO 4. PLAN DE TRABAJO Y TEMPORIZACI ´ ON Costes 1 a˜no 3 a˜nos 5 a˜nos Hardware 3820 3820 3820 Software 0 0 0 Personal 135120 135120x3=405360 675600 Financieros 1160*12=13.920 13.920x3=41760 13.920x3=69.600 C.Apertura 307 307 307 Otros costes 19320 57960 96600 Total 172487 509207 845927 Cuadro 4.5: Tabla costes totales con pr´estamo Con este pr´estamo se incrementar´ıa los costes, pero a cambio cubrir´ıamos los gastos de los primeros 4 o 5 meses hasta que el proyecto pudiese asegurar otras v´ıas de financiaci´on o incluso auto-financiarse con los modelos de negocios explicados anteriormente. Cap´ıtulo 5 Desarrollo del Proyecto 5.1. Requisitos 5.1.1. Product Backlog En esta secci´on podemos ver el product backlog el cual contiene todas las historias de usuario implementadas en la aplicaci´on. Figura 5.1: Product Backlog, primera parte 33 34 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Figura 5.2: Product Backlog, segunda parte 5.1. REQUISITOS 35 Figura 5.3: Product Backlog, tercera parte 36 CAP´ ITULO 5. DESARROLLO DEL PROYECTO 5.1.2. Requisitos del Software A continuaci´on se muestra la interacci´on que tiene el paciente con el sistema mediante el siguiente diagrama de casos de uso. Figura 5.4: Casos de uso del paciente 5.1. REQUISITOS 37 El siguiente diagrama pertenece al m´edico. Como aclaraci´on del diagrama, el caso de uso ((Ver Historial de Historias Cl´ınicas)) hace referencia a las historias cl´ınicas creadas por el propio m´edico, mientras que el caso de uso ((Historial M´edico)) contiene las historias cl´ınicas pertenecientes al paciente. Figura 5.5: Casos de uso del m´edico El ´ultimo diagrama de casos de usos corresponde a la figura del administrador. Como podemos ver la cantidad de funcionalidades al igual que su complejidad es bastante menor que las de los usuarios anteriores, ya que es 44 CAP´ ITULO 5. DESARROLLO DEL PROYECTO 5.4.2. Funcionalidades implementadas Iniciar y cerrar sesi´on Las primeras funcionalidades que se implementaron en el proyecto fueron las de iniciar y cerrar sesi´on, junto con un registro para usuarios. Estas primeras funcionalidades son importantes para el desarrollo del resto de la aplicaci´on ya que ser´an las que nos determinar´an que tipo de usuario estar´a accediendo a la aplicaci´on web, permiti´endonos mostrar ´unicamente las funcionalidades que les corresponde. Para la implementaci´on recurrimos a un HttpSession de Java, el cual nos permite almacenar diferente informaci´on entre diferentes peticiones HTTP debido a que es un protocolo sin estado. En dicho protocolo almacenamos los datos del usuario el cual nos ayudar´a a mostrarle la informaci´on correcta mientras navegue por la aplicaci´on. Este protocolo nos facilita tambi´en la implementaci´on del cierre de sesi´on, el cual una vez guardada toda la informaci´on que el usuario haya podido modificar durante su sesi´on, nos bastar´a con poner a null el objeto correspondiente al usuario cuya sesi´on est´a activa en ese momento. Gesti´on del Perfil El siguiente conjunto de funcionalidades estar´an relacionadas con el perfil del usuario. Para trabajar con el perfil, al igual que con todas las funcionalidades que requieran iniciar sesi´on, se utilizar´a el HttpSession para acceder a la informaci´on del usuario y mostrarla en el formulario correspondiente. En este formulario el usuario podr´a modificar su perfil a˜nadiendo la nueva informaci´on a la base de datos. Cabe destacar que m´as adelante la informaci´on del perfil ser´a utilizada en otras historias de usuario, tanto de forma directa permitiendo el acceso al perfil de otro usuario, o siendo mostrada como informaci´on complementaria en una historia cl´ınica. Gesti´on de las Notificaciones Por ´ultimo, en este sprint se incorpor´o un sistema de notificaciones similar a un correo bastante b´asico. Debido a la naturaleza de la aplicaci´on se decidi´o que las notificaciones solo se pudiesen mandar desde las historias cl´ınicas correspondientes. Esto pretende evitar que el sistema se convierta 5.5. SPRINT 2 45 en un simple correo y que el env´ıo de notificaciones se limite a intercambiar informaci´on relevante sobre una historia cl´ınica. Para revisar las notificaciones se a˜nadi´o un historial el cual muestra un listado con todas las notificaciones del usuario, permiti´endonos tanto acceder a ellas como eliminarlas. 5.4.3. Retrospectiva del Sprint Este sprint, como coment´abamos al principio del cap´ıtulo, nos ha servido para crear una base desde la que ir construyendo y ampliando nuestra aplicaci´on. Durante el desarrollo de estas funcionalidades, se descubrieron nuevas e interesantes historias de usuario que se a˜nadieron al product backlog. Por ´ultimo, al finalizar este sprint se revisaron algunas historias de usuario para las siguientes iteraciones, ya que algunas estar´ıan directamente conectadas a las ya implementadas y nos permitir´a crear funcionalidades m´as completas que mejorar´ıan el resultado final de la aplicaci´on. 5.5. Sprint 2 5.5.1. Objetivo del Sprint En este sprint se trabajar´a sobre la base implementada en la anterior iteraci´on, pasaremos a desarrollar las funcionalidades perteneciente a los pacientes y a los m´edicos. En esta iteraci´on se desarrollar´an las historia de usuario que permitir´an trabajar con las historias cl´ınicas y lo antecedente cl´ınicos de los pacientes, adem´as se a˜nadir´an opciones de b´usqueda por par´ametros para facilitar la navegaci´on por la aplicaci´on. Por ´ultimo podremos ver el sprint backlog perteneciente al segundo sprint en la siguiente figura. 46 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Figura 5.13: Sprint backlog del segundo sprint 5.5. SPRINT 2 47 5.5.2. Funcionalidades implementadas Gesti´on de historias cl´ınicas Este conjunto de funcionalidades nos permitir´a realizar todo el proceso de creaci´on de una historia cl´ınica y su posterior visualizaci´on. Para ello explicaremos las funcionalidades de ambos tipos de usuario. Primero implementamos la parte del paciente, creando varias historias cl´ınicas de ejemplo. Una vez almacenadas en la base de datos se implement´o un historial que nos permitir´a visualizar una lista con todas las historias cl´ınicas pertenecientes al paciente. Desde esta lista podremos acceder a cada una de las historias, las cuales mostrar´an la informaci´on en la p´agina correspondiente. A continuaci´on desarrollamos la parte perteneciente al m´edico. El m´edico podr´a acceder a las historias cl´ınicas de los pacientes desde el historial del mismo. Desde dicho historial tambi´en podr´a crear nuevas historias de usuario que ser´an a˜nadidas al historial m´edico del paciente para permitir su posterior acceso por parte del mismo o de m´edicos que lo requieran. Por ´ultimo, implementamos un historial con las historias cl´ınicas creadas por el propio m´edico. Gesti´on de antecedentes cl´ınicos Las siguientes funcionalidades implementadas incorporar´an a la aplicaci´on la opci´on de tener la informaci´on perteneciente a los antecedente cl´ınicos del paciente en la aplicaci´on. El modo de rellenar esta informaci´on ser´a similar a la del perfil. El usuario acceder´a al formulario correspondiente en el cual podr´a tanto consultar su informaci´on como modificarla. Por parte del m´edico, esta informaci´on estar´a accesible desde cualquier historia cl´ınica del paciente, facilitando su consulta. Tambi´en ser´a accesible, junto al perfil del paciente, desde la creaci´on de historias cl´ınicas con el objetivo de ofrecer la mayor informaci´on cl´ınica posible del paciente para un correcto diagn´ostico. B´usquedas por par´ametros La ´ultima de las funcionalidades implementadas en este sprint corresponde a las b´usquedas por diferentes par´ametros con el objetivo de facilitar el acceso a la informaci´on requerida de manera r´apida. 48 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Estas b´usquedas se han a˜nadido en los listados de pacientes y m´edicos. Para ello se ha incorporado una barra de b´usqueda la cual nos permite elegir el par´ametro por el que se realizar´a la b´usqueda. Los par´ametros por los que permite buscar son el nombre y el apellido, en caso de los pacientes tambi´en permite la b´usqueda de m´edicos por especialidad. Por ´ultimo se tuvo en cuenta la b´usqueda por DNI, pero debido que puede darse el caso de que el paciente no tenga dicho documento se descart´o en favor de otros par´ametros, aunque podr´ıa ser incorporada dicha b´usqueda en un futuro. 5.5.3. Retrospectiva del Sprint En este segundo sprint se ha ampliado la aplicaci´on incluyendo las funcionalidades principales. Estas funcionalidades forman el n´ucleo central de la aplicaci´on, la cual estaba pensada para gestionar historias cl´ınicas, objetivo que se consigue en este sprint. En este sprint adem´as se desech´o la posibilidad de modificar o eliminar historias cl´ınicas, ya que la naturaleza de las mismas impiden que sean alteradas una vez creadas, oblig´andonos a mantener esta pol´ıtica en la aplicaci´on para que el uso de la herramienta sea el adecuado por parte de los usuarios. 5.6. Sprint 3 5.6.1. Objetivo del Sprint En este ´ultimo sprint se implementar´a la figura del administrador al sistema, junto con funcionalidades que le permitan gestionar usuarios. Tambi´en se incorporara una de las caracter´ısticas m´as importante, la cual se ha ido preparando durante el anterior sprint con la implementaci´on de otras funcionalidades necesarias. En este sprint de manera paralela se ha hecho mucho hincapi´e en el dise˜no de la p´agina, con la incorporaci´on de elementos que mejoren el aspecto visual, distribuci´on de men´us y otras caracter´ısticas de la web. 5.6. SPRINT 3 49 Figura 5.14: Sprint backlog del tercer sprint 50 CAP´ ITULO 5. DESARROLLO DEL PROYECTO 5.6.2. Funcionalidades implementadas Gesti´on de Usuarios Con la incorporaci´on al sistema del administrador, se implementar´an una serie de funcionalidades que le permitir´a modificar ciertos aspectos de cualquier usuario. Entre estas funcionalidades se encuentra la posibilidad de modificar los datos m´as relevantes del perfil del usuario, incluso la contrase˜na, en caso de ser necesario. Por ´ultimo, tambi´en se implementar´a la posibilidad de deshabilitar o habilitar el acceso al sistema de cualquier usuario. Gesti´on de Consentimientos El ´ultimo conjunto de funcionalidades consigue incorporar un sistema de consentimientos que permitir´a a los pacientes autorizar el acceso a su historial cl´ınico ´unicamente a los m´edicos que ellos deseen. Para ello el sistema requerir´a que el m´edico env´ıe una solicitud de acceso al historial m´edico del paciente desde el listado de pacientes que ofrece el sistema. Una vez enviado el paciente tendr´a la posibilidad de aceptar o rechazar la solicitud. Si dicha solicitud es aceptada el m´edico tendr´a acceso al historial del paciente. Por ´ultimo, tambi´en se ofrece al paciente la posibilidad de retirar el consentimiento en cualquier momento. 5.6.3. Retrospectiva del Sprint En este sprint la implementaci´on de nuevas funcionalidades ha sido m´as sencilla debido al trabajo realizado previamente en las iteraciones anteriores. Estas funcionalidades como la gesti´on de consentimientos, permite mejorar el resultado final de la aplicaci´on, entregando un producto m´as completo y acorde a las necesidades del entorno donde se aplicar´a este proyecto. Por ´ultimo, en este sprint se identificaron varias historias de usuario que podr´ıan incorporar funcionalidades extras muy interesantes en un futuro. Cap´ıtulo 6 Conclusiones y trabajo futuro 6.1. Conclusiones Una vez concluido el proyecto ((Aplicaci´on web para la creaci´on y revisi´on de historias cl´ınicas online)), podemos afirmar que todos los objetivos iniciales se han llevado a cabo con buenos resultados. Para ello se analizar´a el proceso de realizaci´on de dicho proyecto. En primer lugar, la aplicaci´on de Scrum como metodolog´ıa de desarrollo nos ha ayudado a mejorar la organizaci´on y planificaci´on de proyectos que podremos aplicar en futuros trabajos. Tambi´en nos ha ayudado a reforzar el h´abito del trabajo diario, indispensable para la ejecuci´on de las diferentes iteraciones del proyecto, permiti´endonos avanzar conforme los plazos establecidos. De cara al futuro debemos de mejorar la estimaci´on de historias de usuario ya que, pese a no verse reflejado en el product backlog, las horas empleadas tanto en la implementaci´on de funcionalidades como en la mejora de las distintas ´areas de la aplicaci´on, como el dise˜no de la web, han requerido m´as tiempo del establecido en un principio, superando las 300h establecidas para el desarrollo de este TFG. Por otra parte, el desarrollo de un proyecto de estas caracter´ısticas de manera individual, nos ha ayudado para afianzar y perfeccionar muchos de los conocimientos adquiridos durante la carrera. El uso de patrones de dise˜no como el FrontController o la planificaci´on mediante el modelo de iteraciones incrementales, han sido fundamentales en este proyecto, y nos ha servido para reforzar la experiencia sobre ambos. Tambi´en hemos mejorado nuestra habilidad para el dise˜no visual de las aplicaciones, que pese a ser un apartado secundario, ha requerido de un gran n´umero de horas de trabajo para entregar un resultado a la altura del resto de la aplicaci´on. 51 52 CAP´ ITULO 6. CONCLUSIONES Y TRABAJO FUTURO Respecto al proyecto en s´ı, cabe destacar el trabajo de investigaci´on realizado del ´ambito de la sanidad para la correcta implementaci´on de todas las funcionalidades que se ten´ıan como objetivo al inicio de este proyecto. La sanidad es un ´ambito que necesita de mucha privacidad y seguridad en todos los procesos. Esto ha ayudado a que la aplicaci´on necesite de una serie de funcionalidades extra como los consentimientos, los cuales le da un enfoque diferente a la aplicaci´on y que han sido implementados con ´exito pese a su introducci´on tard´ıa en el product backlog. Por otro lado, tambi´en destacar el uso del framework bootstrap para la ayuda del dise˜no web. Gracias a esta herramienta se ha conseguido un resultado visual de la aplicaci´on bastante bueno. Pese a las facilidades de uso, el tiempo requerido para poder trabajar con la totalidad de las herramientas que nos proporciona la plantilla se hace inviable en un proyecto de estas caracter´ısticas y limitaciones temporales. Aun as´ı la mejora respecto a la plantilla inicial usada es considerable, por no hablar de la mejora en las habilidades adquiridas respecto al trabajo con CSS y HTML5. Por ´ultimo, el resultado final del proyecto ha sido muy satisfactorio, superando incluso las expectativas en algunos de sus apartados. Este proyecto nos ha servido como prueba de fuego para poder identificar todos los defectos y corregirlos, adem´as de poder potenciar las virtudes y ampliar la experiencia en la elaboraci´on de proyectos, desde su concepci´on hasta su implementaci´on final. Gracias a este proyecto, tambi´en hemos podido adquirir una amplitud de miras en cuesti´on de la cantidad de ´ambitos posibles en que la inform´atica y el desarrollo de software pueden trabajar, siendo el de la sanidad uno de los ´ambitos m´as que interesantes para futuros proyectos. 6.2. Trabajo Futuro Aunque en un principio este proyecto se hizo en mente con el ´unico objetivo de implementar una serie de funcionalidades que nos permitiese gestionar las historias cl´ınicas, durante su desarrollo se observ´o que podr´ıa incorporarse m´as caracter´ısticas, preparando la aplicaci´on durante el proceso para poder incorporarlas en un futuro. A continuaci´on pasaremos a explicar futuras funcionalidades que podr´ıan ser desarrolladas: Gesti´on de Citas: Estas funcionalidades podr´ıan dar un gran valor a la aplicaci´on, casi al final del proyecto se contempl´o su incorporaci´on pero la falta de tiempo lo hizo inviable. La implementaci´on de la gesti´on de citas permitir´ıa a un paciente elegir 6.2. TRABAJO FUTURO 53 cu´ando quiere asistir a una consulta m´edica en funci´on del horario y la disponibilidad del m´edico o especialista al que quiera asistir. Por otro lado tambi´en permitir´ıa al m´edico tener una agenda en la aplicaci´on con todas sus citas pendientes, adem´as de poder establecer periodos de vacaciones en los que el sistema no permitir´ıa la asignaci´on de citas a los pacientes. Estas funcionalidades junto a las historias cl´ınicas ya implementadas pueden hacer de la aplicaci´on una opci´on mucho m´as completa. Mejorar el sistema de notificaciones: Actualmente las notificaciones solo se pueden mandar desde las historias cl´ınicas con informaci´on relevante a la misma. Este sistema podr´ıa mejorarse permitiendo otro tipo de notificaciones o mensajes, los cuales podr´ıan estar organizados seg´un la importancia. Esto permitir´ıa seguir con la idea original de usar las notificaciones para transmitir informaci´on importante y adem´as ofrecer alternativas para la notificaci´on de otros procesos que se puedan realizar en la web, por ejemplo, recordatorios de citas o mensajes relevantes a la misma si se incorporasen las funcionalidades descritas en el punto anterior Incorporar Sistema de Recetas: Otra de las caracter´ısticas m´as interesantes que se podr´ıan incorporar en un futuro es la posibilidad de que el m´edico pueda facilitar recetas a los pacientes mediante la aplicaci´on. Dicha receta podr´ıa ser descargada por el paciente e impresa para su uso en farmacias, permitiendo que pueda adquirir las medicinas necesarias para su tratamiento desde cualquier lugar, sin necesidad de tener que realizar una consulta. Por otro lado, se deber´a de implementar las suficientes medidas de seguridad para evitar un mal uso de la herramienta, adem´as de poder incorporarse alg´un tipo de mensaje al sistema de notificaciones actual que permita al m´edico y el paciente el intercambio de informaci´on pertinente para la elaboraci´on de las recetas. Chat con m´edicos de guardia: Esta funcionalidad ser´ıa muy interesante para resolver dudas de tratamientos menores en los que no sea necesario especialistas. Como en otros ´ambitos, esta pr´actica se est´a extendiendo, posibilitando resolver peque˜nas dudas en cualquier momento, sin necesidad de cita previa o la espera de la disponibilidad de un m´edico concreto. Por supuesto este chat ser´ıa implementado con la idea de resolver peque˜nas dudas y no de realizar diagn´osticos los cuales deber´ıan ser rea- 60 AP´ ENDICE B. MANUAL DE USUARIO Figura B.5: Cierre de sesi´on B.1.3. Buscar M´edicos Otra de las opciones que podremos utilizar sin necesidad de registrarnos es la b´usqueda de m´edicos por especialidad. El funcionamiento es muy sencillo, introducimos en la barra de b´usqueda la especialidad que queremos y apretamos ((Buscar)) Figura B.6: B´usqueda de m´edicos por especialidad Una vez terminada la b´usqueda se nos mostrar´a un listado con todos los m´edicos que correspondan con nuestra especialidad buscada. B.2. PACIENTE 61 Figura B.7: Listado de m´edicos Desde esta lista podremos acceder al perfil del m´edico y ver sus datos m´as relevantes. Figura B.8: Perfil de un m´edico B.2. Paciente En esta secci´on se desarrollar´an funcionalidades pertenecientes al tipo de usuario que manejan los pacientes. Algunas de las funcionalidades como la modificaci´on de un perfil o las notificaciones son comunes a los m´edicos pero se explicar´an aqu´ı. 62 AP´ ENDICE B. MANUAL DE USUARIO B.2.1. Informaci´on Cl´ınica A esta parte de la aplicaci´on se podr´a acceder desde el men´u en la parte superior. Para acceder solo tendremos que pulsar en el bot´on indicado en la figura. Figura B.9: Acceso a la informaci´on cl´ınica Una vez dentro se nos mostrar´a un formulario en el cual podremos rellenar informaci´on relevante para nuestras futuras historias cl´ınicas como nuestros antecedentes familiares. Figura B.10: Formulario de la informaci´on cl´ınica B.2.2. Perfil Para acceder a nuestro perfil solo tendremos que elegir la opci´on que se nos muestra en la siguiente figura. Figura B.11: Acceso al perfil Una vez accedamos podremos modificar toda nuestra informaci´on personal. Tambi´en se podr´a cambiar la contrase˜na desde este formulario. B.2. PACIENTE 63 Figura B.12: Formulario para modificar el perfil B.2.3. Historial Cl´ınico En este apartado podremos acceder desde el men´u principal como hemos hecho anteriormente para otras funcionalidades. Figura B.13: Acceso a las historias cl´ınicas Una vez accedamos se nos mostrar´a un listado con todas las historias cl´ınicas que hay en el sistema sobre nosotros. Desde este listado podremos acceder a cada una para revisarla. Figura B.14: Listado de historias cl´ınicas 64 AP´ ENDICE B. MANUAL DE USUARIO Una vez accedamos a una de las historias cl´ınicas se nos deber´ıa mostrar el siguiente formulario con todos los datos referentes a la misma. Desde aqu´ı tambi´en podremos enviar una notificaci´on al m´edico autor de la historia cl´ınica actual. Figura B.15: Acceso al env´ıo de notificaciones B.2.4. Notificaciones Esta funcionalidad se accede desde el men´u principal de la aplicaci´on. Figura B.16: Acceso a las notificaciones Una vez accedamos se nos mostrar´a un listado desde el cual podremos acceder a las diferentes notificaciones que se encuentren en el buz´on. Tambi´en se nos ofrecer´a la posibilidad de eliminar las notificaciones permanentemente. Figura B.17: Listado de notificaciones B.3. M´ EDICO 65 B.2.5. Consentimientos Por ´ultimo tenemos los consentimientos. A este apartado se accede como hemos venido haciendo hasta ahora desde el men´u principal Figura B.18: Acceso a los consentimientos En el listado que se nos muestra podremos ver el estado de nuestros consentimientos. Tambi´en se podr´a gestionar las solicitudes pendientes, adem´as de revisar quienes tienen acceso a nuestro historial m´edico. Figura B.19: Listado de consentimientos B.3. M´edico En esta secci´on veremos las funcionalidades m´as espec´ıficas que los m´edicos podr´an realizar en el sistema. Algunas caracter´ısticas que son compartidas con los pacientes ya han sido explicadas previamente. B.3.1. Historias Cl´ınicas En este apartado podremos ver las historias cl´ınicas creadas por el propio usuario. Para acceder solo tendremos que ir al men´u principal y pulsar en el bot´on se˜nalado. Figura B.20: Acceso a historias cl´ınicas creadas por el propio usuario 66 AP´ ENDICE B. MANUAL DE USUARIO Una vez accedamos se nos mostrar´a el siguiente listado, desde el cual podremos acceder a todas las historias cl´ınicas. Desde el interior de las historias cl´ınicas tambi´en se podr´a enviar notificaciones al paciente al que pertenecen. Figura B.21: Listado de historias cl´ınicas B.3.2. Pacientes Estas funcionalidades nos permitir´an trabajar con los diferentes pacientes dentro de la aplicaci´on. Para acceder, usaremos el bot´on mostrado en la figura Figura B.22: Acceso a pacientes Una vez dentro se nos mostrar´a un listado de pacientes. En este listado se podr´an realizar b´usquedas para facilitar el acceso r´apido al paciente requerido. Por otro lado para poder acceder al historial m´edico de un paciente, primero deberemos solicitar su consentimiento. Figura B.23: Listado de pacientes con el estado de los consentimientos B.4. ADMINISTRADOR 67 Una vez concedido, podremos acceder a un listado con todas sus historias cl´ınicas, a las cuales podremos acceder igual que siempre. En este men´u tambi´en se podr´an crear historias cl´ınicas nuevas en las que podremos introducir la informaci´on relevante a la consulta que le hagamos al paciente. Figura B.24: Opci´on para la creaci´on de una nueva historia cl´ınica B.4. Administrador Por ´ultimo, veremos las funcionalidades implementadas para la figura del administrador. B.4.1. Administrar Usuarios Para entrar en esta parte de la aplicaci´on volveremos a usar el men´u principal como se muestra a continuaci´on Figura B.25: Acceso a la administraci´on de usuarios Una vez dentro, veremos un listado que nos podr´a habilitar o deshabilitar el acceso al sistema de los diferentes usuarios. Tambi´en nos dar´an acceso al formulario correspondiente para hacer modificaciones de la informaci´on m´as relevante de los perfiles de los usuarios del sistema. 68 AP´ ENDICE B. MANUAL DE USUARIO Figura B.26: Listado de usuarios Ap´endice C Normativa y Legislaci´on C.1. Ley de Protecci´on de Datos Nuestra aplicaci´on al trabajar con datos personales debe cumplir una serie de requisitos legales. Estos requisitos vienen recogidos en la Ley Org´anica 15/1999, de 13 de diciembre, de Protecci´on de Datos de Car´acter Personal. Esta ley obliga a personas, empresas y organismos, tanto p´ublicos como privados que manejen datos de car´acter personal, a cumplir y aplicar una serie de medidas de seguridad para la protecci´on de los datos que posean. Esta ley ser´a aplicada a los datos de car´acter personal registrados en soporte f´ısico que los haga susceptibles de tratamiento, y a toda modalidad de uso posterior de estos datos por los sectores p´ublico y privado. Por otro lado, el ´ambito de la sanidad tiene su propia legislaci´on, la cual afecta a nuestro proyecto. Los requisitos que deberemos cumplir vienen recogidos en la Ley General de Sanidad de 25 de abril de 1986 y la Ley 41/ 2002, de 14 de noviembre, b´asica reguladora de la Autonom´ıa del Paciente y de derechos y obligaciones en materia de informaci´on y documentaci´on cl´ınica. Dichas leyes obligan a desarrollar una serie de medidas de seguridad para el correcto uso de las historias cl´ınicas. Esto afecta al acceso de las historias cl´ınicas por parte de los profesionales sanitarios el cual debe realizarse bajo determinadas condiciones, como la identificaci´on y autentificaci´on en el sistema. Las funcionalidades como el sistema de consentimientos tambi´en se ha creado con el prop´osito de ayudar al control del acceso a la informaci´on contenida en las historias cl´ınicas, cumpliendo con las leyes anteriormente mencionadas. 69