{"id":54942,"date":"2020-03-30T12:14:30","date_gmt":"2020-03-30T10:14:30","guid":{"rendered":"https:\/\/www.revista-portalesmedicos.com\/revista-medica\/?p=54942"},"modified":"2024-02-19T10:49:10","modified_gmt":"2024-02-19T09:49:10","slug":"un-ejemplo-de-aplicacion-de-eclipse-scripting-api-para-la-automatizacion-en-la-verificacion-de-planificaciones-de-radioterapia","status":"publish","type":"post","link":"https:\/\/www.revista-portalesmedicos.com\/revista-medica\/un-ejemplo-de-aplicacion-de-eclipse-scripting-api-para-la-automatizacion-en-la-verificacion-de-planificaciones-de-radioterapia\/","title":{"rendered":"Un ejemplo de aplicaci\u00f3n de Eclipse Scripting API para la automatizaci\u00f3n en la verificaci\u00f3n de planificaciones de radioterapia"},"content":{"rendered":"

Un ejemplo de aplicaci\u00f3n de Eclipse Scripting API para la automatizaci\u00f3n en la verificaci\u00f3n de planificaciones de radioterapia<\/strong><\/p>\n

En este trabajo se describe un programa escrito en C# que hace uso de Eclipse Scripting API<\/em> para acceder a varios datos y par\u00e1metros de una planificaci\u00f3n de radioterapia externa realizada con el sistema de planificaci\u00f3n de tratamientos Eclipse. <\/p>\n

Alejandro Barranco L\u00f3pez1<\/sup>, Daniel Nogueira Souto2<\/sup>, \u00c1lvaro Boria Alegre3<\/sup> y Luis Sope\u00f1a Sanz4<\/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). abarrancol@salud.aragon.es<\/p>\n

2<\/sup>M\u00e9dico Interno Residente de Medicina Nuclear. 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>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\/30\/20<\/p>\n

Resumen<\/p>\n

\u00a0En este trabajo se describe un programa escrito en C# que hace uso de Eclipse Scripting API<\/em> para acceder a varios datos y par\u00e1metros de una planificaci\u00f3n de radioterapia externa realizada con el sistema de planificaci\u00f3n de tratamientos Eclipse. Este programa o script<\/em> tiene como finalidad mostrar toda una colecci\u00f3n de ejemplos de los diferentes usos de la API de Eclipse. En particular, los ejemplos mostrados se usan para automatizar tareas de verificaci\u00f3n de los planes de radioterapia calculados.<\/p>\n

Palabras clave\u00a0\u2014<\/strong> ESAPI, Eclipse, radioterapia.<\/p>\n

Abstract<\/p>\n

\u00a0In this paper we describe a C# program making use of Eclipse Scripting API to access several data and parameters of an external radiotherapy planning computed with the Eclipse treatment planning system. This program or script has the aim of showing a collection of examples of different uses of the Eclipse API. In particular, the examples shown are used to automate verification tasks for the computed radiotherapy plans.<\/p>\n

Key words\u00a0\u2014<\/strong> ESAPI, Eclipse, radiotherapy.<\/p>\n

1\u00a0 Introducci\u00f3n<\/h2>\n

Actualmente, un proceso de radioterapia externa incluye una etapa de planificaci\u00f3n del tratamiento en la que se hace uso de programas de ordenador llamados sistemas de planificaci\u00f3n de tratamiento (TPS, por sus siglas en ingl\u00e9s). A esta etapa le sigue otra en la que se verifica la planificaci\u00f3n resultante, como medida de seguridad. Normalmente, la primera de estas dos etapas la suele realizar un dosimetrista y la verificaci\u00f3n la realiza un especialista en Radiof\u00edsica. Por tanto, ambas etapas est\u00e1n sujetas al error humano, aunque con la etapa de verificaci\u00f3n estos errores quedan reducidos. Sin embargo, con las herramientas de las tecnolog\u00edas de informaci\u00f3n podr\u00edamos automatizar estos procesos ahorrando tiempo y reduciendo el factor humano en los posibles errores. Por eso, en este trabajo se presenta un ejemplo de aplicaci\u00f3n de lo anterior. Muchos TPS actuales llevan incorporadas herramientas de scripting<\/em> que permiten obtener y\/o modificar informaci\u00f3n del TPS de manera program\u00e1tica. Este es el caso del sistema de planificaci\u00f3n de Varian Medical Systems, Eclipse, que incorpora una interfaz de programaci\u00f3n de aplicaciones (ESAPI, por sus siglas en ingl\u00e9s), de la que ya se ha hablado en [1]. Hemos usado, por tanto, dicha herramienta de scripting<\/em> para automatizar el proceso de verificaci\u00f3n de las planificaciones de radioterapia externa.<\/p>\n

2\u00a0 Material<\/h2>\n

Las diferentes herramientas que se han usado para este trabajo son:<\/p>\n

Sistema de Planificaci\u00f3n de Tratamientos Eclipse:<\/strong> Como ya hemos comentado, se ha hecho uso del TPS Eclipse (versi\u00f3n 15.6) de Varian Medical Systems.<\/p>\n

Interfaz de Programaci\u00f3n de Aplicaciones de Eclipse, ESAPI:<\/strong> Es el conjunto de clases, objetos, funciones\u2026del lenguaje de programaci\u00f3n C#.NET a trav\u00e9s de las cuales podemos escribir programas o scripts<\/em> para obtener o modificar informaci\u00f3n de Eclipse [2, 3]. En particular, ESAPI ofrece dos modos a la hora de utilizar los programas desarrollados con ella, de forma standalone<\/em>, lo que vendr\u00eda a ser un ejecutable individual; o integrados en la propia interfaz de Eclipse. Es en este \u00faltimo modo en el que se ha trabajado.<\/p>\n

Los scripts<\/em> que vamos a mostrar son peque\u00f1os fragmentos de c\u00f3digo y, por tanto, se pueden escribir en cualquier editor de texto, ya que al ejecutarlos desde la propia interfaz de Eclipse no necesitan ser compilados. No obstante, cualquier entorno de desarrollo integrado (IDE, por sus siglas en ingl\u00e9s) de C# podr\u00eda haber sido utilizado, ya que suelen incorporar bastantes herramientas a la hora de programar o de depurar fallos de los programas, como por ejemplo Visual Studio 12 [4], que es el que recomienda Varian.<\/p>\n

3\u00a0 M\u00e9todo<\/h2>\n

As\u00ed como en [1] se usaba la interfaz para Python PyESAPI, nosotros usaremos la versi\u00f3n original de ESAPI para programaci\u00f3n en C#, sin embargo, el c\u00f3digo que vamos a describir a continuaci\u00f3n y que se muestra en el ap\u00e9ndice es perfectamente transformable para PyESAPI. Como ya hemos comentado, basta escribir el c\u00f3digo que se presenta m\u00e1s abajo en cualquier editor de texto, guardarlo con extensi\u00f3n .cs y abrirlo con la herramienta de scripts<\/em> de Eclipse. Cada vez que se ejecute, el programa realizar\u00e1 autom\u00e1ticamente una serie de comprobaciones acerca de la planificaci\u00f3n seleccionada en la interfaz de Eclipse, correspondientes a la etapa de verificaci\u00f3n.<\/p>\n

Al final del presente trabajo aparece toda una serie de fragmentos de c\u00f3digo que unidos en el orden en el que aparecen constituyen el script<\/em>. A continuaci\u00f3n, se describe en qu\u00e9 consiste cada uno de ellos, de forma que la numeraci\u00f3n de cada descripci\u00f3n coincide con la figura a la que hace referencia.<\/p>\n

    \n
  1. En el primer fragmento de c\u00f3digo se muestra el encabezado, tras cargar una serie de bibliotecas que ser\u00e1n usadas por las funciones que veremos m\u00e1s adelante. De todas estas bibliotecas destacamos las de las l\u00edneas 9 y 10, necesarias para usar ESAPI. Como hemos mencionado m\u00e1s arriba, hay dos modos de trabajar con ESAPI, en el que aqu\u00ed usamos, integrada en la propia interfaz de Eclipse, es necesario trabajar con un contexto, es decir, toda la informaci\u00f3n que manejemos a trav\u00e9s de ESAPI har\u00e1 referencia al contexto de Eclipse que este seleccionado en el momento de ejecutar el script<\/em>. Por ejemplo, si tenemos seleccionado en Eclipse un plan, context.PlanSetup har\u00e1 referencia a dicho plan, tras definir el contexto en la variable context (l\u00ednea 20).<\/li>\n
  2. En el cuerpo principal del script<\/em> se comprueba primero que el contexto sea correcto, es decir, que exista un paciente y un plan seleccionado sobre el cual se recabar\u00e1 cierta informaci\u00f3n (l\u00edneas 1-5). En las l\u00edneas 7 y 8 se definen las variables ss y ps, que contienen el StructureSet y PlanSetup o conjunto de estructuras y plan (propiamente dicho) del contexto. En las l\u00edneas 13-26 y 32 se llaman a las diferentes funciones que definimos m\u00e1s adelante, las cuales devuelven una string con las alertas encontradas si las hubiera. Finalmente, en las l\u00edneas 34-41 se escriben las alertas acumuladas en la string warnings a un archivo (de ah\u00ed la necesidad de la biblioteca System.IO).<\/li>\n<\/ol>\n

    Las comprobaciones que se realizan con las diferentes funciones son:<\/p>\n

      \n
    1. Con la funci\u00f3n CheckCT se comprueba que el TC (tomograf\u00eda computerizada) de planificaci\u00f3n sea el \u00faltimo TC creado. Esto es importante para no planificar en un TC err\u00f3neo, por ejemplo, en uno de un tratamiento anterior. Obviamente habr\u00e1 casos en los que esto de lugar a falsos positivos, pero simplemente se generar\u00eda una alerta y ser\u00eda la persona encargada de ejecutar el script<\/em> la que puede decidir si, efectivamente, es un falso positivo o la planificaci\u00f3n se est\u00e1 realizando sobre un TC err\u00f3neo. En realidad, y para ser m\u00e1s precisos, no se busca el \u00faltimo TC, si no el \u00faltimo conjunto de estructuras contorneado.<\/li>\n
    2. La funci\u00f3n CheckCouch comprueba que se haya introducido la mesa de tratamiento. Para ello se comprueba que existan las estructuras CouchSurface<\/em> y CouchInterior<\/em> y que no est\u00e9n duplicadas.<\/li>\n
    3. CheckStructures comprueba varias cosas:<\/li>\n<\/ol>\n

      Primero, que no existan estructuras vac\u00edas (l\u00edneas 7-9).<\/p>\n

      En segundo lugar, l\u00edneas 11-21, se comprueba la correcta identificaci\u00f3n de los \u00f3rganos bilaterales. En nuestro protocolo de nomenclatura los \u00f3rganos bilaterales son nombrados con _I o _D al final del nombre seg\u00fan sean a izquierda o a derecha. El script<\/em> comprueba que no est\u00e9n intercambiados, es decir, que el centro geom\u00e9trico de los que se han nombrado con _I tengan mayor coordenada X<\/em> que los correspondientes nombrados con _D. Tal y como est\u00e1 programado el script<\/em> solo se tiene en cuenta el caso de un TC HFS<\/em> (cabeza primero, supino), ya que, por problemas de exportaci\u00f3n a aceleradores de otra casa comercial, se etiquetan todos los TC con dicha descripci\u00f3n, aunque no se hayan realizado as\u00ed. Por ejemplo, para los TC que se realizan en prono el script<\/em> genera un falso positivo al creer que los \u00f3rganos bilaterales contorneados est\u00e1n intercambiados. En el caso de que no existieran dichos problemas de exportaci\u00f3n y se generen los TC con la etiqueta correcta habr\u00eda que extender el script<\/em> para los casos diferentes a HFS<\/em>. Para identificar si el nombre de la estructura acaba en _I o _D, se hace uso de expresiones regulares, para lo cual es necesario cargar la biblioteca System.Text.RegularExpressions.<\/p>\n

      Y en tercer lugar (l\u00edneas 23-32), que exista la estructura BODY<\/em> y sea de tipo external<\/em>. En nuestro caso, para tener en cuenta los apoyos e inmovilizadores en el c\u00e1lculo de la dosis se contornean dentro de la estructura BODY<\/em> y se genera otra estructura BODY_CBCT<\/em> que es la que corresponde al paciente exclusivamente. Esto puede dar lugar a confusiones y que se asigne como external<\/em> a la estructura BODY_CBCT<\/em> lo que excluir\u00eda los apoyos del c\u00e1lculo de la dosis.<\/p>\n

        \n
      1. La funci\u00f3n CheckMarkers comprueba que los marcadores est\u00e9n bien colocados, comprobando si existen 5 en total y que al menos 3 caigan en una regi\u00f3n de alta densidad (los que corresponder\u00edan a los perdigones, los otros dos marcadores se colocan sobre la mesa). Para comprobar si caen en una regi\u00f3n de alta densidad se define, para cada uno de ellos, una matriz de p\u00edxeles de 4mm<\/em>\u00d74mm<\/em> con el marcador en el centro, sobre el corte del TC en el que se encuentran situados. Dicha matriz debe contener al menos un p\u00edxel con densidad mayor que 1500HU<\/em> (unidades Hounsfield). Comprobar que los marcadores est\u00e9n bien colocados es importante porque el script<\/em>, m\u00e1s adelante, genera un comentario de centraje con los desplazamientos que se deber\u00e1n hacer al paciente una vez colocado en la camilla de tratamiento y centrado en los tatuajes, y dichos desplazamientos los calcula de la posici\u00f3n de los marcadores.<\/li>\n
      2. La funci\u00f3n CheckOrigin comprueba que el origen sobre el TC est\u00e9 bien colocado, alineado con los marcadores. Para ello se determina que el marcador con menor coordenada X<\/em> en valor absoluto sea menor que 1mm<\/em>. Y, an\u00e1logamente, para los dos marcadores con menor coordenada Y<\/em>.<\/li>\n
      3. La funci\u00f3n CheckCentraje comprueba que en el campo de comentarios del plan haya un comentario de centraje con la siguiente estructura<\/li>\n<\/ol>\n

        Desplazamientos<\/p>\n

        Vrt: 0.0 cm<\/p>\n

        Lng: 0.0 cm<\/p>\n

        Lat: 0.0 cm<\/p>\n

        Altura Marcas: 0.0 cm<\/p>\n

        DFS 0 Marcas: 0.0 cm<\/p>\n

        Altura Isocentro: 0.0 cm<\/p>\n

        DFS 0 Isocentro: 0.0 cm<\/p>\n

        Este comentario incluye los desplazamientos que se tendr\u00e1n que realizar al paciente en tratamiento para llevarlo desde el origen (centrado en tatuajes) hasta el isocentro, as\u00ed como las diferentes distancias que se comprueban para ver que el paciente se ha colocado correctamente: alturas desde los tatuajes laterales a la mesa y las distancias fuente-superficie (DFS), tanto cuando el paciente est\u00e1 situado en el origen como cuando est\u00e1 situado en el isocentro.<\/p>\n

          \n
        1. La funci\u00f3n CheckCamposCentraje comprueba que existan los campos de colocaci\u00f3n a 0\u00ba y 270\u00ba, que incluyan el \u00e1ngulo de gantry en el nombre y que el colimador y la mesa se encuentren en 0\u00ba.<\/li>\n
        2. La funci\u00f3n CheckFields alerta en caso de usarse una energ\u00eda con filtro. Si los campos corresponden a arcos con sentido horario deben contener SH en el nombre, y si tienen sentido antihorario SAH, en caso contrario se alerta para corregirlo. Adem\u00e1s, se alerta tambi\u00e9n si hay campos con giros de colimador similares entre s\u00ed o cercanos a 0\u00ba (con diferencias menores a 5\u00ba). Finalmente, tambi\u00e9n se comprueba que el n\u00famero de arcos en cada sentido, horario o antihorario, est\u00e9 equilibrado.<\/li>\n
        3. La funci\u00f3n CheckTolerancias alerta en el caso de que haya alg\u00fan campo sin una tabla de tolerancia asignada.<\/li>\n
        4. La funci\u00f3n CheckGantrySpeed comprueba que la velocidad de gantry sea constante. Esta es una recomendaci\u00f3n de Varian, as\u00ed que se comprueba que la velocidad de gantry se mantenga, en nuestro caso, en 6\u00ba\/s<\/em> en todos los puntos de control. Obviamente, no en todos los casos se va a poder cumplir con dicho requisito, por ejemplo, en una radiocirug\u00eda.<\/li>\n
        5. Como \u00edndice b\u00e1sico de complejidad del plan se calcula el cociente entre las unidades monitor totales y los cGy<\/em> por fracci\u00f3n. La funci\u00f3n CheckUMcGy alerta en el caso de que dicho \u00edndice sea mayor que 4.<\/li>\n
        6. La funci\u00f3n CheckCalculationModel comprueba que se usa la \u00faltima versi\u00f3n aprobada del algoritmo de Acuros, en nuestro caso Acuros_15.6.03. Obviamente, si se aprueban nuevas versiones la string de la l\u00ednea 4 debe ser cambiada.<\/li>\n
        7. La funci\u00f3n CheckPrescription comprueba varias cosas. En las l\u00edneas 7 y 8, que exista un punto de referencia de dosis. Este punto es el que se usa para almacenar la dosis administrativa en el sistema de registro y verificaci\u00f3n, y en \u00e9l se almacenan la dosis total, dosis diaria y dosis por sesi\u00f3n.<\/li>\n<\/ol>\n

          En las l\u00edneas 9 y 10 se comprueba que exista una prescripci\u00f3n para el plan y, en particular, para alg\u00fan PTV (Planning Target Volume<\/em>).<\/p>\n

          En las l\u00edneas 15-29 se comprueba que la dosis de la prescripci\u00f3n del PTV de mayor dosis coincida con los l\u00edmites de dosis que aparecen en el punto de referencia.<\/p>\n

          Finalmente, si la dosis por fracci\u00f3n es menor que 1.8Gy<\/em>, se alerta de que el tratamiento puede ser hiperfraccionado (l\u00edneas 33 y 34). Y habr\u00e1 que tener cuidado a la hora de establecer los l\u00edmites de dosis diaria y dosis por sesi\u00f3n del punto de referencia.<\/p>\n

            \n
          1. La funci\u00f3n CheckMedula comprueba que si existe la estructura MED (correspondiente a la m\u00e9dula en nuestro protocolo), no sobrepase la dosis biol\u00f3gica equivalente de 45Gy<\/em> en 30 sesiones con un \u03b1\/\u03b2=3. Aunque en la siguiente funci\u00f3n que se presenta, CheckConstraints, se comprueba que se cumple con los l\u00edmites de dosis para los \u00f3rganos de riesgo que aparecen en la prescripci\u00f3n, hemos incluido la funci\u00f3n CheckMedula para comprobar de oficio que ciertos \u00f3rganos cr\u00edticos como la m\u00e9dula no corran ning\u00fan riesgo.<\/li>\n<\/ol>\n

            Obviamente, esta funci\u00f3n se puede extender a otro tipo de \u00f3rganos en serie de manera inmediata.<\/p>\n

              \n
            1. Por \u00faltimo, aparece la funci\u00f3n CheckConstraints. Esta funci\u00f3n es la m\u00e1s compleja de todas por falta de estandarizaci\u00f3n en la nomenclatura de las prescripciones, por ello aparece aparte del resto de funciones en la figura\u00a02. As\u00ed como la nomenclatura de las estructuras est\u00e1 m\u00e1s o menos estandarizada en las planificaciones que manejamos, no ocurre as\u00ed en las prescripciones[1]<\/a>. Por ello, en las l\u00edneas 11-53 se ha creado un diccionario en el que la etiqueta corresponde a la nomenclatura de la estructura en cuesti\u00f3n y el valor es una lista de expresiones regulares que intentar\u00e1n coincidir con los \u00f3rganos que aparecen en la prescripci\u00f3n.<\/li>\n<\/ol>\n

              En las l\u00edneas 57-88 se identifican los \u00f3rganos de riesgo tal y como aparecen en la prescripci\u00f3n con aquellos que aparecen como estructuras, haciendo uso del diccionario creado anteriormente. Tambi\u00e9n se ha tenido en cuenta que en la prescripci\u00f3n los \u00f3rganos pueden aparecer como Contralateral<\/em> o Ipsilateral<\/em> y no como Derecha<\/em> o Izquierda<\/em>. En ese caso se identifican teniendo en cuenta la posici\u00f3n del PTV de mayor dosis.<\/p>\n

              Finalmente, en lo que queda de funci\u00f3n se identifica la prescripci\u00f3n para cada \u00f3rgano de riesgo: si esta est\u00e1 dada como dosis media, dosis m\u00e1xima, volumen permitido para una dosis dada o viceversa, teniendo tambi\u00e9n en cuenta si las dosis y vol\u00famenes son relativos o absolutos. Una vez identificada se busca en el histograma dosis-volumen la dosis o volumen conseguido y se compara con el requerido en la prescripci\u00f3n.<\/p>\n

              Aun as\u00ed, dada la variabilidad en la forma de escribir las prescripciones, esta funci\u00f3n arroja alg\u00fan que otro error de vez en cuando, por lo que no estar\u00eda de m\u00e1s usarla dentro de una sentencia try-catch.<\/p>\n

              4\u00a0 Discusi\u00f3n y conclusiones<\/h2>\n

              Como se puede comprobar, el script<\/em> est\u00e1 enfocado a VMAT (tratamientos de arcoterapia volum\u00e9trica), as\u00ed que alguna funci\u00f3n podr\u00eda arrojar errores inesperados al aplicarse a otro tipo de tratamientos. Desde luego que como posible continuaci\u00f3n de trabajo podr\u00eda generalizarse para incluir otro tipo de tratamientos y, por supuesto, podr\u00eda ser ampliado para verificar cuantos par\u00e1metros se deseen, o ser adaptado a las particularidades de cada servicio.<\/p>\n

              Hemos presentado, por tanto, un ejemplo de c\u00f3mo usar la API que proporciona Eclipse para automatizar el proceso de verificaci\u00f3n de una planificaci\u00f3n. Con ello se ahorra tiempo y se deja lugar a menos fuentes de error. Obviamente el script<\/em> presentado no est\u00e1 exento de posibles errores, por ello siempre tendr\u00e1 que haber una verificaci\u00f3n humana, por lo menos hasta que est\u00e9 lo suficientemente comprobado. Sin embargo, es usual que despu\u00e9s de la verificaci\u00f3n de la planificaci\u00f3n vengan etapas posteriores: aceptaci\u00f3n de la planificaci\u00f3n por parte del m\u00e9dico, verificaci\u00f3n pretratamiento en el acelerador, etc. Por lo que se realiza una segunda verificaci\u00f3n al final del proceso, quiz\u00e1 por otro radiof\u00edsico, y aunque se suelen verificar par\u00e1metros diferentes en ambas verificaciones al final acaba habiendo redundancias, con la consiguiente p\u00e9rdida de tiempo. Con este tipo de scripts<\/em> podemos mantener dicha redundancia sin apenas consumo de tiempo.<\/p>\n

              Finalmente, este trabajo tambi\u00e9n puede servir para aprender a manejar la API de Eclipse dada la gran cantidad de par\u00e1metros a los que este script<\/em> accede.<\/p>\n

              [1] En la funci\u00f3n anterior CheckMedula, se buscaba que existiera la estructura MED, en el caso de que se hubiera llamado Medula no hubiera funcionado.<\/p>\n