Red social. Consulta Médica

Roman Petrov Petrov

UOCTrabajo final de máster DADM

página 2

• Introducción

• Contexto y justificación

• Análisis del dominio y analogías

• Planificación de trabajo

• Análisis, diseño y arquitectura

• Implementación y pruebas

• Conclusiones finales

• Demo de aplicación

Contenido:

página 3

© Roman Petrov Petrov

Reservados todos los derechos. Está prohibido la reproducción total o parcial de esta obra por cualquier medio o procedimiento, comprendidos la impresión, la reprografía, el microfilme, el tratamiento informático o cualquier otro sistema, así como la distribución de ejemplares mediante alquiler y préstamo, sin la autorización escrita del autor o de los límites que autorice la Ley de Propiedad Intelectual.

AgradecimientosDedicado a mi familia, por el apoyo y

ayuda en disponer de tiempo necesario para mi formación en la UOC.

Avances tecnológicos

Introducción

página 4

• En el mundo actual, contemporáneo y digital, usamos a diario diferentes tipos de soluciones móviles. Este hecho tiene su origen en los años 90 cuando fue posible colocar un gran número de microcircuitos y placas integradas en un dispositivo de tamaño relativamente pequeño como para poder llevarlo en el bolsillo de una camisa o pantalón.

• Hoy en día, el volumen de consumo y el número de tipos de soluciones móviles usados a diario es colosal, incomparable e imprevisible en los años anteriores.

• Al mismo tiempo, surgió el concepto de redes sociales, donde y como su propio nombre indica, permiten interconectar grandes grupos de personas de diferentes intereses y donde su número puede variar según los objetivos seguidos por estos.

¿Usar redes sociales en medicina?

página 5

• Total movilidad

• En la palma de la mano

• Sin ser médico

• Canal seguro

Redes sociales NO especializadas

Análisis del dominio y búsqueda de analogías

página 6

Redes sociales especializadas

Redes sociales NO especializadas

página 7

A nivel nacional, los médicos suelen utilizan más las redes sociales generales que las soluciones profesionales.

• Facebook 45%. Acercamiento más directo al paciente y publicar información divulgativa.

• Twitter 40%. Difundir hitos, de destacar las noticias sobre los avances y dar a conocer la información sobre las conferencias y eventos.

• LinkedIn 39%. Ayuda a construir propia marca profesional como especialista en una determinada área

• YouTube 28%. Contenido visual y dinámico sobre las técnicas, tecnologías o los tratamientos médicos.

Redes sociales especializadas

página 8

• Intercambio de conocimiento.

• Consultas dirigidas a una especialidad concreta.

• Valoraciones online.

• Segundas opiniones.

• Pagos por participación.

• Posibilidad de anonimato.

• Revisión de analíticas

página 9

• Solo cursos online para médicos • Consultas a una especialidad concreta.

• Debates.

página 10

Resumen características de las redes sociales

• Difusión de información médica.

• Debates sobre enfermedades

Nombre Diálogo paciente/médico

Usuariosregistrados

Web App Disponible España

Acceso paciente

+ 800.000 + iOSAndroid

- -

- 6.000 + - + -

- 5.000 + - + -

+ 90.000 + - + +

- desconocido + - + +

página 11

Resultado análisis

La mayoría de las redes médicas no están disponibles en España y aquellas que sí lo estaban en su momento sus aplicaciones ya no se pueden descargar de los Market.

Un gran número se utiliza simplemente para difusión de noticias médicas.

No todas cuentan con una aplicación móvil lo que merma bastante su popularidad.

Casi todas están orientadas exclusivamente a profesional sanitario siendo obligatorio el registro del usuario y con confirmación de número colegiado.

Las que sí permiten el acceso a los pacientes son comunicaciones de tipo foro y no un dialogo de tu a tu entre el médico y el paciente.

Objetivos de proyecto

página 12

