Verificación semanal de las hojas de tratamientos de radioterapia externa mediante el uso de logfiles

Verificación semanal de las hojas de tratamientos de radioterapia externa mediante el uso de logfiles

Según el Real Decreto 1566/1998, de 17 de julio, “por el que se establecen los criterios de calidad en radioterapia, es necesario realizar una revisión semanal de las hojas de tratamiento”.

Alejandro Barranco López¹, Luis Sopeña Sanz², Álvaro Boria Alegre³, y Daniel Nogueira Souto⁴

¹Facultativo Especialista de Área de Radiofísica Hospitalaria. PhD en Física, MSc en Astrofísica, Física de Partículas y Cosmología. Lugar de trabajo: H.C.U. Lozano Blesa (Zaragoza).

²Facultativo Especialista de Área de Oncología Radioterápica. Máster Internacional de Oncología Clínica. Máster en Radiocirugía y Radioterapia Estereotáxica. Máster en Oncología Intervencionista. Lugar de trabajo: H.C.U. Lozano Blesa (Zaragoza).

³Facultativo Especialista de Área de Radiodiagnóstico. Máster en Iniciación a la Investigación en Medicina. Lugar de trabajo: Hospital San Jorge (Huesca).

⁴Médico Interno Residente de Medicina Nuclear. Lugar de trabajo: H.C.U. Lozano Blesa (Zaragoza).

30/03/20

Resumen

Según el Real Decreto 1566/1998, de 17 de julio, “por el que se establecen los criterios de calidad en radioterapia, es necesario realizar una revisión semanal de las hojas de tratamiento”. Mostramos aquí unos programas realizados en Python que facilitan dicha revisión mediante la automatización de la comprobación de las unidades monitor impartidas en los tratamientos de radioterapia externa. Esta comprobación se hace generando una base de datos con la información recogida en forma de logfiles por aceleradores lineales de electrones Truebeam y la que procede del sistema de planifiación de tratamiento Eclipse.

Palabras clave — logfiles, revisión semanal, radioterapia.

Abstract

According to the Spanish Royal Decree 1566/1998, 17 july, “which establishes the quality criteria in radiotherapy, it is necessary to carry out a weekly revision of treatment sheets”. Here we show some Python programs that facilitate this revision by automating the checking of monitor units given in external radiotherapy treatments. This check is done by generating a database with the information collected in the form of logfiles by Truebeam electron linear acceleratos and that information coming from the Eclipse treatment planification system.

Key words — logfiles, weekly revision, radiotherapy.

1 Introducción

El Real Decreto 1566/1998, de 17 de julio [1], por el que se establecen los criterios de calidad en radioterapia, establece en su anexo III la necesidad de realizar una revisión semanal por parte del médico y del radiofísico de las hojas de tratamiento. Estas hojas de tratamiento deben incluir, según el artículo 7 del mencionado Real Decreto:

a) “Identificación del paciente”.
b) “Elementos descriptivos suficientes sobre la enfermedad que se va a tratar”.
c) “Decisión terapéutica con la descripción de los volúmenes relacionados con el tratamiento, dosis absorbida a administrar, parámetros clínicos de irradiación y elementos de comprobación, así como la dosis absorbida máxima en los órganos críticos”.
d) “Esquema de tratamiento previsto y dosimetría clínica establecida correspondiente a la decisión terapéutica del apartado anterior”.
e) “Datos necesarios del informe dosimétrico”.
f) “Todos los datos complementarios y relación de elementos auxiliares que permitan la reproducibilidad del tratamiento”.

Obviamente, con los modernos sistemas de registro y verificación, estas hojas físicas han sido sustituidas por sistemas electrónicos, donde se almacenan gran cantidad de datos, más allá de los que recoge el Real Decreto, pero que, ateniéndonos a este, hay que revisar semanalmente. En particular, en este trabajo presentamos una manera de revisar las unidades monitor impartidas en los tratamientos de radioterapia externa a través de la información recogida en los logfiles de los aceleradores líneales de electrones, en contraste con la que procede del sistema de planificación, mediante el uso de programas escritos en Python y de herramientas similares a las explicadas en [2-4].

2 Material

Las herramientas que se han empleado en este trabajo son:

