Kairos : gestión remota de pacientes clínicos

Proyecto fin de carrera. Escuela de Ingeniería Informática. Universidad de Las Palmas de Gran Canaria. Kairos: Gestión remota de pacientes clínicos Yeray Santana Benítez Las Palmas de Gran Canaria Proyecto fin de carrera de la Escuela de Ingeniería Informática presentado por el alumno: YERAY SANTANA BENÍTEZ Título del Proyecto: Kairos, gestión remota de pacientes clínicos Tutor: Abraham Rodríguez Rodríguez Dedicatoria A mis padres, mi hermana y mis abuelos Agradecimientos A mi tutor Abraham Rodríguez Rodríguez, por hacer muchas veces el papel de mi conciencia y no dejar que me desviara del camino correcto, con todo el mérito que eso conlleva. A Daniel González Santana, por ser el cerebro del que surgio la idea y poner su conocimiento a mi disposición. A mis padres y a mi hermana, por la educación, el cariño y los valores que me han enseñado; este proyecto tiene bastante de ellos. A mis amigos, por brindarme tantos momentos de alegria entre análisis, diseños y cabezazos contra la pared. A mis compañeros de universidad, que convirtieron todos esos años en una de las mejores experiencias de mi vida, regalándome un montón de recuerdos que guardo con nostalgia y alegría. A tantos y tantos compañeros de trabajo con los que he tenido el placer de trabajar y que me han ayudado a convertir en el profesional que soy hoy en día. Índice 1. Introducción .................................................................................................................. 8 2. Objetivos del proyecto .................................................................................................. 9 3. Estado actual del tema ................................................................................................ 10 Teladoc (http://www.teladoc.com/) .................................................................... 10 MDLive (https://mdlive.com/)............................................................................ 11 American Well (https://www.americanwell.com/) ............................................. 12 Doctor On Demand Well (http://www.doctorondemand.com/) ......................... 12 Comparativa ....................................................................................................... 13 4. Metodología ................................................................................................................ 14 5. Plan de trabajo y temporización ................................................................................. 17 6. Definición del proyecto .............................................................................................. 18 6.1 Aplicaciones del sistema ...................................................................................... 22 6.1.1 Modelo de negocio ........................................................................................ 24 7. Sprints ......................................................................................................................... 27 7.1 Sprint 1: Entorno tecnológico ............................................................................... 27 7.1.1 Definición del entorno tecnológico ............................................................... 27 Interfaz y gestión de datos .................................................................................. 27 Base de datos ...................................................................................................... 28 Servidor web ....................................................................................................... 28 Sistema de gestión de consultas por video-chat ................................................. 29 Sistema de control de versiones.......................................................................... 30 Otras herramientas .............................................................................................. 30 7.1.2 Entorno tecnológico. ...................................................................................... 32 7.2 Sprint 2: Sistema de comunicación por video y audio ......................................... 35 7.2.1 Obtención de los elementos media ................................................................ 36 7.2.2 Streaming de elementos media ...................................................................... 37 Conectar a los usuarios. ...................................................................................... 37 Control de la transmisión. ................................................................................... 37 Intercambio de información de sesión ................................................................ 40 Intercambio de información de red ..................................................................... 41 Transmisión del contenido media ....................................................................... 43 7.2.3 Streaming de datos ........................................................................................ 44 7.2.4 Exportación e integración .............................................................................. 46 7.2.5 Actualización del entorno tecnológico .......................................................... 46 7.3 Sprint 3: Acceso y consulta del paciente .............................................................. 47 7.3.1 Historias de usuario ....................................................................................... 47 7.3.2 Acceso a la aplicación ................................................................................... 48 Análisis funcional ............................................................................................... 48 Diseño ................................................................................................................. 50 Pantallas .............................................................................................................. 52 7.3.3 Listado de citas del paciente .......................................................................... 53 Análisis funcional ............................................................................................... 53 Diseño ................................................................................................................. 55 Pantallas .............................................................................................................. 58 7.3.4 Consulta del paciente ..................................................................................... 59 Análisis funcional ............................................................................................... 59 Diseño ................................................................................................................. 61 Pantallas .............................................................................................................. 62 7.3.5 Actualización del entorno tecnológico .......................................................... 63 7.4 Sprint 4: Consulta del médico .............................................................................. 64 7.4.1 Historias de usuario ....................................................................................... 64 7.4.2 Gestión de citas .............................................................................................. 65 Análisis funcional ............................................................................................... 65 Diseño ................................................................................................................. 67 Pantallas .............................................................................................................. 68 7.4.3 Consulta ......................................................................................................... 69 Análisis funcional ............................................................................................... 69 Diseño ................................................................................................................. 71 Pantallas .............................................................................................................. 72 7.5 Sprint 5: Sala de espera y datos de consulta ......................................................... 74 7.5.1 Historias de usuario ....................................................................................... 74 7.5.2 Sala de espera ................................................................................................ 75 Análisis funcional ............................................................................................... 75 Diseño ................................................................................................................. 77 Pantallas .............................................................................................................. 80 7.5.3 Detalles de consulta ....................................................................................... 81 Análisis funcional ............................................................................................... 81 Diseño ................................................................................................................. 83 Pantallas .............................................................................................................. 84 8. Resultados y conclusiones .......................................................................................... 85 9. Trabajo Futuro. ........................................................................................................... 87 10. Bibliografía ............................................................................................................... 88 11. Enlaces ...................................................................................................................... 89 Anexos ............................................................................................................................ 91 A. Instalación y configuración del entorno de desarrollo. .......................................... 92 Eclipse .................................................................................................................... 92 Xampp .................................................................................................................... 92 Codeigniter ............................................................................................................. 92 Propel .................................................................................................................... 101 Node.js .................................................................................................................. 105 B. Manual de usuario ................................................................................................ 109 Acceso a la aplicación .......................................................................................... 109 Pantalla principal del paciente .............................................................................. 110 Pantalla de consulta del paciente .......................................................................... 111 Pantalla principal del facultativo .......................................................................... 112 Pantalla de consulta del facultativo ...................................................................... 113 Introducción 8 1. Introducción Con un tiempo medio de espera de 4 horas en las urgencias de los hospitales españoles 1 es lógico pensar que se hace necesaria la incoporación de nuevas herramientas y sistemas tecnológicos que faciliten la atención a los pacientes y que permitan una mejora en la atención sanitaria que reciben. Ha sido en los Estados Unidos, mercado pionero en el uso de asistencia telemática en el ámbito sanitario, donde se ha producido un auge en el desarrollo de plataformas orientadas a la asistencia online de pacientes. Esto se debe en gran parte, a las elevadas inversiones del sector privado en el terreno de la telemedicina, dándonos una idea, de la importancia que ha ido ganando dicho campo en el futuro de nuestro sector sanitario. Por lo expuesto anteriormente surge la motivación de la realización de este proyecto. Nuestro objetivo es la creación de un portal destinado a la gestión de citas y consultas médicas mediante asistencia telemática. Un entorno en el que el paciente pueda solicitar citas y recibir atención remota por videoconferencia, además de tener acceso a toda la información generada. Un entorno en el que el facultativo pueda gestionar su calendario de citas, atender consultas online y acceder a la información de los pacientes. Un entorno en el que las entidades del ámbito sanitario puedan ofrecer un sistema de atención con un bajo coste para su negocio y un gran impacto para sus clientes. Todo lo anterior no sería posible sin un sistema tecnológico que diera soporte a las funciones de comunicación entre dos clientes situados en distintas localizaciones. Es aquí donde surge una tecnología que nos permitirá implementar un sistema de interacción por video y chat de garantías; una tecnología que aporta un conjunto de ventajas sobre las existentes hasta el momento en el mercado: hablamos de WebRTC o Web Real-Time Communication. Empezaremos la redacción del presente documento estableciendo los objetivos del proyecto, para después presentar algunas de las herramientas más significativas dedicadas a la asistencia telemática. Elaboraremos un plan de negocios que haga que nuestro proyecto sea atractivo para los clientes y seguiremos con la explicación de la metodología que aplicaremos y el desarrollo del mismo. Para finalizar expondremos los resultados y conclusiones y las líneas de trabajo futuro con el que se podría continuar el desarrollo. 1 https://aseguradorassanidad.wordpress.com/tag/tiempo-medio-espera/ Objetivos del proyecto 9 2. Objetivos del proyecto Podemos dividir los objetivos del proyecto en dos grupos: Los objetivos funcionales y los objetivos de diseño. Mientras que los primeros explicitan el funcionamiento de la aplicación y por ende, lo que el producto va a ofrecer a los clientes, los segundos determinan los aspectos técnicos a cumplir. Los objetivos funcionales son: - Implementar una solución para ofrecer un portal con el que gestionar el proceso de consulta médica. - Ofrecer a las administraciones (centros sanitarios y consultas privadas) un sistema con el que incorporar asistencia sanitaria de forma telemática a sus servicios. - Ofrecer a los facultativos un conjunto de herramientas para gestionar las citas y que puedan realizar consultas por video conferencia además de manejar la información de los pacientes. - Ofrecer a los pacientes una plataforma con la que podrán gestionar el proceso completo de consulta médica: solicitar una cita y recibir atención, además de poder consultar la información generada por las mismas. Los objetivos de diseño: - Utilizar un proceso de ingeniería de software bien definido. - Definir una arquitectura que sea fácilmente integrable con cualquier sistema de gestión de pacientes. - Definir los requerimientos del sistema y de los distintos perfiles de usuarios que harán uso del sistema. - Implementar un modelo de datos relacional sin ambigüedades. - Desarrollar la lógica de negocio del sistema. - Diseñar e implementar un sistema de comunicación de video y audio para la interacción médico-paciente con un bajo coste de rendimiento y sin la necesidad de instalar software adicional. - Diseñar y desarrollar un prototipo funcional para el acceso y manejo de la información. - Elaborar la documentación necesaria. Metodología 16 usuario como la realización de wireframes tienen como objetivo desarrollar un documento que el product owner pueda verificar y que permita detectar en etapas tempranas divergencias entre lo expresado por él mismo y lo entendido por el equipo de desarrollo. En el diseño plantearemos una solución técnica para dar respuesta a los requisitos detectados en la etapa de análisis, haciendo uso de diagramas UML para representar el dominio del problema. Con diagramas entidad-relación representaremos los objetos a modelar mientras que los diagramas de secuencia nos darán una idea de las acciones que intervienen en los procesos. Por último, los diagramas de clases nos proporcionaran una visión cercana de las funciones y procedimientos a desarrollar para implementar la funcionalidad analizada. En la etapa de implementación desarrollaremos el producto en base al diseño técnico anterior, teniendo como objetivo la creación de un prototipo funcional que cumpla con los requisitos de la etapa de análisis. Por último, en la fase de validación, nuestro product owner comprobará que el entregable (incremento) se ajusta a sus necesidades. Es una fase de control de expectativas donde el propietario podrá proponer nuevos requisitos, modificar los actuales o cambiar la prioridad de los ya existentes. La elección de esta metodología de desarrollo y la adaptación a nuestro proyecto da respuesta a las siguientes necesidades del mismo: - Flexibilidad ante cambios: el cliente va contemplando la evolución del proyecto y tiene la posibilidad de introducir nuevos cambios en base a nuevas necesidades. - Capacidad para tener una versión funcional de la aplicación en etapas tempranas. - Reducción de riesgos al gestionar las expectativas del cliente en cada iteración y poder reaccionar ante ellos. - Equipo de desarrollo pequeño. - Alta disponibilidad de nuestro product owner. Resumiendo el proceso de desarrollo expuesto: - El product owner creará una lista priorizada con las características deseables de nuestro proyecto (product backlog). - En base a las prioridades y la duración del sprint, el equipo junto con el product owner planificará el sprint actual, seleccionando el conjunto de tareas que van a ser abordadas (sprint backlog). - Durante el sprint, el equipo se centrará en la realización de las tareas. - Al finalizar el sprint. el trabajo realizado durante el mismo debe ser cuantificable ya sea en forma de documento, desarrollo, etc. - El equipo realizará una reunión de retrospectiva para evaluar el sprint finalizado. - Se realizará una reunión con el product owner para verificar el resultado del sprint. - Se volverá al punto 2, se seleccionará otro conjunto de tareas y se planificará el siguiente sprint. Plan de trabajo y temporización 17 5. Plan de trabajo y temporización Dividiremos en 4 etapas la duración total del proyecto: - Etapa 1. Establecer las bases del proyecto: Realizar reuniones con el profesor y el product owner para definir el producto a implementar gestionando las expectativas y reduciendo las ambigüedades. (20 horas). - Etapa 2. Definir el entorno tecnológico: Definir la arquitectura del sistema: elección de un Framework, de un ORM, sistema de gestión de base de datos, etc. Definir y eliminar riesgos tecnológicos. Instalar el entorno de programación así como las herramientas de edición de documentos. (80 horas). - Etapa 3. Desarrollo de un prototipo funcional: Descomposición del desarrollo en iteraciones o sprints. Cada uno de estos sprints podrá tener una etapa de análisis, diseño, implementación y/o validación. (800 horas). - Etapa 4. Documentación del Proyecto: Recopilar y generar la memoria del proyecto y realizar los manuales de usuario. (80 horas). Duración total del PFC: 960 horas. Definición del proyecto 18 6. Definición del proyecto Definiremos con la ayuda del product owner el producto a desarrollar. Las herramientas que utilizaremos serán las reuniones y entrevistas, obteniendo la pila del producto o product backlog. Una vez hayamos descrito el product backlog, éste deberá ser validado por nuestro product owner en un proceso cuya finalidad es la de gestionar las expectativas y comprobar que el cliente tiene una visión clara y sin ambigüedades, de lo que va a obtener con el producto final. Nuestro objetivo es crear una plataforma que permita a las organizaciones que ofrecen servicios sanitarios, la configuración de un portal con el que poder dar asistencia por videoconferencia. Dicha herramienta comprenderá de un plan de citas para la consulta con el facultativo, la gestión de listas de espera para los citas, herramientas para la gestión de consultas y video-chat para la interacción médico-paciente. El modelo de dominio del problema en el mundo real se muestra en la figura 2: Figura 2: Modelo de dominio del problema Definición del proyecto 19 En el modelo anterior vemos como un paciente que presenta (o cree presentar) una serie de síntomas solicita una cita con su médico. Esta cita genera una consulta en un día y hora específicos. El médico atiende esa consulta y, una vez analizados los síntomas del paciente y consultado su historial, podrá determinar un diagnóstico y proponer un tratamiento para que el paciente se cure. Podrá además solicitar pruebas para determinar el diagnóstico y también concertar una nueva cita; bien para revisar el resultado de las pruebas del paciente o para ver la evolución del estado del mismo. En el modelo de dominio tenemos los siguientes conceptos: - Paciente: persona que recibe los servicios de un médico u otro profesional de la salud y se somete a un examen o a un tratamiento. - Médico o doctor: profesional que practica la medicina y que intenta mantener y recuperar la salud humana mediante el estudio, el diagnóstico y el tratamiento de la enfermedad o lesión del paciente. - Consulta: proceso por el cual un médico atiende a un paciente en un tiempo determinado. - Diagnóstico: procedimiento por el cual el médico identifica el estado de salud de un paciente. - Cita: asignación de día, hora y lugar entre paciente y médico para que ocurra el proceso de consulta. - Síntoma: referencia subjetiva que da un enfermo de la percepción que reconoce como anómala o causada por un estado patológico o una enfermedad. - Prueba: exploración complementaria que solicita el médico para confirmar o descartar un diagnóstico. - Historial (Historia clínica): documento donde se recoge la información necesaria para la correcta atención de los pacientes con valor informativo, científico y legal, en el que el médico deja constancia de su actuación. - Tratamiento: Conjunto de medios que se emplean para curar o aliviar una enfermedad. Una vez definido el modelo funcional en el mundo real de la aplicación que queremos construir debemos conformar la funcionalidad de la aplicación para cada usuario. Desde el punto de vista del paciente, éste debe poder acceder al sistema o darse de alta en el mismo. Una vez dentro podrá solicitar citas, consultar su historial, acceder a la sala de espera el día que tenga cita y recibir una consulta por video-chat. La funcionalidad deseada sería la siguiente: - Rellenar formulario de alta. - Logearse en el sistema. - Pedir cita. - Acceder a la sala de espera. - Recibir consulta. - Consultar historial. - Obtener informes. El médico debe poder acceder a la aplicación también. Consultar las citas, gestionar la sala de espera, ofrecer una consulta y consultar la información del paciente, así como poder generar y consultar diversos informes: - Logearse en el sistema. Definición del proyecto 20 - Ofrecer consulta (Interacción con el paciente). - Consultar historial del paciente. - Gestionar citas. - Consultar calendario de citas. - Generar informes. - Gestión de la sala de espera (debe poder seleccionar a un paciente de la sala, ver cuantos tiene en cola, etc.). Aparte de los usuarios médico y paciente, debemos incorporar a nuestro proyecto un usuario cuyas funciones sean las de administrar el sistema: - Logearse en el sistema. - Gestionar pacientes. - Gestionar establecimientos. - Gestionar especialistas. - Gestionar especialidades médicas. - Gestionar pruebas médicas. - Informes (datos globales-estadísticos). En la tabla 2 configuramos el product backlog de nuestro proyecto: Id Prioridad Descripción 1 1 El médico y el paciente deben poder realizar una consulta de audio y video. 2 1 Durante el proceso de consulta, el médico y el paciente deben poder comunicarse mediante chat. 3 3 Durante la consulta, el médico debe poder gestionar los datos de la misma. 4 2 El médico debe poder gestionar las citas que se encuentran en la sala de espera. 5 2 El paciente debe poder acceder a la sala de espera de la consulta del médico. 6 4 El médico podrá consultar la información del historial de los pacientes. 7 4 El paciente podrá consultar su información. 8 6 El médico podrá gestionar su calendario de citas. 9 7 El administrador podrá dar de alta nuevos usuarios, especialidades y pruebas. 10 8 El administrador podrá crear informes. 11 8 El médico tendrá acceso a informes. 12 9 El sistema debe permitir la forma digital. 13 9 El sistema debe ser sensible a la LOPD. 14 7 El paciente podrá darse de alta en el sistema mediante un formulario. 15 5 El paciente deberá logearse para acceder a la aplicación. 16 5 El médico deberá logearse para acceder a la aplicación. Tabla 2: Product backlog Definición del proyecto 21 Una vez establecida las prioridades del sistema en base a las necesidades de nuestro product owner estableceremos un calendario de hitos del proyecto, añadiendo al product backlog desarrollado, las tareas que son implícitas a la implementación de nuestro proyecto: - Establecer el entorno tecnológico del proyecto: o Objetivo: Determinar las necesidades del proyecto, las herramientas a utilizar, la arquitectura del sistema y eliminar los riesgos de desarrollo. - Transmisión de audio, video y chat. o Objetivo: Transmitir audio, video y texto entre dos clientes web vía streaming. - Consulta del paciente: o Objetivo: Poder atender una sesión de consulta con el especialista. - Consulta del médico: o Objetivo: Poder atender una sesión de consulta con el paciente. - Sala de espera: o Objetivo: Controlar el acceso de los pacientes a la consulta del médico. - Historial del paciente: o Objetivo: Poder consultar la información del paciente por parte del médico. - Información del paciente: o Objetivo: Poder consultar la información del paciente por parte de él mismo, pedir citas y obtener informes. - Calendario: o Objetivo: Consultar el calendario de citas del médico. - Administración del sistema: o Objetivo: Poder dar de alta usuarios (médicos y pacientes), especialidades, pruebas y establecimientos. - Login de la aplicación: o Objetivo: Logearse en el sistema y gestión de permisos. - Generar informes: o Objetivo: Generación de informes por parte del médico. - Firma digital: o Objetivo: Poder firmar digitalmente los informes. - LOPD: o Objetivo: Asegurarnos que la información guardada en la BBDD cumpla la LOPD. Definición del proyecto 22 6.1 Aplicaciones del sistema El sistema comprenderá una solución completa al problema de la gestión de citas y consultas médicas con el valor adicional de que el proceso completo podrá realizarse a través de la web. El paciente podrá solicitar una cita, recibir la consulta desde casa y consultar su historial. Por otro lado, el sistema permitirá a los facultativos administar sus citas, gestionar la información de los pacientes y ofrecer consultas de forma centralizada, también favoreciéndose del proceso de interacción vía web. Además el sistema es fácilmente integrable con el sistema de historial clínico del cliente. Desde el punto de vista funcional el sistema que desarrollaremos podrá cubrir un amplio abanico de necesidades. Algunas de las cuales podrían ser: - Gestión de consultas: para hospitales o consultas médicas tanto públicas como privadas, los usuarios del sistema podrán gestionar todos los aspectos del proceso de consulta. Imagen 5: Consulta médica - Gestión de consultas de pacientes con un alto cargo contagioso: para la gestión de pacientes en condiciones de aislamiento. Imagen 6: Médico trabajando con un traje de aislamiento Definición del proyecto 23 - Gestión de consultas en zonas remotas o de difícil acceso: lugares que son de difícil acceso y que requieran de una consulta rápida para evaluar el estado del paciente y la necesidad o no de trasladarse a la zona. Imagen 7: Isla de Diómedes Menor - Gestión de consultas en zonas desfavorecidas: lugares con pocos recursos económicos en los que no se puede mantener una consulta. Imagen 8: Favela en Rio de Janeiro Definición del proyecto 24 6.1.1 Modelo de negocio Hemos descrito anteriormente cuales son nuestros objetivos y algunos de los productos más populares relacionados con el servicio que pretende dar unuestra plataforma, por lo que pasaremos ahora a conformar nuestro modelo de negocio. Un modelo de negocio es básicamente el mecanismo por el que nuestro negocio va a generar beneficios. Para ello, utilizaremos la plantilla de modelo de negocio [O08] propuesta por Alexander Osterwalder que mostramos a continuación en la imagen 9: Imagen 9: Business Model Canvas En dicha plantilla se intenta dar respuesta a los siguientes puntos: ¿Cuál es la propuesta de valor de nuestro producto? ¿A qué segmento de clientes va dirigido? ¿Por qué medios lo distribuiremos? ¿Qué relaciones estableceremos con los clientes? ¿Cómo ganaremos dinero con el producto? ¿Cuáles son nuestros recursos claves? ¿Y nuestras actividades? ¿Cuáles son nuestros socios clave? Y por último, ¿Cuál es la estructura de costes de nuesto proyecto? La propuesta de valor es lo que diferencia nuestro producto de la competencia: ver que elementos innovadores introducimos para dar respuesta a las necesidades de nuestros clientes. Nuestro proyecto proporciona un portal web para la gestión de citas y consultas online para que los centros sanitarios oferten a sus pacientes asistencia telemática. Todo esto, con un coste de rendimiento relativamente bajo, permitiendo el acceso a la aplicación a cualquier equipo que disponga de un navegador con internet, facilitando la movilidad de los facultativos y centralizando el proceso. Además con el éxito del negocio, podríamos ofrecer la explotación de los datos generados por la aplicación. Para ver si nuestro producto tiene mercado, debemos indentificar a que segmento de clientes va dirigida nuestra aplicación y estudiar sus necesidades para valorar nuestras oportunidades de negocio. Nuestros clientes potenciales serán los centros sanitarios y Definición del proyecto 25 las consultas privadas que desen ofrecer un portal web a sus clientes para la asistencia sanitaria por videoconferencia. Esta es la principal diferencia con los sistemas estudiados anteriormente ya que nuestro cliente objetivo no son los pacientes. Debemos determinar que servicios aportaremos a nuestros clientes y que relaciones estableceremos con los mismos. Un servicio de soporte para la atención personalizada, formación para el uso de la aplicación y ayudas y manuales online es lo mínimo que deberíamos ofrecer. Además podríamos incorporar un servicio de integración de nuestro sistema con el sistema de historia clínica de los clientes. Los canales de distribución determinan la forma en la que hacemos llegar nuestro producto a los clientes finales. En principio nuestro producto se distribuirá directamente por internet y también a través de comerciales. Para monetizar el producto, nuestra fuente de ingresos principal vendrá de la venta de licencias. En el mercado actual, tan competitivo y con la crisis de fondo, pensamos que la mejor forma de generar ingresos es cobrar una pequeña licencia por facultativo y otra por paciente, además de un pequeño procentaje por cada consulta. De esta forma nuestro producto crecerá con la rentabilidad del comprador y el uso de la misma, en un esquema win-win. Para generar un producto necesitamos de una serie de actividades estratégicas que den valor a nuestra propuesta. Éstas son el análisis, diseño e implementación de la plataforma, el soporte a la misma y la gestión de la distribución del producto. Ademas de actividades, para lograr nuestro objetivo debemos especificar los recursos físicos, intelectuales, humanos y financieros que necesitaremos. Los recursos físicos serían un despacho y equipos para el desarrollo del producto, además del motor de videoconferencia. Los recursos intelectuales podrían ser la creación de una marca y la explotación de la base de datos del producto. Los recursos humanos serían los ingenieros de software para el desarrollo y mantenimiento del proyecto, los ITs para mantener la estructura del mismo, los técnicos de soporte para las relaciones con el cliente y el equipo de comerciales. Por último, como recurso financiero podríamos tener una línea de crédito para las primeras fases del proyecto, en las que no se generan ingresos. Necesitamos también incorporar recursos externos a nuestro proyecto y crear asociaciones clave que cubran las necesidades que no podemos cubrir nosotros. Nuestros socios clave serían los proveedores de material informático, de Internet y de hosting. Además, para mejorar la aplicación necesitamos de socios expertos en el dominio de la información del problema, por lo que sería bien visto asociaciones con facultativos y administradores de servicios sanitarios. Por último, necesitamos conocer la estructura de costos de nuestro proyecto para determinar la rentabilidad de la inversión del mismo. La inversión inicial debería cubrir los sueldos, la compra de los equipos y el alquiler de las instalaciones. Sprints 32 7.1.2 Entorno tecnológico. Como hemos descrito en los puntos anteriores tenemos las dos capas en las que hemos dividido nuestro entorno y que mostramos en la figura 5: la capa de la aplicación que se encarga del manejo de información, KairosOMAC, montada en un entorno Apache, y la capa encargada de las comunicaciones, KairosOVC, implementada sobre un entorno Node. Esta separación nos permitirá poder utilizar en otros proyectos cada una de las capas de forma independiente, con un bajo coste de integración. Figura 5: Entorno tecnológico Sprints 33 En la figura 6, mostramos la arquitectura de nuestro sistema de gestión de citas y consultas médicas: montado en un entorno Apache tenemos nuestro framework PHP Codeigniter para el desarrollo de la lógica de negocio de nuestra aplicación. Para la capa de presentación y experiencia de usuario utilizamos HTML5 y JQuery. Para el manejo de los datos tenemos Propel como ORM encargado de la gestión de los procesos CRUD, abstrayendo a nuestra aplicación de los detalles del motor de BBDD, que en nuestro caso es MySQL. Además utilizamos los siguientes plugins. - JQuery UI Notification: Plugin JQuery para mostrar mensajes al usuario. Figura 6: Capa de gestión de datos Sprints 34 La arquitectura del sistema de comunicación se muestra a continuación en la figura 7. Un servidor Node.js, que ejecuta código Javascript. Como hemos comentado esta separación lógica nos permitirá exportar o utilizar el servicio de comunicaciones en otros proyectos. Las librerías utilizadas: - Node-static: módulo para Node.js que permite servir contenido estático. Figura 7: Capa de gestión de las comunicaciones Sprints 35 7.2 Sprint 2: Sistema de comunicación por video y audio En esta segunda iteración del proyecto abordaremos una de las funcionalidades principales de nuestro sistema y la que conlleva mayor riesgo técnico. Como se ha comentado previamente, es fundamental abordar este tipo de hitos lo más temprano posible y evaluarlos para determinar los riesgos a los que se expone el proyecto. El objetivo a cumplir en esta etapa es lograr una comunicación fluida entre dos clientes o peers a través de la web, con un bajo coste de rendimiento y sin la necesidad de plugins. Como hemos comentado en el apartado anterior, haremos uso de la API WebRTC para la comunicación en tiempo real a través del navegador web entre dos clientes. En el momento de la realización del proyecto los navegadores que soportaban la API eran: - Navegadores de escritorio: o Google Chrome, a partir de la versión 23. o Mozilla Firefox a partir de la 22. o Opera a partir de la 12. - Navegadores móviles: o Google Chrome 28 para Android. o Mozilla Firefox 24 para Android. o Opera Mobile 12 para Android. Resaltar que cada navegador implementa la API de forma independiente. Los esfuerzos en la estandarización de la misma es uno de los objetivos de la W3C. Internet Explorer y Safari no desarrollan de forma nativa la API pero existen numerosos plugins que permiten al navegador soportar dicha funcionalidad, aunque se espera que la incorporen en próximas versiones. Además, y afortunadamente para nosotros, existen numerosos shims que nos permiten abtsraernos de las diferentes implementaciones, haciendo transparente la nomenclatura que cada navegador utiliza para la representación de la API. Los tres pilares básicos sobre los que se sostiene WebRTC para lograr su propósito son: - MediaStream: es una representación de un stream de audio y/o video, lo que permite al navegador su uso y manejo. - PeerConnection: es el objeto que establece la comunicación directa entre clientes y transmite los elementos media. - DataChannels: objeto que permiten a los navegadores compartir datos de carácter no media entre clientes. Con todo esto, nuestra aplicación será capaz de ofrecer un sistema de videoconferencia con las siguientes características: - Infraestructura tecnológica económica de mantener. - Facilmente integrable en sistemas de terceros - Bajo consumo de recursos. Sprints 36 - Sin necesidad de que el cliente realice la instalación de ningún plugin. - Comunicación entre clientes independientemente de la forma en la que estén conectados a Internet (routers, firewalls, etc.). 7.2.1 Obtención de los elementos media Empezaremos con la implementación de nuestra librería de comunicaciones. En esta primera etapa mostraremos como se puede capturar los elementos media del equipo a través del navegador usando el componente getUserMedia de WebRTC. La función 13 está diseñada para acceder a los streams de audio y video de los dispositivos media locales y proporcionar una interfaz para el manejo de los mismos. Esta función acepta tres parámetros: - Un objeto con las restricciones: si queremos capturar audio y su bitrate, video y su resolución, etc. - Una función o callback en caso de poder acceder a la funcionalidad con un objeto de tipo LocalMediaStream pasado como argumento, que representa el stream media capturado. El formato de dicho stream nos permitirá mostrarlo por pantalla (mediante un elemento HTML5 video, por ejemplo) o pasarlo como parámetro a un objeto RTCPeerConection para su posterior transmisión por la red a otro usuario. - Una función o callback en caso de producirse un error al intentar acceder a la API. En la imagen 10, mostramos el resultado de la captura de video mediante getUserMedia. Imagen 10: Captura de imagen mediante getUserMedia 13 http://w3c.github.io/mediacapture-main/getusermedia.html Sprints 37 7.2.2 Streaming de elementos media El siguiente paso una vez capturado el video y el audio es transmitirlo desde un peer a otro peer haciendo uso de la interfaz RTCPeerConection 14 . Podemos descomponer el proceso de configuración de la transmisión en los siguientes pasos [M13]: - Conectar a los usuarios: el primer paso es identificar a los usuarios y proporcionarles un acceso común a la funcionalidad. - Control de la transmisión: Una vez conectados los dos peers, debemos proporcionar un mecanismo para que puedan enviarse mensajes de control para la configuración de la transmisión. - Intercambio de información media a transmitir: cada cliente debe ponerse de acuerdo en el tipo y el formato de los elementos que se van a transmitir. - Intercambio de información de red: una vez establecido el mecanismo de señalización los dos clientes deben empezar un proceso de descubrimiento de rutas de red, por las que podrán acceder entre ellos. - Comenzar con el envío de los elementos haciendo uso el objeto RTCPeerConection. Conectar a los usuarios. Lo primero que debemos hacer es establecer un mecanismo para que los participantes se identifiquen. La forma más sencilla es que ambos clientes accedan a la misma página y se conecten a un servidor que los identifique y les proporcine los mecanismos necesarios para el control de la comunicación. Control de la transmisión. Una vez hemos puesto en contacto a los clientes, debemos establecer un mecanismo de control de la transmisión con el que puedan enviar y recibir mensajes. A este proceso se le denomina „señalización‟. Los objetivos de dicho proceso son los siguientes: - Obtener la información de los clientes como son la dirección IP y el puerto. - Coordinar el proceso de comunicación para iniciar, cerrar la sesión y manejar los errores en dicho proceso. - Gestionar las capacidades de cada sistema: codecs, resolución, etc. El proceso de señalización no se contempla dentro de la especificación de la API, por lo que cada implementación es libre de utilizar los mecanismos que crea adecuados. Sin embargo, la implementación de un servidor de señalización debe seguir un enfoque orientado por el protocolo JSEP 15 . Además separar el servicio de señalización en una capa distinta en vez de tenerlo embebido en el navegador, nos evita problemas como pueden ser la pérdida del estado de la comunicación si por algún problema tuviéramos que recargar el navegador. En la figura 8 mostramos el esquema de señalización JSEP. 14 http://w3c.github.io/webrtc-pc/#rtcpeerconnection-interface 15 Javascript Session Establishment Protocol, http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03 Sprints 38 Figura 8: Modelo de señalización JSEP Describamos ahora el blujo básico de interacción bajo este protocólo. Supongamos que dos clientes quieren entablar una comunicación. Uno de los clientes, el emisor, se conectará al servidor y realizará una petición para crear un canal con el que poder comunicarse. Si el canal no existe, como es el caso, el servidor lo creará y se lo notificará al emisor. El receptor, que quiere entablar una conversación con el emisor, se conectará al servidor y realizará una petición para crear el canal, pero como éste ya existe, solicitará el uso del mismo al servidor. Una vez el receptor ha ingresado en el canal, se enviará una notificación al emisor. Entonces el proceso de comunicación podrá comenzar, enviándose mensajes entre los dos clientes con la información necesaria para controlar el proceso de comunicación (descriptores de media e información de red). Recordemos que éste proceso es sólo para el control de la transmisión, no para la transmisión en si. Cualquiera de ellos podrá terminar la conversación desconectándose del servidor en cualquier momento. Ilustramos el proceso en la figura 9: Sprints 39 Figura 9: Proceso de señalización Para la implementación del servidor de señalización hemos optado por utilizar websockets en nuestro entorno Node.js [LR14]. WebSocket 16 es una tecnología que proporciona un canal de comunicación bidireccional, asíncrona, persistente y fullduplex sobre un único socket TCP, evitando abrir múltiples puertos entre aplicaciones cliente-servidor: una vez establecida la conexión a través de un socket, ésta permanecerá activa hasta que uno de los lados decida cerrarla. Con esta API se pueden enviar mensajes a un servidor y recibir respuestas controladas por eventos, lo que evita al cliente tener que estar siempre consultando al servidor (polling) con el consumo de 16 https://tools.ietf.org/html/rfc6455 Sprints 40 recursos que esto implica. Para implementar esta tecnología en nuestro servidor Node haremos uso del paquete Socket.Io 17 . Intercambio de información de sesión Una vez implementado nuestro servidor de señalización ya disponemos de un mecanismo para negociar el contenido media que se van a intercambiar los clientes. El modelo de señalización propuesto por JSEP y utilizado por nuestro servidor se basa en el intercambio de metadatos con formato SDP 18 (Session Description Protocol) entre los clientes, mediante el sistema de publicar una oferta y obtener una respuesta. Veamos un ejemplo del proceso de señalización bajo el modelo JSEP. Supongamos que un cliente emisor quiere realizar una llamada a otro cliente receptor. El emisor crea una oferta con la información de su SDP y la envía al receptor por medio del servidor de señalización. Cuando es recibida por el receptor, éste crea una respuesta a dicha oferta, la relaciona localmente para guardar la referencia y la envía al emisor. El emisor la recibe y la asocia con la oferta emitida. El proceso lo ilustramos en la figura 10: Figura 10: Intercambios de SDPs SDP o Session Description Protocol es en protocolo que describe el formato de los parámetros para la participación en una conexión multimedia, como pueden ser el tipo 17 http://socket.io/ 18 https://www.ietf.org/rfc/rfc2327.txt Sprints 41 de contenido, el formato, los codecs... o lo que es lo mismo, qué se va a transmitir y como se va a manejar el contenido media que se reciba. SDP no se encarga de la transmisión del contenido, sino de la negociación entre los clientes de las capacidades de cada uno. Intercambio de información de red Además del intercambio de información media durante el proceso de señalización, los participantes envían información de la dirección y del puerto donde pueden ser localizados: a este proceso se le conoce por el nombre de “búsqueda de candidatos”. El objetivo de intercambiar esta información de red es el de poder transmitir directamente el contenido media de un cliente a otro cliente sin necesidad de elementos mediadores. Para este proceso de descubrir interfaces y puertos de red utilizaremos el framework ICE o Interactive Connectivity Establishment 19 . El objetivo de dicho framework es encontrar la mejor ruta entre los dos clientes solventando las complejidades de la topología de la red. En un entorno real, como el que se muestra en la figura 11, los clientes no se conectan a la red directamente sino que lo hacen a través de algún dispositivo, como puede ser un router o un firewall. Cada cliente posee una dirección IP privada que lo identifica dentro de la red a la que pertenece y que no es accesible desde Internet. Para poder comunicarse con el exterior, se utiliza un mecanismo denominado NAT o Network Address Translation, para convertir las IPs privadas, que son únicas y accesibles desde Internet, en públicas y permitir a los equipos enviar peticiones al exterior y realizar el proceso inverso de convertir las direcciones públicas en privadas, para que el equipo que envió la petición, pueda recibir una respuesta. Figura 11: Topología de red NAT 19 https://tools.ietf.org/html/rfc5245 Sprints 48 7.3.2 Acceso a la aplicación Análisis funcional Descripción Para acceder a la aplicación el usuario deberá identificarse mediante una combinación usuario/contraseña. Una vez comprobada su acreditación el usuario será redirigido a la pantalla de gestión de citas si es un usuario de tipo paciente, o a la pantalla de gestión de consultas si es un médico. Mockups La pantalla de acceso presenta dos campos de entrada de texto, uno para el nombre de usuario y otro para la contraseña, además de un botón cuya funcionalidad es la de proceder a la comprobación de acreditación del usuario. La pantalla se representa en el mockup 1: Mockup 1: Acceso a la aplicación Usuarios - Paciente. - Médico. Sprints 49 Historias de usuario - 1. Restricciones - Los usuarios deben estar dados de alta en la aplicación para poder acceder a ella. - El acceso al sistema se hará en base a la combinación email/password. - No podrá haber dos usuarios en el sistema con el mismo email. - El campo contraseña debe ocultar los caracteres que esté escribiendo el usuario. Pruebas de aceptación - El paciente se logea correctamente y accede a la pantalla de gestión de citas. - El doctor se logea correctamente y accede a la pantalla de gestión de consultas. - El usuario, médico o paciente, se logea incorrectamente, se muestra mensaje de error y nos quedamos en la pantalla de login. Sprints 50 Diseño Para el acceso a la aplicación haremos uso de un plugin de Codeigniter llamado Ion_auth 23 . Ion_auth es una librería con funcionalidad para la gestión de autentificación y manejo de roles de usuario. Nos proporciona un sistema de autentificación seguro basado en el almacenamiento de los passwords con ¡Error! No se encuentra el origen e la referencia. y evitando ataques ¡Error! No se encuentra el origen de la referencia.. Es una mejora de la librería Redux Auth 2 y hoy en día es una de las más utilizadas en el desarrollo de aplicaciones bajo Codeigniter debido a su sencillez de uso, su simplicidad y su gran potencialidad. En esta librería delegaremos la autentificación y gestión de roles de nuestra aplicación. Además Ion_auth proporciona funcionalidad para la gestión avanzada de usuarios, funcionalidad que implementaremos en iteraciones avanzadas de nuestro desarrollo. La instalación es tan sencilla como descargar el último paquete de la distribución (2.0 en el momento de la realización del proyecto), sobrescribir nuestro código y ejecutar el SQL correspondiente al motor de base de datos que estemos utilizando (MySQL en nuestro caso). Ion_auth utiliza una organización de usuarios basada en pertenencia a grupos. El diagrama entidad-relación 1, que representa esta asociación, se muestra a continuación: Diagrama entidad-relación 1: Usuarios - grupos Describiremos ahora las acciones involucradas en el proceso de logeo. El usuario de la aplicación, médico o paciente, accede a la web y procede a identificarse. Comprobamos entonces si el usuario está dado de alta en el sistema para que, en caso afirmativo, sea redirigido a la pantalla de gestión principal del tipo al que pertenece. El diagrama de secuencia 1, que representa el proceso de acceso a la aplicación es el siguiente: 23 http://benedmunds.com/ion_auth/ Sprints 51 Diagrama de secuencia 1: Acceso a la aplicación Modelamos ahora el diagrama de secuencia para obtener el modelo clases y tener una visión concreta y cercana al detalle de la implementación de los objetos involucrados en el proceso. Desde la vista de acceso a la aplicación vlogin, llamamos al controlador que se encargará de la gestión de usuarios, auth. Mediante la función login y haciendo uso de la librería de autorización, el controlador comprobará si los datos pasados pertenecen a un usuario válido para redirigirlo al método principal, index, del controlador del tipo al que pertenece, cpatients o cdoctors y redirigirlos a la vista de gestión apropiada: vpatient o vdoctor respectivamente. El diagrama de clases 1 representando el modelo explicado: Diagrama de clases 1: Acceso a la aplicación Sprints 52 Pantallas La pantalla 1, de acceso a la aplicación. Pantalla 1: Acceso a la aplicación Sprints 53 7.3.3 Listado de citas del paciente Análisis funcional Descripción Se muestra un listado con las citas para día actual del paciente. La información que se mostrará en las citas será la del nombre del médico, su especialidad, la fecha y hora de la consulta. Mockup La pantalla principal se dividirá en dos. En la parte derecha dejaremos un espacio para un futuro menú, en la parte central mostraremos la información de la pantalla en la que estemos, que en este caso será el listado de citas para el día actual. El mockup 2: Mockup 2: Listado de citas del paciente Usuarios - Paciente. Historias de usuario - 2. Restricciones - Sólo se muestran las citas del paciente actual. - Sólo se muestran las citas del día en cuestión. Sprints 54 Pruebas de aceptación - Al acceder se muestran todas las citas del usuario para el día actual. Sprints 55 Diseño La idea es implementar la pantalla principal del menú del paciente. La pantalla se mostrará cuando el paciente se haya logeado con éxito y mostrará el listado de citas para el día actual. Lo primero es establecer los modelos de los objetos implicados en el proceso: paciente, doctor y cita. El modelo del objeto paciente, que será una especialización del objeto usuario, se presenta a continuación en el diagrama entidadrelación 2: Diagrama entidad-relación 2: Usuario-paciente Por el momento el único campo propio es el de fecha de nacimiento. El modelo del objeto doctor, que también es una especialización del objeto usuario, tiene como elemento diferenciador la especialidad del mismo. La representación en el diagrama 3: Diagrama entidad-relación 3: Usuario-doctor Sprints 56 El objeto cita, que representa un arreglo en un instante de tiempo entre el paciente y el doctor con la finalidad de estudiar unos síntomas y emitir un diagnóstico se representa de la siguiente forma en el diagrama 4: Diagrama entidad-relación 4: Paciente - doctor - cita Una vez construidos los modelos pasamos a definir el proceso. El paciente, después de logearse correctamente, es redirigido a la vista de gestión con la información de las citas, proceso mostrado en el diagrama de secuencia 2: Diagrama de secuencia 2: Obtener citas del paciente Sprints 57 Extrapolemos ahora el diagrama de secuencias al diagrama de clases 2, con los métodos necesarios para obtener y mostrar el listado de citas. Creamos el controlador cpatients para agrupar la implementación de la funcionalidad del modelado del paciente y un paquete para agrupar las vistas del mismo con la vista principal vpatient. Además necesitaremos obtener la información relacionada con las citas por lo que también creamos un modelo para las mismas, appointments_model. Como vamos a construir la pantalla de gestión principal, lo vamos a hacer desde el método index del controlador. Al acceder, cargaremos desde el modelo las citas con el método get_appointments_by_patient Diagrama de clases 2: Obtener citas del paciente Sprints 64 7.4 Sprint 4: Consulta del médico En este sprint abordaremos las tareas de gestión de citas y consulta por video-llamada del lado del médico. 7.4.1 Historias de usuario Identificador 4 Product Backlog ID 4 Título Gestión de citas Descripción: Como médico quiero ver el listado de citas diarias para poder atender a los pacientes. Prioridad (1 a 10): 5 Dependencias 1 Identificador 5 Product Backlog ID 1 Título Consulta por parte del médico Descripción: Como médico quiero atender una sesión de consulta para poder dar respuesta a un paciente. Prioridad (1 a 10): 10 Dependencias 1, 4 Sprints 65 7.4.2 Gestión de citas Análisis funcional Descripción Desde esta pantalla el médico tiene información de las consultas del día. La información que deberán presentar las citas es la de nombre y apellidos del paciente, especialidad y la hora a la que está programada la consulta. Mockup Esta será la pantalla principal del doctor. Se mostrará el listado de citas del día en el centro. El modelo de la pantalla representado en el mockup 4: Mockup 4: Gestión de citas Actores - Médico. Historias de usuario - 4. Restricciones - Sólo se muestran las citas del día actual. - Sólo se muestran las citas del médico actual. Sprints 66 Pruebas de aceptación - Al acceder se muestran todas las citas programadas para el médico para el día actual. Sprints 67 Diseño El proceso es similar al desarrollado para el paciente. Los objetos que representan al doctor y a la cita médica, así como el modelo de ésta última se definieron en apartados anteriores. El diagrama de secuencia 4 que representa las acciones: Diagrama de secuencia 4: Obtener citas del médico El diagrama de clases 4, es también muy similar al de la funcionalidad para los pacientes. Crearemos ahora un controlador cdoctors, para la funcionalidad del doctor y una vista para la pantalla de gestión vdoctor. El modelo para obtener las citas se creó en apartados anteriores. Diagrama de clases 4: Obtener citas del médico Sprints 68 Pantallas El listado de citas del doctor mostrado en la pantalla 4. Pantalla 4: Gestión de citas del doctor Sprints 69 7.4.3 Consulta Análisis funcional Descripción Cuando el médico pulsa sobre una de la citas de la pantalla anterior, es redirigido a una vista nueva para que pueda tener una consulta con el paciente mediante video-chat. El médico puede terminar la cita cuando quiera, lo que le llevaría de regreso a la pantalla de “Gestión de citas”. Mockup Dividiremos la pantalla en dos secciones. En la principal mostraremos la captura del video del paciente, las opciones de chat y un botón para finalizar la consulta. En la sección de la derecha la captura de video del doctor. La estructura en el mockup 5: Mockup 5: Consulta del doctor Actores - Médico. Historias de usuario - 5. Restricciones - La consulta entre médico y paciente debe ser exclusiva. Sprints 70 Pruebas de aceptación - Se puede realizar una sesión de video-chat con el paciente. - Se vuelve a la pantalla principal del doctor al pulsar sobre el botón para finalizar la consulta. Sprints 71 Diseño También para esta pantalla, el comportamiento es similar al del proceso para el paciente, por lo que no entraremos mucho en detalle. El diagrama de secuencia 5: Diagrama de secuencia 5: Acceder a la consulta Y el diagrama de clases 5, también similar al diseñado para el paciente: Diagrama de clases 5: Acceder a la consulta Sprints 72 Pantallas La pantalla 5 de consulta del médico con la captura de video local, las opciones de chat y la vista donde irá el video remoto del paciente: Pantalla 5: Consulta del doctor Sprints 73 La pantalla 6 muestra la interacción médico-paciente desde el punto de vista del paciente: Pantalla 6: Interacción médico-paciente Sprints 80 Pantallas La pantalla 7 del doctor mostrando las citas del día en la zona central y las citas que están en la sala de espera esperando por la consulta en el lateral Pantalla 7: Sala de espera Sprints 81 7.5.3 Detalles de consulta Análisis funcional Descripción Durante el proceso de consulta, el médico debe poder ver la información del paciente y actualizarla. La información básica comprenderá el nombre y los apellidos, la fecha de nacimiento, los síntomas y el diagnóstico. Mockup Se añadirá un menú lateral a la pantalla de consulta del doctor en el que se mostrará la información del paciente. La información se podrá editar y guardar mediante la adición de un botón. El mockup 7 representa la estructura del detalle de consulta: Mockup 7: Detalles de consulta Actores - Médico. Historias de usuario - 7 Sprints 82 Restricciones - El proceso de consulta no puede interrumpirse. - Los datos mínimos para poder guardar el formulario deberán ser el nombre, los apellidos y la fecha de nacimiento. Pruebas de aceptación - Al acceder se muestra la información del paciente ya cargada. - Al pulsar sobre el botón guardar, la información se actualizará sin interrumpir la comunicación. Sprints 83 Diseño Durante el proceso de consulta, el doctor puede ir editando la información del paciente. Las acciones que realiza el médico las mostramos en el diagrama de secuencia 7: Diagrama de secuencia 7: Guardar información de la consulta Creamos una nueva vista vappointment_info, que integraremos en la vista general vappointment. La nueva vista contendrá un formulario que llamará a la función save_appointment del controlador mediante Ajax. Al hacerlo así, cargaremos la vista de forma asíncrona y sin interrumpir el proceso de consulta. En el modelo crearemos dos funciones, una para persistir los datos, save_appointment y otra para obtener los datos de la consulta, get_appointment_by_id. El controlador las utilizará para guardar y obtener los datos de la consulta y mandarlos de nuevo a la vista de información de la consulta. El diagrama de clases 7: Diagrama de clases 7: Guardar información de la consulta Sprints 84 Pantallas La pantalla 8 del doctor con la información del paciente y las opciones para modificarlas: Pantalla 8: Detalles de consulta Resultados y conclusiones 85 8. Resultados y conclusiones El proceso de desarrollo de un producto software, cómo el de cualquier otra ingeniera, no es un proceso sencillo ni trivial: desde las primeras fases en las que se va conformado la idea de negocio, hasta la obtención del producto, hay que pasar por una serie de etapas en las que cada una supone un riesgo para la consecución de nuestro objetivo final. Nuestra primera aproximación a la realización del presente proyecto, fue con la idea de implementar una aplicación que se conectara a diversos dispositivos médicos por USB y gestionara toda esa información de forma centralizada. Nos pusimos en contacto con Daniel González Santana, médico especialista en pediatría digestiva del Centro Hospitalario Universitario Insular-Materno Infantil, con la idea de que aceptara el rol de product owner y nos guiara en la realización del mismo. Durante el proceso de extracción de información y desde las primeras entrevistas, fuimos descubriendo de forma conjunta unas necesidades diferentes a las definidas en los objetivos iniciales del proyecto: las urgencias, por normal general, presentaban un número de pacientes significativo y los tiempos de espera no eran cortos. También en los procesos de consultas médicas generales el número de pacientes era elevado. Ambos grupos contaban con un identificador común: en un alto porcentaje, los diagnósticos eran fácilmente realizables mediante una exploración supericial del paciente, ya que eran dolencias bastante comunes: resfriados, sinusitis, fiebres, etc. Decidimos investigar un poco sobre el tema y descubrimos que en Estados Unidos, el mercado de la teleasistencia sanitaria tenía bastante aceptación, por lo que después de otra serie de entrevistas y conversaciones, decidimos pivotar a este nuevo negocio. Con la idea del proyecto ya en mente, empezamos a organizar los detalles técnicos para gestionar los riesgos y comprobar la viabilidad del proyecto; el más destacable era la transmisión de video y audio, además de contenido no media, para implementar el módulo de videoconferencia. Afortunadamente investigando este aspecto, dimos con la API WebRTC que nos permitía afrontar el desarrollo de dicha funcionalidad con las garantías de ofrecer un módulo de videconferencia sencillo de integrar, sin necesidad de instalaciones adicionales por parte del cliente, fácil de mantener y con un bajo consumo de recursos. Con las herramientas ya seleccionadas empezamos el desarrollo del prototipo funcional siguiendo una metodología de desarrollo agíl: análizabamos un hito, lo validábamos con el product owner, realizábamos el diseño técnico, implementábamos la funcionalidad y por último, validábamos el resultado con el product owner, La elección de una metodología ágil venía favorecida en gran medida por la alta disponibilidad de nuestro product owner, permitiéndonos ir de forma conjunta durante el proceso de implementación del prototipo, gestionando sus expectativas y reaccionando rápido a los cambios. El resultado ha sido bastante satisfactorio, dando como producto un prototipo funcional para la gestión de consultas por videoconferencia. Ademas, podemos destacar la posibilidad de reutilización del módulo de comunicaciones para proyectos de terceros Resultados y conclusiones 86 por haberlo implementado de forma totalmente desacoplada al módulo de gestión de información. También resaltar que la utilización de un ORM para la gestión de la base de datos, nos permite integrar nuestro sistema, con un coste relativamente bajo, en otros sistemas de gestión sanitaria, como un módulo complementario a los servicios originales. Trabajo futuro. 87 9. Trabajo Futuro. Como continuidad al trabajo realizado proponemos los siguientes hitos: - Terminar con la funcionalidad propuesta por el product owner y que no ha sido cubierta en la realización del proyecto presentado. - Implementación de un módulo de facturación para la gestión del cobro por consultas. - Implementación y configuración de un servidor NAT/TURN propio para sustituir a los utilizados por el proyecto, que son servidores libres de Google. - Implementar mecanismos de seguridad en las llamadas por video, como podría ser la aplicación del protocolo HIPAA. - Implementación de un cliente móvil. - Implementación de un módulo de personalización de la herramienta en función del cliente. Bibliografía 88 10. Bibliografía - [LR14]. Salvatore Loreto & Simon Romano. “Real Time Comunication With Web-RTC”. O‟Really, 2014. - [M02]. Robert C. Martin. “Agile Software Development: Principles, patterns and practice”. Prentice Hall, 2002. - [M13]. Rob Manson. “Getting Started With WebRTC”. Packt Publishing, 2013. - [PM08]. Dan Pilone & Russ Miles. “Head First Software Development”. O‟Really, 2008. - [S95]. Ken Schwaber. “SCRUM Development Process”. OOPSLA 1995. Bibliografía 89 11. Enlaces - Teladoc: o http://www.teladoc.com (12/01/2015) - MDLive: o https://mdlive.com/ (12/01/2015) - American Well: o https://www.americanwell.com/ (12/01/2015) - Dr On Demand: o http://www.doctorondemand.com/ (12/01/2015) - HIPAA: o http://www.hhs.gov/ocr/privacy/hipaa/understanding (12/01/2015) - ISO 27002:2013: o http://www.iso.org/iso/catalogue_detail?csnumber=54533 (12/01/2015) - VSEE: o http://vsee.com/ (12/01/2015) - AddLive: o http://www.addlive.com/ (12/01/2015) - [O08] Página oficial del creador del modelo canvas: o http://alexosterwalder.com (20/01/2015) - Modelo canvas: o http://businessmodelgeneration.com/canvas/bmc (20/01/2015) - Codeigniter: Framework de desarrollo. o https://ellislab.com/codeigniter (10/09/2014) - Ventajas de Codeigniter: o http://www.php-developers.org/blog/codeigniter/advantages-andfeatures-of-codeigniter-framework.html (10/09/2014) - Información sobre motores de base de datos: o http://db-engines.com/en/ranking (10/09/2014) - Introducción a los ORMs o http://www.orm-designer.com/article/orm-frameworks-for-php5-generalintroduction (10/09/2014) Anexos 96 Ya tenemos implementado una estructura básica para la gestión de vistas. Vamos ahora a desarrollar una funcionalidad para la gestión de notificaciones al usuario. Para ello utilizaremos el plugin JQuery, UI Notify Widget. Además, crearemos un controlador básico del que heredarán el resto de controladores de nuestra aplicación con la funcionalidad común a todos ellos, como es el caso que nos ocupa. La idea es añadir los mensajes en sesión y luego mostrarlos utilizando el plugin, por lo que al controlador genérico le añadimos tres métodos: uno para gestionar los mensajes, otro las advertencias y por último uno para los errores. class My_Controller extends CI_Controller { function __construct() { try { parent::__construct(); error_reporting(E_ALL); // Cargamos el fichero de lenguaje general de la // aplicación $this->lang->load('kairos_common'); } catch (Exception $e) { log_message( 'Error', $e->getMessage( ) . ' en ' . $e->getFile() . ':' . $e->getLine() ); } } // Método para guardar los mensajes de información public function add_message($value) { if( !empty($value) ) { $_SESSION['messages'][] = $value; } } // Método para obtener los mensajes de información public function get_messages() { return isset($_SESSION['messages']) ? $_SESSION['messages'] : NULL; } // Método para borrar los mensajes de información public function delete_messages() { unset($_SESSION['messages']); } // Método para añadir los mensajes de advertencia public function add_warning($value) { if( !empty($value) ) { $_SESSION['warnings'][] = $value; } } // Método para obtener los mensajes de advertencia public function get_warnings() { Anexos 97 return isset($_SESSION['warnings']) ? $_SESSION['warnings'] : NULL; } // Método para borrar los mensajes de advertencia public function delete_warnings() { unset($_SESSION['warnings']); } // Método para añadir los mensajes de error public function add_error($value) { if( !empty($value) ) { $_SESSION['errors'][] = $value; } } // Método para obtener los mensajes de error public function get_errors() { return isset($_SESSION['errors']) ? $_SESSION['errors'] : NULL; } // Método para borrar los mensajes de error public function delete_errors() { unset($_SESSION['errors']); } } Ahora hacemos que nuestro controlador cprueba extienda de nuestro nuevo controlador y por lo tanto, herede la funcionalidad del mismo: class cprueba extends My_Controller { public function index() { $this->data['params']['texto'] = 'Esto es el contenido'; $this->data['params']['main'] = 'prueba/vprueba'; // Añadimos un mensaje haciendo uso de la funcionalidad // heredada de My_Controller $this->add_warning(„Sesión finalizada con éxito‟); $this->load->view('main/main_template', $this->data); } } Ya tenemos el mensaje añadido a sesión; vamos ahora a implementar la forma de mostrarlos por pantalla con ayuda del plugin. Lo primero es cargar las librerías de JQuery y la de notificaciones en la plantilla principal. <!DOCTYPE HTML> <html> <head> . . Anexos 98 . <!-- Cargamos la librería de JQuery --> <script type="text/javascript" src="<?php echo base_url ('js/jquery-1.9.1.min.js');?>"></script> <!-- Cargamos la librería de Notificaciones --> <script type="text/javascript" src="<?php echo base_url ('js/jquery-notify/ui.notify.js');?>"></script> <!-- Cargamos los estilos de la librería de notificaiones --> <link rel="stylesheet" type="text/css" href="<?php echo base_url('css/ui.notify.css');?>" media="screen" /> . . . </head> . . . </html> Implementamos una vista para gestionar los mensajes del sistema: <div> <!-- Creamos un div con la estructura definida por la librería para mostrar las notificaciones --> <div id="container" style="display:none"> <div id="info-notify" class="ui-notify-message ui-notify-message-info"> <a class="ui-notify-cross ui-notify-close" href="#">x</a> <div style="float:left;margin:-7px 10px 0px 0"> <img src="<?php echo base_url();?> /css/images/information.png" alt="info"></div> <h1><?php echo $this->lang->line('information');?></h1> <p>#{text}</p> </div> <div id="warning-notify"> <a class="ui-notify-cross ui-notify-close" href="#">x</a> <div style="float:left;margin:-7px 10px 0 0"> <img src="<?php echo base_url();?> /css/images/warning.png" alt="warning"></div> <h1><?php echo $this->lang->line('warning');?></h1> <p>#{text}</p> </div> <div id="error-notify"> <a class="ui-notify-cross ui-notify-close" href="#">x</a> <div style="float:left;margin:-7px 10px 0 0"> <img src="<?php echo base_url();?> /css/images/error.png" alt="error"></div> <h1><?php echo $this->lang->line('error');?></h1> <p>#{text}</p> </div> </div> <?php // Cargamos los mensajes de información que se han // añadido $messages = get_instance()->get_messages(); // Añadimos al DOM los mensajes de información Anexos 99 if(isset($messages)) { ?> <div class="messages" style="display:none"> <ul> <?php foreach( $messages as $message ) { echo sprint ('<li>%s</li>', $message); } ?> </ul> </div> <?php // Borramos los mensajes get_instance()->delete_messages(); } ?> <?php // Cargamos los mensajes de advertencia que se han // añadido $messages = get_instance()->get_warnings(); // Añadimos al DOM los mensajes de advertencia if(isset($messages)) { ?> <div class="warnings" style="display:none"> <ul> <?php foreach( $messages as $message ) { echo sprint ('<li>%s</li>', $message); } ?> </ul> </div> <?php // Borramos los mensajes get_instance()->delete_warnings(); } ?> <?php // Cargamos los mensajes de error que se han // añadido $messages = get_instance()->get_errors(); // Añadimos al DOM los mensajes de error if(isset($messages)) { ?> <div class="errors" style="display:none"> <ul> <?php foreach( $messages as $message ) { echo sprint ('<li>%s</li>', $message); } ?> </ul> </div> <?php // Borramos los mensajes get_instance()->delete_errors(); } ?> </div> <script> $(function() { Anexos 100 // Añadimos la funcionalidad. $("#container").notify(); // Por cada mensaje añadido al DOM, mostramos una notificación // haciendo uso de la librería $.each( $('.messages > ul > li'), function(id, value) { $("#container").notify("create", "info-notify", { text: $(value).html() }); }); $.each( $('.warnings > ul > li'), function(id, value) { $("#container").notify("create", "warning-notify", { text: $(value).html() }); }); $.each( $('.errors > ul > li'), function(id, value) { $("#container").notify("create", "error-notify", { text: $(value).html() }); }); </script> Y la añadimos a la plantilla principal: <!DOCTYPE HTML> <html> <head> . . . </head> <body> <div class="page"> <div class="page-header"> <?php $this->load->view('main/header', $params); ?> </div> <div class="main-section"> <?php $this->load->view($params['main'], $params); ?> </div> <div class="page-footer"> <?php $this->load->view('main/footer', $params); ?> </div> </div> <!-- Añadimos la vista de notificaciones --> <?php $this->load->view('main/notify', $params); ?> </body> </html> Anexos 101 Ejecutando la aplicación, observamos lo que podemos ver en la pantalla 3: Pantalla 3 Propel Una vez configurado nuestro framework pasamos a instalar Propel. Podemos instalar Propel de dos formas distintas: la primera es dentro del proyecto en cuestión y la segunda es a través de Pear. La diferencia principal entre una y otra es que si instalamos Propel de la primera manera, el ORM sólo estará disponible para el proyecto en cuestión. Sin embargo, si la instalamos de la segunda forma, tendremos instalado el ORM de forma general para todos los proyectos. Elegimos instalarlo de la primera manera y así hacemos independiente la versión del ORM entre los distintos proyectos que queramos desarrollar. Los pasos para instalar Propel son los siguientes: 1. Nos descargamos el ORM, en nuestro caso la versión 1.7. 2. Lo descomprimimos dentro de una carpeta en nuestro proyecto, application/third_party. 3. Instalamos la dependencia Phing a través de Pear. Para ello ejecutamos en la línea de comandos (ejecutarla con permisos de administrador) la siguiente cadena de comandos. Recordar que la ruta de los .bat debe estar añadida como variable del sistema en el PATH de Windows o tendremos que ir a la ubicación donde se encuentran para poder ejecutarlos (C:\xampp\php). Esto lo tendremos que hacer para que Propel puede ejecutar Phing. Una vez instalado tecleamos en la línea de comandos phing -v para comprobar que se ha instalado correctamente: Anexos 102 a. pear channel-discover pear.phing.info b. pear install phing/phing c. pear install Log 4. Probamos la instalación. Vamos a la carpeta donde hemos instalado la librería Propel y en /propel/generator/bin/ ejecutamos el comando propel-gen. Se empezará a ejecutar el script mostrando un mensaje de fallo. Esto es normal ya que no hemos configurado la librería. Configuraremos ahora nuestro ORM. Lo primero es decirle a Propel que sistema de gestión de base de datos estamos utilizando y cuál es el nombre de la misma; eso lo hacemos en el fichero application/third_party/propel-1.7.0/generator/bin/build build.properties. Propel necesita comunicar en tiempo de ejecución el modelo que generemos de los objetos con la bbdd. Para ello hace uso de un fichero de configuración, application/third_party/propel-1.7.0/generator/bin/build/runtime-conf.xml: # Database driver propel.database = mysql # Project name propel.project = kairos <?xml version="1.0" encoding="UTF-8"?> <config> <propel> <datasources default="kairos"> <datasource id="kairos"> <adapter>mysql</adapter> <connection> <dsn>mysql:host=localhost;dbname=kairos</dsn> <user>kairos</user> <password>kairos</password> <settings> <setting id="charset">utf8</setting> </settings> <options> <option id="MYSQL_ATTR_INIT_COMMAND"> SET NAMES utf8 COLLATE utf8_unicode_ci </option> </options> </connection> </datasource> </datasources> </propel> </config> Anexos 103 Configuramos en dicho fichero las opciones de acceso a nuestra base de datos (base de datos que previamente hemos creado con ayuda de PHPMyAdmin). Es el momento ahora para crear un objeto propel y modelar una tabla de nuestra base de datos; crearemos la tabla usuarios y la modelaremos. En principio la tabla sólo contendrá un identificador y un campo nombre. El modelado de las tablas se hace en el fichero application/third_party/propel-1.7.0/generator/bin/build/schema.xml, cada tabla se define dentro de las etiquetas <table></table>. La definición de la tabla usuarios: <?xml version="1.0" encoding="utf-8"?> <database name="kairos" defaultIdMethod="native"> <table name="users" phpName="Users"> <column name="id" type="integer" required="true" primaryKey="true" autoIncrement="true"/> <column name="name" type="varchar" size="50" /> </table> </database> Y la definición de nuestra tabla usando MySQL: CREATE TABLE IF NOT EXISTS `users` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(100) CHARACTER SET utf8 COLLATE utf8_spanish2_ci DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci AUTO_INCREMENT=2 ; Para más información sobre cómo definir las tablas en términos de nuestro ORM nos remitiremos a la documentación de Propel: ahí se explica bien la correspondencia de campos entre Propel y nuestra base de datos. Construiremos ahora el modelo mediante el comando propel-gen om en la ruta application/third_party/propel-1.7.0/generator /bin. Esto creará un nuevo directorio application/third_party/propel-1.7.0/generator /bin/build/classes/kairos con las clases Propel. Por cada tabla, Propel genera 3 clases: - La clase modelo, que representa una fila dentro de la bbdd. - La clase peer, que ofrece las constantes y métodos para operar con el objeto. - La clase query, que se utiliza para operar con la tabla. Ahora relacionaremos los objetos de la base de datos con las clases PHP generadas, ejecutando el comando propel-gen convert-conf. Ya tenemos Propel instalado y listo para ser utilizado. Probaremos ahora que todo está correcto. Modificamos el método index de nuestro controlador cprueba, nos creamos un modelo al que llamaremos prueba_model, cargamos los datos de la tabla users y lo devolveremos al controlador para que los muestre en la vista vprueba. class cprueba extends CI_Controller { public function index() { // Cargamos el modelo $this->load->model('uers_model'); Anexos 104 // Llamamos al modelo para obtener los usuarios $this->data['params']['users'] = $this->users_model->get_users(); // Establecemos la vista $this->data['params']['main'] = 'prueba/vprueba'; // Cargamos la vista en la plantilla principal y // la mostramos $this->load->view('main/main_template', $this->data); } } En el modelo crearemos un constructor en el que configuraremos el acceso a Propel para poder utilizarlo y un método get_users() para obtener los usuarios haciendo uso de nuestro ORM: class Users_model extends CI_Model { public function __construct() { parent::__construct(); // Incluímos el script de Propel require_once 'application/third_party/ propel-1.7.0/runtime/lib/Propel.php'; // Inicializamos Propel Propel::init("application//third_party/ propel-1.7.0/generator/bin/build/conf/kairos-conf.php"); // Añadimos el directorio con las clases PHP que // modelan a los objetos de la base de datos set_include_path("application//third_party/ propel-1.7.0/generator/bin/build/classes" . PATH_SEPARATOR . get_include_path()); } public function get_users() { // Creamos la consulta para obtener los usuarios $users_query = UsersQuery::create()->find(); $users = array(); foreach ($users_query as $user_query) { $user['id'] = $user_query->getId(); $user['name'] = $user_query->getName(); $users[] = $user; } return $users; } } En la vista mostramos los datos obtenidos por la consulta: Anexos 105 <div> <ul> <?php foreach ($users => $user) { ?> <li> <?php echo $user['id'] . ' ' . $user['name']; ?> </li> <?php } ?> </ul> </div> Si nos vamos a la dirección http://direccion_ip_local/kairosomac/index.php/cprueba en nuestro navegador, comprobamos que accedemos a nuestra BBDD utilizando Propel como observamos en la pantalla 4: Pantalla 4 Node.js Por último instalaremos nuestro servidor Node. La instalación de Node.js en entornos Windows es bastante sencilla: basta con bajarnos desde su página web oficial la versión que queramos (0.10 en nuestro proyecto) y lanzar el ejecutable. Una vez instalado (y configuradas las variables de entorno correctamente) para acceder al mismo solamente tenemos que teclear node en el bash de Windows. Además, Node viene con una utilidad de línea de comandos para la compilación, instalación y actualización de módulos así como la gestión de las dependencias en nuestro servidor: NPM. Instalar una es tan sencillo como ejecutar la siguiente línea, una vez estemos en el bash de Node: Anexos 112 Pantalla principal del facultativo Pantalla 4: Gestión del facultativo La pantalla 4 es la pantalla principal del facultativo. En el apartado central, “Mis citas”, se muestra un listado con las citas del día actual. En el menú de la izquierda, “Sala de espera” se irán introduciendo las citas de los pacientes que estén en espera. Para acceder a una sesión de consulta, el doctor sólo tiene que pulsar sobre una de estas citas y será redirigido a la pantalla de consulta, en la que estará esperando el paciente. Anexos 113 Pantalla de consulta del facultativo Pantalla 5: Consulta del facultativo Desde la pantalla 5, el doctor atenderá al paciente mediante videoconferencia y la posibilidad de chat. Podrá consultar la información básica del paciente y guardar la información de la consulta. Una vez haya terminado la cita, el facultativo podrá volver a la pantalla principal mediante el botón de finalizar cita.