Crear una nueva red social especializada con acceso desde una aplicación móvil y que cumpla con siguientes características:

Permita establecer un diálogo seguro entre el paciente y los médicos, o entre los especialistas entre si.

Permita intercambiar ficheros de las pruebas del paciente como imágenes de radiología o analíticas del laboratorio.

Permita visualizar los ficheros subidos para su posterior análisis

La aplicación funcione y esté disponible en España.

Permita acceso al sistema tanto a los médicos como a los pacientes.

Todo ello llevado y gestionado cómodamente desde una aplicación móvil.

Scrum

Planificación de trabajo

página 13

Para tener una planificación más realista, se ajustó la duración máxima de los sprint a una semana, de lunes a domingo, y permitiendo al alumno trabajar cualquier día pero con el compromiso de dedicar un mínimo de dieciocho horas de carga en cada uno, para garantizar las entregas de los hitos a tiempo y acorde a las fases de TFM, así como de los entregables finales a las fechas marcadas por el plan de la asignatura.

página 14

Fases y sus detalles

Fase 0. Definir y presentar una propuesta justificada de una idea por el estudiante para su validación y aprobación por parte del consultor de la asignatura.

Fase 1. Definir los objetivos del proyecto, la metodología que se utilizará y de realizar la planificación realista de entregas de los hitos basada en la disponibilidad del alumno y las fechas de entregas del plan docente.

Fase 2. Definir el diseño completo de todo el proyecto, el lado funcional y el técnico. El modelo de datos y la arquitectura del sistema, el tipo y forma de comunicación entre el cliente y el servidor, realizar los prototipos de baja y alta fidelidad.

Fase 3. Preparar el entorno de desarrollo e implementar la aplicación final de forma iterativa e incremental agregando en cada Sprint las nuevas funcionalidades que se validan al final y pasan los test correspondientes.

Fase 4. Preparar el contenido de la entrega final que incluye una presentación en texto con los puntos y las decisiones tomadas más importantes, una presentación en vídeo y una memoria final con las conclusiones y resultados obtenidos a lo largo de desarrollo del proyecto.

Riesgos de proyecto

página 16

Riesgo Grado Probabilidad Afectación Como anticiparComo actuar si pasa

Horas extras en el trabajo Riesgo mayor Alta Alta Aprovechar las horas de la comida para adelantar

TFM, llegar antes para dedicar tiempo por la

mañana

Enfermedad común Riesgo medio Baja Baja Evitar contacto con los enfermos.

Enfermedad y estado alarma Covid-19 Riesgo Alto Alta Alta Evitar contacto con los enfermos. Uso de

mascarilla si sales, teletrabajo con la empresa.

Necesidades formativas Riesgo Alto Media Alta Revisión de toda la documentación necesaria

antes de ponerse a desarrollar

Planificación inexacta Riesgo Medio Baja Alta Revisar las tareas pendientes de Backlog más a

menudo y replanificar las prioridades

Análisis, diseño y arquitectura

página 17

DCU-Diseño centrado en usuario:

Usuarios y contextos de uso.

Diseño conceptual.

Prototipado

Evaluación

Diseño técnico:

Casos de uso

Modelo de datos

Diseño de la arquitectura

página 18

Usuarios y contextos de uso

Mediante benchmarking realizar un análisis de público objetivo y sus

necesidades actuales:

soluciones similares o de competencia directa para conocer usuarios y sus

expectativas, tendencias del mercado y funcionalidades más usadas en las

aplicaciones

Perfiles de usuario

Agrupar los objetivos, las necesidades y las expectativas de los usuarios en función de

sus características:

paciente y médico donde ambos pueden realizar las mismas acciones, pero se han

diferenciado en el sistema por su perfil para dar una visibilidad correcta a los

usuarios

Diseño conceptual

página 19

Definir los actores finales y declarar los escenarios de uso de estos en

base a la información obtenida en la etapa anterior:

Definición de personas

Escenarios de uso