Logfiles: En los aceleradores lineales de electrones usados en radioterapia externa se generan una serie de archivos, logfiles, que recogen el desempeño del acelerador a la hora de impartir el tratamiento. En particular, hemos trabajado con los logfiles generados por un acelerador Truebeam SVC de Varian Medical Systems. Los logfiles generados por dicho acelerador recogen la posición de los diferentes ejes (gantry, colimador, posiciones de las láminas del colimador y camilla) y las unidades monitor impartidas para cada muestra tomada o snapshot, entre otros datos [5]. Nosotros hemos usado la información acerca de las unidades monitor impartidas para contrastarla con la planificada (que se obtiene del sistema de planificación de tratamiento Eclipse versión 15.6, también de Varian Medical Systems) y generar una alerta en el caso de que no concuerden.

Python: Python es un lenguaje de programación interpretado de alto nivel y de propósito general [6]. Hemos trabajado con la versión 3.6.4. En este lenguaje de programación se han escrito dos programas, haciendo uso de las bibliotecas o módulos que se describen a continuación, con el fin de automatizar la generación de alertas a la hora de comparar las unidades monitor impartidas en los tratamientos de radioterapia externa con las unidades monitor planificadas.

pylinac: Python dispone de la biblioteca pylinac [7] cuyo propósito principal es el análisis de pruebas de control de calidad propuestas en el TG-142 [8]. Esta biblioteca dispone de gran cantidad de módulos, pero para lo que nos ocupa sólo hemos hecho uso del módulo de análisis de logfiles. Con este módulo podemos leer logfiles y comparar las posiciones de los ejes o unidades monitor registradas con las esperadas. Realmente sólo lo hemos usado para obtener el número de unidades monitor impartidas según se recogen en los logfiles. Hemos trabajado con la versión 2.2.7.

