edurep-neuro: una plataforma educativa para mejorar el
TRANSCRIPT
Ricardo Enrique González Peñuela, José Felipe Quiroga Peláez
Tesis en Ingeniería de Sistemas y Computación
Universidad de Los Andes
12 2019
EduRep-Neuro: Una plataforma educativa para mejorar el acceso y la educacién
de los estudiantes de radiología. Casos de Neuro-radiología
Copyright 2019 [Ricardo González Peñuela, José Felipe Quiroga]
Abstract
“El método utilizado para enseñar a los radiólogos es proporcional al nivel
de conocimientos y habilidades del estudiante, esto hace que la tarea de enseñar
radiología sea un reto dinámico y único” (2). Tradicionalmente la exploración de
imágenes de neuro radiología es realizada mediante un “Picture Archiving and
Communication System” (PACS), estos sistemas usualmente tienen baja
usabilidad y un acceso limitado, debido a las restricciones de seguridad de acceso
a los datos contenidos de los pacientes. Actualmente existe un gran número de
herramientas que pueden ser utilizadas para realizar exploración y visualizaciones
de imágenes diagnósticas con el propósito de educar y realizar investigaciones.
EduRep-Neuro es una herramienta que integra 4 elementos: NAVIO, que es
nuestra herramienta de visualización de variables clínicas de los pacientes; Osimis
Web Viewer, que es un visualizador de imágenes diagnósticas con un grupo de
herramientas para marcado y análisis de las imágenes; Orthanc PACS system,
para almacenar y acceder a la información de los datos clínicos registrados; y
finalmente nuestra plataforma web que maneja los retos educativos asignados por
los doctores a sus estudiantes.
Reconocimientos
Quisiéramos agradecerle al Profesor John Guerra por el apoyo dado a lo
largo del proyecto, además de sus contribuciones para el diseño del sistema. Sin
su ayuda este proyecto no hubiese salido adelante.
También le quisiéramos agradecer al profesor Tiberio por guiarnos a lo
largo de todo el proyecto y ser un excelente tutor de tesis. Fue un gran apoyo en
todas las reuniones y también nos dio bastantes oportunidades para crecer y
practicar muchas cosas aprendidas a lo largo de la carrera.
Finalmente le quisiéramos agradecer al equipo aliado de neuroradiología
del Hospital Militar Central. La información y los aportes dados por el equipo del
hospital militar han sido fundamental para tener la base científica y educativa que
ha permitido el desarrollo y el despegar de este trabajo. Sus aportes en el
conocimiento de radiología fueron absolutamente necesarios para el desarrollo
correcto de esta tesis. También agradecemos el aporte investigativo del estado
del arte, que fue clave para identificar los puntos de mejora en los sistemas
virtuales y metodologías educativas de radiología actuales.
Tabla de contenidos
Reconocimientos .......................................................................................................... iv
Cap. I. ..................................................................................................................................7
Introducción .....................................................................................................................7
Descripción del problema .................................................................................7
Cap. II. ...............................................................................................................................11
Objetivos .........................................................................................................................11
Objetivo General................................................................................................11
Objetivos Específicos ......................................................................................11
Cap. III...............................................................................................................................13
Estado del Arte ..............................................................................................................13
Cap. IV. .............................................................................................................................21
Diseño y Especificaciones del sistema ..................................................................21
Especificaciones del sistema ........................................................................21
Requerimientos del sistema ..........................................................................21
Restricciones del sistema ..............................................................................24
Cap. V. ..............................................................................................................................26
Arquitectura e Implementación .................................................................................26
Arquitectura del sistema .................................................................................26
Diagramas de uso, interfaces ........................................................................32
Implementación: Frontend .............................................................................38
Implementación: Backend ..............................................................................46
Implementación: Integración de sistemas .................................................71
Cap. VI. .............................................................................................................................74
Validación con Usuarios .............................................................................................74
Introducción ......................................................................................................................74
Explicación del sistema (profesor)................................................................................75
Explicación del sistema (estudiante) ............................................................................76
Conclusión ......................................................................................................................78
Cap. VII. ............................................................................................................................91
Conclusiones .................................................................................................................91
Trabajo a Futuro ............................................................................................................92
Bibliografía......................................................................................................................93
Cap. I.
Introducción
En el mundo académico de la Radiología, uno de los pilares de la
educación de los futuros radiólogos es el entrenamiento independiente.
Actualmente existen muchas publicaciones que evalúan el uso de diferentes
herramientas de aprendizaje para comprender el grado de mejora en las
habilidades que tiene que desarrollar el estudiante: Diagnosticar, sugerir
tratamientos, detectar lesiones, entre otras cosas. En estos artículos publicados
evalúan el uso de herramientas convencionales como libros de texto clásico,
videos, juegos interactivos, sistemas de archivos manejados por profesores y
paginas web con imágenes estáticas de pacientes diagnosticados. Como
podemos ver, ha habido un largo camino de Desarrollo y evolución en las
metodologías educativas de los radiólogos (1,3,4,5,6,7,8).
Descripción del problema
A pesar de estos avances tecnológicos, los estudiantes de radiología aun
no tienen acceso a un cuerpo de imágenes diagnosticas de pacientes, ni tampoco
acceso a los sistemas de archivos con los estudios de los pacientes. Esto es un
hecho grave ya que, como establecimos anteriormente, el entrenamiento y el
desarrollo de las habilidades de un estudiante de radiología depende de la
8
disponibilidad de un ambiente en el que el estudiante pueda desarrollar sus
habilidades de exploración y diagnóstico independiente. En la disciplina de
Radiología los estudiantes se enfrentarán a casos dinámicos con muchas
imágenes diagnósticas y tendrán que estudiarlas y concluir sobre ellas, a partir de
un análisis profundo y cuidadoso que solo se puede lograr en las herramientas de
exploración de imágenes diagnosticas.
Dicho esto, los estudiantes que si tienen acceso a estos exploradores de
imágenes diagnosticas usualmente tienen que esperar largas colas y reservar
turnos en las terminales en donde se puede realizar la exploración de casos y sus
imágenes diagnosticas. Esto se debe a la baja disponibilidad de recursos para
realizar estas tareas, muchas veces el sistema es compartido con un
hospital/clínica y existen restricciones de acceso sobre el recurso. Esta situación
trae problemas tanto a estudiantes como a los profesores de Radiologia. Si los
estudiantes no pueden acceder a las imágenes diagnosticas de los pacientes para
realizar una exploración similar a la que harían cuando estén desarrollando su
profesión, el profesor se vera limitado a crear retos y tareas restringidas bajo el
contexto de los recursos disponibles a los estudiantes. Esto quiere decir, revertir
a las metodologías antiguas de enseñanza: Usar imágenes estáticas de casos
específicos curados por el profesor, utilizar libros de texto con limitada
interactividad que los estudiantes tendrán que comprar, presentaciones de
PowerPoint que dependen absolutamente de la narración del profesor para poder
comprenderlas, entre otros ejemplos.
9
La interpretación exitosa y acertada de las diferentes modalidades de
estudios radiológicos se correlaciona directamente con la habilidad clínica de
resolución de problemas que los estudiantes, los residentes y los radiólogos
practicantes deben adquirir. Esto implica la correcta integración de lo que a simple
vista ven en la imagen con sus conocimientos de anatomía, fisiología, física de la
imagen, patología radiológica y datos clínicos. Esto solo se puede dar en un
ambiente de aprendizaje similar a la realidad que se van a enfrentar en casos
médicos. Esto finalmente es considerado una habilidad; la cual, al ser combinada
con el uso de patrones de búsqueda, listas de chequeo y pre informes termina
siendo crucial a la hora de realizar la más acertada interpretación de la imagen o
el reconocimiento del hallazgo. (11,12)
La investigación de la forma en cómo se adquiere y enseña esta habilidad
si bien no ha sido ampliamente examinada y evaluada en el pasado, actualmente
se ha convertido en tendencia de investigación tanto en el campo de la educación
médica en sí misma, como de la educación radiológica en particular; gracias al
indiscutible avance tecnológico que acompañó las décadas precedentes, que
continúa su imparable desarrollo y evolución y que hace parte indiscutible y
protagónica de la radiología en sí misma. Teniendo esto en cuenta, podemos
afirmar que el foco de la investigación de los procesos de aprendizaje de la
radiología se centra en la resolución de problemas; el uso de algoritmos y
patrones; la introducción de la incertidumbre en los escenarios clínicos; la
incorporación de la tecnología en los entornos de aprendizaje; las técnicas de
aprendizaje activo y los métodos de aprendizaje independiente. (11,13)
10
Aunque es difícil de cuantificar, se sugiere que los métodos de enseñanza-
aprendizaje activos en lugar de los formatos pasivos tienen mayores tasas de éxito
a la hora de retención de información. “Una extensión de este concepto se
denomina “pirámide de aprendizaje” (9,10). Esta teoría afirma que las
experiencias educativas más pasivas, como lectura y observación de radiólogos
durante la lectura, tienen las tasas más bajas de retención de información (5% -
20%), mientras que los métodos activos como la discusión grupal, la práctica de
hacer o enseñar a otros tienen el mayor porcentaje de retención de información
(50% –90%.)” (9,10).
Se encontró según las conclusiones de Erinjeri et al. que el aprendizaje
basado en casos cuando se trata de la practica en radiología resulta más
beneficioso para el aprendizaje en el momento en que éste pasa de un enfoque
de observación pasiva de la lectura por el profesor de radiología a un aprendizaje
activo de parte del residente que involucre su participación en el enfoque y el
reporte o diagnóstico final del caso. (9,11)
Con este proyecto queremos demostrar que se puede implementar un
sistema sencillo en el que los estudiantes de radiología tengan acceso a
herramientas similares a las que tendrán cuando estén desarrollando su profesión,
y ofrecerle una herramienta a los profesores donde puedan hacer el manejo de
parte de sus recursos para enseñarle a los estudiantes. Esto quiere decir, un
sistema en el que los profesores puedan asignar retos a grupos de estudiantes, y
que los estudiantes puedan acceder a la información de estos retos, navegarlos a
traves de las variables clínicas de los pacientes en cuestión y finalmente poder
11
acceder a las imágenes diagnosticas de estos pacientes, donde podrán aplicar
diferentes filtros para poder analizar las imágenes y responder a los retos
asignados por el profesor. Todo esto con el objetivo del desarrollo de las
habilidades la resolución de problemas; el uso de algoritmos y patrones para
identificar casos, entre otras cosas.
Cap. II.
Objetivos
Objetivo General
Nuestro objetivo es desarrollar una solución basada en tecnologías web
para producir una plataforma educativa donde se provea a los estudiantes y
profesores de radiología una herramienta de visualización de datos para realizar
la exploración de variables clínicas de pacientes, exploración de imágenes
diagnósticas y con esto, que los estudiantes de radiología puedan desarrollar
habilidades de diagnóstico y análisis de pacientes.
Objetivos Específicos
• Desarrollar una plataforma web que integre un PACS, un DICOM
Web Viewer de imágenes diagnósticas y nuestra herramienta de
exploración de datos, Navio (20).
12
• Crear un sistema de manejo de usuarios para poder registrar y
restringir el acceso a la información del sistema. Esto incluye crear
cuentas y crear grupos para asignar retos a los estudiantes.
• Proveer una herramienta en la cual los profesores puedan crear
muestras (conjuntos de pacientes) con las variables clínicas para
poder crear retos a sus estudiantes.
• Evaluar y validar el sistema diseñado con los usuarios finales:
Estudiantes y profesores de radiología.
13
Cap. III.
Estado del Arte
Esta sección es tomada de la propuesta del proyecto (Hecha por el equipo
HMC-Imagine) aprobado en el mes de Julio de 2019, presentada ante el comité
de evaluación de proyectos y el comité de ética del Hospital Militar Central.
En este apartado se pretende documentar los distintos trabajos publicados
acerca de herramientas tecnológicas, recursos interactivos, desarrollos
computacionales, plataformas web y demás medios empleados en la enseñanza
y formación de radiólogos en el mundo, para contextualizar similitudes o
diferencias con nuestro repositorio, haciendo énfasis en los últimos 15 años.
ELERA (E Learning in Radiology) es una de las primeras herramientas web
publicadas con amplio grado de sofisticación para la enseñanza y aprendizaje en
radiología. Desarrollada en la universidad de Erlanger-Nurember en Alemania, se
hizo en conjunto con estudiantes de medicina interesados en el proyecto y un
grupo de radiólogos especialistas para el desarrollo de la herramienta. En esta
plataforma existe una gran cantidad de casos clínicos con libre acceso, utilizados
para ejemplificar patologías y casos anatómicos. Al igual que en nuestra
plataforma, cada caso fue seleccionado por un radiólogo experto y viene
acompañado de las variables clínicas de interés. En estos casos también se
adicionaron preguntas relacionadas a los casos, con respectivas respuestas de
opción múltiple. (15)
14
La dificultad de las preguntas, el número de opciones de respuesta, así
como el número de respuestas correctas varían de acuerdo con cuatro grupos
establecidos, según el grado de conocimientos en radiología (I-estudiantes de
medicina en fase preclínica-, II -estudiantes de medicina en fase clínica-, III-
residentes de I y II año-, IV – residentes de III Y IV año y radiólogos graduados -).
Después de que se ha resulto la última pregunta de un caso o sesión, se
muestran los resultados de este caso con un porcentaje de respuestas correctas
e incorrectas, así como gráficamente en una tabla, que es capaz de establecer
comparaciones con intentos previos del mismo usuario y con usuarios diferentes
del mismo nivel, permitiendo hacer una evaluación y autoevaluación del progreso
en el conocimiento. Por lo que incluso sus creadores concluyen que: “En el
contexto del aprendizaje autoguiado, ELERA es una herramienta que permite la
autoevaluación, motiva al estudiante al brindar desafíos interesantes y ayuda a
descubrir brechas en el conocimiento radiológico de un usuario individual frente a
sí mismo y a su grupo de referencia”. (15,13)
En el año 2004, fue publicado un articulo en el que se describe el proceso
de creación de un currículo web de acceso gratuito a través de
http://www.cchs.net/pediatricradiology, para la educación en radiología pediátrica,
basado en seis competencias previamente establecidas por las autoridades
académicas de radiología pediátrica en los Estados Unidos. En el mismo se
diseñaron módulos de aprendizaje interactivo individual -construidos por
radiólogos-, que para la fecha de exposición del diseño web contaba con alrededor
de 25; en cada uno de ellos es posible desarrollar un proceso de evaluación antes
15
y después de haber hecho la visualización del material interactivo de cada módulo,
el cual incluye texto e imágenes, con un cuestionario autoguiado y con posibilidad
de retroalimentación sobre el rendimiento; además tiene la posibilidad de registrar
datos demográficos del estudiante, que pueden ser útiles para otros proyectos de
investigación.
Estos investigadores concluyen que: “El aprendizaje basado en la web con
un plan de estudios en línea tiene el potencial de convertirse en un componente
integral de la capacitación de residencia y el hecho de proporcionar una
experiencia de aprendizaje integral diseñado por parte de expertos en radiología
puede mejorar la educación en esta área en todo el mundo”. (16,13)
“Se han descrito pocos simuladores que imitan la practica diaria de la
radiología, es decir, la interpretación de imágenes, y cada uno de estos
simuladores se ha utilizado en una escala limitada” (14,17).
Sin embargo, al realizar nuestra búsqueda de la literatura encontramos algunos
buenos ejemplos de estos, generalmente haciendo uso de herramientas
computacionales sofisticadas y enfocados en principio al fortalecimiento de los
procesos educativos.
Es así como, con el uso de herramientas computacionales en la Florida –
EE. UU, se diseño y empleo un simulador ecográfico al cual posteriormente se le
realizo una validación de su efectividad para la evaluación de residentes de
radiología de primer año, antes de enfrentarse a los turnos nocturnos no
supervisados. El estudio consistió en la administración durante dos años a ocho
16
residentes de casos con datos tridimensionales de pacientes reales y se evaluó la
precisión de las mediciones y la interpretación de los resultados en ecografía (los
cuales se calificaron en una escala de 5 puntos: 1, completamente incorrecto; 2,
muestra algo de conocimiento del tema pero dio una respuesta incorrecta; 3,
muestra una comprensión básica y dio una respuesta razonable; 4, casi
completamente correcta; 5, completamente correcto).
Además, les fueron realizadas encuestas antes y después del uso del
simulador para evaluar el conocimiento y las habilidades percibidas. Los autores
del estudio concluyen que: “al comparar los 2 años del estudio, los puntajes
promedio de las pruebas aumentaron de 3.5 a 4.0 (p> 0.05) para las preguntas de
la ecografía abdominal y de 3.4 a 4.2 (p <0.05) para las preguntas de ginecología
y obstetricia. La autoevaluación del conocimiento y la capacidad de exploración
de los residentes también mejoró significativamente”. (17,13)
De manera similar, en el año 2008 se publicó en la revista Radiographics
la descripción de la construcción de un simulador de casos en radiología, como
herramienta para el apoyo del aprendizaje. El mismo fue diseñado bajo los
criterios de calidad que según los autores debe cumplir un simulador de este tipo;
que incluyen: su similitud a un sistema PACS; la posibilidad de amonificación de
datos del paciente; la facultad para realizar mediciones, cambios en nivel y ancho
de ventana de la imagen, disponibilidad de todas las imágenes del estudio
preferiblemente en formato DICOM; la fácil alimentación del simulador con nuevos
casos – es decir, capacidad del sistema para aceptar fácilmente el aporte de
nuevos casos, para enriquecimiento continuo de la herramienta- y finalmente la
17
importantísima propiedad de proporcionar de forma inmediata al estudiante y a
largo plazo, datos acerca de su progreso en el aprendizaje, con la inclusión de la
respuesta correcta de acuerdo a un parámetro de referencia confiable (que para
los autores sería la lectura oficial de un especialista).
El simulador fue creado para integrarse con el Stentor PACS (Philips,
Brisbane, California) empleado en el Cincinnati Children’s Hospital Medical
Center. En el mismo, el estudiante puede abrir casos al azar, o elegir según
categorías de patología. Debe revisar el caso completo y realizar un informe en
texto libre hasta que considere que el mismo está listo para enviar. De manera
inmediata, después de realizar el envío, el estudiante puede hacer una
comparación directa entre su informe y el informe oficial del radiólogo graduado,
así como identificar si sus impresiones diagnósticas están anotadas en el mismo
orden de importancia que en el informe oficial. El simulador ambienta de manera
muy realista la actividad radiológica del día a día en un sistema PACS. Incluso, en
cualquier momento durante el uso del simulador, el usuario puede obtener un
informe de su rendimiento el cual se genera utilizando datos recopilados por el
simulador, en el que se muestra al usuario el número total de casos que vio, el
porcentaje total de hallazgos correctos, el porcentaje total de hallazgos primarios
que se enumeraron primero y el tiempo promedio en segundos que se tardó en
completar cada caso. En su conclusión los autores citan que: “Los simuladores
tienen el potencial de promover la educación en radiología con el uso de un
proceso de aprendizaje activo. Los simuladores basados en casos imitan de cerca
18
la práctica real de la radiología y pueden ayudar a preparar al usuario para muchos
escenarios específicos”. (18)
En el año 2009 en la revista radiographics se publicó un articulo que relata
la creación de herramienta “RENDER”, en el cual sus creadores describen el
diseño y la utilidad de un repositorio de imágenes que fue integrado con una
aplicación de búsqueda en línea y un informe completo de estudios de radiología
del Massachusetts General Hospital. La misma “fue desarrollada para facilitar la
búsqueda de exámenes radiológicos en el RIS con fines de enseñanza, educación
e investigación” (14). RENDER permite el acceso a un importante número de
imágenes y estudios radiológicos luego de que el usuario inicia sesión en la
herramienta, la cual se encuentra protegida por contraseña. En su conclusión los
autores resaltan que: “Desde una perspectiva educativa, la herramienta puede
usarse para acceder a múltiples ejemplos (imágenes e informes que representan
a diferentes pacientes) con diferentes presentaciones patológicas para una sola
enfermedad o presentaciones similares para diferentes enfermedades, pudiendo
filtrar los criterios de búsqueda. Además, entre sus funciones los usuarios pueden
preparar una presentación de búsqueda. Además, entre sus funciones los
usuarios pueden preparar una presentación de PowerPoint (Microsoft) u obtener
imágenes o informes de Render para la enseñanza, publicación o presentación
de datos con fines de investigación”. (14)
Recientemente, en el año 2018 se publicó la descripción de un modelo
basado en la nube de acceso público gratuito, en el que se realizó la integración
de un visor PACS en un formato de aula invertida para la formación de radiólogos
19
en el área de la neurorradiología, específicamente en casos de urgencias del
sistema nervioso central para preparar a los residentes de primer año en su
identificación. Para su creación utilizaron un PACS basado en la nube, el
pacsbin.com® (Orion Medical Technologies, LLC) el cual fue alimentado con un
total de 50 casos de ejemplos instructivos en emergencias y urgencias del sistema
nervioso central, aprobados por neuro radiólogos especialistas y se incluyeron
casos de diagnóstico diferencial, así como algunos estudios normales para una
adecuada comparación. La herramienta tiene la posibilidad de hacer zoom,
modificar el nivel de ventana, visualizar la totalidad del estudio, entre otras
herramientas que recrean el formato PACS. Para aplicar el modelo de aula
invertida, en un primer lugar los participantes debieron revisar módulos separados
de casos normales divididos en cinco categorías (CT cráneo; CT tejidos blandos
de cuello; CT columna cervical; RM cerebral y CT cara) con la correspondiente
anatomía anotada y descripciones detalladas de patrones de búsqueda. Al
completar los módulos normales los estudiantes pudieron avanzar hacia la
evaluación de casos patológicos programados de forma asincrónica. Se
proporcionó un temporizador para cada caso (un total de 12 minutos), para
agregar a la experiencia de simulación. Cada caso constaba de alrededor de 5 –
8 preguntas y la herramienta se aplicó antes y después de la visualización de los
módulos educativos y participaron en ellos 12 residentes de primer año de
radiología. “Al finalizar el cuestionario, los resultados de la evaluación detallada
se enviaron automáticamente al participante, así como al supervisor del
cuestionario, a fin de abordar las deficiencias generales y monitorear los cambios
20
en el desempeño del usuario. Esta evaluación incluyó comentarios para cada
pregunta, incluida la identificación de la opción de respuesta correcta, así como
una descripción breve de por qué esta respuesta fue correcta” (19). En sus
conclusiones los autores registran que se observó una mejora sustancial en el
rendimiento general. El puntaje promedio en el cuestionario previo fue del 65%
(rango 48-85%), mientras que el puntaje promedio del cuestionario posterior fue
del 83% (68-95%) y en general en la encuesta posterior a finalizar la
implementación de la plataforma de aula invertida los participantes, tanto
estudiantes como moduladores afirman que es una herramienta, cómoda, útil y
recomendable para el fortalecimiento de procesos de aprendizaje y enseñanza.
(19)
Aunque existe la descripción de algunas otras herramientas de este tipo en
el mundo, las descritas parecen ser suficientes para hacerse una idea y
convencerse de que los modelos educativos en la formación de médicos
especialistas particularmente radiólogos está cambiando y lo está haciendo de
manera drástica para virar desde un modelo tradicional de conferencias y charlas
impartidas por un docente, hacia los modelos innovadores, no ortodoxos de “aula
invertida”, y otros modelos, que propenden e impulsan el aprendizaje activo del
residente, el autoaprendizaje, los horarios asincrónicos de aprendizaje y sobre
todo el uso de herramientas tecnológicas basadas en la internet, en los recursos
computacionales y en diseño de softwares aptos y propicios para ello.
21
Cap. IV.
Diseño y Especificaciones del sistema
Especificaciones del sistema
A partir de los capítulos anteriores y el trabajo que pudimos ver que existe
sobre repositorios de imágenes diagnósticas, surgió el diseño del sistema que se
describirá a continuación. Una plataforma web educativa por la cual los
estudiantes pueden acceder a imágenes diagnosticas e información de pacientes
para realizar retos interactivos, asignados por los profesores de radiología.
Señalado esto, existe un numero de requerimientos, restricciones y retos
tecnológicos que involucra crear el sistema. A continuación:
Requerimientos del sistema
Decidimos dividir los requerimientos del sistema en requerimientos
funcionales y requerimientos no funcionales:
Requerimientos funcionales para Profesores (P), estudiantes (S) y
mantenimiento del sistema (M):
• (S, P, M) Crear usuarios en el sistema, únicamente autorizados en
una ACL (Lista de control de acceso).
22
• (M) Agregar nuevos pacientes al PACS para expandir la base de
casos.
• (M) Anonimizar la data de los pacientes en el PACS para proteger
los datos de los pacientes agregados.
• (M) Conectar la información encontrada en el PACS con la
información en nuestro sistema para poder crear muestras de
pacientes y mostrar las visualizaciones de datos.
• (P) Crear grupos de clases para asignar retos, conformados por
profesores y estudiantes.
• (P) Crear muestras de pacientes, aplicando diferentes filtros de
acuerdo con las necesidades que tenga el profesor para las
habilidades que quiere enseñar con el reto.
• (P) Crear retos y asignarlos a un grupo de estudiantes específico
con información adjunta: Enunciado (archivo) y una muestra de
pacientes.
23
• (P) Quitar profesores y estudiantes de un grupo previamente creado.
• (P) Agregar profesores y estudiantes a un grupo previamente
creado.
• (P) Enviar retroalimentación a las entregas de los estudiantes sobre
un reto.
• (P) Finalizar un reto y enviar una posible solución al reto.
• (S) Acceder a un grupo del que es miembro el estudiante y dentro
del grupo, poder visualizar los retos y los miembros del grupo.
• (S) Enviar una respuesta a un reto, enviando un archivo con la
respuesta.
• (S) Acceder a la retroalimentación dada por un profesor a una
respuesta de un reto.
Requerimientos no funcionales del sistema:
24
• Una aplicación web responsiva. Responsiva definido como el
acceso a todas las funcionalidades no puede tardar mas de 3
segundos en accederse.
• Un sistema durable, la información de los usuarios debe ser
consistente a través de toda la solución.
• Se debe proteger la información de los pacientes, asegurando el
almacenamiento y acceso seguro a esta.
• Un sistema fácil de aprender, fácil de usar, que apoye la exploración
eficiente de los casos de los pacientes.
Restricciones del sistema
Las restricciones principales para el desarrollo de este proyecto son:
• Como el proyecto tiene alta complejidad, decidimos utilizar una
arquitectura monolítica en donde todo el código desplegado corre
dentro de un solo computador, para evitar problemas de conexión
(Ya que esto no es parte del scope de nuestro proyecto). Este
sistema pudiese ser más escalable (pero también más difícil de
implementar) cambiando a una arquitectura de microservicios.
25
• Anonimizar los datos de los pacientes y su información en el PACS,
para proteger su identidad y su privacidad.
• Solo permitir usuarios al sistema que estén registrados en la ACL
(Lista de control de acceso).
26
Cap. V.
Arquitectura e Implementación
Arquitectura del sistema
Para la solución, propusimos una estructura estándar vista comúnmente en
soluciones full-stack: Un servidor front-end, un servidor back-end y una base de
datos. Adicionalmente a este despliegue, también tenemos el Osimis Web-Viewer
(21) el cual se encarga de mostrar las imágenes diagnósticas de los pacientes, y
por último tenemos el PACS que se encarga de almacenar la información
relacionada a las imágenes diagnósticas de los pacientes.
Esta es la leyenda que utilizaremos para describir el diagrama de
despliegue:
Fig.1 Leyenda de Componentes.
27
• Computador/Servidor: Hace referencia al hardware en el que
correrán los distintos componentes de software de la solución.
• Bases de datos: Hacen referencia a todos los componentes de
software que sistemáticamente pueden almacenar información y
permiten la consulta de esta información, mediante un protocolo
establecido.
• Backend: Se encarga de manejar la transaccionalidad de la
aplicación, da acceso a los servicios de las bases de datos y además
se encarga de que se cumplan todas las reglas de negocio (Límites
de fechas, restricción de acceso, etc.).
• Frontend: Aplicaciones web las cuales presentan las
funcionalidades del sistema, de cara al usuario (profesores y
estudiantes).
• Servicios de 3ero (Third-party software): Hace referencia a los
servicios contratados externos, utilizados para el desarrollo y la
implementación de la aplicación.
28
• Listas con información: Generalmente documentos excel en los
que están contenidos información utilizada por la aplicación: Listas
de acceso e información de los pacientes para formar las muestras.
Teniendo en cuenta la información presentada previamente, pasamos a
mostrar la arquitectura del despliegue de la solución:
Fig.2 Arquitectura de la aplicación.
NeuroRadVis (frontend): Es nuestro componente principal. Es la
aplicación de cara a los estudiantes y los profesores, en ella los usuarios pueden
29
acceder a todas las funcionalidades mencionadas en los requerimientos
funcionales: Crear grupos, manejar grupos, crear muestras de pacientes, crear
retos, entregar retroalimentación a una respuesta de un reto, etc.
Fig.3 Pantalla Inicial de Aplicación Web.
30
Fig.4 Pantalla de explorador de imágenes. Parte del frontend
Osimis Web Viewer (frontend): Componente open-source desarrollado
por la compañía Rewired (21,22). Este componente se encarga de mostrar las
imágenes diagnosticas de los sujetos de interés para el usuario, además de
ofrecerle un gran numero de herramientas para hacer un análisis a mayor
profundidad, entre ellas: Lupa, filtros de luz, medidores de distancia, medidores
de áreas, etc.
31
Fig.5 Pantalla de Osimis Viewer. Parte del frontend
Backend en express (NeuroRadVis): Este backend desarrollado con
NodeJS desplegado con express, ofrece una API que permite el manejo de todos
los recursos utilizados para el diseño de la aplicación: Muestras, entregas, sujetos,
grupos, usuarios, archivos.
PACS Orthanc Server (Backend de Osimis): Este backend es parte de
la solución de OSIMIS, al igual que el backend de NeuroRadVis, tiene una API
que permite el manejo de todos los recursos almacenados en la base de datos de
Orthanc (21). Funciones notables que tiene la API de interés para nosotros:
Agregar nuevas imágenes diagnosticas de pacientes, obtener identificadores
únicos para acceder a imágenes diagnosticas de pacientes, anonimizar pacientes.
Base de datos de NeuroRadVis: Como mencionamos anteriormente, en
esta base de datos (Mongodb) se almacenan todos los recursos para manejar
32
nuestra aplicación NeuroRadVis. El backend es el único que tiene acceso directo
a esta base de datos.
Base de datos de Orthanc: En esta base de datos se almacenan las
imágenes diagnósticas de los pacientes y, de no estar anonimizada, la información
asociada a cada paciente. A esta base de datos solo puede accederse mediante
el API del Orthanc Server.
Firebase Auth: Este es un servicio de tercero que decidimos utilizar para
hacer el manejo de las cuentas de los usuarios cumpliendo todos los
requerimientos de seguridad: Hash de los passwords, tokens de autenticación,
manejo de la sesión en la página (Mantener conectado, si el usuario ha ingresado
al sistema).
Diagramas de uso, interfaces
Para el diseño del sistema y para asegurarnos de desarrollar las cosas
necesarias para el funcionamiento propio del sistema, realizamos 7 diagramas de
uso:
Crear una muestra: En este diagrama se muestra el flujo de pantallas para
poder acceder a la funcionalidad de crear una muestra de interés. El profesor
tendrá acceso a esta funcionalidad, con el fin de poder crear muestras de
pacientes que cumplan con características especificas seleccionados por el
mismo.
33
Fig.6 Flujo de crear escenario.
Entrar a una Muestra: En este diagrama se muestra el flujo de pantallas
para poder acceder a la funcionalidad de entrar a explorar una muestra. El
profesor y el estudiante tendrá acceso a esta funcionalidad, con el fin de poder
acceder a las muestras de sujetos y responder/explorar los retos de los
profesores.
34
Fig.7 Flujo para entrar a un escenario.
Crear un grupo: En este diagrama se muestra el flujo de pantallas para
poder acceder a la funcionalidad de crear un grupo (profesores). El profesor tendrá
acceso a esta funcionalidad, con el fin de poder crear nuevos grupos para manejar
sus estudiantes.
Fig.8 Flujo para crear un grupo.
35
Agregar/Quitar estudiante de grupo: En este diagrama se muestra el flujo
de pantallas para poder acceder a la funcionalidad de agregar/quitar estudiante.
El profesor tendrá acceso a esta funcionalidad, con el fin de poder manejar los
grupos de estudiantes que posee.
Fig.9 Flujo para agregar estudiantes a un grupo.
Enviar reto a grupo: En este diagrama se muestra el flujo de pantallas
para poder acceder a la funcionalidad de enviar reto a grupo de estudiantes. El
profesor tendrá acceso a esta funcionalidad, con el fin de poder enviar los retos a
los estudiantes y asignarles una retroalimentación
36
Fig.10 Flujo para enviar un reto a un grupo.
Enviar respuesta a reto: En este diagrama se muestra el flujo de pantallas
para poder acceder a la funcionalidad de enviar una respuesta a un reto. El
estudiante tendrá acceso a esta funcionalidad, con el fin de poder responder a los
retos asignados por el profesor.
Fig.11 Flujo para enviar tarea como respuesta a reto.
37
Revisar respuesta de reto: En este diagrama se muestra el flujo de
pantallas para poder acceder a la funcionalidad de revisar una respuesta de un
reto. El profesor tendrá acceso a esta funcionalidad, con el fin de poder realizar
una retroalimentación a las entregas de los estudiantes.
Fig.12 Flujo para revisar reto de un estudiante.
En este punto vale la pena aclarar que estos diagramas no representan la
versión final del producto (como podrán ver posteriormente), sino una guía para
el diseño de la versión final del producto. Estos diagramas nos ayudaron a
determinar todos los requerimientos funcionales y no funcionales de la aplicación,
y de esta forma hacer un desarrollo apropiado bajo las necesidades y restricciones
del proyecto.
38
Implementación: Frontend
Para la implementación del frontend describiremos el uso de paquetes y
la estructura del proyecto.
Entre los paquetes tenemos:
• React-multi-select: Componente JSX para poder hacer selección
de varios elementos. Altamente modificable para el uso que se le
quiera dar, para este proyecto se utilizó en la creación de grupos.
• Axios: Esta librería sirve para hacer peticiones AJAX al backend
(API REST).
• D3: Librería para generar visualizaciones de datos. Se utilizó para el
componente de Navio. Adicionalmente, tiene la funcionalidad de
poder hacer lectura de archivos csv con lo cual se inicializa la
aplicación.
• Firebase: Librería que sirve para utilizar todas las funcionalidades
que provee Firebase. En mayor detalle, este paquete es un wrapper
sobre los llamados al API de firebase.
• Materialize CSS: Librería css para estilos utilizados a lo largo de la
aplicación. Utiliza el diseño que provee google.
• Moment: Librería para la manipulación de objetos tipo fecha en
Javascript. Es muy útil al momento de realizar operaciones de
comparación y de generación de timestamps UNIX.
39
• Navio: Componente para la visualización de datos creado por John
Guerra (20). Utiliza por detrás d3.js y es altamente reutilizable, lo
cual se puede evidenciar en la aplicación, específicamente en las
secciones de muestras.
• Papaparse: Librería para la lectura y manipulación de archivos csv.
• React: Librería para la creación de interfaces gráficas. Utiliza el
lenguaje JSX para poder renderizar HTML en la página. Por detrás,
tiene un DOM virtual que hace comparaciones para manipular el
DOM verdadero de la página.
• React datepicker: Componente de React para crear un elemento
de selección de fechas. Muy útil para formatear fechas y obtener los
datos sobre esta.
• React router dom: Librería encargada de provisionar enrutamiento
dinámico en una aplicación de React. Esto se debe a que
aplicaciones hechas con React son SPA (Single Page Application),
si queremos agregarle dinamismo por medio de URLs esta librería
nos da todas las funcionalidades ya hechas para poder
implementarlo.
• React toastify: Librería y componente de React para mostrar
‘toasts’ lo cuales son notificaciones de cualquier tipo, sea de éxito o
fallo sobre una acción. Ejemplo: éxito al crear un reto.
Para la estructura del proyecto tenemos:
40
Como se puede apreciar, se tiene dos carpetas importantes; public y src.
En el caso de public lo que se debe resaltar es el archivo PARAMETERS2.csv.
Actualmente, este es un csv modificado sobre el excel que proveen los radiólogos
41
del Hospital Militar que contiene la información pertinente a los pacientes, desde
sus atributos hasta los links para la visualización directa a los estudios los cuales
fueron agregados por medio de un script.
En el caso de src es un poco más complicado, ya que se debe a la
visualización de la aplicación de por sí. Dado que es un proyecto hecho en React,
este funciona por medio de componentes. Un componente simplemente es un
elemento que será agregado al DOM de la página, pensando en términos de
HTML, esto sería el contenido por medio de etiquetas. A continuación, se verá en
mayor detalle esta parte:
42
• Routes.js: Describe las rutas a utilizar en la aplicación. Se tiene por ahora
la ruta inicial ‘/’ la cual sería la página para iniciar sesión/registrarse y
‘/session’ para acceder a la aplicación de por sí.
• NotFound.js: Componente que muestra una página donde se le avisa al
usuario que la ruta no existe.
• NavioComponent.js / css: Componente que muestra el elemento navio.
Toda la inicialización para mostrar los datos se hace por aquí.
Adicionalmente, el archivo css serían los estilos utilizados.
• Index.js/css: Punto de entrada de la aplicación con sus respectivos estilos.
• Constants.js: Lista de rutas como variables constantes.
• App.js /css: Componente que muestra la página inicial con sus respectivos
estilos cuando se ingresa a la aplicación con usuario autenticado.
• API.js: constante que apunta a la dirección URL del backend.
• Loading.js: Elemento que muestra un ‘spinner’ de carga, al momento de
cambiar de página, o hacer consultas de datos.
• PreviewSample.js: Componente para mostrar información asociada a una
submuestra: Navio y Galeria de imágenes.
Ya visto lo anterior, se explicará cada carpeta adicional con sus diferentes
componentes:
• Gallery.js: Galería de imágenes de vista previa sobre los estudios de
radiología.
43
• Image.js: Componente que renderiza una sola imagen, es utilizado para
que sea renderizado varias veces en Gallery.js
• Session.js: Componente que renderiza la página y diferentes sub-
componentes dependiendo del estado actual. Por ejemplo: En caso de
estar en página de muestras, este componente renderiza el componente
asociado a muestras, lo mismo para grupos.
• Signout.js: Componente que renderiza un botón para cerrar sesión.
• Homepage.js: Componente para mostrar el formulario para iniciar sesión o
registrarse. Dependiendo del estado, renderiza Login.js ó SignUp.js.
• Login.js: Componente que muestra solamente el formulario para iniciar
sesión.
• SignUp.js: Componente que muestra solamente el formulario para
registrarse.
44
• Index.js: Componente para mostrar y agregar grupos.
• GroupSection.js: Componente que se muestra cuando se hunde click en
un grupo específico. Muestra los estudiantes, profesores y retos asociados
al grupo.
• CreateGroupForm.js: Formulario para crear un grupo.
• BreadCrumb.js: Componente que muestra las migas de pan o
‘breadcrumbs’ para facilitar la navegación en la página.
• Challenge/CreateChallengeForm.js: Formulario para crear un reto.
• Challenge/index.js: Componente que renderiza la vista en caso de hundir
en un reto. En el caso de que el usuario ingresado sea un profesor
renderiza TeacherSection.js, caso contrario renderiza StudentSection.js.
• Challenge/TeacherSection.js: Componente que muestra las respuestas de
los estudiantes sobre un reto.
• Challenge/StudentSection.js: Formulario para enviar una respuesta sobre
un reto, permite realizar varias entregas.
45
• Context.js: Componente que se encarga de mantener el estado de
autenticación de firebase.
• Firebase.js: Componente que provee todas las funcionalidades requeridas
para utilizar la autenticación de firebase.
• Index.js: Componente que utilizando los dos anteriores componentes,
permite conectarse a firebase y utilizar las funciones asociadas a la
autenticación.
• ViewSession/index.js: Componente que renderiza la muestra utilizando
PreviewSample.js por detrás.
• CreateSession/ContentPage.js: Componente que renderiza y maneja la
lógica detrás de la creación de una sub muestra, desde tipo de filtro
(FilterForm.js ó NavioForm.js) hasta los datos finales que serán enviados
al backend.
46
• CreateSession/FilterForm.js: Formulario para crear una sub muestra
utilizando parámetros.
• CreateSession/index.js: Componente que renderiza ContentPage y hace el
envío final de los datos al backend.
• CreateSession/Parameter.js: Componente reutilizado en FilterForm.js para
renderizar un solo parámetro que haya seleccionado el usuario.
• Exercisespage.js: Componente que renderiza todas las submuestras
creadas por el profesor y ademas el boton para ingresar en el proceso de
crear muestra (CreateSession/index.js).
• NavioForm.js: Formulario para crear submuestra utilizando el componente
de Navio.
Implementación: Backend
Para la implementación del backend describiremos el uso de paquetes, la
estructura del proyecto y las funcionalidades de la API.
Entre los paquetes tenemos:
• Body-parses: Este paquete es utilizado para manejar los requests
que entran y salen del servidor, esto quiere decir modificar el cuerpo
o leer los requests con el tipo de dato apropiado.
• CORS: Este paquete es utilizado para poder hacer cross-origin
requests, para poder prototipar rápidamente y no tener que
47
preocuparnos por configuraciones de red (no es lo importante de
nuestro sistema).
• Express, Express-formidable: Este par de paquetes nos permite
desplegar nuestro código como un servidor que escucha en un
puerto los requests de los usuarios, y también realiza las conexiones
necesarias con la base de datos.
• Fast-csv: Este paquete lo utilizamos para acceder a la ACL (Lista
de control de acceso), archivo que está en formato csv. Nos permite
leer rápidamente el archivo y aplicar las reglas de negocio.
• Gridfs-stream, multer, multer-gridfs, storage, mongoose: Estos
5 paquetes son utilizados para acceder a la base de datos, y también
poder almacenar archivos en la base de datos.
• Nodemon: Este paquete es utilizado únicamente en desarrollo. Es
utilizado para correr el código “en caliente”. Nos permite actualizar
el código del servidor, sin tener que reiniciarlo cada vez que se
realizan cambios en el mismo.
48
Para la estructura del proyecto tenemos:
Fig.13 Estructura de directorio backend.
Como podemos ver, tenemos 3 módulos importantes: API, controladores y
esquemas. Además de esto, contamos con un archivo de configuración y un
archivo lista.csv, que es la lista de control de acceso. El archivo de configuración
contiene la URL de acceso a la base de datos de mongodb. Para cambiar la base
de datos simplemente se le tiene que dar la URL de acceso y un usuario permitido
en la base de datos. Todo debería seguir funcionando perfectamente con la nueva
base de datos.
Dentro de los controladores, tenemos un controlador por cada recurso:
49
Fig.14 Estructura de directorio controladores backend.
Cada uno de estos controladores contiene los métodos que aplican las
reglas de negocio y además hacen el manejo del recurso (Como se crean, como
se acceden a estos y como se almacena la información de estos en la base de
datos).
• AttachmentsController: Este controlador tiene 6 métodos: Crear,
actualizar archivo de entrega, borrar, obtener recurso por Id, obtener
recurso por Id del dueño y obtener todos los recursos en la
colección.
• ChallengesController: Este controlador tiene 5 métodos: Crear
reto, actualizar estado del reto, borrar, obtener reto por Id, y obtener
todos los retos en la colección.
• FileManagement: Este controlador tiene 3 métodos: Obtener todos
los archivos subidos, borrar un archivo y descargar un archivo
especifico.
50
• GroupsController: Este controlador tiene 9 métodos: Crear,
actualizar, borrar, obtener grupo por Id, obtener todos los grupos en
la colección, agregar estudiante a grupo, quitar estudiante de grupo,
agregar profesor a grupo, quitar profesor de grupo.
• SamplesController: Este controlador tiene 5 métodos: Crear
muestra, actualizar muestra, borrar, obtener muestra por Id, y
obtener todas las muestras en la colección.
• SubmissionsController: Este controlador tiene 5 métodos: Crear
entrega, actualizar entrega, borrar, obtener entrega por Id, y obtener
todas las entregas en la colección.
• UsersController: Este controlador tiene 6 métodos: Crear,
actualizar, borrar, obtener usuario por Id, obtener usuario por email
y obtener todos los usuarios en el sistema.
Dentro de la API, tenemos una interfaz de acceso por cada recurso:
Fig.15 Estructura directorio API back end
51
En cada una de estas interfaces de acceso se tiene las rutas para
manipular y acceder a los recursos del backend (Mediante los controladores
previamente descritos):
Para la referencia a los archivos que se suben al sistema tenemos:
52
53
54
Para los retos que se suben al sistema tenemos:
55
56
57
Para los archivos que se suben al sistema tenemos:
58
Para los grupos que estan en el sistema tenemos:
59
60
61
Para las muestras que se suben en el sistema tenemos:
62
63
Para las entregas que se suben en el sistema tenemos:
64
65
66
Para los usuarios que estan en el sistema tenemos:
67
68
Finalmente, dentro de los esquemas tenemos:
69
Fig.16 Estructura directorio modelo de datos backend.
Para cada recurso utilizado en la aplicación tenemos un esquema
asociado. Este esquema describe la estructura de información (objeto) que se va
a guardar dentro de la base de datos en una colección.
Fig. 17 Diagrama UML de datos.
70
• Attachment: Describe la estructura de información que se va a
guardar por cada archivo.
• Challenge: Describe la estructura de información que se va a
guardar por cada reto creado.
• Groups: Describe la estructura de los grupos de clase, para asignar
retos y enviar retroalimentaciones a estudiantes.
• Sample: Describe la estructura que tiene cada muestra, este objeto
almacena la información de cuales sujetos se tienen que mostrar en
la visualización de NAVIO, en cada uno de los retos.
• Submission: Describe la estructura que tiene cada entrega de un
estudiante, y además contiene la retroalimentación hecha por el
profesor.
• Users: Guarda la información del usuario y un identificador
asociado, que se utiliza para relacionar el usuario con las muestras,
los grupos y las entregas hechas.
71
Implementación: Integración de sistemas
En esta sección explicaremos brevemente:
1. Como agregar nuevos pacientes a la base de datos del sistema
2. Como conectar la información de la base de datos del PACS con la
información de la herramienta de visualización de datos.
Como agregar nuevos pacientes a la base de datos del sistema
Para agregar nuevos pacientes a la base de datos creamos un protocolo
sencillo:
1. Tener todas las imágenes diagnosticas de los pacientes de los cuales
se quiere subir la información.
2. Tener acceso a la maquina donde esta corriendo el PACS, o en su
defecto la IP de la maquina.
3. Correr el script UploadStudiesOrthanc.py, en la carpeta en la que se
encuentran las imágenes.
Este es un script que creamos a mano, el cual se encarga de acceder a
cada carpeta dentro de la carpeta que contiene cada imagen de los pacientes y
realiza un llamado a la API del PACS por cada imagen de paciente. Este llamado
de la API agrega al paciente a la base de datos si no existe previamente, y si
72
existe asocia las imágenes diagnosticas entre ellas si pertenecen al mismo estudio
del paciente.
Como conectar la información de la base de datos del PACS con la
información de la herramienta de visualización de datos.
Una vez agregado los pacientes al PACS, podemos conectar la información
que hay en el PACS, con la información que tenemos en nuestra base de datos
de variables clínicas y variables de las imágenes diagnosticas de los pacientes.
El protocolo para conectar los estudios con la base de datos es el siguiente:
1. Los scripts descritos a continuación se tienen que correr en la máquina
del PACS, o en su defecto se tiene que dar la dirección IP del PACS.
2. Para obtener los nombres de los pacientes con sus estudios se corre el
script ScriptEstudiosConNombre.py.
3. Luego para obtener la URL de acceso a los estudios de cada paciente
se corre el script ScriptObtenerUniqueId.py.
4. Una vez obtenido los identificadores únicos de cada paciente con su url,
se tiene que colocar en el Excel que tiene los datos de las variables las
url obtenidas en la columna “link”, para que al hacer click en las
imágenes de vista previa se pueda acceder al visor de OSIMIS con los
estudios.
73
Estos scripts se dejarán dentro del repositorio del proyecto, para que en
un futuro las personas que utilicen y mantengan este sistema puedan agregar
nuevos pacientes en sus implementaciones.
74
Cap. VI.
Validación con Usuarios
Protocolos
Para realizar las validaciones con los usuarios se diseño un protocolo de
pruebas, para profesores y estudiantes. En el protocolo se le explica al usuario las
funcionalidades que tiene el sistema, las tareas que tiene que realizar y por último
se le dio acceso a una encuesta, de la que sacamos nuestras conclusiones acerca
de la usabilidad del sistema.
A continuación, mostramos el protocolo que se les entrego a los usuarios
al momento de hacer las pruebas:
Protocolo para estudio de usuario
EduRepNeuro Ambiente educativo con base en un repositorio de neuroimágenes
Caso de estudio: Hospital Militar Central
Grupo IMAGINE- Universidad de los Andes Noviembre 2019
Introducción
Hola, somos Ricardo González Peñuela, José Felipe Quiroga y José Tiberio Hernández. Somos 2 estudiantes de pregrado y un profesor asociado de la Universidad de Los Andes. Formamos parte de un grupo colaborativo entre el Hospital Militar y La Universidad de Los Andes. Les agradecemos por hacer parte de este estudio.
75
Este proyecto está enfocado en construir una plataforma web educativa para tareas de exploración de imágenes diagnosticas. Nuestro propósito con este estudio es obtener información acerca de qué tan funcional es nuestro prototipo y reconocer puntos de mejora en la herramienta.
Este estudio tardará alrededor de <1 hora y media>. Primero le explicaremos las funcionalidades que puede usar de acuerdo con su rol (estudiante o profesor), luego requeriremos que cumpla con un número de tareas que se pueden hacer con el sistema y posteriormente le haremos un cuestionario para conocer su satisfacción sobre la usabilidad del sistema.
Si alguna cosa no le quedó clara, por favor háganoslo saber y se lo aclararemos.
Explicación del sistema (profesor)
Antes de comenzar, quisiéramos familiarizarlo con las tareas que puede hacer como <Profesor> con la herramienta Como profesor, el rol central será el de diseñar y asignar retos a un grupo de estudiantes, revisar sus entregas, y enviarles su realimentación. Un reto es una pregunta que, con base en la información de una muestra de sujetos (neuroimágenes, datos clínicos), un estudiante de radiología pueda responder con un documento que integre en su contenido, anotaciones sobre las neuroimágenes y argumentación pertinente,
Para lograrlo, usted debe poder • Definir los grupos que tiene asignado como profesor • Navegar por la población de sujetos que contiene la base de datos de
sujetos de interés (tanto las neuroimágenes como los datos clínicos de cada sujeto y, cuando esté disponible, la información confirmada del diagnóstico de dicho sujeto con base en la información anterior)
• Definir una muestra de sujetos que son de interés para la definición de uno o más retos para los estudiantes. Para esto usted puede utilizar una herramienta interactiva que le facilitará esta tarea.
• Para una muestra específica, y un grupo de estudiantes específico, usted puede definir un reto que asigna con una fecha para las entregas que realicen los estudiantes.
• Pasada esta fecha, usted podrá revisar las entregas realizadas, y para cada una de ellas, generar una realimentación que estará materializada en un documento que será enviado al estudiante en cuestión. Este documento puede contener revisiones sobre el documento enviado por el estudiante y
76
anotaciones complementarias sobre las neuroimágenes, según el profesor lo considere conveniente.
Todo esto a través de su buscador! En cualquier momento, desde cualquier parte!
Para este estudio le pediremos las siguientes tareas: 1. “Familiarización”
a. Navegar en la población de datos, escoger un sujeto y presentarlo a sus compañeros brevemente (15 mins) b. Definir una muestra de 10 sujetos con base en características de diagnóstico (10 mins)
2. “Definir una muestra” . Definir una muestra con base en criterios propuestos por usted (15 mins)
3. “Definir un reto con bajo nivel de dificultad” . Para un grupo específico, y la muestra anteriormente definida, hacer una pregunta dirigida a los residentes. (30 mins, 15 cada uno)
La cuenta de su usuario ya estará creada. Ingrese con el Usuario: <<[email protected]>> y el Password: <<profesor123456>>
Solo tendrá que acceder al ambiente Web, y realizar las tareas solicitadas
¡Si tiene alguna duda durante las tareas, no dude en consultarnos!
Explicación del sistema (estudiante)
Antes de comenzar quisiéramos familiarizarlo con las tareas que puede hacer como <Estudiante> con la herramienta.
Como estudiante, usted podrá acceder a diferentes retos asignados por el profesor en cada una de sus asignaturas/grupos. Estos retos estarán conformados por un enunciado y una muestra de sujetos. La muestra de sujetos contiene variables clínicas del caso de estudio y una herramienta que permite acceder a las neuroimágenes del sujeto. Usted deberá acceder al reto y resolver las preguntas que se le hagan, a partir de la muestra de sujetos que se le provea.
77
Para responder el reto, usted tendrá la oportunidad de subir unos archivos que contengan la respuesta al reto. Después de que usted realice una entrega, el profesor podrá darle retroalimentación de la entrega realizada.
En resumen, usted puede:
1. Revisar los grupos de los que hace parte 2. Acceder a los retos dentro de los grupos y ver la información proveída 3. Acceder a una muestra de pacientes y sus variables clínicas 4. Explorar las imágenes diagnósticas de un sujeto de interés. 5. Realizar una entrega a un reto, con archivos incluidos. 6. Recibir retroalimentación a su respuesta y leerla
Todo esto a través de su buscador! ¡En cualquier momento, desde cualquier parte!
Para este estudio le pediremos que complete 2 retos asignados por su profesor.
La cuenta de su usuario ya estará creada. Ingrese con el Usuario: <<[email protected]>> y el Password: <<estudiante123456>>
Solo tendrá que acceder al grupo en el que esté y responder a los retos.
Lea detenidamente el documento del reto, acceda a la muestra que se le otorgó y explore los sujetos para llegar a una respuesta.
¡Si tiene alguna duda durante las tareas, no dude en consultarnos!
Encuesta del sistema
78
https://forms.gle/f29vnnqorfH7SdG26
Conclusión
De nuevo les agradecemos por formar parte del estudio. Apreciamos su tiempo y su paciencia.
Con este protocolo pudimos probar las funcionalidades principales del
sistema y además obtener retroalimentación directa a través de los usuarios
finales del sistema.
En la siguiente sección explicaremos el contenido de las encuestas, como
se hizo, porque se hizo de esta manera y además analizaremos los resultados de
las encuestas.
Resultados
Para obtener la retroalimentación de nuestros usuarios hicimos una
encuesta, esta sigue el protocolo de evaluación SUS (Standard Usability Scale) y
la adaptamos a nuestras necesidades. SUS es una escala utilizada para evaluar
sistemas complejos de una manera estandarizada. Cambiamos la manera en que
esta redactada algunas de las preguntas con el fin de que fuesen más fácil de
entender las preguntas, por parte de los usuarios.
79
Con SUS, pudimos evaluar de manera efectiva la usabilidad del sistema y
establecer un punto de comparación, para que en un futuro nuestro sistema se
pueda comparar con otros sistemas similares.
Las preguntas que le hicimos a los usuarios finales fueron:
1. Yo pienso que usaría frecuentemente EduRepNeuro.
2. Me pareció que EduRepNeuro era innecesariamente complejo.
3. Me pareció que EduRepNeuro es fácil de utilizar.
4. Siento que necesitaría ayuda de una persona técnica para saber
como utilizar la herramienta (siempre).
5. Me pareció que las funcionalidades de EduRepNeuro estaban bien
integradas.
6. Me parece que la mayoría de los (doctores y estudiantes)
aprenderían a utilizar EduRepNeuro rápidamente.
7. Me pareció bastante complicado utilizar EduRepNeuro.
8. Me sentí cómodo utilizando EduRepNeuro.
9. Tuve que aprender muchas cosas antes de poder utilizar
EduRepNeuro.
Como podemos ver, las preguntas están distribuidas entre afirmaciones
positivas y negativas. Las impares R1, R3 y R5 son las afirmaciones positivas,
esto quiere decir que un puntaje de 5 (fuertemente de acuerdo con la pregunta)
80
es un buen puntaje, y un puntaje de 1 (fuertemente en desacuerdo con la
pregunta) es un mal puntaje. También R6 y R8 sigue el mismo principio que estas
impares. Las pares R2, R4 y además R7 y R9 son las afirmaciones negativas,
esto quiere decir que un puntaje de 1 (fuertemente en desacuerdo con la pregunta)
es un buen puntaje, y un puntaje de 5 (fuertemente de acuerdo con la pregunta)
es un mal puntaje.
A continuación, presentamos los resultados:
Las pruebas se hicieron con 2 profesores y 3 estudiantes. Los dos
profesores tienen amplia experiencia en Radiografía. Ambos han trabajado en la
disciplina y también han dado catedra.
Los 3 estudiantes tenían perfiles variados: 1 estudiante estaba en su primer
año de la carrera, mientras que los otros dos estudiantes ya estaban finalizando
la carrera (4to y 5to año).
Resultados de las encuestas estudiantes:
81
82
83
84
Como podemos ver en las respuestas de las encuestas a los estudiantes,
el sistema efectivamente posee una buena usabilidad. Obtuvo un puntaje bastante
alto para las afirmaciones positivas: R1 5.00, R3 4.67, R5 4.67, R6 4.67 y R8 5.00.
De estas respuestas podemos concluir que el sistema efectivamente es
considerado fácil de usar, fácil de aprender a utilizar, los usuarios consideran que
utilizarían el sistema frecuentemente y por último, los usuarios se sienten
cómodos utilizando el sistema. Para R9, obtuvimos un puntaje un poco más bajo
85
(2.67 promedio). Creemos que esto se debe a que los usuarios, que en este caso
son estudiantes, aun no están familiarizados acerca de explorar sobre bases de
datos con técnicas nuevas como las que implementamos en nuestro sistema, que
utilizan filtros de manera visual y reactiva. Además de esto, la falta de experiencia
utilizando visores de imágenes diagnósticas creemos que fue consecuencia de
este puntaje bajo. La idea es que en un futuro puedan acostumbrarse a cualquier
herramienta para explorar imágenes diagnósticas, indiferente de las
funcionalidades que posee cada una.
Estas conclusiones se pueden confirmar haciendo un breve análisis sobre
las respuestas para las afirmaciones negativas: R2 1.00, R4 1.67 y R7 1.00. Estas
respuestas a las afirmaciones se pueden interpretar como: Los usuarios hallaron
poco complejo de utilizar, los usuarios sienten que podrían utilizar el sistema (una
vez aprendido) sin ayuda de una persona técnica que los ayude y por último, los
usuarios hallaron el sistema “intuitivo”.
86
Resultados de las encuestas profesores:
87
88
89
Como podemos ver en las respuestas de las encuestas a los doctores, el
sistema también obtuvo muy buenos resultados, inclusive mejores. Obtuvo un
puntaje bastante alto para las afirmaciones positivas: R1 5.00, R3 5.00, R5 5.00,
R6 5.00 y R8 5.00. De estas respuestas podemos concluir que el sistema
efectivamente es considerado fácil de usar, fácil de aprender a utilizar, los
usuarios consideran que utilizarían el sistema frecuentemente y por ultimo, los
usuarios se sienten cómodos utilizando el sistema. Podríamos estar tentados a
concluir que los resultados positivos se dieron de tal manera por la familiaridad
90
que tenia uno de los dos doctores con el sistema, pero realmente anterior a esta
evaluación, ningún de los dos doctores había utilizado el sistema de primera
mano. Únicamente habían visto algunas funcionalidades y, de hecho, no se les
dieron instrucciones específicas ni entrenamiento para utilizar el sistema. De esta
manera, podemos decir que efectivamente el sistema es muy usable para
doctores veteranos en la profesión.
Estas conclusiones se pueden confirmar haciendo un breve análisis sobre
el puntaje promedio a las respuestas para las afirmaciones negativas: R2 1.00,
R4 1.00 y R7 1.00. Estas afirmaciones se pueden interpretar de la misma manera
que con los estudiantes, pero para las funcionalidades de los doctores. Esto quiere
decir que: Los usuarios hallaron poco complejo de utilizar el sistema, los usuarios
sienten que podrían utilizar el sistema (una vez aprendido) sin ayuda de una
persona técnica que los ayude y por ultimo, los usuarios hallaron el sistema
“intuitivo”.
Finalmente, es importante mencionar que la pequeña diferencia que hay
entre los resultados de los doctores y los estudiantes, estimamos que se debe a
la experiencia con herramientas de exploración de imágenes diagnósticas entre
ambos grupos. Los doctores han estado por décadas utilizando este tipo de
herramientas, herramientas con mucho menos usabilidad y mucho menos
intuitivas, y por esto creemos que dieron un puntaje perfecto para nuestro sistema.
Mientras que los estudiantes, que están acostumbrados a tecnología mucho más
91
refinada, reactiva, eficiente y con diseño, les pareció que tuvieron que aprender
varias cosas antes de poder estar familiarizados con el sistema.
Cap. VII.
Conclusiones
En resumen, en este trabajo presentamos la problemática que existe en la
metodologías educativas para Radiólogos, indicamos cuales son las prácticas
actuales, los sistemas utilizados actualmente y que los hace no deseables,
procedimos a presentar nuestro sistema y las funcionalidades que debía tener
para cumplir con las necesidades de los usuarios, explicamos la implementación
de este sistema y por último, describimos y analizamos los resultados tomados de
una actividad de evaluación del sistema.
La importancia de tener herramientas que se ajusten a las necesidades de
los estudiantes de Radiología de esta nueva generación y que se adapten a la
nueva modalidad de aula invertida no puede ser subestimado. Estas herramientas
tienen un impacto profundo en el proceso educativo, el cual no solo se hace más
eficiente con este nuevo tipo de metodologías y sistemas (mayor recordación de
conceptos), sino que también desarrollan nuevas habilidades sobre los
estudiantes, como es la discusión de casos, el trabajo colaborativo y la discusión
con los doctores.
92
Con este trabajo entendimos que desarrollar una solución de gran
envergadura como este, requiere de bastante esfuerzo, coordinación y
cooperación de distintas partes. Sin la ayuda de los doctores y los estudiantes del
Hospital Militar Central hubiese sido imposible de comprobar, comprender y
solventar las necesidades que tienen los doctores y los estudiantes de radiología,
al momento de producir y consumir material de aprendizaje.
También es importante recalcar el valor que tiene la información proveída
por los pacientes, que permitieron utilizar sus datos para el aprendizaje de futuros
médicos y radiólogos. En este aspecto estamos muy agradecidos con las
personas que dieron permiso para utilizar sus datos para el desarrollo de este
proyecto. Finalmente, es importante mencionar que la seguridad alrededor de esta
solución es un tema fundamental. Se deberían manejar protocolos seguros de
comunicación web (Lo cual no se pudo realizar en esta entrega, porque todo fue
desarrollado para una red local), y el almacenamiento de la información de los
pacientes debería estar toda anonimizada y almacenada de manera segura, ya
que esto es información sensible.
Trabajo a Futuro
Aun existe mucho trabajo por hacer en el marco de este Proyecto. Nuestro
sistema por ahora esta limitado a manejar casos de Neuroradiología, pero existe
el potencial para manejar diferentes casos y expandir las ramas de medicina con
93
las que podrían aprender nuevos estudiantes en esta disciplina. Por mencionar
algunos ejemplos: Se podría agregar un Sistema de clasificación para diferenciar
los pacientes que se agregan a la base de datos, y de esta manera permitir a los
médicos crear submuestras de pacientes dependiendo de la disciplina que
desempeñe (Cardiología, osteo-muscular, caja toráxica, etc.), se podrían agregar
herramientas de análitica sobre el comportamiento de los usuarios y los resultados
de los diferentes retos para poder apoyar las tareas de docente de los doctores,
también se podría modificar OSIMIS web-viewer para que los estudiantes puedan
hacer anotaciones sobre los casos de interes, y que el profesor pueda recuperar
las anotaciones de los usuarios directamente sobre la aplicación (Mejorando el
proceso de interacción entre doctores-estudiantes).
Estos son unos cuantos ejemplos de lo que podría agregarsele a este
sistema, y esperamos que las personas que en un futuro trabajen en esta misma
linea puedan ver el potencial que se tiene con este sistema. Se podría revolucionar
la manera con la que los estudiantes de medicina aprenden sobre imágenes
diagnósticas y mejorar de manera sustancial el proceso educativo de los mismos.
94
Bibliografía
1. Polanco-Cortés J. Repositorios digitales. Definición y pautas para su
creación. Vicerrectoría de Investigación. 2014; 4. 1-19.
2. Abadal E. Acceso abierto a la ciencia. Versión del autor. UOC. Barcelona:
Editorial; 2012.
3. López Medina A. Guía para la puesta en marcha de un repositorio
institucional. SEDIC. 2007. 1-159.
4. González-Díaz C, Iglesias-García M, Baeza Devesa V, Martín Llaguno M.
Ideas para el diseño del repositorio de la Red Teoría y Práctica de la
Comunicación. Jornadas de Redes de Investigación en Docencia
Universitaria. Alicante: Universidad de Alicante; 2016.
5. Barton M, Waters M. Cómo crear un repositorio Institucional. Manual
LEADIRS II. Cambridge: MIT; 2004-2005.
6. Crow R. The case for institutional repositories: a SPARC position paper.
Washington, DC: The Scholarly Publishing & Academic Resources
Coalition; 2007.
7. Gibbons S. Defining an institutional repository. Library Technology Reports.
2004. 40, 4. 6-10.
8. Medina A. y Salvador F. Didáctica General. Pearson Educación. Madrid;
2009.
9. Joseph P. Erinjeri, Sanjeev Bhalla. Redefining Radiology Education for
First-Year Medical Students: Shifting From a Passive to an Active Case-
Based Approach1. Acad Radiol 2006; 13:789–796.
95
10. National Teaching Laboratory-Institute for Applied Behavioral Science. The
Learning Pyramid. Bethel, ME: early 1960s.
11. Kathleen L. Linaker DC. Pedagogical Approaches to Diagnostic Imaging
Education: A Narrative Review of the Literature. Journal of Chiropractic
Humanities 2015 Dec; 22: 10–16.
12. Blane CE, Vydareny KH, Ten Haken JD, Calhoun JG.Problem-solving
model in radiology for medical students. JMIRO Australas Radiol
1989;33(2):173
13. Scarsbrook AF, Graham RNJ, Perriss RW. Radiology education: a glimpse
into the future. Clin Radiol 2006;61(8):640–64
14. Pragya A. Dang, Mannudeep K. Kalra, Thomas J. Schultz, Steven A.
Graham, Keith J. Dreyer. Informatics in Radiology Render: An Online
Searchable Radiology Study Repository1. RadioGraphics 2009; 29:1233–
1246.
15. Grunewald M, Heckemann RA, Wagner M, et al. ELERA: a WWW
application for evaluating and developing radiologic skills and knowledge.
Acad Radiol 2004; 11:1381-1388.
16. Reid JR, Goske MJ, Hewson MG, et al. Creating an international
comprehensive web-based curriculum in pediatric radiology. AJR Am J
Roentgenol 2004; 182:797-801.
17. Monsky WL, Levine D, Mehta TS, et al. Using a sonographic simulator to
assess residents before overnight call. AJR Am J Roentgenol 2002; 178:35-
39.
96
18. Alexander J. Towbin, Brian E. Paterson, Paul J. Chang. Informatics in
Radiology Computer-based Simulator for Radiology: An Educational Tool.
RadioGraphics 2008; 28:309–316
19. Payam Sajedi , Noriko Salamon , Jason Hostetter , Stellios Karnezis ,Arvind
Vijayasarathi , Reshaping Radiology Pre-Call Preparation: Integrating a
Cloud-based PACS Viewer into a Flipped Classroom Model, Current
Problems in Diagnostic Radiology (2018),
doi10.1067/j.cpradiol.2018.07.014
20. Navio. (2018). Tomado 6 de Diciembre 2019 de: https://navio.dev/
21. Jodogne, S. J Digit Imaging (2018) 31: 341.
https://link.springer.com/article/10.1007/s10278-018-0082-y
22. Osimis Web Viewer. Tomado el 4 de Diciembre 2019 de:
https://bitbucket.org/osimis/osimis-webviewer-plugin/src/master/