Flujos de interacción

Prototipado

página 20

La técnica de prototipado consiste en realizar un diseño inicial de la aplicación y que se divide en dos partes:

creación de un prototipo de baja fidelidad y otro de alta fidelidad.

Prototipo de baja fidelidad con sketching

página 21

Prototipo de alta fidelidad

página 22

página 23

Evaluación

Evaluación heurística mediante modelo Nielsen de la aplicacación y que ha cumplido con todos sus principios:

P1. Visibilidad del estado del sistema

P2. Coincidencia entre el sistema y el mundo real

P3. Control y libertad del usuario

P4. Coherencia y estándares

P5. Prevención de errores

P6. Reconocimiento antes que memoria

P7. Flexibilidad y eficiencia de uso

P8. Estética y diseño minimalista

P9. Ayudar al usuario a reconocer los errores, diagnosticarlos y recuperarse de ellos

P10. Ayuda y documentación

Patrón MVVMSu finalidad es de tratar desacoplar al máximo la interfaz de usuario de la lógica de la aplicación. Sus componentes son:

• El modelo (Model). Representa la capa de datos y/o la lógica de negocio. Contiene la información, pero nunca las acciones o servicios que la manipulan.

• La vista (View). Representa la información a través de los elementos visuales que la componen. Las vistas son activas, contienen eventos, comportamientos y enlaces a datos que.

• Modelo de vista (ViewModel). Es un actor intermediario entre el modelo y la vista, contiene toda la lógica de presentación y se comporta como una abstracción de la interfaz. La comunicación entre la vista y el viewmodel se realiza por medio los enlaces de datos (binders).

Diseño de la arquitectura

página 24

La arquitectura final resultante de la red social médica

página 25

Vista física

página 26

El proyecto final es una solución cliente-servidor, con componentes distribuidos entre las capas de Frontend y Backend.

Software, tecnologías, librerías y herramientas utilizadas:

página 27

Implementación y pruebas

Se utilizaron las herramientas acordadas para llevar a cabo un correcto desarrollo de la aplicación y del proyecto.

• Android Studio, como IDE de desarrollo

• Android Architecture Components, como patrón de diseño.

• PostgreSQL, como base de datos de código abierto.

• WebSocket como tecnología de comunicación sobre TCP entre cliente y servidor.

• Ubuntu OS, como servidor de backend. Oracle Virtual Box, como máquina virtual para montarlo.

• SpringBoot, como framework y Spring Tools, como herramienta de Eclipse para integraciones Spring

• REST, como protocolo de intercambio y manipulación de datos en los servicios.

• Hibernate, para definir las entidades de bbdd y JPA, para generar operaciones sobre las tablas.

• Liquibase, como gestor de cambios en bbdd y DTO, para encapsular y pasar los datos entre las capas

• JUnit4 y Mockito, para las pruebas unitarias y la automatización.

Se revisó la planificación y se encontraron algunas desviaciones debido a la situación actual de la pandemia de COVID-19 y el recién llegado el nuevo concepto de teletrabajo en la empresa, que requirió adaptaciones y ajustes a nivel personal y laboral, pero pudieron ser corregidos a tiempo no afectando a la línea temporal del trabajo final.

Se organizaron las clases siguiendo el modelo MVVM como se especificó en la fase de Análisis y Diseño.

Estructura de proyecto cliente

página 28

Encriptación de comunicación con HTTPS.

Para garantizar la seguridad de información intercambiada se encriptó la comunicación con un certificado auto firmado de tipo ssl, distribuyendo la clave privada y pública entre los participantes.

Se organizaron las clases siguiendo el modelo Spring Boot como se especificó en la fase de Análisis y Diseño.

Estructura de proyecto backend

página 29

• Ayudan a identificar las debilidades de la aplicación, los valores y verificar los casos de uso. Por norma general, se divide en tres partes principales, expresados mediante el concepto llamado "Pirámide de Cohn" que indica que cuanto más bajo se encuentra la capa en la pirámide, más acciones independientes puede cubrir y más fácil será desarrollarla.