pyesapi: Otra biblioteca de Python que hemos usado es pyesapi, en su versión 0.2.1 [9]. Esta biblioteca es una interfaz para Python de ESAPI, la interfaz de programación de aplicaciones de Eclipse (originalmente desarrollada para C#.NET), que permite acceder a la información contenida en el sistema de planificación Eclipse.

SQLite: SQL (Structured Query Language, por sus siglas en inglés) o lenguaje de consulta estructurada es un lenguaje para la creación, la administración y la gestión, así como la recuperación de información de bases de datos de tipo relacional. Hemos trabajado con la implementación de SQL, SQLite [10], de dominio público y que, a diferencia de otros sistemas de gestión de bases de datos basados en la relación cliente-servidor, como por ejemplo Microsof SQL Server, SQLite está programado para que los procesos que quieran acceder a la base de datos lean o escriban directamente en los archivos de dicha base de datos localmente. Para trabajar con SQLite en Python (versión 3.29.0) hemos hecho uso de la biblioteca sqlite3, versión 2.6.0 [11]. Hemos usado esta biblioteca para crear una base de datos, que rellenamos con los datos obtenidos de los logfiles y del sistema de planificación de tratamientos Eclipse, y para realizar las consultas que alerten en el caso de discrepancias entre las unidades monitor impartidas y las planificadas.

3 Método

Con las herramientas mencionadas en la sección anterior hemos construido una base de datos muy sencilla, compuesta de dos tablas, que se explican más adelante. En conjunto, se han creado dos programas, uno que crea la base de datos, que hemos llamado CreateDatabase.py (figuras Error: no se encontró el origen de la referencia y Error: no se encontró el origen de la referencia), y otro para realizar las consultas sobre la base de datos creada, llamado ReadDatabase.py (figuras Error: no se encontró el origen de la referencia y Error: no se encontró el origen de la referencia). Explicamos estos programas en las siguientes secciones.

3.1 CreateDatabase.py

En primer lugar, para crear la base de datos, hay que importar la biblioteca sqlite3 (línea 1 de la figura Error: no se encontró el origen de la referencia), y crear una conexión con la base de datos (línea Error: no se encontró el origen de la referencia), que en este caso se llamará database.db y se generará en el directorio de trabajo. Con las líneas Error: no se encontró el origen de la referencia-Error: no se encontró el origen de la referencia creamos las tablas Logfiles y Eclipse y con el resto de código de las figuras Error: no se encontró el origen de la referencia y Error: no se encontró el origen de la referencia las poblamos. Las tablas en cuestión se explican a continuación:

Tabla Logfiles: Las columnas de esta tabla se pueden ver en el cuadro 1.

Cada entrada de esta tabla corresponde a la información contenida en cada logfile para cada campo tratado. En ocasiones, los campos que constituyen el tratamiento se tratan en autosecuencia, de forma que se genera un único logfile para todos los campos que componen la autosecuencia, y estos aparecen dentro del logfile en forma de subbeams o subcampos. En ese caso, cada subcampo de la autosecuencia se separa de forma que cada uno tenga su entrada independiente en la tabla.

Las columnas AR, Plan, Beam y Date se obtienen del nombre del archivo del logfile, ya que este es una concatenación de dichos atributos. Sin embargo, como el nombre de los logfiles se genera concatenando los elementos anteriores uniéndolos con el símbolo “_”, si alguno de los elementos concatenados contiene dicho símbolo, por ejemplo, un plan que se llamara “Plan_Prostata”, sería bastante difícil determinar si el guión bajo que une “Plan” y “Prostata” es un separador o forma parte del nombre de alguno de los atributos, en este caso de Plan o de Beam. Para solucionarlo se hace uso de la información recogida en la tabla Eclipse, y se comparan los nombres de los atributos recogidos en dicha tabla con el nombre del archivo del logfile (líneas Error: no se encontró el origen de la referencia-Error: no se encontró el origen de la referencia de la figura Error: no se encontró el origen de la referencia).

Tabla Eclipse: Su estructura puede observarse en el cuadro 2. Esta tabla es similar a la anterior pero se nutre de los valores almacenados en el sistema de planificación Eclipse. En particular, se buscan para cada paciente que aparece en la tabla Logfiles (línea Error: no se encontró el origen de la referencia), que cursos están activos (línea Error: no se encontró el origen de la referencia), y de estos se obtienen los planes, campos, etc. para rellenar la tabla Eclipse (líneas Error: no se encontró el origen de la referencia-Error: no se encontró el origen de la referencia de la figura Error: no se encontró el origen de la referencia).

Como para poblar esta tabla es necesario acceder a los datos de Eclipse, hay que importar antes la biblioteca pyesapi (línea 2 de la figura Error: no se encontró el origen de la referencia) y hacer uso de la función de dicha biblioteca que aparece en la línea Error: no se encontró el origen de la referencia, así como devolver los recursos cuando ya no se vayan a usar, con la expresión de la línea Error: no se encontró el origen de la referencia.

3.2 ReadDatabase.py

En las figuras Error: no se encontró el origen de la referencia y Error: no se encontró el origen de la referencia aparece el código correspondiente al programa ReadDatabase.py, donde se manipula la información y se realizan las consultas a la base de datos database.db creada con anterioridad.

En la figura Error: no se encontró el origen de la referencia, se realiza una consulta (líneas Error: no se encontró el origen de la referencia-Error: no se encontró el origen de la referencia), de nuevo, tras importar la biblioteca sqlite3 y crear una conexión con la base de datos database.db, en la que se seleccionan los pacientes para los que se ha generado algún logfile con fecha incluida la semana anterior al momento de la ejecución del programa. Para dicha consulta se ha hecho uso de la función lastWeek (líneas 3-Error: no se encontró el origen de la referencia), que dada una fecha (o si no, toma por defecto la fecha actual), devuelve una lista con las fechas de los días de la semana anterior. Realmente, esta parte podría omitirse para realizar una consulta global sobre todos los logfiles encontrados, pero al pretender realizar una revisión semanal se ha incluido.

Posteriormente, en la figura Error: no se encontró el origen de la referencia se ejecuta en SQL una expresión para crear una view o vista a modo de tabla virtual sobre la que posteriormente realizaremos consultas. Esta nueva tabla, llamada v_Logfiles, unifica las dos tablas de la base de datos database.db y su estructura se puede consultar en el cuadro 3.

Finalmente, para los pacientes encontrados en la consulta de la figura Error: no se encontró el origen de la referencia, se realiza una nueva consulta (líneas Error: no se encontró el origen de la referencia-Error: no se encontró el origen de la referencia de la figura Error: no se encontró el origen de la referencia) en la que se obteniene como resultado los siguientes atributos:

AR
Date
Beam
DeliveredMU
ExpectedMU
DeliveredAcumDay
SessionsPerDay * ExpectedMU
DeliveredAcum
Sessions * ExpectedMU

cuando las unidades monitor impartidas en el tratamiento, DeliveredMU, no coincidan con las esperadas según el sistema de planificación, ExpectedMU; o se superen los límites de unidades monitor diarios o totales. Cada entrada en el resultado de esta consulta ya nos alertaría de que algo puede que no haya ido como se esperaba, pero para hacerlo más legible, en las líneas Error: no se encontró el origen de la referencia-Error: no se encontró el origen de la referencia se le da formato a este resultado y se imprime por consola.

4 Discusión

Al aplicar los programas anteriores vamos a obtener un gran número de falsos positivos debido a la estructura que siguen los logfiles y que mayoritariamente se deben a paradas en algún campo de tratamiento. Supongamos un tratamiento con dos campos, que se haya automatizado y que en el primero de ellos haya sufrido una parada, de forma que se complete más tarde el tratamiento, dando las unidades monitor faltantes correspondientes al primer campo y todas las unidades del segundo campo, que no se había tratado inicialmente. En ese caso se generarán dos logfiles, uno que contendrá a los dos subcampos con las unidades monitor impartidas (iguales a las planificadas, puesto que, al final, los dos campos sí se han tratado) y otro con las unidades monitor únicamente dadas en la reanudación. Por tanto, el atributo ExpectedAcumDay parecerá que supera el límite diario de unidades monitor establecido.

Obviamente, los programas aquí presentados se podrían refinar para distinguir estos casos, pero por simplicidad se ha preferido dejarlo así, además de que de esta manera obtenemos alertas de los tratamientos que han sufrido interrupciones. Una vez obtenidas las alertas se puede consultar en el sistema de registro y verificación qué es lo que ha ocurrido con más detalle.

5 Conclusiones

Se ha mostrado en este trabajo cómo, haciendo uso de herramientas similares a las presentadas en los trabajos [2-4], se puede automatizar o facilitar el proceso de revisión de las hojas de tratamiento que recoge el Real Decreto 1566/1998, de 17 de julio, por lo menos en lo referente a la comprobación de las unidades monitor impartidas en los tratamientos de radioterapia externa.

Por supuesto estos programas se pueden expandir para verificar otros parámetros y, desde luego, discriminar en el propio programa los casos en los que se trata de una simple interrupción del tratamiento sin mayor importancia de los que no.

uso-de-logfiles

Referencias

[1] Ministerio de Sanidad y Consumo. Real Decreto 1566/1998, de 17 de julio, por el que se establecen los criterios de calidad en radioterapia. 1998.

[2] A. Barranco López, L. Sopeña Sanz, D. Nogueira Souto y A. Boria Alegre. Eclipse Scripting API, Pylinac y ARIA en una sola plataforma. Revista Electrónica de PortalesMedicos.com (en prensa).

[3] A. Barranco López D. Nogueira Souto, A. Boria Alegre y L. Sopeña Sanz. Un ejemplo de aplicación de Eclipse Scripting API para la automatización en la verificación de planificaciones de radioterapia. Revista Electrónica de PortalesMedicos.com (en prensa).

[4] A. Barranco López, A. Boria Alegre, L. Sopeña Sanz y D. Nogueira Souto. Solución de un error de importación de ARIA mediante el uso de pydicom. Revista Electrónica de PortalesMedicos.com (en prensa).

[5] Varian Medical Systems. Truebeam trajectory log file specification. 2011.

[6] Python Software Foundation. Recuperado en febrero de 2020 de https://www.python.org/.

[7] James Kerns. pylinac. Recuperado en febrero de 2020 de https://pylinac.readthedocs.io/en/stable/.

[8] E. E. Klein, J. Hanley, J. Bayouth et al. Task Group 142 report: Quality assurance of medical accelerators. Am. Assoc. Phys. Med, 2009.

[9] Michael Folkerts. pyesapi. Recuperado en febrero de 2020 de https://github.com/VarianAPIs/PyESAPI.

[10] SQLite. Recuperado en febrero de 2020 de https://sqlite.org/index.html.

[11] Gerhard Häring. sqlite3. Recuperado en febrero de 2020 de https://docs.python.org/3/library/sqlite3.html.