1
Visualizador de imágenes médicas para el seguimiento de tumores cerebrales
Informe final de proyecto de grado
Juan Manuel Castillo Meneses [email protected]
Asesores:
Marcela Hernández Hoyos Luis Felipe Uriza
UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
BOGOTÁ D.C. 2020
2
Contenido
Agradecimientos ... 3
Introducción ... 4
1. Contexto médico ... 6
2. Trabajo previo ... 8
3. Nuestra propuesta ... 9
3.1. Funcionalidades ... 10
3.2. Arquitectura de software ... 16
3.2.1. Diagrama de clases ... 17
3.2.2. Diagrama de componentes ... 20
3.2.3. Diagramas de secuencia ... 21
3.3. Implementación ... 23
3.4. Dependencias ... 24
3.5. Despliegue ... 25
4. Resultados ... 26
5. Conclusiones y trabajo futuro ... 27
6. Referencias ... 29
3
Agradecimientos
Muchas gracias a mi asesora Marcela Hernández Hoyos por el seguimiento y los consejos durante el proyecto y por la oportunidad de realizar este trabajo. Agradezco también a Juan Pablo Cano por la colaboración en el desarrollo de la herramienta presentada. Muchas gracias a Carla Singh, Luis Felipe Uriza y Pablo Reyes por la enorme colaboración en el tema médico, no hubiera sido posible sin las discusiones y guías que nos dieron durante el proyecto.
4
Introducción
El seguimiento tumoral consiste en la evaluación de distintas características clínicas de un paciente a través del tiempo con el objetivo de identificar el avance de la enfermedad o la respuesta a distintos tratamientos. Las imágenes médicas metabólicas proveen información acerca de la evolución del tumor y son usadas por el personal médico para evaluar el comportamiento del paciente. En este trabajo proponemos la evaluación de imágenes médicas de difusión a través de métricas cuantitativas de regiones de interés y visualizaciones que permitan identificar el cambio en el comportamiento de un tiempo a otro a través de una aplicación web. La aplicación desarrollada permite importar, visualizar y transformar imágenes médicas de distintos formatos y realizar comparaciones entre imágenes a través de estadísticas y visualizaciones de regiones de interés. La herramienta fue implementada y validada con personal médico para identificar los requerimientos y oportunidades de mejora en términos de funcionalidades y experiencia de usuario a través de la ejecución del proyecto.
La correcta evaluación de la evolución de un paciente como respuesta a tratamientos permite avanzar en la identificación y comparación de tratamientos para las distintas situaciones observadas. En este trabajo, nos enfocamos en el estudio de tumores cerebrales a través de imágenes diagnósticas. Además, el uso de métricas cuantitativas y comparables permite la evaluación de los resultados obtenidos. Con esto en mente planteamos los siguientes objetivos:
• Identificar los requerimientos y estudiar el proceso de seguimiento de tumores cerebrales.
• Proveer una herramienta que le permita al personal médico evaluar la evolución de tumores cerebrales a partir de imágenes diagnósticas.
• Importar y visualizar imágenes médicas en una aplicación web que resulte útil para comparar el estado del paciente en dos tiempos distintos.
• Construir una herramienta de registro automático de imágenes para comparar lesiones en tiempos distintos.
• Funcionalidad de crear y comparar regiones de interés designadas por el usuario dentro de la herramienta.
• Proveer estadísticas y visualizaciones que le permitan al usuario comparar el progreso del paciente a través del tiempo mediante métricas cuantitativas de las imágenes médicas.
El resultado del trabajo es una aplicación web que le permite a un usuario importar imágenes médicas en formatos nifti y dicom, visualizar la imagen con varias posibilidades de interacción como trasladar y cambiar su tamaño, realizar registro automático o manual en dos dimensiones entre dos imágenes distintas, y delimitar y comparar regiones de interés.
5
La aplicación web se encuentra desplegada y esta puede ejecutar todas las funcionalidades en el explorador del usuario sin componentes externos a excepción del registro automático, el cual requiere del servidor backend. La herramienta fue validada con el personal médico para identificar oportunidades de mejora en cuento a funcionalidades requeridas y experiencia de usuario.
6
1. Contexto médico
El seguimiento tumoral consiste en la evaluación de distintas características clínicas de un paciente a través del tiempo con el objetivo de identificar el avance de la enfermedad o la respuesta a distintos tratamientos. En este trabajo trataremos el seguimiento de tumores cerebrales a partir de imágenes médicas.
El Response assessment in neuro-oncology criteria (RANO) busca caracterizar la respuesta de pacientes con tumores cerebrales. En él se especifican distintas mediciones clínicas como el área del tumor, características de imágenes o del comportamiento del paciente para evaluar el progreso del paciente ante tratamientos (Gaillard). Herramientas como la presentada permiten avanzar y usar estas guías para realizar el seguimiento del paciente de una manera objetiva y comparable.
Figura 1. Imágenes de un mismo paciente en dos instancias diferentes, la fila superior es antes del tratamiento y la inferior es después del tratamiento. Cada columna presenta una secuencia de resonancia magnética distinta, de izquierda a derecha, FLAIR, T1 con agente de contraste, DWI y ADC. Tomado de (Villanueva-Meyer, Mabray y Cha).
Imágenes diagnósticas morfológicas como T1, T2, FLAIR y T1 con contraste no proveen la información metabólica del tejido para evaluar de manera completa el progreso del tumor cerebral.
Es necesario usar otras técnicas para la identificación de estado del paciente. En particular, dos situaciones presentan problemas en la caracterización de la evolución del paciente ante un tratamiento dado (Thust MD, van den Bent MD PhD y Smits MD PhD):
7
Pseudoprogresión se refiere a cuando las mediciones obtenidas indican que el paciente está empeorando en el tratamiento, sin embargo, el cambio en las mediciones no representa el estado actual del paciente o el tejido evaluado. Esto usualmente ocurre en los primeros tres meses de tratamiento y se cree que su causa es necrosis por radiación.
Pseudorespuesta es una mejora aparente del tumor. Se puede presentar tan temprano como 1 día después del inicio de tratamiento y no necesariamente refleja el efecto antitumoral del tratamiento.
Estas dos condiciones representan un problema para la correcta evaluación del progreso del paciente porque la imagen diagnóstica no es indicativa del comportamiento real del tumor. Estas condiciones se presentan principalmente en gliomas de alto grado, sin embargo, también pueden aparecer en otros tumores. Para identificar si estas condiciones están ocurriendo o no, es necesario usar técnicas avanzadas de resonancia magnética como difusión o perfusión que buscan representar el metabolismo del tejido del paciente.
En este trabajo realizamos el estudio e implementación sobre imágenes de resonancia magnética de difusión, sugerido por el personal médico por su capacidad de identificar respuestas al tratamiento como pseudoprogresión y pseudorespuesta (Villanueva-Meyer, Mabray y Cha), posibilidad de extraer datos cuantitativos comparables entre imágenes y disponibilidad en los datos obtenidos para la investigación.
Imágenes ponderadas por difusión (DWI) puede usarse para identificar la celularidad de tumores gracias a que esta secuencia mide el movimiento de moléculas de agua. En tejidos que crecen rápidamente el movimiento de agua se reduce comparado con tejido normal. Sin embargo, la intensidad de las imágenes de DWI no se pueden comparar directamente entre ellos, lo cual reduce su utilidad para la extracción de métricas cuantitativas. Por otro lado, el coeficiente aparente de difusión (ADC) usa las secuencias de DWI para generar imágenes que pueden compararse cuantitativamente (Rock y Niknejad). Por esta razón, imágenes de ADC serán las bases para realizar el estudio presentado.
8
2. Trabajo previo
Open Health Imaging Foundation (OHIF) desarrolla un framework para implementar visor de imágenes médicas. El framework usa React como su principal dependencia y ofrece distintos módulos para crear aplicaciones web. Este framework tiene una implementación de referencia presentada en https://ohif.org/ (Open Health Imaging Foundation).
El LesionTracker (http://lesiontracker.ohif.org/) de OHIF es otra implementación que se enfoca en flujos de oncología. Su principal uso es soportar mediciones de tumores. Incluye un servidor DICOM para guardar y transferir imágenes, herramientas para medir y hacer seguimiento de lesiones y una base de datos para guardar mediciones. Este proyecto tiene una es similar al presentado en este documento.
En cuanto a la implementación, se exploraron distintas librerías para visualizar y manipular imágenes médicas. Esto se realizó a través de los repositorios de GitHub y npm de las librerías evaluadas. Métricas como popularidad, número de estrellas en GitHub y descargas fueron usadas para comparar las librerías. Además, la calidad de la documentación fue fundamentar para tomar la decisión, pues la documentación faltaba o no era muy buena para muchas de las librerías evaluadas.
XTK (UMass Boston) (Bernal-Rusiel, Rannou y Gollub) y su sucesor AMI (UMass Boston ) presentan herramientas para visualizaciones complejas en tres dimensiones y colaboración remota.
BrainBrowser (BrainBrowser Contributors) permite la visualización de imágenes neurológicas en dos y tres dimensiones. Se enfoca en la manipulación y análisis de imágenes cerebrales en tres dimensiones.
La herramienta elegida fue Cornerstone (Cornerstone contributors) por su documentación, popularidad y por su actividad y desarrollo consistente a través d ellos años. Esta herramienta implementa la lógica para importar distintos formatos médicos y herramientas para manipular y transformar las imágenes. Además, las funcionalidades implementadas eran cercanas a las buscadas en este proyecto. Algunos de los proyectos y librerías discutidas como AMI y el visor de OHIF usan Cornerstone para leer e interpretar imágenes médicas en distintos formatos.
9
3. Nuestra propuesta
En el siguiente reporte documentaremos las funcionalidades, el diseño y la implementación técnica de la herramienta de siguimiento tumoral a partir de imágenes médicas. Las funcionalidades explican las principales acciones que un usuario puede tomar para importar, visualizar, transformar y comparar las imágenes médicas. Esta sección puede ser usado como una guía para el usuario final o para tener una idea general de la aplicación.
Figura 2. Interfaz principal de la aplicación.
Basado en los requerimientos expuestos evaluamos la implementación de una herramienta para la visualización y manipulación de imágenes médicas. Se decidió usar una aplicación web para implementar la herramienta para facilitar la instalación y distribución de la aplicación pues solo es necesario usar un servidor de archivos estáticos y enviar el enlace al usuario final para que este pueda acceder mediante un explorador web. Además, el proyecto puede extenderse e integrarse con otros trabajos realizados en la universidad, los cuales utilizan tecnologías similares. Por
10
ejemplo, la decisión de usar AngularJS como framework web se tomó gracias a que otras herramientas se habían desarrollado en este framework.
El diseño de la aplicación se explicará mediante un conjunto de diagramas de la arquitectura de software y los distintos componentes de la aplicación. El primer diagrama presenta las clases más importantes en la aplicación con las responsabilidades y dependencias. Luego explicaremos los componentes de la aplicación y cómo estos interactúan entre ellos para ejecutar las funcionalidades.
Los detalles de la implementación se explicarán en la última sección. Las tecnologías y las dependencias son presentadas con la función que cumplen en la aplicación. Además, se eplican los pasos para realizar el despliegue de la aplicación, junto con algunas consideraciónes para compilar el código fuente.
El diseño de la aplicación y la implementación técnica puede ser usado modificar el código fuente o entender cómo los disntintos componentes interactuan entre ellos.
3.1. Funcionalidades
• Regiones de interés
Esta sección le permite al usuario crear, eliminar y contralar las herramientas para modificar las regiones de interés dentro de la imagen médica. Estas regiones de interés se usan para comparar las dos imágenes.
Figura 3. Sección de la interfaz usada para manejar las regiones de interés.
o Crear regiones de interés seleccionando la herramienta ROI tool (botón del mismo nombre). Una vez seleccionada, el usuario puede especificar los puntos de la región de
11
interés oprimiendo el clic izquierdo sobre la imagen. Para terminar una región de interés, se debe cliquear sobre el punto inicial de la región de interés parcial.
o Borrar regiones de interés. Es posible borrar regiones de interés por secciones (en todo el volumen o en la vista actual) o eliminar la última región de interés modificada. Esto se puede hacer con la selección presentada en el botón “Clear”. También es posible borrar regiones de interés no terminadas, es decir, que no se hayan cerrado, con la tecla
“Esc”.
o Es posible sincronizar o dejar de sincronizar las regiones de interés entre las dos imágenes con la selección “Sync Rois”. Cuando una región de interés es modificada mientras se están sincronizando, la región de interés se modifica en la otra imagen también (o se crea si no existe).
o Seleccionar el mapa de color para la visualización de la diferencia entre las dos imágenes sobre la región de interés con el selector “Roi Colormap”.
• Posición de la secuencia en el volumen
La posición de la secuencia indica el índice de la imagen que se está presentando en pantalla con respecto al volumen médico importado.
Figura 4. Sección de la interfaz encargada de modificar la posición en la secuencia y realizar registro automático de las imágenes.
o Realizar registro automático de las imágenes en la posición actual de la secuencia.
Proveemos distintos métodos registro automático. Para esta funcionalidad es necesario desplegar y tener acceso al servidor backend para realizar el procesamiento de la petición de registro. Para seleccionar el método se usa el selector “Method” y para enviar la petición al servidor backend, con el botón “Register”.
o Sincronizar o dejar de sincronizar la posición de las secuencias de imágenes entre los dos lados. Cuando el usuario cambia la imagen dentro del volumen, y la posición está sincronizada, el volumen del otro lado también cambia de posición. Esto se configura con la selección “Sync Stack”.
o Reiniciar la sincronización con la nueva diferencia en posición entre los dos lados. Esta funcionalidad resulta útil cuando los volúmenes están desfasados y las imágenes no corresponden entre los dos lados. El usuario puede dejar de sincronizar la posición,
12
encontrar la posición que corresponda con la imagen del otro lado y reiniciar el desface.
Una vez reiniciada, la posición se mantendrá sincronizada con el nuevo desfase.
• Imágenes
Figura 5. Sección para configurar las imágenes presentadas.
o Importar imágenes en formato nifti o dicom. Es posible importar volúmenes a partir de archivos que contengan volúmenes o volúmenes dicom al importar varios archivos de imágenes de dos dimensiones que pertenezcan al mismo volumen. Esto se puede hacer con el selector “Image Import”.
o Seleccionar la imagen importada que se quiere mostrar en cada lado o importar una nueva imagen.
o Indicador de la posición actual y el número de imágenes en el volumen seleccionado.
Posicionado en el lado derecho del selector “Image Import” (texto 1/29 en la imagen).
o Ocultar/mostrar regiones de interés para cada lado. Permite visualizar la imagen sin el mapa de color ni las estadísticas de las regiones de interés.
o Cambiar la opacidad del mapa de color presentado sobre la región de interés con el deslizador.
• Transformación de las imágenes, registro manual
Las transformaciones manuales le permiten al usuario realizar un registro simple en dos dimensiones cuando no se puede usar el registro automático, o su resultado no es el esperado.
13
Figura 6. Controles para realizar registro manual de la imagen.
o Trasladar la imagen de la derecha con respecto a la imagen de la izquierda con los botones “Left”, “Right”, “Up” y “Down”.
o Rotar la imagen de la derecha con respecto a la imagen de la izquierda con el deslizador “Angle”.
• Controles de teclado y ratón
o Trasladar las imágenes moviendo el ratón con el clic izquierdo oprimido (sincronizado entre los lados).
o Cambiar el tamaño la imagen al mover el ratón de arriba a abajo con el clic derecho oprimido (sincronizado entre los lados).
o Aumentar y reducir el contraste de la imagen moviendo el ratón de arriba a abajo con el clic central oprimido.
o Cuando una herramienta es seleccionada, como la de región de interés, trasladar la imagen se realiza con el clic central oprimido y no es posible modificar el contraste de la imagen.
• Comparaciones
o Selección de distintas regiones para la comparación. Por volumen completo en donde se tiene en cuenta todas las regiones de interés creadas por el usuario, por la posición de la imagen en secuencia del volumen, es decir las regiones de interés que son visibles. O solo la última región de interés seleccionada. Para seleccionar las distintas secciones se pueden usar los botones “Volume”, “Stack Position” y “Selected ROI”.
o Estadísticas como el promedio, desviación estándar y área de la sección comparada para las imágenes en ambos lados. Estas estadísticas son calculadas para las regiones seleccionadas para cada lado y por la unión de las regiones (presentada entre
paréntesis en la tabla de estadísticas). La unión puede ser distinta al área seleccionada de cada lado, pues las regiones de interés no siempre están sincronizadas.
14
o Promedio y desviación estándar de la diferencia de intensidades para la unión de las regiones de interés seleccionadas. Esta diferencia se calcula pixel a pixel entre las dos imágenes.
o Histograma de distribución de intensidades de la región seleccionada para las imágenes de ambos lados. En la siguiente imagen se presenta en histograma con la distribución normalizada y agrupado por lado (representado por color).
Figura 7. Sección de la interfaz para la comparación de regiones de interés. A la izquierda se presenta la tabla de estadísticas y en la derecha el histograma de intensidades.
o Histograma de distribución de diferencia de intensidades para la región seleccionada.
La diferencia se calcula punto a punto como el valor de intensidad en la imagen de la izquierda menos el valor en la imagen de la derecha en la misma posición. Para presentar el histograma de distribución o de diferencia se puede usar los botones
“Distribution” y “Difference”.
15
Figura 8. Sección de la interfaz para la comparación de regiones de interés. En este caso, el histograma presenta la diferencia pixel por pixel de las regiones de interés.
o Visualización de las diferencias en las regiones de interés a partir de mapas de color. El mapa de color está limitado por el valor mínimo y máximo de la diferencia en cada región de interés.
Figura 9. Visualización de la diferencia en las secciones de interés a partir de mapas de color.
16
• Metadatos
Figura 10. Sección de la interfaz que indica los metadatos de la imagen extraídos a partir de la imagen en formato dicom o nifti.
o Para ver la sección de metadatos, se debe hacer clic sobre el botón del “Metadata” en la parte superior derecha. Para volver a la sección de comparación se debe oprimir el mismo botón ahora con el texto “Comparison”.
o Metadatos de las dos imágenes seleccionadas en formato de tabla disponible para archivos nifti y dicom. Para cambiar del lado seleccionado se pueden usar los botones
“Left” y “Right”.
o Funcionalidad de filtrar por nombre y valor de metadatos para cada imagen con la entrada de texto “Search”.
3.2. Arquitectura de software
La arquitectura de software se explicará a continuación con mediante diagramas de diseño. Primero presentaremos el diagrama de clases con las dependencias y responsabilidades de cada clase, luego el diagrama de componentes con los principales componentes de la aplicación en donde se puede ver el sistema desde un alto nivel y los diagramas de secuencia con la interacción entre componentes para funcionalidades específicas.
17 3.2.1. Diagrama de clases
Figura 11. Diagrama de clases de la aplicación.
La arquitectura de software está dividida en dos partes principales, la interfaz y los servicios. En la interfaz se encuentra la lógica de renderizado y el manejo de interacciones de usuario como botones y campos de selección. Los servicios ejecutan la lógica de las distintas funcionalidades, típicamente asociadas a trasformación del estado de la imagen para mostrar resultados de las interacciones de usuario en la interfaz. El componente principal de la interfaz (AppComponent) contiene el estado global de la aplicación como las diferentes imágenes importadas, las imágenes seleccionadas en cada lado, el mapa de color, la herramienta seleccionada y si se están sincronizando o no las regiones de interés.
Los servicios utilizan `ImageState` y utilidades globales como `CornerstoneService` para implementar las funcionalidades de la aplicación. Además, ellos tienen estado interno específico
18
para cada funcionalidad. Las clases de color azul representa los componentes de interfaz, las amarillas y naranjas son los servicios específicos para la aplicación y los rojos son utilidades de Cornerstone (Cornerstone contributors), la principal librería usada para importar, transformar y visualizar imágenes médicas.
A continuación, explicaremos cada clase presentada en el diagrama junto con sus principales responsabilidades y dependencias.
AppComponent
Componente principal de interfaz, implementa las funciones encargadas de responder a las entradas de usuario y utiliza servicios para ejecutar la lógica de las distintas funcionalidades. Su principal responsabilidad es coordinar el estado de las imágenes, importar nuevas imágenes y ejecutar la lógica de los eventos generados por el usuario. En esta clase se encuentra la mayoría de las funciones que ejecuta la interfaz como respuesta a interacciones del usuario.
DropFileComponent
Un componente de interfaz encargado de proveer una región para que el usuario pueda importar archivos al arrastrarlos y dejarlos sobre la interfaz (drag and drop). El componente es genérico, la lógica para interactuar con los formatos específicos de imágenes médicas se realiza en el componente principal de la aplicación junto con los servicios.
ImageState
Clase que centraliza el estado de una imagen. En cada momento, hay dos instancias de ImageState en la aplicación, una para cada lado. Esta clase se utiliza en gran parte del código y su función principal es la comunicación del estado de la imagen para la implementación de las distintas funcionalidades de la aplicación. Los servicios usan esta clase para conocer y transformar el estado de las imágenes.
ImageStats
Realizar los cálculos de las estadísticas e histogramas de intensidades. Tiene estado propio como las regiones de interés para realizar el cálculo y también implementa la lógica para obtener estadísticas a partir de una imagen.
ImageOverlay
Encargado de generar el mapa de color de la imagen de diferencia para presentarlo como una capa sobre la imagen médica. Este componente calcula la diferencia entre los pixeles de las imágenes y realiza un cache del cálculo para no ejecutar el mismo procesamiento si las regiones de interés no han cambiado. También modifica el tamaño de secciones de las imágenes para realizar el cálculo cuando las imágenes en los dos lados tienen un tamaño distinto.
19
ImageRegistration
Encargado de realizar el registro de las imágenes de manera automática. Este componente ejecuta las peticiones al servidor backend para obtener los parámetros de transformación o la imagen ya transformada. La comunicación se realiza mediante una petición http POST al servidor con la información de las imágenes por registrar, el método de registro y metadatos de la imagen como las dimensiones.
ImageMetadataService
Este servicio implementa la lógica para adquirir los metadatos de la imagen a partir de un archivo importado. Las funciones principales son getDicomSummary y getNiftiSummary, las cuales reciben información de la imagen importada y utilizan las apis de Cornerstone para obtener los metadatos y formatearlos en una estructura que resulte conveniente para la aplicación.
CornerstoneService
Tiene la lógica de inicialización de las distintas librerías de Cornerstone y utilidades varias que requieren de las librerías de Cornerstone para su implementación. Algunas de estas funciones son:
createRoiData, buildTranslatePoints, pointInFreehand y calculateScaleRatio. Además, implementa algunos sincronizadores, los cuales se explicarán a continuación.
Cornerstone usa “sincronizadores” para mantener el mismo estado entre dos elementos HTML que estén presentando imágenes. Estos sincronizadores son funciones que responden a eventos de la interfaz generados a partir de cambios en el estado de la imagen. La función toma como parámetros los elementos HTML que deben ser sincronizados y ejecuta cambios a través de apis de Cornerstone para llevarlos al mismo estado. Un ejemplo del sincronizador es el encargado de mantener la misma traslación y tamaño entre las dos imágenes cuando el usuario usa los controles del ratón. Estos sincronizadores se basaron en las implementaciones del repositorio de cornerstoneTools
https://github.com/cornerstonejs/cornerstoneTools/tree/d9a2c2b0bb34c6fba08b6c068de1641ef2a 7d815/src/synchronization.
• stackImageIndexSynchronizer
Sincronizador de la posición del stack para imágenes de tres dimensiones. La lógica se modificó con respecto a la implementada en cornerstoneTools para tener en cuenta el offset de imágenes que no tenga el mismo número de posiciones, o cuando las posiciones de las imágenes no correspondan la una con la otra.
• freehandRoiSynchronizer
Sincroniza las regiones de interés entre las dos imágenes. Solo se sincronizan cuando la opción de sincronizar está habilitada por el usuario.
• panZoomSynchronizer
Sincroniza la posición y el tamaño de las dos imágenes. La lógica fue modificada para tener en cuenta la traslación manual o automática aplicada en el registro de imágenes.
20
CornerstoneTypes
Tipos en TypeScript de las principales apis de Cornerstone usadas en la aplicación. Los tipos pertenecen a varias librerías de Cornerstone, las principales son Cornerstone y CornerstoneTools.
Infortunadamente, Cornerstone no trae el archivo de definición de los tipos de TypeScript, por esta razón, se optó por crear los nuestros basados en el uso de la librería. El tipado no es completo y no se ha probado de forma rigurosa. Sin embargo, estos tipos fueron mapeados para las versiones y apis usadas en la aplicación. Es posible que se necesite actualizar este archivo cuando se quiera usar otras apis o actualizar la versión de alguna librería de Cornerstone. Los tipos no son necesarios para compilar TypeScript, sin embargo, proveen ayudar a la hora de implementar las funcionalidades. Existe un issue en GitHub sobre la implementación de tipos en Cornerstone (https://github.com/cornerstonejs/cornerstoneTools/issues/1021).
CornerstoneEvents
Similar a CornestoneTypes, provee tipos para los eventos de Cornerstone y CornerstoneTools.
Estos eventos fueron tomados directamente del repositorio de código fuente de Cornerstone (https://github.com/cornerstonejs/cornerstone/blob/7f826556a759c2c053be776e8c3d24ff2b2a05d
1/src/events.js) y CornerstoneTools
(https://github.com/cornerstonejs/cornerstoneTools/blob/e38e2f5c81b0f83cca5a29a03334bee287 028a8a/src/events.js).
3.2.2. Diagrama de componentes
En el siguienete diagrama presentamos los principales componentes de la herramienta. La aplicación web se presenta como un paquete que contiene los componentes de interfaz, el manejador de eventos y el servicio. La aplicación se comunica con el componente de registro
21
através de peticiones https para ejecutar la funcionalidad de registro automático y la interfaz se comunica con el sistema de archivo a través de la api del explorador.
Figura 12. Diagrama de componentes de la herramienta.
En la aplicación, el componente de interfaz es usado por el manejador de eventos para configurar la respuesta a las interacciones de usuario, mientras que el servicio modifica la interfaz como respuesta a los eventos generados. El manejador de eventos utiliza las funcionalidades del componente de servicio para ejecutar la lógica de los diferentes eventos. El componente de registro automático es desplegado como un servidor web que responde a peticiones de la aplicación. Las peticiones cont A continuación, se presentan los diagramas de secuencia con la interacción entre los distintos componentes del sistema.
3.2.3. Diagramas de secuencia
En los diagramas de secuencia se puede apreciar la comunicación y las dependecias de los distintos componentes de la aplicación en ejemplos concretos. En la siguiente figura presentamos el diagrama de secuencia para el registro de imágenes. El usuario ejecuta la funcionalidad de registro de imágenes a través de la interfaz gráfica. La interfáz llama al manejador de eventos y este ejecuta
22
las función correspondente al registro de imágenes en el servicio. El servicio verifica la petición y empieza con el procesamiento, primero actualiza a la interfáz con el nuevo estado de la petición (cargando) y luego realiza una petición https al componente de registros con las imágenes por registrar. Si la petición sale bien, el componente de registro responde con la imagen registrada, o con los parámetros de transformación para registrar las imágenes. En este caso, los casos de error los verifica el servicio y los comunica a la interfaz.
Figura 13. Diagrama de secuencia del registro de imágenes.
El proceso de importar imágenes se describe a continuación. El usuario selecciona la opción de importar imágenes en la interfaz, la cual le comunica al manejador de eventos sobre la interacción.
El manejador de eventos le pide a la interfaz mostrar la selección de archivos a través del explorador. Una vez el usuario selecciona un archivo, el manejador de eventos le envía el archivo al servicio para que este lo lea y lo interprete. El servicio identifica el tipo de archivo (nifti o dicom) y lo interpreta para obtener la imagen y los metadatos de la imagen. Cuando el proceso de lectura
23
empieza, el servicio le comunica a la interfaz que el archivo se está cargando. Una vez leido, la imagen y sus metadatos se presentan en la interfaz.
Figura 14. Diagrama de secuencia de importar imágenes
3.3. Implementación
La interfaz gráfica está implementada en tecnologías web HTML, CSS, TypeScript (https://www.typescriptlang.org/) y AngularJS 9 (https://angular.io/). El código fuente se puede encontrar en el repositorio de GitHub https://github.com/juancastillo0/medical-image-viewer.
TypeScript es un lenguaje de programación basado en JavaScript que provee tipado del código en tiempo de compilación. AngularJS es un framework para la implementación de “single page
24
applications” (SPA), con él implementaremos gran parte de la lógica para renderizar el HTML y CSS, basándonos en el estado de la aplicación y el manejo de interacciones del usuario. La aplicación usa las herramientas primitivas provistas por Angular para suscribir la interfaz a los cambiar de estado de la aplicación como respuesta a interacciones de usuario o eventos externos.
Los componentes de interfaz se comunican con los distintos servicios mediante llamados a funciones o por callbacks asignados a eventos de la interfaz.
3.4. Dependencias
Usamos yarn (https://yarnpkg.com/) como manejador de dependencias, sin embargo, también es posible usar npm (https://www.npmjs.com/) para los compilar y probar el código fuente. Las principales dependencias de la aplicación se presentan a continuación con sus principales usos:
• Cornerstone
Librería principal de Cornerstone, integrar los otros paquetes de Cornerstone y provee las clases base para importar, modificar e interactuar con las imágenes.
• CornerstoneTools
Librería de herramientas para interactuar con las imágenes de Cornerstone. Por ejemplo, la herramienta de regiones de interés y las herramientas para modificar el tamaño o moverse en la imagen son basadas en esta librería. También provee funcionalidades para cambiar el estado de las distintas herramientas, lo cual resulta útil en nuestra aplicación.
• CornerstoneMath
Utilidades de Cornerstone con operaciones matemáticas.
• CornerstoneNiftiImageLoader.
Importar imágenes en formato nifti y lectura de metadatos de la imagen.
• CornerstoneWADOImageLoader
Importar imágenes en formato dicom y lectura de metadatos de la imagen.
• CornerstoneWebImageLoader
Importar imágenes en formato web como png o jpg. Usado en pruebas para la comunicación con el back, los formatos web no están soportados como formatos para importar imágenes médicas en el momento.
• Uuid
Generación de identificadores únicos. Usado en la creación de regiones de interés.
• Vega/vega-lite/vega-embed
Usado para presentar gráficos como los histogramas de comparación de regiones de interés.
• Tensorflow.js/Tensorflow.js-wasm
Operaciones matemáticas eficientes, en esta aplicación lo usamos para cambiar el tamaño de las imágenes con el backend de ejecución wasm para tener mejor desempeño.
25 3.5. Despliegue
La aplicación inicial fue generada con Angular y los comandos encontrados en la sección “scripts”
del archivo “package.json” pueden ser usados para compilar o probar la aplicación.
Como la aplicación está compuesta por archivos HTML, CSS y JavaScript, estos pueden ser desplegados en un servidor web de archivos estáticos simple, sin necesidad de un backend. La única funcionalidad que necesita del servidor backend es el registro automático. Todas las otras funcionalidades son ejecutadas en el explorador del usuario.
Usamos GitHub Pages para el despliegue de los archivos estáticos. El despliegue se realiza en cada git push a la rama “main” con un script de GitHub Actions. En el script se construyen los archivos estáticos para ambiente producción con comandos de Angular y se estos archivos se suben a la rama “gh-pages” del repositorio para ser desplegados por GitHub. La aplicación está desplegada en https://juancastillo0.github.io/medical-image-viewer/.
En el proceso de construcción de los archivos estáticos, es necesario ejecutar el script “build.js”
para realizar transformaciones necesarias para la correcta compilación. Este archivo también debe ser ejecutado cuando se actualicen las dependencias de npm localmente. Existen dos casos que requieren de la modificación de archivos de las librerías de npm a través del archivo “build.js”.
• Los archivos de distribución minificados de cornerstoneWADOImageLoader no funcionan para la aplicación de AngularJS. Por esto debemos modificar el package.json para usar los archivos no minificados encontrados en la misma carpeta de distribución de la librería.
• El paquete Emscripten no compila con la configuración de TypeScript usada. Para esto debemos declarar los tipos del módulo con una sintaxis distinta para ser reconocidos por el compilador. Además, debemos agregar el nuevo import a las librerías que dependen de este módulo. En esta aplicación, lo usamos en el backend de wasm para Tensorflow.js por esto debemos agregar la línea para importar Emscripten en Tensorflow.js.
26
4. Resultados
La herramienta se validó con la participación de personal médico que conoce el tema en cuestión y son usuarios potenciales de la aplicación. En las reuniones de validación se explicaron las distintas funcionalidades mientras se escuchaba la retroalimentación para mejorar o modificar el comportamiento de la aplicación. Se realizaron reuniones a lo largo del desarrollo del proyecto para discutir el progreso e identificar nuevos requerimientos o explorar opciones de implementación a los requerimientos propuestos en reuniones previas.
Algunos hallazgos de las reuniones de validación fueron los siguientes:
Se halló confusión sobre el significado de los colores en el mapa de color de la imagen en las regiones de interés, era necesario realizar una explicación del significado para tener un entendimiento que resulte útil para hacer una comparación de las dos imágenes.
Comentarios sobre la presentación del histograma incluyen la adición de controles para modificar la granularidad de las agrupaciones. Además, relacionado con el punto anterior, la habilidad de visualizar el mapa de color compartiendo colores con el histograma de referencia presenta una oportunidad para mejorar la visualización y el entendimiento de las métricas calculadas.
En términos generales, la herramienta cumple con los objetivos propuestos y le permite al usuario realizar comparaciones de distintas regiones de las imágenes médicas importadas. Además, implementa distintas funcionalidades como el registro automático para facilitar el uso de la aplicación y mejorar el flujo de comparación de imágenes. La aplicación web se encuentra desplegada y esta puede ejecutar todas las funcionalidades en el explorador del usuario sin componentes externos a excepción del registro automático.
Existen posibilidades para mejorar y agregar extensiones y nuevas funcionalidades, esto se discutirá en la siguiente sección.
27
5. Conclusiones y trabajo futuro
En términos generales, los objetivos propuestos se cumplieron y se validaron con el personal médico a través del desarrollo del proyecto.
La interfaz web y el servidor backend cumplen con las funcionalidades propuestas. El usuario puede importar dos imágenes de resonancia en tiempos distintos y transformar las imágenes para ponerlas en correspondencia. La herramienta le permite la comparación de regiones de interés a partir de diferentes estimadores como el promedio, la desviación, y el histograma de intensidades y diferencias, junto con el área calculada para la región.
La aplicación le provee al usuario herramientas para la comparación cuantitativa de imágenes médicas. La infraestructura desarrollada puede ser extendida para soportar otras herramientas o funcionalidades. Un ejemplo de esto es la segmentación automática de regiones de interés o acceso a imágenes a través de un servicio web que las exponga.
Como trabajo futuro, algunas funcionalidades, nuevas integración y buenas prácticas de desarrollo de software pueden ser implementadas. Nuevas funcionalidades que pueden ser interesantes para implementar en trabajos futuros son las siguientes:
• Importar imágenes desde servicios que expongan las imágenes médicas a través de un api web. El servicio puede estar desplegado localmente en la máquina del usuario o en otro servidor externo. Esto facilitaría la importación y selección de las imágenes médicas. En el momento, el usuario debe tener las imágenes localmente y seleccionarlas, una por una, desde su sistema de archivos.
• Segmentación automática de regiones de interés. Esto permitiría automatizar gran parte de las operaciones manuales necesarias para usar la herramienta. Con la segmentación automática, el usuario importaría las imágenes, se realizaría el registro y luego se segmentarían las regiones de interés, todo automáticamente. Con las regiones de interés en la aplicación, el usuario puede comparar las imágenes a través de las estadísticas y visualizaciones.
• Exportar las regiones de interés como un archivo. Esto puede ser útil para compartir las regiones de interés, no perder el trabajo realizado para obtenerlas o para usarlas en herramientas externas. Otra opción es guardarlas localmente en el explorador con herramientas como IndexedDB.
• Mejorar la visualización de las imágenes al permitir al usuario configurar la interfaz. Hacer que las secciones de interfaz se puedan cambiar de tamaño, tener la opción de presentar las imágenes en pantalla completa, habilidad de escoger el color principal de la interfaz (modo oscuro).
28
• El histograma de diferencia de intensidades podría permitirle al usuario seleccionar el rango para realizar el agrupamiento y también sincronizar el color de las barras con el mapa de color de la imagen para tener la correspondencia visual con la magnitud de las diferencias.
• Implementar aplicación de escritorio. Existen herramientas como ElectronJS que permiten compartir partes del código entre la implementación web y escritorio. Otra alternativa es implementar la aplicación como una PWA. Sin embargo, el principal beneficio de implementar la aplicación de escritorio es el acceso al sistema de archivos, lo cual no es posible en todos los exploradores mediante PWA u otras apis.
Algunas prácticas que pueden mejorar:
• Implementación de pruebas de software. Pruebas unitarias, de interfaz y de integración mejorarían la estabilidad de las funcionalidades, permitirían tener más confianza en la aplicación y facilitaría la adición o modificación de funcionalidades. Además, permitiría la identificación de errores y los pasos para replicarlos.
• Documentación del código fuente. En el momento hay comentarios para secciones complejas o que pueden resultar difíciles de seguir, sin embargo, esto puede mejorar y extenderse a la mayoría de las secciones de código.
• División de las responsabilidades de interfaz. La aplicación tiene la mayoría de la lógica de la interfaz en un solo componente a pesar de que existen varias funcionalidades en la aplicación. Esta clase se puede separar en componentes de interfaz específicos para mejorar la mantenibilidad, la facilidad de entendimiento del código y disminuir las dependencias innecesarias.
29
6. Referencias
Bernal-Rusiel, Jorge L., et al. "Reusable Client-Side JavaScript Modules for Immersive Web- Based Real-Time Collaborative Neuroimage Visualization." Frontiers in
Neuroinformatics (2017). <https://github.com/FNNDSC/ami>.
BrainBrowser Contributors. "BrainBrowser. Web-based visualization tools for neurological data." 2019. <https://github.com/aces/brainbrowser>.
Cornerstone contributors. CornerstoneJS. n.d. <https://docs.cornerstonejs.org/>.
Gaillard, Assoc Prof Frank. "RANO criteria for glioblastoma." 2021. 2021.
<https://radiopaedia.org/articles/rano-criteria-for-glioblastoma?lang=us>.
Open Health Imaging Foundation. OHIF Viewer. 2017. 2021. <https://ohif.org/>.
Rock, Dr Patrick and Dr Mohammad Taghi Niknejad. "Apparent diffusion coefficient." 2021.
2021. <https://radiopaedia.org/articles/apparent-diffusion-coefficient-1?lang=us>.
Thust MD, Stefanie C., Martin J. van den Bent MD PhD and Marion Smits MD PhD.
"Pseudoprogression of brain tumors." Journal of magnetic resonance imaging : JMRI (2018): 571–589.
UMass Boston . "AMI Medical Imaging (AMI) JS ToolKi." 2019. 2021.
<https://github.com/FNNDSC/ami>.
UMass Boston. The X Toolkit: WebGL™ for Scientific Visualization. 2019.
<https://github.com/xtk/X/>.
Villanueva-Meyer, Javier E, Marc C Mabray and Soonmee Cha. "Current Clinical Brain Tumor Imaging." Neurosurgery (2017): 397-415.