• La primera capa, Unit (pruebas unitarias) se utiliza para verificar que los métodos sean correctos a través de las comparaciones ordinarias.

• La segunda capa, de integración o de servicios, se utiliza para probar la interacción del proyecto con otros componentes

• En la parte superior de la pirámide, se encuentran las pruebas de la interfaz de usuario

Pruebas finales

página 30

Pirámide de Cohn

Test de backend

página 31

Siguiendo la recomendación de Cohn, se definieron para Backend

todos los test necesarios y fueron pasados con éxito validando por

completo el funcionamiento del servidor.

página 32

Test de frontendPrueba Resultado Observaciones

Registro en el sistema OK Correcto, se dan de alta en el

sistema ambos perfiles

Login en el sistema OK Correcto, se realiza el login en el

sistema

Ver perfil de usuario OK Correcto, se visualizan los datos

de usuario

Listar usuarios OK Correcto, se listan los usuarios

registrados

Ver usuarios favoritos OK Correcto, se listan los usuarios

favoritos

Marcar como favorito OK Correcto, se guarda usuario como

favorito

Ver diálogos OK Correcto, se visualizan los

diálogos de usuario

Empezar un diálogo OK Correcto, se abre un diálogo

nuevo o ya anterior

Enviar un mensaje OK Correcto, se envía un mensaje al

destinatario

Visualizar un fichero OK Correcto, se visualiza el fichero

adjunto

Responder un mensaje OK Correcto, usuario lee y responde

el mensaje

Ver ficheros propios OK Correcto, se visualizan los

ficheros del almacén

Subir fichero OK Correcto, se sube el fichero al

almacén

Las diferentes APIs aplicación cliente

Carga en Sesión Profiler

Resultado final

página 33

• Se realizó una comparativa de análogos concluyendo que era necesario crear una nueva red social especializada con cliente móvil Android y se identificaron los requisitos de esta.

• Se evaluó el porcentaje de dispositivos de diferentes sistemas operativos disponibles en el mercado y se eligió el más popular, Android.

• Mediante la utilización de Android Studio, se desarrolló la aplicación que ha cumplido con todos los objetivos y requisitos establecidos.

• Mediante la utilización de Spring BootStudio, se desarrolló un Backend que realiza todo el registro de la información en una base de datos relacional.

• Se comprobó la funcionalidad de la aplicación y se demostró que todos los elementos de la aplicación funcionan correctamente y no dan errores.

• Se creó la documentación de uso y mantenimiento de la aplicación.

página 34

Mejoras futuras

• Como cualquier otro proyecto informático, puede y debe ser mejorado mediante anexo de nuevas funcionalidades y mejora de las existentes. En la comparación final del conjunto desarrollado se identificó que sería muy interesante tener también una versión web.

• También añadir más formatos de ficheros adjuntos como podrían ser los modelos STL.

• Añadir compresión de imágenes adjuntas

• Para terminar, una etapa más en el desarrollo de la aplicación sería lanzar una versión para el sistema operativo iOS, que es el segundo sistema operativo más popular del mercado.

página 35Conclusiones

• Todas las tareas se realizaron en tiempo y siguiendo la planificación prevista, siendo resueltas correctamente logrando con éxito el objetivo principal: crear una red social especializada que permita poner en contacto a pacientes con los médicos y especialistas entre sí, todo cómodamente utilizando una aplicación móvil en sus smartphones.

• El uso de las soluciones como Room, Retrofit 2 y RxJava ha sido casi un reto personal costando bastante al principio, pero avanzando a paso firme y aprendiendo las novedades.

• Las poderosas técnicas de DCU permitieron ampliar la perspectiva de la aplicación más allá del ámbito de programador, hasta los usuarios que la van a utilizar para comprender sus opiniones e impresiones