Informe - Trabajo final -Marcos R IS corregido

Vista previa del material en texto

Aplicación web para gestión y detección
de retinopatía diabética
Proyecto Final de Carrera Ingeniería de Sistemas de la Universidad
Nacional del Centro de la Provincia de Buenos Aires
Alumno
Roberto David Marcos
Director
Ignacio Larrabide
22 de Marzo de 2023
1
Resumen
Las personas con diabetes pueden tener una enfermedad ocular llamada retinopatía
diabética. Esta enfermedad ocurre debido a que los niveles altos de azúcar en la
sangre causan daño a los vasos sanguíneos en la retina.
La retinopatía diabética es la principal causa de ceguera prevenible e irreversible en
adultos en edad laboral. Su detección temprana es esencial para iniciar el tratamiento
a tiempo y prevenir que avance hacia la ceguera irreversible.
Dada esta problemática, se propuso Retinar, una plataforma de telemedicina que
posee un algoritmo de inteligencia artificial que se utiliza para asistir de manera remota
los diagnósticos de retinopatía diabética. Por lo tanto surgió este proyecto, el cual es
una interfaz web a partir de un maquetado, que funciona como intermediario entre los
distintos actores en el flujo de análisis de la retinopatía diabética.
Este trabajo final de carrera contribuye al proyecto Retinar, otorgándole un medio por
el cual intercambiar datos entre cliente y servidor, siendo el cliente los distintos
usuarios (retinologo, técnicos de captura de imagen, admins, pacientes) y el servidor
los distintos nodos donde se encuentra desplegado un back-end para recibir peticiones
e interactuar con la inteligencia artificial.
2
3
Índice
Resumen 2
Índice 4
Capítulo 1: Introducción 4
1.1 Descripción de la problemática 8
1.2 Propuesta de solución 10
1.3 Vinculación con contenido académico 10
1.4 Organización del trabajo 11
Capítulo 2: Estado del arte 11
Capítulo 3: Contexto 13
3.1 Órganos y patología 13
3.1.1 Los ojos y el cerebro 13
3.1.2 Diabetes 13
3.1.3 Retinopatía diabética 14
3.2 Apartado técnico 15
3.2.1 Aplicación web 16
3.2.2 Algoritmos 16
3.2.3 Inteligencia artificial 16
3.2.4 Algoritmo de Inteligencia Artificial 17
3.2.5 Algoritmo de Retinar 17
Capítulo 4: Alcance y aporte del proyecto 17
4.1 Alcance del proyecto 17
4.2 Necesidad de Retinar 18
4.3 Aporte de este trabajo final a Retinar 19
4.4 Principales desafíos 19
Capítulo 5: Herramientas e interfaz 21
5.1 Figma 21
5.2 HTML, CSS, Javascript 22
5.3 React 24
5.3.1 Flujo de información 24
4
5.3.2 JSX 25
5.3.3 React respecto a otras librerías 26
5.4 Vercel 27
5.5 Arquitectura 28
5.5.1 Orientado a que usuario 28
5.5.2 Estructura de carpetas 30
5.5.3 Manejo de estado: Redux y useState 30
5.5.4 Navegación 31
5.5.5 Autenticación 33
5.5.6 Código semántico 33
5.5.7 Despliegue automatizado 34
Capítulo 6: Flujos de trabajo 35
6.1 Técnico de captura de imágenes 36
6.2 Oftalmólogo 39
6.3 Administrador 39
6.4 Paciente 40
Capítulo 7: Implementación y resultados 40
7.1 Vistas 41
7.1.1 Login 42
7.1.2 Home 42
7.1.3 Ficha paciente 45
7.1.4 Listado de estudios 45
7.1.5 ABM de técnicos 46
7.1.6 Nuevo estudio - Paso 1 - Búsqueda 46
7.1.7 Nuevo estudio - Paso 2 - Datos personales 47
7.1.8 Nuevo estudio - Paso 3 - Diagnóstico IA 48
7.1.9 Nuevo estudio - Paso 4 - Finalizar 50
7.2 Componentes relevantes 51
7.2.1 Header 52
7.2.2 Menú para cambiar de roles 52
7.2.3 Selector de acción 53
5
7.2.4 Stepper 54
7.2.5 Gestor y visor de imágenes 54
7.2.6 Modal 55
7.2.7 Inputs 55
Capítulo 8: Conclusión 56
Bibliografía 58
6
7
Capítulo 1: Introducción
La diabetes es una patología cada vez más común, cuya característica principal es la
elevada concentración de glucosa, muchas veces de manera crónica, debido a una
baja producción de insulina por parte de un individuo, o bien por la resistencia del
mismo al accionar de la insulina. También existen situaciones menos favorables en las
cuales pueden darse ambos casos simultáneamente [1].
La retinopatía diabética es una complicación ocular, producto de la diabetes, que está
causada por el deterioro de los vasos sanguíneos que irrigan la retina. Si se producen
daños en los vasos sanguíneos de la retina entonces puede ocurrir que estos sufran
una fuga de sangre o fluido. Si la enfermedad avanza, con el tiempo se producirá el
deterioro progresivo de la visión, culminando en una ceguera irreversible en adultos en
edad laboral [2].
Actualmente las imágenes médicas contribuyen a un gran avance en cuanto a
estudios. Estas son un conjunto de técnicas y procesos utilizados para crear imágenes
del cuerpo humano, o parte del mismo.
Las ya mencionadas imágenes médicas se han vuelto fundamentales en la actualidad
para poder realizar diferentes tipos de estudios. Además estas contribuyen a aumentar
el grado de exactitud y confianza con las cuales son las causas de determinadas
patologías.
Es posible, entonces, utilizar las imágenes médicas aplicadas en algoritmos
exhaustivamente elaborados, para así obtener análisis completos y detallados de una
determinada patología, y de esta manera aumentar el índice de éxito detectando estas
enfermedades.
Las imágenes médicas son un conjunto de técnicas y procesos utilizados para crear
imágenes del cuerpo humano o partes del mismo, con propósitos clínicos o bien para
ciencia médica [11].
Existen distintos tipos de imágenes médicas, que se realizan con distintos métodos y
para distintos fines. Algunos ejemplos son:
8
● Fluoroscopia
● Imagen de resonancia magnética
● Medicina nuclear
● Tomografía
● Radiografía
● Retinografía
Esta última es la de interés en este proyecto. La retinografía es una técnica que se
utiliza en medicina para obtener imágenes de la retina del paciente, es decir, de la
parte posterior del ojo [12].
9
1.1 Descripción de la problemática
Retinar es una plataforma de telemedicina que utiliza inteligencia artificial para asistir
al diagnóstico remoto de la retinopatía diabética.
Esta plataforma conecta redes de captura de imágenes con oftalmólogos y
especialistas en tratamiento, para brindar diagnósticos, informes detallados y
asesoramiento médico asistencial [5].
Actualmente Retinar posee un algoritmo de inteligencia artificial el cual se encarga de
realizar análisis y diagnóstico basado en imágenes de entrada.
Retinar conecta redes de captura de imágenes con oftalmólogos y especialistas en
tratamientos para brindar diagnósticos e informes detallados, y asesoramientos
médico/asistenciales.
Actualmente esta plataforma de telemedicina no posee una interfaz la cual le permita
interactuar entre los distintos actores del proceso de análisis de fondo de ojo. Esto
implica que los procesos para comunicarse entre estos es lento, manual y poco
escalable para quienes se encuentran relacionados.
Los técnicos de captura de imágenes tienen que generar las mismas y enviarlas de
alguna forma a quien esté a cargo de utilizar el algoritmo de inteligencia artificial. Estos
últimos deben correr el algoritmo, cargando las imágenes de entrada, generar la salida
y luego enviarla a quienes correspondan, pero esto solamente si el proceso fue
exitoso. En caso de que las imágenes tengan algún defecto, se debe comunicar a los
técnicos de lo sucedido y comenzar nuevamente el proceso. Luego el diagnóstico
automatizado es enviado al oftalmólogo encargado del caso. Finalmente, luego de
analizar el caso y comprobar los resultados del software mencionado, el oftalmólogo
comunica al paciente los resultados, y cómo debe proseguir.
Es posible que alguno de estos pasos falle y haya que reiniciar el proceso en
cualquiera de sus puntos. Por lo tanto es necesario algún medio por el cual
automatizar todos estos procesos y agilizar la comunicación y entrega de
documentación entre los distintos actores.
10
1.2 Propuesta de solución
La propuesta para la problemática abordada es una interfaz web, que cumpliria el rol
de conectar los distintos actores, de manera tal que el flujo pueda efectuarse de una
manera dinámica y sin necesidad de realizar cada uno de los procedimientos de
maneramanual, ganando así tiempo y fiabilidad, dada la automatización de las tareas
tanto de envío de datos, como de análisis de los mismos, asignación de un
oftalmólogo y, finalmente, el envío del informe para notificar a los pacientes.
1.3 Vinculación con contenido académico
Durante el desarrollo del proyecto, se aplicaron diversos contenidos aprendidos a lo
largo de la carrera. Entre ellos se puede mencionar un desarrollo de código
estructurado, modularizado y con funciones específicas como se vió en Programación
Orientada a Objetos, Introducción a la programación 1 y 2. También se aplicaron
expresiones regulares para los distintos inputs en los formularios de la aplicación y se
utilizó lógica avanzada para ciertas condiciones que requieren mayor complejidad,
vistos estos temas en Ciencias de la Computación 1 y 2 respectivamente.
El desarrollo constantemente se vio influenciado por metodologías ágiles vistas en el
ámbito laboral y en cátedras como lo son Metodologías de Desarrollo de Software y la
optativa Métodos Ágiles Para el Desarrollo de Software.
Distintas estructuras de datos fueron utilizadas para cada caso particular, ya sean
mapas de hash para un acceso eficiente a datos o arreglos de datos para un conjunto
de los mismos que se acceden de manera secuencial. La teoría de estas estructuras
fueron vistas en Estructura de Datos y Análisis y Diseño de Algoritmos 1. También, el
análisis de datos y el recorrido de estructura de datos se diseñó teniendo en cuenta la
complejidad espacial y temporal de las mismas, buscando minimizar los parámetros
mencionados. Este contenido fue profundizado en Análisis y Diseño de Algoritmos 1 y
2.
Si bien la aplicación está orientada a usuarios que posean dispositivos con banda
ancha, se pensó de antemano una solución para ahorrar el consumo de red lo más
posible, y evitar así tener que realizar solicitudes extras con información que sería
redundante. Esta mejora temprana se gestionó teniendo en consideración los
11
conceptos aprendidos en Comunicación de datos 1 y 2. Es un punto importante a tener
en cuenta para conseguir una buena experiencia de usuario, y también para el futuro
si la aplicación estuviese orientada a dispositivos móviles, ahorrando lo más posible
los datos móviles.
1.4 Organización del trabajo
En el presente trabajo se organiza el informe a través de capítulos, que abordan los
siguientes temas:
En el capítulo 2 se expone el estado del arte, explicando y detallando los conceptos
necesarios.
El capítulo 3 brinda distintas definiciones a tener en cuenta respecto a la diabetes y a
la retinopatía diabética.
En el capítulo 4 se detalla brevemente el alcance del proyecto, el aporte del mismo
hacia Retinar y los principales desafíos que se presentaron durante la elaboración del
trabajo final.
El capítulo 5 describe el modo de trabajo. Herramientas utilizadas para el desarrollo,
para entregas continuas e iterativas, para la visualización del objetivo de la interfaz,
buenas prácticas de desarrollo, entre otros.
En el capítulo 6 se detalla el flujo completo que se espera tener una vez finalizado el
front-end, haciendo énfasis en que acciones lleva a cabo cada rol, brindando así un
mayor y más claro contexto de la contribución e importancia del proyecto.
En el capítulo 7 se muestran los resultados del desarrollo; las distintas pantallas
terminadas, el flujo de datos, los formularios.
Finalmente, en el capítulo 8, se detallan las conclusiones del proyecto, posibles
mejoras sobre el trabajo realizado y una retrospectiva sobre lo aprendido.
12
Capítulo 2: Estado del arte
La aplicación desarrollada para Retinar es una muy específica. Si bien existen
aplicaciones de gestión de datos de uso genérico, como puede ser Google Sheets,
también existen aplicaciones de gestión de datos más genéricas que es posible
adaptar a distintos usuarios.
En el mundo del desarrollo web, es muy común desarrollar una sola aplicación que
luego pueda adaptarse a diferentes clientes / usuarios de manera tal de ahorrar tiempo
de desarrollo y poder reutilizar la aplicación. De esta forma, es posible reducir costos
de mano de obra, tiempo de desarrollo, y además permite unificar varios clientes
dentro de un mismo esquema, logrando luego un fácil mantenimiento de la aplicación.
Este concepto de reutilizar el mismo software para distintos usuarios se denomina
Tenencia múltiple [28].
Estas aplicaciones reutilizables, si bien podrían haber sido un buen acercamiento, el
software desarrollado requirió de características muy específicas que daban lugar a
una aplicación única para Retinar.
Entre las características que hacen único a este software, se encuentran:
● Vistas de usuario basadas en roles
● Estadísticas de usuarios para determinados roles
● Exportación de fichas de usuarios en formato PDF
● Visualización y almacenamiento de imágenes
● Analisis de imagenes con análisis de las mismas mediante inteligencia artificial
● Alta, baja y modificación de usuarios
● Formularios con datos específicos
● Comunicación con el backend específico de Retinar que posee el algoritmo de
inteligencia artificial capaz de analizar las imágenes de entrada
Si bien hay aplicaciones que gestionan estos requerimientos por separado, en su
conjunto no existe una aplicación que reúna todas estas características, y por
supuesto tampoco que esté relacionado con el dominio de interés. Por lo tanto el
software desarrollado puede considerarse único.
13
Capítulo 3: Contexto
En este capítulo se brinda información y contexto respecto a la patología de interés, al
algoritmo utilizado por Retinar y al ambiente web.
El capítulo se dividirá en dos secciones, una con el contenido relativo a la patología de
interés y los órganos implicados, y por otro lado se describirán aspectos técnicos
relacionados a la solución propuesta.
3.1 Órganos y patología
A continuación se detalla el padecimiento de interés, se explica en que consiste, los
órganos relacionados, su gravedad y estadísticas en la población.
3.1.1 Los ojos y el cerebro
La vista es uno de los sentidos más fundamentales de los seres humanos, y esta
actúa mediante un sistema constituido que tiene como ejes fundamentales a los ojos y
al cerebro.
Los ojos son los responsables de enfocar la luz y luego convertirla en impulsos
eléctricos, que posteriormente serán enviados hacia el cerebro. Por otro lado, este
último es el responsable de interpretar los impulsos recibidos y convertirlos en
imágenes [3].
3.1.2 Diabetes
La diabetes sacarina o diabetes mellitus (normalmente denominada “diabetes”) es una
enfermedad crónica que se presenta cuando el páncreas no secreta suficiente insulina
o cuando el organismo no utiliza eficazmente la insulina que produce. La insulina es
una hormona que regula la concentración de glucosa en la sangre, es decir, la
glucemia. Un efecto común de la diabetes no controlada es la hiperglucemia (es decir,
la glucemia elevada), que con el tiempo daña gravemente muchos órganos y sistemas
del cuerpo, sobre todo los nervios y los vasos sanguíneos.
14
En 2014, un 8,5% de los mayores de 18 años padecían diabetes. En 2019, esta
afección fue la causa directa de 1,5 millones de defunciones y, de todas las muertes
por diabetes, un 48% tuvo lugar antes de los 70 años de edad.
Entre 2000 y 2016, las tasas de mortalidad prematura, es decir previos a tener 70
años, por diabetes aumentó en un 5%. En los países de ingresos altos, esta tasa de
mortalidad disminuyó entre 2000 y 2010, pero luego repuntó entre ese año y 2016. En
los países de ingresos bajos o medianos, dicha tasa aumentó en ambos períodos.
En cambio, entre 2000 y 2016, la probabilidad de morir entre los 30 y los 70 años de
edad por alguna de las cuatro principales enfermedades no transmisibles
(enfermedades cardiovasculares, cáncer, enfermedades respiratorias crónicas o
diabetes) se redujo en un 18% a escala mundial [1].
La diabetes de tipo 1 (denominada anteriormente diabetes insulinodependiente,
juvenilo de inicio en la infancia) se caracteriza por una producción deficiente de
insulina y requiere la administración diaria de esta hormona.
Entre los síntomas de esta diabetes se incluyen la excreción excesiva de orina
(poliuria), sed (polidipsia), hambre constante, pérdida de peso, trastornos visuales y
cansancio. Existe la posibilidad de que los síntomas aparezcan de forma súbita [1].
La diabetes de tipo 2 se debe a una utilización ineficaz de la insulina por el
organismo. Más de un 95% de las personas con diabetes presentan la de tipo 2, que
se debe en gran medida al exceso de peso y a la inactividad física.
Los síntomas pueden parecerse a los de la diabetes de tipo 1, pero son a menudo
menos intensos, por lo que puede ocurrir que la enfermedad sea diagnosticada varios
años después de que se manifiesten los primeros síntomas, cuando ya han surgido
complicaciones [1].
3.1.3 Retinopatía diabética
Las personas con diabetes pueden desarrollar una enfermedad ocular llamada
retinopatía diabética. Esta enfermedad ocurre porque los niveles altos de azúcar en la
sangre causan daño a los vasos sanguíneos en la retina. Estos vasos sanguíneos
pueden hincharse y tener fugas de líquido. También pueden cerrarse e impedir que la
sangre fluya. A veces, se generan nuevos vasos sanguíneos anormales en la retina.
15
Todos estos cambios pueden hacerle perder la visión. La retinopatía diabética puede
separarse en dos grandes etapas: Retinopatía diabética no proliferativa (NPDR) y
Retinopatía diabética proliferativa (PDR).
La Retinopatía diabética no proliferativa es la etapa temprana de la enfermedad
ocular diabética. Muchas personas con diabetes la tienen. Cuando tiene NPDR,
muchos vasos sanguíneos pequeños sufren pérdidas y hacen que la retina se hinche.
Cuando se hincha la mácula, se denomina edema macular. Esta es la razón más
común por la que la gente con diabetes pierde la visión. Además, los vasos
sanguíneos en la retina pueden cerrarse. Esto se llama isquemia macular. Cuando eso
sucede, la sangre no puede llegar a la mácula. En algunos casos, se pueden formar
pequeñas partículas en la retina, llamadas exudados. Estas partículas también pueden
afectar la visión. En esta etapa de la patología, la visión del afectado será borrosa.
La etapa Retinopatía diabética proliferativa es la etapa más avanzada de la
enfermedad ocular diabética. Se produce cuando la retina comienza a desarrollar
nuevos vasos sanguíneos. Esto se denomina neovascularización. Estos vasos nuevos
frágiles a menudo sangran hacia el vítreo. Si sólo sangran un poco, quizá vea unas
cuantas moscas volantes oscuras. Si sangra mucho, puede que bloqueen toda la
visión. Estos vasos sanguíneos nuevos pueden desarrollar cicatrices. El tejido
cicatrizante puede causar problemas con la mácula o derivar en un desprendimiento
de retina. La retinopatía diabética proliferativa es muy grave y puede hacerle perder
tanto la visión central como la periférica (lateral) [2].
3.2 Apartado técnico
A continuación se detalla brevemente en qué consiste una aplicación web y por qué es
una solución viable. A su vez, se describe que es un algoritmo, que es la inteligencia
artificial y, finalmente, como la propuesta de trabajo final conecta con el algoritmo de
inteligencia artificial desarrollado por Retinar.
3.2.1 Aplicación web
Una aplicación web es un software que se ejecuta en los navegadores, tanto de
escritorio como de dispositivos móviles. Estos navegadores pueden ser Google
Chrome, Firefox, Safari, Microsoft Edge, entre otros.
16
Este tipo de aplicaciones es utilizada principalmente cuando se busca utilizar un
software el cual no requiere ser instalado en un dispositivo y que, normalmente,
consume pocos recursos a la hora de ejecutarse [9].
Las aplicaciones web también se caracterizan por tener una interfaz e interacción muy
amenas, siendo sencillas de comprender y utilizar.
A su vez, existen múltiples asistentes de desarrollo que ayudan a la construcción de la
aplicación, dando indicaciones de como estructurar el programa de tal forma que
cumpla con ciertos estándares que permiten que más usuarios puedan utilizar el
software independientemente de las capacidades psíquicas y motrices del usuario,
como es el caso del daltonismo, movilidad reducida, ceguera, sordera, entre otras [10].
3.2.2 Algoritmos
Actualmente cualquier software, como aplicaciones web o aplicaciones para
dispositivos móviles, está basado en algoritmos. Estos se describen como cualquier
procedimiento computacional bien definido que toma uno o más valores de entrada y
produce uno o más valores de salida. Por lo tanto, un algoritmo es una secuencia de
pasos computacionales que transforman entradas en salidas. También se puede ver a
un algoritmo como una herramienta para resolver un cálculo bien especificado [7].
En este caso particular, todo el flujo de datos está basado en el procesamiento de
información, que está constituido por diferentes algoritmos.
3.2.3 Inteligencia artificial
La inteligencia artificial nació en la década de 1950, como respuesta respecto a si las
computadoras podían "pensar" preguntas cuyas alternativas todavía están siendo
exploradas hoy en día. Una definición concisa de IA sería: el esfuerzo por automatizar
tareas intelectuales que normalmente son realizadas por humanos. Como tal, la IA es
un campo general que abarca el aprendizaje automático (machine learning) y el
aprendizaje profundo (deep learning) [8].
3.2.4 Algoritmo de Inteligencia Artificial
A partir de las definiciones previamente dadas, podemos definir un algoritmo de
inteligencia artificial como un subconjunto del aprendizaje automático que le dice a la
17
computadora cómo aprender a operar por sí misma. A su vez, el software continúa
adquiriendo conocimientos (entrenando) para mejorar los procesos y ejecutar las
tareas de manera más eficiente.
3.2.5 Algoritmo de Retinar
El proceso de diagnóstico y análisis manual de las imágenes de fondo de ojo
constituye en sí mismo una tarea costosa. Es por esto que Retinar posee su propio
conjunto de algoritmos para poder llevar a cabo esta tarea de manera automatizada
[41].
Estos algoritmos mencionados se crearon para su utilización en el aprendizaje
automático y el aprendizaje profundo. De esta manera se podrían solventar las tareas
de clasificación de imágenes y detección de elementos de interés de manera más
sencilla, con una alta tasa de precisión y mayor robustez respecto a la fidelidad de los
resultados [41].
A continuación se listan los diferentes algoritmos de inteligencia artificial utilizados por
Retinar:
● Fundus Vessel Segmentation - TBME: Versión modificada del algoritmo
publicado por los mismos autores, en IEE TBME 2016. Permite realizar la
segmentación de vasos sanguíneos en imágenes de fondo de ojos a color
[42][43].
● Overfeat Glaucoma: Algoritmo para la detección automática de glaucoma
(enfermedad que genera pérdida de visión) a partir de redes neuronales
específicas (OverFeat y VGG-S) [42][44].
● Red Lesion Detection: Algoritmo utilizado para la detección de lesiones rojas,
como son los microaneurismas y las hemorragias. [42][45].
18
Capítulo 4: Alcance y aporte del
proyecto
A continuación se explica brevemente el alcance y aporte del proyecto. También se
detallan, sin entrar en detalles técnicos, los desafíos que se presentaron en el
transcurso del trabajo final.
4.1 Alcance del proyecto
El proyecto en sí es una interfaz web, para que los distintos usuarios puedan
interactuar con la información que es brindada desde el lado del servidor. Se procuró
crear un front-end completo, para luego poder delegar el código a las personas
encargadas de realizar la conexión con el back-end y mantener el front-end.
Durante todo el proyecto también fue requerido tener constantemente desplegada en
la web una versión del proyecto para, de esta manera, poder mostrar continuamente
los cambios realizados y tener un feedback constante.
El proyecto se almacenó en un repositoriode Github, una plataforma para alojar
archivos destinada al trabajo colaborativo entre equipos [4]. De esta forma, el código
fuente del proyecto estaría disponible a todo momento para quienes tuviesen permisos
para visualizarlo y/o editarlo, en este caso las personas a cargo de Retinar y los
desarrolladores que posteriormente tomarían la responsabilidad del proyecto.
4.2 Necesidad de Retinar
Esta plataforma surge ante la necesidad de agilizar los diagnósticos relacionados con
la retinopatía diabética. Por lo tanto, esta misma propone un sistema completo para
poder lidiar con ciertas complicaciones que han detectado que aletargan todo el flujo
de análisis de los pacientes. Ejemplos de lo ya mencionado es la gran demanda de
oftalmólogos respecto a los pocos que se encuentran disponibles, o bien el elevado
número de etapas por la cual transita un paciente hasta que finalmente obtiene sus
resultados con un diagnóstico real [5].
19
Además, la necesidad de este software también surge de las características tan
propias que fueron solicitadas por Retinar. Como se expuso en el capítulo 2, una
aplicación de propósitos general no alcanza a cubrir todas las necesidades y
características que se necesitan.
4.3 Aporte de este trabajo final a Retinar
Este proyecto final de carrera aportó la interfaz necesaria para poder conectar los
distintos actores alrededor de los objetivos de la organización. Es decir, la aplicación
web es el intermediario entre la IA, los oftalmólogos, los pacientes y el servidor.
La aplicación permite, entonces, que los procesos puedan ser automatizados en
mayor medida. Las imágenes de fondo de ojos son entregadas a los oftalmólogos
mediante la plataforma web, y estos mismos tienen la opción de visualizar las
imágenes como fueron tomadas y tambien una version ya analizada por la IA,
generando así una mayor certeza para los oftalmólogos en sus análisis, lo cual implica
diagnósticos con mayor grado de certeza para los pacientes.
También, dada la estructura del proyecto, se deja abierta la posibilidad de añadir
nuevas características a la aplicación en el futuro. Esto puede ser, por ejemplo, nuevas
funciones para usuarios administradores, otra herramienta interna para la visualización
de imágenes, nuevas vistas que impliquen nuevo flujos de datos, la posibilidad de
importar datos de pacientes directamente desde documentos con extensión .csv o
similar, entre otras.
4.4 Principales desafíos
Durante el desarrollo de la maquetación se encontraron varios desafíos que valen la
pena resaltar:
● Fidelidad al diseño realizado por los diseñadores gráficos: La aplicación
fue realizada en base a mocks realizados por diseñadores y alojados en Figma.
Al realizar el desarrollo, cada componente tenía que ser lo más fiel posible
respecto al realizado por las personas profesionales encargadas del diseño.
Esto llevó a un desarrollo un poco más tardado dados los detalles de las
20
pantallas, las distancias, los tamaños, las fuentes, entre otros.
● Código comprensible / escalable: Desde un principio el proyecto estuvo
destinado a quedar en manos de otros desarrolladores. Esto es dado que el
proyecto de grado solo sentaría las bases de la interfaz web. Por lo tanto, estas
bases se hicieron de la manera más escalable y comprensible posible, para
que quienes tuviesen que seguir con el proyecto pudieran hacerlo sin que esto
requiriera un esfuerzo extra [6], agilizando así el desarrollo y finalización de la
interfaz web.
● Vistas privadas: Tan solo una de las vistas de la aplicación es pública, es
decir, que es accesible sin necesidad de estar logueado en la app. Se realizó
un logueo maquetado para poder desarrollar la interfaz gráfica sin necesidad
de un back-end con un flujo real de autenticación, pero de igual manera fue un
obstáculo que pudo superarse es generar una lógica para permitir el acceso al
resto de las vistas solo a usuarios que estuviesen autentificados.
Esto también aplica para vistas las cuales solo son accesibles dado
determinado rol, es decir que las vistas para realizar informes solo estuviesen
disponibles para oftalmólogos, o las vistas de alta / baja / modificación
estuviesen solo para admins.
● Manejo de imágenes: Un gran desafío fue el implementar la lógica e interfaz
para el manejo de imágenes. Ejemplo de esto es la herramienta para subir las
imágenes, las opciones para alternar entre los distintos modos (normal, con
primer diagnóstico de IA, con segundo diagnóstico de IA), el informe con
respecto a qué imágenes se subieron exitosamente.
● Minimizar el número de dependencias: Las dependencias se definen código
externo al proyecto principal, que se utiliza gracias a la funcionalidad o
funcionalidades que brinda [33]. Este se almacena en un fichero del proyecto
llamado “package.json” y queda almacenado allí para guardar la referencia a la
dependencia. Si bien estas son muy útiles, ya que es código que ya fue
refinado y testeado, el uso excesivo de las mismas incrementa el tamaño final
de la aplicación, haciendo de esta manera que el software sea cada vez más
21
costoso a la hora de ser cargado en los navegadores. Además, como su
nombre propiamente indica, estas dependencias están sujetas a los cambios
que realicen sus autores sobre ellas. Esto quiere decir que si son modificadas,
y en el proyecto principal nos traemos tales actualizaciones, estaremos sujetos
a los cambios realizados [34]. Si bien existen técnicas para solventar esta y
otras problemáticas, las dependencias siguen siendo muy útiles en su justa
medida. Por esto mismo se buscó utilizar el número mínimo e indispensable de
software externo para este proyecto.
22
Capítulo 5: Herramientas e interfaz
A continuación se detallan las herramientas utilizadas, y cómo las mismas contribuyen
a la creación de la aplicación web en sus distintas etapas de desarrollo.
5.1 Figma
El desarrollo de plataforma estuvo apoyado por un diseño otorgado por Retinar. El
mismo se alojó en Figma, una plataforma para la creación de interfaces gráficas,
orientado al trabajo colaborativo entre diseñadores y desarrolladores.
Figura 1: diseños en figma de la aplicación
Gracias a esta herramienta se pudieron replicar de manera minuciosa los distintos
detalles plasmados en el diseño, como son tamaños de fuente, familias de las mismas,
colores, márgenes, alineamiento, entre otros.
Esta herramienta, además, es útil no solo para desarrolladores, sino también para
quien esté destinada la aplicación, ya que es posible ver una preview del software a
realizar y pueden realizarse cambios bajo demanda. A su vez Figma permite montar
un flujo de datos con componentes interactivos, como botones y desplegables, para
que todo tipo de usuarios puedan conocer cómo son las interacciones esperadas con
la aplicación [31].
23
Otra característica a resaltar de este software es la capacidad de generar
documentación de manera alternativa. Nos referimos de manera alternativa al hecho
de poder dejar anotaciones, especificaciones y detalles a tener en cuenta en las
mismas pantallas en donde se encuentran los diseños para maquetar.
5.2 HTML, CSS, Javascript
Estos tres lenguajes son, normalmente, los pilares para crear una aplicación web.
HTML permite crear los cimientos de la aplicación, definiendo metadata necesaria para
el sitio, y creando un punto de entrada que, posteriormente, usará el framework
utilizado para montar el resto del software [13]. Este lenguaje de etiquetado es
fundamental para los sitios web porque puede ser que una aplicación sea montada
simplemente con este lenguaje o, también, puede utilizarse simplemente como punto
de entrada y que otras librerías trabajen en base a esta.
Definimos como “punto de entrada” a una plantilla mínima necesaria para que otra
librería pueda ejecutarse cómodamente dado un punto de partida, en este caso el
punto de entrada, como puede ser una etiqueta sencilla con un identificador.
Figura 2: ejemplo de punto de entrada por defecto deuna aplicación React
CSS es el lenguaje que permite modificar los elementos web, ya sea en tamaño, color,
o cualquier otra propiedad que sea necesaria cambiar [14]. Este lenguaje es
indispensable para lograr una interfaz de usuario amena, sencilla de utilizar, de
comprender, e indispensable para lograr diseñar a nivel código lo plasmado en el
Figma.
24
Finalmente Javascript es el lenguaje que permite darle interactividad a la aplicación, y
el que se utiliza en conjunto con el framework React [15]. Es el principal actor a la hora
de realizar lógica en la aplicación, ya sea envío de formularios, escuchar eventos
(clicks, drag, drop), navegar entre vistas de manera imperativa, fetching de datos,
entre otros. Si bien es una herramienta opcional, se utiliza en la mayoría de los casos.
También se utiliza de manera implícita, ya que hay librerías como React que las
utilizan por debajo para lograr sus características.
5.3 React
React es una librería para la creación de interfaces de usuario, orientada a
componentes reutilizables. Esta utiliza un punto de entrada configurado con HTML que
luego, a partir de este, todo el resto de la aplicación es renderizada [16] [17]. Por lo
tanto la aplicación es, normalmente casi en toda su totalidad, dinámica.
Figura 3: flujo de datos en React
Principalmente React fue utilizado dado el conocimiento previo con esta tecnología
respecto a otras alternativas.
Además, esta librería permite la creación de vistas y componentes muy rápidamente
dada su sencillez a la hora de importar dependencias dentro del mismo proyecto.
25
También su estructura de carpetas normalmente es sencilla de gestionar, por lo tanto
esta característica también aporta a una rápida escalabilidad del proyecto.
5.3.1 Flujo de información
A diferencia de otras librerías para gestión de UI como Angular, React posee un flujo
de datos unidireccional [21]. Esto quiere decir que los componentes padres envían
datos a sus descendientes, pero estos últimos no poseen comunicación directa con
sus predecesores. Por lo tanto en React se trabaja mucho con eventos y callbacks.
Los eventos son acciones generadas por una acción disparada por un usuario desde
la interfaz gráfica o, también, disparada por el sistema mismo [22]. Por medio del
burbujeo, propagación de un evento desde un componente hacia sus ancestros, los
componentes padres sabrán que una acción se disparó, siendo esta acarreada hasta
la raíz.
Los callbacks son funciones pasadas por parámetros [23]. Estas son especialmente
utilizadas en React ya que, como mencionamos, los padres envían datos a sus hijos, y
esta data puede ser por ejemplo uno o más callbacks.
5.3.2 JSX
JSX (JavaScript XML) es un syntactic sugar que se utiliza en conjunto con React para
facilitar el desarrollo del código, ya que este se asemeja a la sintaxis de XML [18]. El
syntactic sugar se define como una sintaxis más amena para cualquier lenguaje de
programación, que permite un trabajo de desarrollo más fluido al tener ciertas
funciones o features del lenguaje expresados de manera sencilla o, también, de
manera más abstracta logrando así una mejoría en la calidad del código [38].
Hoy en día prácticamente cualquier proyecto escrito en React utiliza esta sintaxis dado
su entendimiento y similitud con, por ejemplo, HTML. En equipos profesionales de
trabajo es, sin dudas, la mejor opción para desarrollar con este framework.
26
Figura 4: Ejemplo de JSX utilizado en repositorio popular de código abierto. Link:
https://github.com/sanyuan0704/react-cloud-music/blob/master/src/App.jsx
Como se mencionó, JSX es un agregado y React podría utilizarse de manera pura sin
ningún problema; llamando funciones de creación de nodos, especificando el tipo de
elemento, su contenido, sus props [24]. Se definen como “props” a aquellos datos que
son asignados a un componente de manera dinámica; los componentes se sirven
estos datos para conocer cuándo deben volver a renderizar, es decir, cuando deben
actualizar los datos que deben ser mostrados en la interfaz gráfica [35].
27
Figura 5: Sintaxis básica de React, sin JSX
5.3.3 React respecto a otras librerías
El uso de librerías para el desarrollo de aplicaciones web es algo opcional, aunque en
la mayoría de los casos se utilizan. Se pueden identificar ciertos pros y contras en el
uso de estas:
Pros:
● Desarrollo más ágil
● Gestión de componentes
● Gestión de eventos
Contras:
● Overhead por dependencias de librería
● Curva de aprendizaje
● Diferencias sustanciales entre librerías
En las etapas más tempranas del proyecto hubo que decidir si se iba a utilizar una
librería, y si fuese así, cuál de todas las que hay actualmente para desarrollar un
front-end. Las principales alternativas fueron React y Vue. Esta última fue
recomendación por parte del director de este trabajo, dado que quienes luego
tomarían el ownership del proyecto y terminarían con el resto de pendientes, son
desarrolladores con experiencia en Vue. Sin embargo, para agilizar el proceso de
28
desarrollo y realizar un código de calidad, finalmente se optó por React, dada la
experiencia previa y actual con esta tecnología.
Otra opción viable era Angular, librería de front-end para la creación de interfaces
gráficas altamente escalables con un flujo de datos bidireccional, a diferencia de React
que posee un flujo unidireccional [25]. Si bien en escalabilidad y gestión de carpetas
Angular posee cierta ventaja sobre React, esta última siguió siendo mejor opción dado
el dominio sobre la misma.
5.4 Vercel
Vercel es una plataforma que permite el despliegue de aplicaciones front-end [19].
Esta fue utilizada para mantener actualizado el proyecto a medida que se añadían
nuevas características y/o vistas, logrando así mantener un constante feedback con
Retinar.
Figura 6: login de la aplicación desplegado en Vercel
Adicional a lo mencionado, fue utilizada por su sencillez, dado que basta con
configurar un usuario en esta plataforma con la rama principal de un proyecto en un
29
repositorio, y automáticamente Vercel se encarga de dejar una configuración interna
por defecto, que realiza despliegues a medida que se generan merge entre ramas [20],
un proceso automatizado que es un muy solicitado y necesario en la industria.
Esta plataforma permite el despliegue de aplicaciones con un “nivel” gratuito, lo que lo
hace ideal para prototipos de proyectos, ya que no hay gastos de servidores y posee
una performance muy alta, permitiendo despliegues a demanda cuando se realiza un
merge contra ciertas ramas.
5.5 Arquitectura
Para tener un mayor control y organización del proyecto, se planificó y realizó una
arquitectura con librerías, organización de carpetas y buenas prácticas ya utilizadas en
el ámbito laboral.
5.5.1 Orientado a que usuario
La aplicación está basada completamente en sesiones. Esto implica que la gran
mayoría de las vistas son privadas al público y solamente quienes posean
credenciales de usuario podrán acceder a la plataforma.
Los tipos de usuario hasta el día de la fecha son: técnico de captura, oftalmólogo,
administrador y paciente. Independientemente del número de vistas/pantallas a la
cada usuario pueda acceder, todos tendrán en común que necesitan mantener una
sesión para poder navegar a través de la aplicación web.
Como se mencionó anteriormente, la aplicación en su mayoría es constantemente una
aplicación “privada”. Por lo tanto, esto permite un desarrollo sencillo con React. Esta
librería tiene como desventaja la construcción de vistas que no pueden ser
encontradas por los rastreadores de Google, por lo tanto, el SEO (Search Engine
Optimization) se ve duramente afectado. Sin embargo, como ya se aclaró con
anterioridad, el objetivo de Retinar no es atraer público a la aplicación, así que se ve
solventada la desventaja de React gracias al negocio de Retinar.
Los rastreadores de Google son robots que permiten indexar páginas web y poder
otorgarles un “puntaje”, que luego seusa como referencia para aparecer en las
búsquedas utilizadas en el buscador de esta empresa [37]. Coloquialmente se define
30
como SEO a un conjunto de prácticas que permiten a una aplicación web obtener un
buen posicionamiento, entre los resultados de Google, cuando se realiza una
búsqueda con temas relacionados con la misma [38].
5.5.2 Estructura de carpetas
La estructura de carpetas se mantuvo simple, centrada principalmente en el directorio
src que contiene los componentes que constituyen a las vistas y sus subcomponentes.
En otros escenarios, el proyecto contiene más ficheros que contribuyen, por ejemplo, a
procesos de CI/CD (continuous integration, continuous delivering), configuración de
Docker, variables de entorno, entre otros.
Figura 7: estructura de carpetas de la aplicación web desarrollada para Retinar
Existen muchas otras maneras de generar estructuras de carpetas, dependiendo del
enfoque que se quiera dar o del objetivo del proyecto. Una alternativa popular podría
haber sido utilizar Atomic Design, generando así una estructura más modularizada con
componentes subdivididos.
Atomic Design es una metodología para el diseño de sistemas, principalmente
orientada maximizar la subdivisión de las piezas del código, agrupando así fragmentos
del mismo en grupos bien definidos, otorgándoles una semántica similar en cuanto a
granularidad de cada fichero [40]. Si bien es un diseño que puede ser adaptado a la
31
necesidad de cada equipo de trabajo, comúnmente se dividen en: átomos, moléculas,
organismos, templates y páginas.
Figura 8: diseño general de Atomic Design
5.5.3 Manejo de estado: Redux y useState
Las aplicaciones de front-end que utilizan React se basan fuertemente en estados;
estos son datos que se persisten internamente por la aplicación y notifican a los
componentes para que estos vuelvan a renderizar la UI cuando sea necesario.
Por un lado se manejan estados locales con useState, una utilidad de React que se
utiliza para gestionar estados en componentes y los subcomponentes del mismo.
Figura 9: flujo de datos de Redux
Por otro lado se utiliza Redux, una librería de Javascript para mantener el estado de
forma global, que normalmente se usa para gestionar los estados de varios
componentes que en vez de ser descendiente uno del otro, son “primos” o “hermanos”.
Esta decisión de diseño fue a causa de los distintos pasos que hay a la hora de
registrar pacientes y cargar datos.En la figura 9 se puede ver como el flujo de datos
32
está constantemente cambiando pero siempre siguiendo una misma dirección o una
misma idea. Es por eso que, finalmente, se optó por gestionar los datos de manera
global. Esto también contribuye a un código más “limpio”, ya que la lógica relacionada
con datos es movida a un lugar independiente del resto de código, facilitando así la
búsqueda de estos fragmentos de lógica, separando archivos, evitar mezclar ideas
dentro de los mismos ficheros, entre otras mejoras.
5.5.4 Navegación
La navegación de la aplicación se manejó utilizando el concepto de Single Page
Application (SPA), utilizando la librería React Router Dom.
Una SPA es una aplicación web la cual provee una navegación más fluida entre vistas,
simulando que fuese una aplicación como las de escritorio, que poseen sus vistas ya
cargadas desde el inicio [26]. Las SPA, entonces, permiten una navegación más
amena para el usuario y también permite el ahorro de recursos, evitando llamados
HTTP innecesarios para volver a cargar recursos que ya fueron solicitados con
anterioridad.
React Router Dom es una librería que permite construir single page applications. Este
paquete se utiliza de la mano de React para levantar las interfaces web, suministrando
a los desarrolladores múltiples utilidades (entre ellas componentes, hooks, funciones)
para su uso [27].
Si bien el uso de SPA es un agregado interesante, no es obligatorio. La navegación
podría solventar muy fácilmente utilizando anchors [32], lo que supondría un menor
tiempo de desarrollo de software y también disminuiría el tamaño final de la aplicación.
Como contra de esta alternativa, todos los recursos deberían cargarse nuevamente,
aumentando el tiempo de navegación entre vistas y, también, el ancho de banda final
consumido.
Se definen como “anchors” a aquellos elementos HTML que se utilizan como links, y
permiten abrir una nueva pestaña, o navegar sobre la pestaña activa, o bien permite la
descarga de documentos como PDF, imágenes, entre otros.
33
5.5.5 Autenticación
Como el desarrollo de la interfaz gráfica fue independiente del sistema de
autenticación por parte del back-end, se utilizó una bandera almacenada en el
navegador web para simular una sesión real. De esta forma se dejaría lista la
posibilidad de cambiar esta “bandera” en el futuro y reemplazarla por el mecanismo de
autenticación que sea más conveniente de acuerdo a las necesidades que surjan.
El término “bandera” hace alusión a un dato que haga de identificador para un
proceso, en este caso se utiliza para saber si el usuario se encuentra logueado o no.
Un mecanismo adecuado para la autenticación de usuarios podría ser el uso de JSON
Web Token (JWT). Este es un mecanismo de estándar libre para el cifrado de
información, que permite que tanto el cliente como el servidor se comuniquen de
manera segura gracias a que estos tokens llevan una firma que puede ser corroborada
[29].
Figura 10: cómo está conformado un JWT
Podría ser interesante agregar un mecanismo de encriptado de datos, de manera que
todas las peticiones posean sus datos seguros, hasta el token de autenticación.
5.5.6 Código semántico
El código utilizado para manejar la interfaz fue escrito utilizando Styled-Components,
una librería para escribir código de manera más semántica, facilitando así la
34
compresión del proyecto trabajando de manera colaborativa que, utilizado de manera
correcta, permite transmitir explícitamente lo que se busca realizar en la vista.
Figura 11: ejemplo de código semántico orientado al trabajo colaborativo
Figura 12: Este es un ejemplo, extraído de MDN Web Docs, de cómo es un HTML básico
En la figura 12 se puede notar que sin conocimientos del lenguaje de etiquetado, se
dificulta la comprensión del contenido que se está creando. El código semántico,
35
previo a ser procesado por navegadores, permite transmitir las ideas que se expresan
en el código de manera sencilla.
5.5.7 Despliegue automatizado
Como se mencionó con anterioridad, el despliegue fue gestionado utilizando Vercel.
Esto se realizó con una configuración externa a los ficheros del proyecto, evitando así
tener configuraciones en el mismo y a su vez gestionando desde otra plataforma de
manera automática e incremental.
El principal beneficio de esta plataforma, es la sencillez con la que se puede lograr un
despliegue. Toma como fuente un repositorio y el resto lo hace la misma aplicación.
Además Vercel posee configuraciones que le permite estar “escuchando” a los “merge”
que son realizados en las ramas de los repositorios [36]. De esta forma el despliegue
solamente depende de lo realizado en el repositorio, en este caso de Github,
facilitando la visualización de las nuevas características del proyecto a Retinar.
El merge es la acción de fusionar ramas, logrando así un resultado final con los
cambios de una rama, o la otra, o una mezcla/fusión de ambas. Pueden producirse
conflictos cuando se realiza esta acción por lo que es necesario gestionar, en algunos
casos, manualmente estas fusiones.
Existen otras opciones como Netlify o Heroku, las cuales son plataformas para el
despliegue de aplicaciones, pero Vercel fue considerada la mejor opción dada su
facilidad de uso y su interfaz gráfica que resulta ser muy intuitiva para su manejo.
36
Figura 13: interfaz gráfica de Vercel para la aplicación web de Retinar.
37
Capítulo 6: Flujos de trabajo
La aplicación en sí misma posee un objetivo general: ser un medio por el cual, los
distintosactores del proceso del análisis de imágenes de fondo de ojo, puedan cumplir
su función de la manera más rápida y sencilla posible.
Figura 14: roles dentro de la aplicación, y acciones que pueden realizar
A su vez, dentro del mismo software existen distintas funcionalidades, dependiendo
del rol de cada usuario y que se desee hacer, dependiendo de este rol mencionado. A
continuación se listan los roles que existen dentro de la plataforma, y qué acciones o
flujos puede realizar cada uno.
Figura 15: distintos roles de la aplicación, seleccionables gracias a un widget personalizado
38
6.1 Técnico de captura de imágenes
Los técnicos de captura de imágenes son aquellos usuarios encargados de subir las
imágenes de fondo de ojo en la plataforma, para que luego los oftalmólogos lleven a
cabo su diagnóstico. Los técnicos tienen acceso a dos flujos de trabajo, estos son:
● Listar los estudios realizados anteriormente: como su nombre lo indica, lista
los estudios realizados con anterioridad. Sirve como un histórico para llevar
cuenta de que pacientes han sido cargados, en que fecha, que tipo de estudio
(monocular izquierdo, derecho o binocular), si existe un informe asociado al
estudio y finalmente, el estado en el cual se encuentra tal estudio.
● Realizar nuevo estudio: este flujo permite realizar un nuevo estudio a partir de
un paciente que se encuentre ya cargado en la base de datos o no. Este paso
se realiza al principio del proceso, buscando por DNI y género. En el caso de
que el paciente se encuentre realizado, se pasa al siguiente paso, caso
contrario el mismo es cargado junto con los datos correspondientes; nombre
completo, fecha de nacimiento, correo, localidad, seguridad social.
En la siguiente etapa se registran los datos asociados a la nueva consulta,
independientemente si el paciente se encontraba registrado o no, junto con los
datos necesarios para generar el histórico, como son la fecha del estudio,
domicilio actual del paciente, su peso y altura actual, el tipo de examen e
información adicional si así se requiriese.
Luego de registrar la información del caso, se cargan las diferentes imágenes
de fondo de ojo que fueron capturada con anterioridad por el técnico. Estas
imágenes son previamente analizadas antes de permitir una visualización,
indicando si poseen la calidad adecuada para ser analizadas por la inteligencia
artificial y así asistir al diagnóstico médico. Finalmente, las imágenes son
enviadas al backend y se visualiza un pequeño mensaje de paciente referible o
paciente no referible, indicando una respuesta inmediata por parte de la IA
respecto al estudio. Este resultado no es definitivo, pero ayuda a los técnicos a
dar un resultado preliminar que puede servir para distintos motivos, según cada
laboratorio lo requiera.
39
6.2 Oftalmólogo
Los oftalmólogos poseen similitudes y diferencias con las acciones que puede tomar
un técnico. Comparten el acceso al listado de estudios realizados, pero además
poseen una opción adicional, que es evaluar un nuevo estudio.
● Evaluar un nuevo estudio: Esta opción permite tomar un caso que fue
anteriormente cargado por un técnico, y llevar a cabo un análisis del mismo. Al
oftalmólogo pertinente se le facilitan las imágenes que fueron cargadas por los
especialistas junto con las imágenes analizadas por la inteligencia artificial,
para asi el oftalmologo finalmente pueda proporcionar un resultado en base a
lo que este observa, y adición a lo que la IA le ofrece como resultado de su
propio análisis. Es posible generar un archivo con extensión pdf luego de
finalizar el estudio, para que este sea luego archivo y enviado al paciente.
Dependiendo de ciertas circunstancias, puede ocurrir la situación en la que el
oftalmólogo sea penalizado, y así de esta manera tenga restricciones a la hora
de tomar casos, y que no los tome sin control alguno.
6.3 Administrador
Respecto a los accesos que poseen los administradores, estos pueden generar altas,
bajas y modificaciones de distintos recursos, como son otros usuarios
(administradores, técnicos, oftalmólogos), de nodos, de centros de atención
registrados, entre otros. Es decir, la función principal de este rol, es poder gestionar los
recursos dentro de la aplicación.
En la figura 15 se puede observar los distintos estados que puede poseer un
administrador.
Para estas secciones se facilitó solamente la vista para la gestión de otros
administradores. Existe la posibilidad de que el ABM (alta / baja / modificación) del
resto de los recursos posea una estructura similar.
40
La creación de un primer administrador, una vez que la aplicación se encuentre
productiva, se deberá hacer manualmente desde la base de datos del software, para
así luego poder gestionar nuevos administradores.
Figura 16: vista de ABM de administradores, desplegado en Vercel.
6.4 Paciente
Aquellos usuarios que sean pacientes poseen la versión más “reducida” de la
aplicación. Puede navegar solo en su “home” personalizada, que es una vista muy
similar a la del oftalmólogo cuando revisa algún estudio, pero en este caso sería una
vista de solo lectura con el informe del profesional. Adicional a esto puede ver un
historial con la lista de estudios que el paciente ha tenido, muy similar a la lista de
estudios recientes que pueden ver el oftalmólogo y el técnico de captura.
La idea es que el paciente pueda visualizar la información de una manera clara y
accesible. Si bien se le envía un pdf al paciente, indicando los resultados con las
imágenes adjuntas, el tener también la interfaz web ayuda a comprender de manera
más interactiva el resultado de sus análisis.
41
Capítulo 7: Implementación y
resultados
La aplicación ya finalizada posee diferentes vistas. Estas, a su vez, poseen diferentes
funciones, características y formas de interactuar. También existen usuarios con
distintos roles, los cuales pueden causar que el comportamiento de una vista cambie,
se habilitan o deshabilitan ciertas características, que algunas vistas sean totalmente
inaccesibles, entre otras variantes.
A continuación se listan brevemente las distintas vistas, para poder tener una visión
más clara de cómo está conformada la plataforma:
● Login
● Home
● Ficha paciente
● Listado de estudios
● ABM de técnicos
● Nuevo estudio - Paso 1 - Búsqueda
● Nuevo estudio - Paso 2 - Datos personales
● Nuevo estudio - Paso 3 - Diagnóstico IA
● Nuevo estudio - Paso 4 - Finalizar
Existen además más vistas pendientes pero que no fueron añadidas en el diseño, por
lo tanto no fueron maquetadas. Estas serían:
● ABM de retinólogos
● ABM de admins
● ABM de tratamientos
● ABM de nodos
● ABM de estudios
● ABM de centros de tratamientos
● ABM de pacientes
Si bien las vistas faltantes en esencia son similares dada la funcionalidad de “alta -
baja - modificación”, es prudente realizarlas siguiendo los lineamientos de un diseño,
para evitar realizar vistas que pueden no coincidir con lo que el diseñador y Retinar
42
buscan reflejar con la interfaz gráfica.
En la figura 14 se puede observar los diferentes roles y las acciones que puede
realizar cada uno. Algunas acciones son compartidas entre roles y otras son
específicas para cada tipo de usuario.
A continuación se detallan las vistas maquetadas, mostrando una comparativa del
diseño en Figma comparado con el resultado final desplegado. También se adjuntan
los enlaces del repositorio desplegado para que pueda ser accedido y examinado si
así se requiriese.
7.1 Vistas
Una vista es una pantalla completa que muestra toda la información disponible en la
actual URL de la aplicación, y se considera el conjunto de todos sus elementos [40]. A
su vez la vista, normalmente, se subdivide en componentes más pequeños, que
veremos más adelante en este capítulo. A continuación se detallan las vistas
trabajadas a partir de los diseños provistos por Retinar, en Figma.
7.1.1 Login
Esta es la pantalla que sirve como punto de entrada de la aplicación. Su principalfunción es poder permitir que un usuario ingrese sus credenciales y obtenga acceso al
resto de las vistas. Es la página por defecto al ingresar por primera vez a la
plataforma. Dado que el software desplegado no está conectado con un backend,
basta con seleccionar el botón para ingresar, y el usuario será redirigido a la Home.
43
Figura 17: login de la aplicación desde Figma
Figura 18: login de la aplicación desplegada en Vercel.
44
7.1.2 Home
La home es la pantalla en donde la plataforma permite al usuario navegar entre las
demás vistas. Como oftalmólogo o técnico solo hay disponibles un par de opciones,
pero como administrador es posible entrar a diferentes tipos de vistas ABM. Se puede
considerar la página principal del software una vez que el usuario se encuentra
logueado.
En capítulos anteriores se mencionó que dentro de la aplicación existen roles. Estos
permiten a la aplicación poder dar diferentes experiencias de usuario dependiendo del
mismo.
Para un técnico, las opciones disponibles son visualizar el listado de evaluaciones o
realizar un nuevo estudio.
Un oftalmólogo puede mirar también el listado de evaluaciones, o bien evaluar un
nuevo caso. Aquí entra en juego también las acciones realizadas con anterioridad del
oftalmólogo, ya que si este revisó un caso pero no concluyó con el flujo del mismo, es
decir no brindó un análisis o resolución sobre este, entonces tendrá otra opción, que
es continuar el caso. Dadas ciertas reglas del negocio, si el oftalmólogo no cumple con
determinados requisitos en sus análisis, este será penalizado, no puede generar
análisis y reportes por un determinado tiempo. Finalmente, pasado cierto tiempo y
concluida la penalización, el oftalmólogo podrá seguir utilizando el software y
analizando casos.
Figura 19: vistas de la home del oftalmólogo, desplegadas en Vercel, para evaluar un nuevo
estudio y continuar con otro, respectivamente
45
Figura 20: home del administrador, desplegado en Vercel, donde se pueden ver todas las
opciones de ABM
El usuario administrador posee una home con más opciones. Todas ellas relacionadas
con el ABM de entidades.
Figura 21: vistas de la home del oftalmólogo, desplegadas en Vercel, donde este se haya
bloqueado y luego con la posibilidad de habilitar el módulo de informes de nuevo,
respectivamente
Finalmente el usuario con rol “paciente” no posee una página de home como las vistas
anteriormente. A continuación se detalla el caso del paciente, ya que su
comportamiento y accesos es muy distinto al de un profesional de Retinar.
46
7.1.3 Ficha paciente
En contraste con la home del resto de los roles, la home para el rol de paciente posee
una estructura más orientada a una “ficha”, además accede inmediatamente a una
vista que muestra los resultados del último estudio que usuario obtuvo. Esto da lugar a
una experiencia de usuario más destinada a la “solo lectura”, ya que es el tipo de
usuario que menos permisos posee sobre la plataforma, siendo esta solo una
herramienta informativa para el paciente.
Figura 22: home del paciente, desplegada en Vercel
En este caso se utiliza el layout de la vista para cargar imágenes y realizar su análisis
de calidad, que será explicado más adelante. El detalle a resaltar es la reutilización de
una vista que su función es la carga de imágenes, para luego ser usada para una
sección de solo lectura.
7.1.4 Listado de estudios
Esta vista tiene como principal objetivo reflejar un histórico de los estudios, ya sean
propios en el caso de los pacientes, o los realizados en el caso de técnicos de captura
u oftalmólogos. Existen pequeñas variaciones entre vistas, aunque en esencia es el
mismo componente.
47
Figura 23: listado de estudios para técnicos u oftalmólogos
Figura 24: listado de estudios para pacientes
7.1.5 ABM de técnicos
El alta / baja / modificación de técnicos de captura se realiza en una vista solamente
accesible para usuarios administradores.
48
Figura 25: vista de ABM de administradores
7.1.6 Nuevo estudio - Paso 1 - Búsqueda
Los técnicos de captura de imágenes es el único tipo de usuario que puede acceder a
esta vista. La misma forma parte del conjunto de pasos para almacenar o recuperar
información de un determinado paciente, y posteriormente cargar las imágenes de
fondo de ojo que fueron tomadas en el momento.
En esta etapa se buscan coincidencias de usuarios ya registrados con el DNI del
paciente junto con su género. A partir de aquí puede suceder que el paciente se
encuentre en las bases de datos de Retinar o no. En el caso de que se encuentre, se
continúa con el paso siguiente, recuperando los datos que ya se encuentran
almacenados. Caso contrario, se dejan los formularios vacíos, listos para rellenar con
la información del paciente a tratar.
49
Figura 26: primer paso de la vista de nuevo estudio
7.1.7 Nuevo estudio - Paso 2 - Datos personales
A partir del paso anterior, pueden suceder dos situaciones:
1. El paciente se encuentra registrado, por lo que los formularios son
autocompletados, para luego ser confirmados por el técnico, o bien realizar
modificaciones de ser necesario, para luego continuar con el paso siguiente.
Esta funcionalidad se encuentra desactivada en Vercel dada la ausencia de
una base de datos real.
2. El paciente es uno nuevo, por lo que los formularios están vacíos, listos para
completarse con los datos del usuario.
Una vez situados efectivamente en el paso 2, hay una serie de datos que deben ser
completados. Estos pueden variar o no entre estudios, siendo algunos más dinámicos
que otros.
50
Figura 27: segundo paso de la creación de un estudio: datos del usuario
Figura 28: segundo paso de la creación de un estudio: datos de consulta
7.1.8 Nuevo estudio - Paso 3 - Diagnóstico IA
Esta vista es la que permite cargar las imágenes previamente tomadas, para enviarlas
al backend y analizarlas. Esta pantalla es la que más lógica posee a nivel código, y
esto es dado el propósito que tiene.
51
En esta las imágenes al ser cargadas en el frontend, en un principio son analizadas
para corroborar si cumplen con un criterio de calidad mínima. De ser así, las imágenes
tendrán una pequeña circunferencia verde, denotando que poseen la suficiente calidad
para ser enviadas. Caso contrario, la imagen poseerá una circunferencia roja, dando a
entender que necesitan cargar otra imagen. En el frontend desplegado, esta
funcionalidad fue reemplazada con una función la cual, de manera pseudoaleatoria,
indica si la imagen pasó o no el criterio.
La cantidad de imágenes a cargar dependerá del tipo de estudio a realizar. En la figura
28 se puede observar un apartado para el tipo de estudio, que puede ser monocular o
binocular. Esta opción determina la cantidad de imágenes a cargar en esta etapa.
Adicional a los componentes para la carga de imágenes, la vista también posee datos
del paciente y la consulta misma, permitiendo así que el técnico tenga todos los datos
necesarios disponibles a todo momento del proceso de carga.
Figura 29: creación de estudio, carga de imágenes desplegado en Vercel
7.1.9 Nuevo estudio - Paso 4 - Finalizar
Como paso final en el proceso de creación de un estudio, toda la información
previamente cargada es enviada al backend y rápidamente las imágenes son
52
sometidas a un examen preliminar. El backend, entonces, devuelve una posible
respuesta de entre dos, “referible” o “no referible”.
La primera opción es el resultado de un análisis con resultados negativos, mientras
que la segunda opción denota un resultado positivo. Siempre estos resultados son
preliminares, y no es el análisis definitivo del examen.
Figura 30: Pantalla final del proceso de creación de estudio, desplegado en Vercel
7.2 Componentes relevantes
La aplicación está conformada por distintos y muy variados elementos. Algunos de
ellos se utilizan de forma repetida, mientras que otros pertenecen a una determinada
vista y solo son utilizados allí. React favorece la componentización,dando una sintaxis
y herramientas que permiten que este proceso se lleve a cabo con fluidez [35].
Durante el desarrollo del proyecto, este proceso fue esencial para lograr el diseño final
alcanzado. A continuación se listan los componentes más relevantes de la aplicación.
7.2.1 Header
El header es un componente clásico de cualquier aplicación web, y otorga un acceso
rápido a las distintas opciones más habituales que necesita el usuario, normalmente,
53
para la navegación del sitio. En este caso, el mismo es utilizado para navegar a través
de las opciones disponibles, para cerrar la sesión actual, o bien para cambiar el rol
actual, aunque este último es un agregado solo para la versión de desarrollo de la
aplicación.
Este componente está presente a todo momento cuando el usuario se encuentra
logueado, es decir es un componente transversal a casi todas las vistas. Se encuentra
fijo en la parte superior de las páginas.
Figura 31: componente header, con el menú lateral abierto
7.2.2 Menú para cambiar de roles
Este componente es un agregado que no estuvo presente en los diseños otorgados
por Retinar, pero que fue de utilidad a la hora de probar la aplicación. Como se aprecia
en la figura 15, este pequeño widget permite intercalar entre distintos roles, y a su vez
entre distintos estados dentro de cada rol, si este último lo permite, por ejemplo un
oftalmólogo que se encuentra en un estado penalizado.
Internamente, este elemento utiliza el estado global de la aplicación que se usa para
llevar a cabo un flujo de usuario u otro. Por lo tanto se reutilizo lógica que ya existía,
agregando simplemente una pequeña y sencilla interfaz gráfica que permitiese el
cambio de rol de manera rápida e intuitiva.
7.2.3 Selector de acción
En el menú principal de la aplicación se encuentran unos componentes comunes a
casi todos los roles, que permiten iniciar un flujo u otro. Estos son los selectores de
54
acciones, que poseen una imagen, un texto, y una redirección al flujo de trabajo
pertinente.
Estos elementos son completamente personalizables y cumplen su función, que es
que instintivamente el usuario sepa qué debe hacer click sobre ellos para ser
redirigidos a otra página.
Figura 32: componentes de selección de acción
En la figura 21 se puede ver que estos elementos también poseen un estado
deshabilitado de ser necesario, como es el caso de un oftalmólogo que se encuentra
con una penalización.
7.2.4 Stepper
Cuando se registra un nuevo estudio, se pasa por distintos pasos hasta que el mismo
es enviado y almacenado en la base de datos, como se puede observar de la sección
7.1.6 a la sección 7.1.9. Para mostrar al usuario en qué estado se halla en todo
momento, se creó el componente “stepper” que se encuentra en el header de la vista
para un nuevo estudio.
Este componente se caracteriza por mostrar el estado actual, los anteriores
completados y cuales son los que faltan, junto con un título descriptivo. Al momento
del desarrollo de la aplicación, este stepper es meramente informativo y no permite
55
volver atrás a pasos previos. Esta característica necesitaría una mayor cantidad de
lógica y un sistema para mantener la información consistente entre pasos.
Figura 33: componente stepper, visible desde la vista de un nuevo estudio
7.2.5 Gestor y visor de imágenes
Este es un componente fundamental de la aplicación, ya que permite que el técnico
cargue las imágenes tomadas con anterioridad, las visualiza, sean analizadas para
corroborar si cumplen con el control de calidad mínimo y finalmente son enviadas para
ser analizadas y almacenadas. Se puede observar este componente en la figura 29.
En la sección derecha se puede observar un log que le indica al usuario el estado de
cada imagen, adicional al pequeño círculo que se está junto con la miniatura de cada
imagen.
7.2.6 Modal
Otro componente fundamental es el modal. Este se configuró de tal manera que
permite que su contenido sea totalmente dinámico, dejando como características
transversales entre las instancias de este componente el fondo difuminado, la
superposición entre componentes para lograr darle prioridad al modal, la accesibilidad
del mismo permitiendo cerrarlo a través de la tecla de escape, y finalmente un padding
interior para poseer un espaciado homologado.
Figura 34: instancias del modal, en el caso de la izquierda advierte sobre una imagen de baja
calidad y permite accionar, y el caso de la derecha se utiliza para confirmar la cancelación del
estudio
56
7.2.7 Inputs
Para los inputs de datos se utilizó la misma plantilla en todos los casos. Excepto
ciertos casos específicos, como los input de búsqueda, los inputs de datos poseen
todos el mismo estilo, espaciado y comportamiento por defecto. Este es un caso ideal
para mostrar la potencia de React y la forma que incentiva a los desarrolladores a
trabajar; generar componentes reutilizables.
Figura 35: inputs de la pantalla de registrar un nuevo estudio
57
Capítulo 8: Conclusión
Muchas veces sucede que excelentes aplicaciones del lado del servidor no pueden
aprovecharse al máximo, dada una falta de interactividad. Esto es, la ausencia de una
interfaz que permita a los usuarios objetivos el uso indirecto de las aplicaciones del
backend.
Los desarrolladores de Retinar generaron el software de inteligencia artificial necesario
para poder analizar las imágenes que se toman en los centros de captura de
imágenes. Tanto el frontend como el backend no son del todo necesarios pero brindan
un flujo de trabajo el cual consigue que los procesos se agilicen, puedan
personalizarse, sean gestionables y puedan escalar de una manera correcta.
En un principio, se planificó que tanto el software del lado del cliente como del lado del
servidor fuese creado a la par para este proyecto. Se llevó a cabo un desarrollo
temprano del frontend basado en croquis suministrados por Retinar, y un backend
sencillo para cumplir con el flujo básico de la aplicación: registro de usuario, ingreso a
la plataforma y almacenamiento de imágenes.
A medida que se llevaba a cabo el desarrollo, las prioridades y objetivos de Retinar
cambiaron, dando lugar a lo que es ahora el proyecto: la base del frontend se
desarrolla en este proyecto para luego ser entregado a un equipo profesional, que se
encarga del desarrollo productivo de la aplicación de manera cross.
Los conocimientos previos adquiridos a lo largo de la carrera universitaria, junto con el
día a día en la industria del software, dieron lugar a un desarrollo rápido, ágil y
constante. Los conocimientos adquiridos en la carrera se pueden reflejar en la
performance, escalabilidad del código y en las distintas soluciones utilizadas para
distintos escenarios, ya que en distintas cátedras se vieron estos conceptos y más
aplicados a una gran cantidad de escenarios, desde programas sencillos ejecutables
desde la terminal, pasando por bases de datos y finalmente aplicaciones reales como
lo es un software para analisis de imagenes.
58
El ámbito laboral también fue un factor totalmente relevante. Fué la clave para realizar
un proyecto el cual pueda ser transferido a otro grupo de desarrolladores, minimizando
las dudas de estos y aplicando buenas prácticas en la medida de lo posible, para que
su comprensión del trabajo ajeno fuese lo más ameno posible.
Ambos sectores, el académico y el laboral, se complementan para enriquecer el
conocimiento de los desarrolladores, y otorgar habilidades y puntos de vista que son
necesarios para el día a día de un desarrollador profesional.
59
Bibliografía
1. World Health Organization. Diabetes. (16 de septiembre de 2022).
https://www.who.int/en/news-room/fact-sheets/detail/diabetes.
2. Boyd, K. (09 de septiembre de 2022). Retinopatía diabética: causas, síntomas,
diagnóstico, tratamiento.
https://www.aao.org/salud-ocular/enfermedades/retinopatia-diabetica
3. Color Atlas and Synopsis of Clinical Ophthalmology (Wills Eye Institute
Neuro-Ophthalmology. LippincottWilliams & Wilkins, 2012).
4. GitHub: Let 's build from here. Documentación de Github. (07 de Septiembre de
2022). https://github.com/
5. Retinar. (08 de Agosto de 2022). https://retinar.com.ar/
6. Martin, Robert C. (2008). Clean Code: A Handbook of Agile Software
Craftsmanship.
7. Cormen, Thomas H. (2011). Introduction to Algorithms.
8. Chollet, François. (2017). Deep Learning with Python.
9. La web y los estándares web | MDN. (29 de Noviembre de 2022).
https://developer.mozilla.org/es/docs/Learn/Getting_started_with_the_web/The_
web_and_web_standards
10. What is accessibility? - Learn web development | MDN. (23 de Febrero de
2023).
https://developer.mozilla.org/en-US/docs/Learn/Accessibility/What_is_accessibil
ity
11. Medical imaging - Wikipedia. (22 de Agosto de 2022).
https://en.wikipedia.org/w/index.php?title=Medical_imaging
12. Diagnostic tests - Retinography | IMO. (s.f).
https://www.imo.es/en/pruebas-diagnosticas/retinography
13. HTML: Lenguaje de etiquetas de hipertexto | MDN. (29 de Noviembre de 2022).
https://developer.mozilla.org/es/docs/Web/HTML
14. CSS | MDN. (08 de Enero de 2023).
https://developer.mozilla.org/es/docs/Web/CSS
15. JavaScript | MDN. (09 de Febrero de 2023).
https://developer.mozilla.org/es/docs/Web/JavaScript
16. JavaScript library for building user interfaces. Documentación de React.
https://reactjs.org/
17. Rendering Elements. Documentación de React.
https://reactjs.org/docs/rendering-elements.html
18. Introducing JSX. Documentación de React.
https://reactjs.org/docs/introducing-jsx.html
19. Introduction to Vercel. Documentación de Vercel. https://vercel.com/docs
20. How to Deploy a React Site with Vercel. Documentación de Vercel.
https://vercel.com/guides/deploying-react-with-vercel
21. Pensando en React. Documentación de React.
https://es.reactjs.org/docs/thinking-in-react.html
60
https://www.who.int/en/news-room/fact-sheets/detail/diabetes
https://www.aao.org/salud-ocular/enfermedades/retinopatia-diabetica
https://github.com/
https://retinar.com.ar/
https://developer.mozilla.org/es/docs/Learn/Getting_started_with_the_web/The_web_and_web_standards
https://developer.mozilla.org/es/docs/Learn/Getting_started_with_the_web/The_web_and_web_standards
https://developer.mozilla.org/en-US/docs/Learn/Accessibility/What_is_accessibility
https://developer.mozilla.org/en-US/docs/Learn/Accessibility/What_is_accessibility
https://en.wikipedia.org/w/index.php?title=Medical_imaging
https://www.imo.es/en/pruebas-diagnosticas/retinography
https://developer.mozilla.org/es/docs/Web/HTML
https://developer.mozilla.org/es/docs/Web/CSS
https://developer.mozilla.org/es/docs/Web/JavaScript
https://reactjs.org/
https://reactjs.org/docs/rendering-elements.html
https://reactjs.org/docs/introducing-jsx.html
https://vercel.com/docs
https://vercel.com/guides/deploying-react-with-vercel
https://es.reactjs.org/docs/thinking-in-react.html
22. Introduction to events - Learn web development | MDN. (26 de Febrero de
2023).
https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Building_blocks/Eve
nts
23. Función Callback | MDN. (29 de Noviembre de 2022).
https://developer.mozilla.org/es/docs/Glossary/Callback_function
24. API de Alto Nivel de React. Documentación de React.
https://es.reactjs.org/docs/react-api.html#createelement
25. Getting started with Angular - Learn web development | MDN. (23 de Febrero
de 2023).
https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_J
avaScript_frameworks/Angular_getting_started
26. Single-page application - Wikipedia. (18 de Febrero de 2023).
https://en.wikipedia.org/wiki/Single-page_application
27. Tutorial v6.8.. Documentación de React Router.
https://reactrouter.com/en/main/start/tutorial
28. Tenencia múltiple - Wikipedia, la enciclopedia libre. (03 de Marzo de 2020).
https://es.wikipedia.org/w/index.php?title=Tenencia_m%C3%BAltiple
29. JSON Web Token Introduction - jwt.io. Documentación de JWT.
https://jwt.io/introduction
30. Syntactic sugar - Wikipedia. (30 de Enero de 2023).
https://en.wikipedia.org/w/index.php?title=Syntactic_sugar
31. Figma: the collaborative interface design tool. Documentación de Figma.
https://www.figma.com/
32. <a>: El elemento ancla - HTML: Lenguaje de etiquetas de hipertexto | MDN. (14
de Febrero de 2023).
https://developer.mozilla.org/es/docs/Web/HTML/Element/a
33. package.json. Documentación de Node Package Manager.
https://docs.npmjs.com/cli/v8/configuring-npm/package-json#dependencies
34. Versionado Semántico 2.0.0. Documentación del versionado semántico.
https://semver.org/lang/es/
35. Componentes y propiedades. Documentación de React.
https://es.reactjs.org/docs/components-and-props.html
36. Deploying Git Repositories with Vercel. Documentación de Vercel.
https://vercel.com/docs/concepts/git
37. Descripción general del rastreador de Google | Central de la Búsqueda de
Google | Documentación | Google Developers. (11 de Febrero 2023).
https://developers.google.com/search/docs/advanced/crawling/overview-google
-crawlers?hl=es-419
38. Guía de SEO para principiantes: conceptos básicos | Centro de la Búsqueda de
Google | Documentación | Google Developers. (17 de Febrero de 2023).
https://developers.google.com/search/docs/beginner/seo-starter-guide?hl=es
39. Frost, Brad. (10 de Junio de 2013). Atomic Design.
https://bradfrost.com/blog/post/atomic-web-design/
40. Chowdhury, Tamal. (15 de Mayo de 2018). What is a view in Web Application?.
Medium.
61
https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Building_blocks/Events
https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Building_blocks/Events
https://developer.mozilla.org/es/docs/Glossary/Callback_function
https://es.reactjs.org/docs/react-api.html#createelement
https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Angular_getting_started
https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Angular_getting_started
https://en.wikipedia.org/wiki/Single-page_application
https://reactrouter.com/en/main/start/tutorial
https://es.wikipedia.org/w/index.php?title=Tenencia_m%C3%BAltiple
https://jwt.io/introduction
https://en.wikipedia.org/w/index.php?title=Syntactic_sugar
https://www.figma.com/
https://developer.mozilla.org/es/docs/Web/HTML/Element/a
https://docs.npmjs.com/cli/v8/configuring-npm/package-json#dependencies
https://semver.org/lang/es/
https://es.reactjs.org/docs/components-and-props.html
https://vercel.com/docs/concepts/git
https://developers.google.com/search/docs/advanced/crawling/overview-google-crawlers?hl=es-419
https://developers.google.com/search/docs/advanced/crawling/overview-google-crawlers?hl=es-419
https://developers.google.com/search/docs/beginner/seo-starter-guide?hl=es
https://bradfrost.com/blog/post/atomic-web-design/
https://medium.com/front-end-weekly/what-is-a-view-in-web-application-6a2836
eed4eb
41. Castilla, Tomas. (2021). Algoritmos de aprendizaje profundo para soporte al
diagnóstico de la retinopatía diabética en fotografías de fondo de ojo. Proyecto
final de grado. UNICEN.
42. Orlando, Ignacio J. (2017). Aprendizaje automático para asistencia al
diagnóstico de enfermedades visuales basado en imágenes de fondo de ojo.
Tesis doctoral. UNICEN.
43. Orlando, Ignacio J. GitHub - ignaciorlando/fundus-vessel-segmentation-tbme.
(08 de Marzo de 2017).
https://github.com/ignaciorlando/fundus-vessel-segmentation-tbme
44. Orlando, Ignacio J. GitHub - ignaciorlando/overfeat-glaucoma. (27 de
Noviembre de 2017). https://github.com/ignaciorlando/overfeat-glaucoma
45. Orlando, Ignacio J. GitHub - ignaciorlando/red-lesion-detection. (21 de
Noviembre de 2019). https://github.com/ignaciorlando/red-lesion-detection
62
https://medium.com/front-end-weekly/what-is-a-view-in-web-application-6a2836eed4eb
https://medium.com/front-end-weekly/what-is-a-view-in-web-application-6a2836eed4eb
https://github.com/ignaciorlando/fundus-vessel-segmentation-tbme
https://github.com/ignaciorlando/overfeat-glaucoma
https://github.com/ignaciorlando/red-lesion-detection