{"id":54891,"date":"2020-03-30T10:28:38","date_gmt":"2020-03-30T08:28:38","guid":{"rendered":"https:\/\/www.revista-portalesmedicos.com\/revista-medica\/?p=54891"},"modified":"2024-02-19T10:47:10","modified_gmt":"2024-02-19T09:47:10","slug":"verificacion-semanal-de-las-hojas-de-tratamientos-de-radioterapia-externa-mediante-el-uso-de-logfiles","status":"publish","type":"post","link":"https:\/\/www.revista-portalesmedicos.com\/revista-medica\/verificacion-semanal-de-las-hojas-de-tratamientos-de-radioterapia-externa-mediante-el-uso-de-logfiles\/","title":{"rendered":"Verificaci\u00f3n semanal de las hojas de tratamientos de radioterapia externa mediante el uso de logfiles"},"content":{"rendered":"

Verificaci\u00f3n semanal de las hojas de tratamientos de radioterapia externa mediante el uso de logfiles<\/strong><\/p>\n

\u00a0Seg\u00fan el Real Decreto 1566\/1998, de 17 de julio, \u201cpor el que se establecen los criterios de calidad en radioterapia, es necesario realizar una revisi\u00f3n semanal de las hojas de tratamiento\u201d. <\/p>\n

Alejandro Barranco L\u00f3pez1<\/sup>, Luis Sope\u00f1a Sanz2<\/sup>, \u00c1lvaro Boria Alegre3<\/sup>, y Daniel Nogueira Souto4<\/sup><\/p>\n

1<\/sup>Facultativo Especialista de \u00c1rea de Radiof\u00edsica Hospitalaria. PhD en F\u00edsica, MSc en Astrof\u00edsica, F\u00edsica de Part\u00edculas y Cosmolog\u00eda. Lugar de trabajo: H.C.U. Lozano Blesa (Zaragoza).<\/p>\n

2<\/sup>Facultativo Especialista de \u00c1rea de Oncolog\u00eda Radioter\u00e1pica. M\u00e1ster Internacional de Oncolog\u00eda Cl\u00ednica. M\u00e1ster en Radiocirug\u00eda y Radioterapia Estereot\u00e1xica. M\u00e1ster en Oncolog\u00eda Intervencionista. Lugar de trabajo: H.C.U. Lozano Blesa (Zaragoza).<\/p>\n

3<\/sup>Facultativo Especialista de \u00c1rea de Radiodiagn\u00f3stico. M\u00e1ster en Iniciaci\u00f3n a la Investigaci\u00f3n en Medicina. Lugar de trabajo: Hospital San Jorge (Huesca).<\/p>\n

4<\/sup>M\u00e9dico Interno Residente de Medicina Nuclear. Lugar de trabajo: H.C.U. Lozano Blesa (Zaragoza).<\/p>\n

30\/03\/20<\/p>\n

Resumen<\/strong><\/p>\n

\u00a0Seg\u00fan el Real Decreto 1566\/1998, de 17 de julio, \u201cpor el que se establecen los criterios de calidad en radioterapia, es necesario realizar una revisi\u00f3n semanal de las hojas de tratamiento\u201d. Mostramos aqu\u00ed unos programas realizados en Python que facilitan dicha revisi\u00f3n mediante la automatizaci\u00f3n de la comprobaci\u00f3n de las unidades monitor impartidas en los tratamientos de radioterapia externa. Esta comprobaci\u00f3n se hace generando una base de datos con la informaci\u00f3n recogida en forma de logfiles<\/em> por aceleradores lineales de electrones Truebeam y la que procede del sistema de planifiaci\u00f3n de tratamiento Eclipse.<\/p>\n

Palabras clave\u00a0\u2014<\/strong> logfiles, revisi\u00f3n semanal, radioterapia.<\/p>\n

Abstract<\/p>\n

\u00a0According to the Spanish Royal Decree 1566\/1998, 17 july, \u201cwhich establishes the quality criteria in radiotherapy, it is necessary to carry out a weekly revision of treatment sheets\u201d. 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.<\/p>\n

Key words\u00a0\u2014<\/strong> logfiles, weekly revision, radiotherapy.<\/p>\n

1\u00a0 Introducci\u00f3n<\/p>\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\u00f3n semanal por parte del m\u00e9dico y del radiof\u00edsico de las hojas de tratamiento. Estas hojas de tratamiento deben incluir, seg\u00fan el art\u00edculo 7 del mencionado Real Decreto:<\/p>\n

    \n
  1. a) \u201cIdentificaci\u00f3n del paciente\u201d.<\/li>\n
  2. b) \u201cElementos descriptivos suficientes sobre la enfermedad que se va a tratar\u201d.<\/li>\n
  3. c) \u201cDecisi\u00f3n terap\u00e9utica con la descripci\u00f3n de los vol\u00famenes relacionados con el tratamiento, dosis absorbida a administrar, par\u00e1metros cl\u00ednicos de irradiaci\u00f3n y elementos de comprobaci\u00f3n, as\u00ed como la dosis absorbida m\u00e1xima en los \u00f3rganos cr\u00edticos\u201d.<\/li>\n
  4. d) \u201cEsquema de tratamiento previsto y dosimetr\u00eda cl\u00ednica establecida correspondiente a la decisi\u00f3n terap\u00e9utica del apartado anterior\u201d.<\/li>\n
  5. e) \u201cDatos necesarios del informe dosim\u00e9trico\u201d.<\/li>\n
  6. f) \u201cTodos los datos complementarios y relaci\u00f3n de elementos auxiliares que permitan la reproducibilidad del tratamiento\u201d.<\/li>\n<\/ol>\n

    Obviamente, con los modernos sistemas de registro y verificaci\u00f3n, estas hojas f\u00edsicas han sido sustituidas por sistemas electr\u00f3nicos, donde se almacenan gran cantidad de datos, m\u00e1s all\u00e1 de los que recoge el Real Decreto, pero que, ateni\u00e9ndonos 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\u00e9s de la informaci\u00f3n recogida en los logfiles<\/em> de los aceleradores l\u00edneales de electrones, en contraste con la que procede del sistema de planificaci\u00f3n, mediante el uso de programas escritos en Python y de herramientas similares a las explicadas en [2-4].<\/p>\n

    2\u00a0 Material<\/strong><\/p>\n

    Las herramientas que se han empleado en este trabajo son:<\/p>\n

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

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

    pylinac:<\/strong> Python dispone de la biblioteca pylinac [7] cuyo prop\u00f3sito principal es el an\u00e1lisis de pruebas de control de calidad propuestas en el TG-142 [8]. Esta biblioteca dispone de gran cantidad de m\u00f3dulos, pero para lo que nos ocupa s\u00f3lo hemos hecho uso del m\u00f3dulo de an\u00e1lisis de logfiles<\/em>. Con este m\u00f3dulo podemos leer logfiles<\/em> y comparar las posiciones de los ejes o unidades monitor registradas con las esperadas. Realmente s\u00f3lo lo hemos usado para obtener el n\u00famero de unidades monitor impartidas seg\u00fan se recogen en los logfiles<\/em>. Hemos trabajado con la versi\u00f3n 2.2.7.<\/p>\n

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

    SQLite:<\/strong> SQL (Structured Query Language, por sus siglas en ingl\u00e9s) o lenguaje de consulta estructurada es un lenguaje para la creaci\u00f3n, la administraci\u00f3n y la gesti\u00f3n, as\u00ed como la recuperaci\u00f3n de informaci\u00f3n de bases de datos de tipo relacional. Hemos trabajado con la implementaci\u00f3n de SQL, SQLite [10], de dominio p\u00fablico y que, a diferencia de otros sistemas de gesti\u00f3n de bases de datos basados en la relaci\u00f3n cliente-servidor, como por ejemplo Microsof SQL Server, SQLite est\u00e1 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\u00f3n 3.29.0) hemos hecho uso de la biblioteca sqlite3, versi\u00f3n 2.6.0 [11]. Hemos usado esta biblioteca para crear una base de datos, que rellenamos con los datos obtenidos de los logfiles<\/em> y del sistema de planificaci\u00f3n de tratamientos Eclipse, y para realizar las consultas que alerten en el caso de discrepancias entre las unidades monitor impartidas y las planificadas.<\/p>\n

    3\u00a0 M\u00e9todo<\/strong><\/p>\n

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

    3.1\u00a0 CreateDatabase.py<\/h3>\n

    En primer lugar, para crear la base de datos, hay que importar la biblioteca sqlite3 (l\u00ednea\u00a01 de la figura\u00a0Error: no se encontr\u00f3 el origen de la referencia), y crear una conexi\u00f3n con la base de datos (l\u00ednea\u00a0Error: no se encontr\u00f3 el origen de la referencia), que en este caso se llamar\u00e1 database.db y se generar\u00e1 en el directorio de trabajo. Con las l\u00edneas\u00a0Error: no se encontr\u00f3 el origen de la referencia-Error: no se encontr\u00f3 el origen de la referencia creamos las tablas Logfiles y Eclipse y con el resto de c\u00f3digo de las figuras\u00a0Error: no se encontr\u00f3 el origen de la referencia y Error: no se encontr\u00f3 el origen de la referencia las poblamos. Las tablas en cuesti\u00f3n se explican a continuaci\u00f3n:<\/p>\n

    Tabla Logfiles:<\/strong> Las columnas de esta tabla se pueden ver en el cuadro\u00a01.<\/p>\n

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

    Las columnas AR, Plan, Beam y Date se obtienen del nombre del archivo del logfile<\/em>, ya que este es una concatenaci\u00f3n de dichos atributos. Sin embargo, como el nombre de los logfiles<\/em> se genera concatenando los elementos anteriores uni\u00e9ndolos con el s\u00edmbolo \u201c_\u201d, si alguno de los elementos concatenados contiene dicho s\u00edmbolo, por ejemplo, un plan que se llamara \u201cPlan_Prostata\u201d, ser\u00eda bastante dif\u00edcil determinar si el gui\u00f3n bajo que une \u201cPlan\u201d y \u201cProstata\u201d 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\u00f3n recogida en la tabla Eclipse, y se comparan los nombres de los atributos recogidos en dicha tabla con el nombre del archivo del logfile<\/em> (l\u00edneas\u00a0Error: no se encontr\u00f3 el origen de la referencia-Error: no se encontr\u00f3 el origen de la referencia de la figura\u00a0Error: no se encontr\u00f3 el origen de la referencia).<\/p>\n

    Tabla Eclipse:<\/strong> Su estructura puede observarse en el cuadro\u00a02. Esta tabla es similar a la anterior pero se nutre de los valores almacenados en el sistema de planificaci\u00f3n Eclipse. En particular, se buscan para cada paciente que aparece en la tabla Logfiles (l\u00ednea\u00a0Error: no se encontr\u00f3 el origen de la referencia), que cursos est\u00e1n activos (l\u00ednea\u00a0Error: no se encontr\u00f3 el origen de la referencia), y de estos se obtienen los planes, campos, etc. para rellenar la tabla Eclipse (l\u00edneas\u00a0Error: no se encontr\u00f3 el origen de la referencia-Error: no se encontr\u00f3 el origen de la referencia de la figura\u00a0Error: no se encontr\u00f3 el origen de la referencia).<\/p>\n

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

    3.2\u00a0 ReadDatabase.py<\/h3>\n

    En las figuras\u00a0Error: no se encontr\u00f3 el origen de la referencia y Error: no se encontr\u00f3 el origen de la referencia aparece el c\u00f3digo correspondiente al programa ReadDatabase.py, donde se manipula la informaci\u00f3n y se realizan las consultas a la base de datos database.db creada con anterioridad.<\/p>\n

    En la figura\u00a0Error: no se encontr\u00f3 el origen de la referencia, se realiza una consulta (l\u00edneas\u00a0Error: no se encontr\u00f3 el origen de la referencia-Error: no se encontr\u00f3 el origen de la referencia), de nuevo, tras importar la biblioteca sqlite3 y crear una conexi\u00f3n con la base de datos database.db, en la que se seleccionan los pacientes para los que se ha generado alg\u00fan logfile<\/em> con fecha incluida la semana anterior al momento de la ejecuci\u00f3n del programa. Para dicha consulta se ha hecho uso de la funci\u00f3n lastWeek (l\u00edneas\u00a03-Error: no se encontr\u00f3 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\u00edas de la semana anterior. Realmente, esta parte podr\u00eda omitirse para realizar una consulta global sobre todos los logfiles<\/em> encontrados, pero al pretender realizar una revisi\u00f3n semanal se ha incluido.<\/p>\n

    Posteriormente, en la figura\u00a0Error: no se encontr\u00f3 el origen de la referencia se ejecuta en SQL una expresi\u00f3n para crear una view<\/em> 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\u00a03.<\/p>\n

    Finalmente, para los pacientes encontrados en la consulta de la figura\u00a0Error: no se encontr\u00f3 el origen de la referencia, se realiza una nueva consulta (l\u00edneas\u00a0Error: no se encontr\u00f3 el origen de la referencia-Error: no se encontr\u00f3 el origen de la referencia de la figura\u00a0Error: no se encontr\u00f3 el origen de la referencia) en la que se obteniene como resultado los siguientes atributos:<\/p>\n

      \n
    • AR<\/li>\n
    • Date<\/li>\n
    • Beam<\/li>\n
    • DeliveredMU<\/li>\n
    • ExpectedMU<\/li>\n
    • DeliveredAcumDay<\/li>\n
    • SessionsPerDay * ExpectedMU<\/li>\n
    • DeliveredAcum<\/li>\n
    • Sessions * ExpectedMU<\/li>\n<\/ul>\n

      cuando las unidades monitor impartidas en el tratamiento, DeliveredMU, no coincidan con las esperadas seg\u00fan el sistema de planificaci\u00f3n, ExpectedMU; o se superen los l\u00edmites de unidades monitor diarios o totales. Cada entrada en el resultado de esta consulta ya nos alertar\u00eda de que algo puede que no haya ido como se esperaba, pero para hacerlo m\u00e1s legible, en las l\u00edneas\u00a0Error: no se encontr\u00f3 el origen de la referencia-Error: no se encontr\u00f3 el origen de la referencia se le da formato a este resultado y se imprime por consola.<\/p>\n

      4\u00a0 Discusi\u00f3n<\/strong><\/p>\n

      Al aplicar los programas anteriores vamos a obtener un gran n\u00famero de falsos positivos debido a la estructura que siguen los logfiles<\/em> y que mayoritariamente se deben a paradas en alg\u00fan 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\u00e1s tarde el tratamiento, dando las unidades monitor faltantes correspondientes al primer campo y todas las unidades del segundo campo, que no se hab\u00eda tratado inicialmente. En ese caso se generar\u00e1n dos logfiles<\/em>, uno que contendr\u00e1 a los dos subcampos con las unidades monitor impartidas (iguales a las planificadas, puesto que, al final, los dos campos s\u00ed se han tratado) y otro con las unidades monitor \u00fanicamente dadas en la reanudaci\u00f3n. Por tanto, el atributo ExpectedAcumDay parecer\u00e1 que supera el l\u00edmite diario de unidades monitor establecido.<\/p>\n

      Obviamente, los programas aqu\u00ed presentados se podr\u00edan refinar para distinguir estos casos, pero por simplicidad se ha preferido dejarlo as\u00ed, adem\u00e1s 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\u00f3n qu\u00e9 es lo que ha ocurrido con m\u00e1s detalle.<\/p>\n

      5\u00a0 Conclusiones<\/strong><\/p>\n

      Se ha mostrado en este trabajo c\u00f3mo, haciendo uso de herramientas similares a las presentadas en los trabajos [2-4], se puede automatizar o facilitar el proceso de revisi\u00f3n 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\u00f3n de las unidades monitor impartidas en los tratamientos de radioterapia externa.<\/p>\n

      Por supuesto estos programas se pueden expandir para verificar otros par\u00e1metros y, desde luego, discriminar en el propio programa los casos en los que se trata de una simple interrupci\u00f3n del tratamiento sin mayor importancia de los que no.<\/p>\n