Report on the Potential use of CfH PACS for Archiving Radiotherapy Information

Transcription

1 Report on the Potential use of CfH PACS for Archiving Radiotherapy Information David Mott, & Sue Chatterton June 2010 North Western Medical Physics Introduction Background Current Archive Methods and Shortcomings Local Systems Simplified Model of PACS Data Flow through RA600 Auto Routing Date Issues Study Issues Visualising RT Objects Conclusions Other Considerations Local Potential for the Utilisation of the RA600 Proposed Workflow Acknowledgements Appendix I Listings Introduction The North West Strategic Health Authority provided the Christie Foundation Trust with a GE Healthcare RA600 to investigate the use of the CfH PACS to archive radiotherapy information. The RA600 was installed November 2009 as was a ProSoma on loan from OSL Ltd. The ProSoma was required to allow the radiotherapy information to be visualised as this functionality does not exist on the RA600. The aims of the were To understand the capabilities or the RA600 thus ensuring that any future decisions about the implementation of CfH PACS are adequately informed. To check that RT Objects pass into and out of the PACS archive correctly. To automate the process as much as possible. Background simplest process would be:- If we look at the temporal flow of DICOM Objects through the Radiotherapy process the Output (in DICOM format) Scan RT Struct RT Plan & RT Dose RT Image or CB Decision to treat Planning scan Outline Tumour & Relevant anatomy Plan the treatment Treat daily for up to six weeks Confirm the treatment geometry Time This differs significantly for the typical workflow within Diagnostic Radiology, for which CfH PACS was designed, in the following areas. Report on the Potential use of CfH PACS for Archiving Radiotherapy Information Page 1 of 11

2 Objects are created over a protracted period of time which can be up to seven weeks. Objects are based on other Objects Scan RT Structure Set RT Plan RT Dose 1 Objects are created on a range of s scanners, treatment planning s, and image based verification s on the treatment accelerators as is illustrated. Output (in DICOM format) Scan RT Struct RT Plan & RT Dose RT Image or CB Decision to treat Planning scan Outline Tumour & Relevant anatomy Plan the treatment Treat daily for up to six weeks Confirm the treatment geometry Time Scanner Treatment Planning Delivery Accelerator based Imaging A simple linear workflow should not be confused with a simple linear information flow. All of the s illustrated above use DICOM to transfer information between each other but They do not use DICOM format internally. The information is converted to and from internal formats. They only accept and use the Objects that they require. For example the Delivery only accepts the RT Plan Object and has no interest in any of the proceeding Objects. So the information flow can be complex with different Objects being transferred to a variety of scanner s throughout the treatment episode. The final complication is that DICOM is generally Scans (no Scout views!) implemented within Radiotherapy as a method of transferring Objects through definite routes so Planning Query/Retrieve is not often implemented. So in the diagram an arrow indicates a simple Send from one to a known recipient. This results in RT Plan RT Structure Set, the potential to use a central server for all the RT RT Plan Objects not being considered as a priority. The Planning System effectively acts as a server for all Accelerator the Objects created before treatment (, RT Delivery Based Structure Set, RT Plan, and RT Dose) while those imaging objects created during treatment for purpose of verification (RT Image and for cone-beam ) remain on the s that generated them (Accelerator Based imaging on the diagram). 1 Note while a hierarchical relationship is show this is not how these Objects are related to each other within the DICOM standard. Report on the Potential use of CfH PACS for Archiving Radiotherapy Information Page 2 of 11

3 The result of this is that a Radiotherapy Study, as defined within the DICOM standard, might not be achievable. A Study is defined as shown and it should be noted that the relationship between Objects is not defined by any hieratical structure but by references ( ) maintained in the Objects. (The diagram is taken from the DICOM Standard) In the local configuration while the Planning System is the source of a large amount of the DICOM Objects the RT Images can be generated on one of two separate imaging s integrated into the treatment accelerators. While the internally cross referencing will be achieved on the Planning System it might not always be achieved between s and is covered in the section on Study Issues. 2 It should be noted that the RT Treatment Record ( ) will not be generated as treatment records are maintained within existing commercial databases. It is not expected that the implementation of the DICOM RT Treatment Record would be seen as a priority as it would duplicated what these s already produce. Cone Beam verification Mega-voltage image verification Planning System To summarize DICOM is used as a method of transferring information through well established routes. The use of distributed s results in it not always being possible to have a single DICOM study containing all the relevant Objects 3. Current Archive Methods and Shortcomings The installed Radiotherapy s offer some form of archive but all use proprietary formats and specific archive media. This perpetuates the long standing problem of failing to maintain an archive when a is replaced. Given that disease free results are normally quoted in terms of five year survival figures the inability to archive for much more than 7-10 years means that it is problematical to perform retrospective studies analysing clinical outcomes against treatment techniques. Local Systems The Radiotherapy that this work was conducted on is relatively simple and consists of Images from one of three scanners, or one of two MR s. These are used as the basis of Treatment Planning. All of these images are currently archived to CfH PACS 2 RT Treatment Record is a record of the Linear Accelerator parameters used for each fraction of a treatment. 3 If a single supplier is used for all the s and then a DICOM compliant study will be created. On the present site there is equipment from a number of suppliers and this is generally the case within Radiotherapy departments. Report on the Potential use of CfH PACS for Archiving Radiotherapy Information Page 3 of 11

4 Images from one of two Varian Acuity Cone Beam scanners. These are used as the basis of Treatment Planning. Treatment Planning on a Phillips Pinnacle TPS. Treatment Delivery through an Elekta Mosaiq R&V on either Elekta or Varian accelerators. Verification Mega-Voltage images from either Elekta iview GT or Varian Portal Vision on the corresponding Linear Accelerators Verification Cone Beam on one of two Elekta XVI s based on a corresponding Linear Accelerator. The current data flows are simple to transmission of the DICOM Objects that are required. Simplified Model of PACS The diagram is a gross simplification of the communications route within PACS and is really just to highlight the various s (RIS, Broker, Modality) to aid the understanding of the role the RA600 performs The RA600 is effectively acting in the role of a Modality. Normally a Modality would generate DICOM Objects but in the present case it is collecting DICOM Objects from the Radiotherapy Systems. 4. RIS 3.1 Broker tells Modality to expect Study to be performed. (Worklist) Modality 1 Create Appointment on RIS 2 RIS sends details to Broker Broker 3.2 Broker lets PACS know that a Study is about to be done PACS 4 Once Study done it is sent to PACS which is expecting it. Data flow through RA600 This is a brief description of how the Objects are passed through the RA600 and the places where they can be interrogated and edited. DICOM Objects received. Editing of fields is allowed via a Repair script. A script is Microsoft JScript (cf Java Script) code which can allow fairly complex manipulation and correction of the information within the header section of the DICOM file. It can also be used to initiate other activities. QC or Matching of the incoming Study to a Study defined in the Broker Worklist. The Matching criteria are defined by the user i.e. Patient ID must be identical, etc. Matching can be extended to increase the complexity using a Match script. For example instead of looking for a precise match on the Study Date a match within a range of dates can be achieved. Auto Route to PACS or other destination. Based on simple criteria but the criteria can be extended using a Routing script. Correction of fields to precisely conform to the Broker Worklist. The information flow through the RA600 is largely based on the concept of an Origin which is the source of the Objects coming into it. The Repair script, Match criteria and script, and the Forward criteria and script are all based on each individual Origin. This allows each script to be tailored to the requirements either imposed or desired from each Origin. The disadvantage is the increased maintenance of what should be identical 4 All the communications regarding Attendance, Verification, and Reporting have been omitted as they are not important in the context of Radiotherapy Archive. Report on the Potential use of CfH PACS for Archiving Radiotherapy Information Page 4 of 11

5 scripts from a which appears as multiple Origins. For example the Treatment Planning that was used in the development and testing has 15 terminals each being seen as a separate Origin. Auto Routing The fact that the RA600 performs Auto Routing (or Forwading) was considered advantageous for a number of reasons. Previously it was shown that the Treatment Planning often acts as a router sending different Objects to different destinations. This involves the operator actively sending the required Objects to the required destinations. So the question was could the RA600 perform this function automatically? That is if Objects were sent to it could it decide what required forwarding and to where? Conventionally Auto Routing on the RA600 only operates at the Study level so it would forward everything (, RT Structure Set, RTPlan, & RT Dose) to the Delivery System which was not the functionality that was required. What was required was to forward at the level of Object and this has been achieved as part of the Repair script. In our case there was sufficient information within the DICOM Object to decide which destination it should be forwarded to 5. RT Plan Delivery scanner Scans (no Scout views!) Planning RA 600 RT Structure Set, RT Plan Accelerator Based imaging There are a number of reasons for wanting to implement Auto Routing. Simplification of data flow. The operator now only has to send the data to the RA600 and it forwards onto the correct destinations. Ensuring data capture for Archive. Passing everything from Planning through the RA600 ensures that the PACS archive is complete. If a separate, manual, transfer to the RA600 in addition to the current transfers had been implemented then there would be the possibility of information not being sent and therefore not being archived. Ensure PACS has only clinically relevant information. Treatment Planning is similar to other design exercises in that various designs can be produced but only one will be seen as clinically acceptable for treatment. The reasons for selecting one plan over another are not recorded either physically or within the DICOM standard. So only archiving the plan that is going to be treated to and not archiving any discarded variations will result in the archive only containing clinically relevant information. Date Issues In the Background section the protracted time scale over which a Radiotherapy Study is acquired was raised. An additional complication is that a significant number of patients will subsequently return for more treatment. Any subsequent treatment episode should be seen as a separate archive entry. 5 This might be dependant on the particular treatment planning but in the case of a Phillips Pinnacle the Radiation Machine Name (3002,0020) is populated which allowed the RT Image to be distributed to the required Varian or Elekta. Report on the Potential use of CfH PACS for Archiving Radiotherapy Information Page 5 of 11

6 So what date should be used as the Study Date and what mechanism can be used to generate separate archives for subsequent treatments? We looked at a number of alternatives for the Study Date but operationally what appeared to be the most appropriate date was the decision to treat date. The reason this was selected was that on this date the diary entries in the Mosaiq B&S (RT version of RIS) are created and therefore it seemed logical to do the parallel booking of the Radiotherapy Archive onto RIS. One issue that did arise when looking at images on the RA600 was the inappropriate use of the Study Date (0008,0020) when displaying images. It is not surprising that the RA600 uses the Study Date as in Diagnostic Radiology the Study Date will be the date when the images are acquired. With the extended time period over which Objects are acquired is not the appropriate date for Radiotherapy Objects. A more appropriate date to display with the images would be the Content Date (0008,0023) or the Acquisition Date (0008,0022). While the latter is a type 3 it is generally found within the image headers and is becoming a type 1 on many of the newer modalities 6. Attribute Name Tag Type Attribute Description Study Date 0008, Date the Study started Content Date 0008,0023 2C The date the image pixel data creation started. Required if image is part of a series in which the images are temporally related. Acquisition Date 0008, The date the acquisition of data that resulted in this image started. RT Specific Dates Structure Set Date 3006, Date at which Structure Set was last modified. RT Plan Date 300A, Date treatment plan was last modified. As shown in the table there are a number of possible date fields that can be used depending on the actual Object. Looking at the RT Structure Set, RT Plan, & RT Dose a review of the DICOM Conformance Statement for Pinnacle shows that in all cases the date being set in these locations is the date the information was converted into the DICOM format. (i.e. the date the operator sent the information from the.) This is a completely inappropriate date and is illustrative of how primitive the DICOM Conformance can be within radiotherapy. Fortunately the Elekta iview and XVI s, which provide the verification images, are more rigorous in the storage of appropriate dates. For example with XVI the Content Date is the date the original Cone Beam images are converted to while the Acquisition Date is the date the Cone Beam data was acquired. So in this case the Acquisition Date is the more appropriate date as that was the date the patient was actually examined. The question therefore arises about how a reviewer would understand the temporal sequence of events if RT Objects are returned from the CfH archive. If a single plan has been archived then there is no problem. The archive would have been indexed on RIS by the Decision to Treat Date and internally the, RT Structure Set, RT Plan, and RT Dose would all be linked together. If the plan had been modified during treatment and multiple plans used then the Content 6 This might be a RFC for GE Healthcare to consider that the date displayed with an image is Acquisition Date, but if that is empty then Content Date, but if that is empty then Study Date. Report on the Potential use of CfH PACS for Archiving Radiotherapy Information Page 6 of 11

7 Date on the RT Plan file would indicate when the plan had been sent from the Planning System and the separate R&V record consulted to indicate when the modified treatment plan had been used. There is no problem with the Verification Images as they all contain a valid Content or Acquisition date in the header so the sequence of events can be understood. Because of inconsistencies in handling dates and the RT Objects and images requiring a more specialised appreciation by the observer the automatic report that will appear on RIS was worded appropriately. RADIOTHERAPY ARCHIVE 1) There is no clinically significant diagnostic quality images in the study. Do NOT use it to make clinical decisions. 2) The Study Date (shown on all images) is the date when all the information was archived. Individual images will have been taken prior to this date. The actual dates are held as the Acquisition Date in the DICOM header. 3) This study contains items that can only be viewed with specialised software. Study Issues As has already been pointed out in the Background section an RT Study requires fairly complex internal linking quite apart from the normal unique identification afforded by the Study Unique Identifier (UID). With the complexity of the routing of various RT Objects around the various s it was not expected that the Study UID would be managed correctly. What was found was: - scans, all the RT objects sent from Pinnacle, and all the CB scans sent from XVI were placed in a single study on the RA600. This means that a single study is achieved for the most complex treatments with the most advanced form of Verification imaging currently available at this Trust. RT Image from the MVI and anything from the Varian simulators appeared as separate studies. This is to be expected Visualising RT Objects Prior to the project it was fully understood that the RA600 would not be able to visualise all of the RT Objects so OSL Limited were approached for assistance as they marketed the only independent commercial capable of displaying all DICOM RT Objects. OSL agreed to provide us with a ProSoma on loan for the period of the project. We consider it preferable that a specific viewer is required to visualise the RT Objects especially as the PACS archive is open to all levels of competency with respect to understanding what is being displayed. Viewing the DICOM RT Objects in isolation is limited for a number of reasons The clinical reasons for drawing volumes are not documented. The technical reasons for any specific volume dilation are not documented. The clinical and technical reasons for using a particular treatment beam configuration are not documented. Because the RT Treatment Record is not part of the archive the viewer will not be aware that the treatment might have been terminated for clinical reasons prior to the final fraction. This project was undertaken to assess the RA600 and CfH PACS as an archive solution and not as a method of disseminating RT Objects to a wide audience. It was based on the premise that recovery from archive would be to meet very specific clinical objectives which could be met by recovery to a dedicated viewing and analysis. This functionality was met by the ProSoma. Report on the Potential use of CfH PACS for Archiving Radiotherapy Information Page 7 of 11

8 The RA600 did provide some additional benefits when viewing RT Image from the Elekta iview s. It provided better image windowing and display capabilities and allowed a more appropriate image paging by paging between images from the same gantry angle on subsequent days. This allowed patient movement between successive fractions to be more easily visualised. The web-browser had a slightly unusual appreciation of RT Dose as it paged through the dose distribution as a series of grey scale images. This is of no clinical use but was unusual to see. Conclusions This section will review the conclusions applicable to any Radiotherapy centre. The RA600 will handle DICOM RT Objects and allow them to be passed into CfH PACS. It can be used to interrogate the DICOM files but will not allow RT Structure Set, RT Plan, or RT Dose to be viewed. CfH PACS will accept and return DICOM RT Objects. The various scripting options with the RA600 give it a degree of flexibility to meet local needs. o This requires a level of software and DICOM expertise to be available on site. o Because of the specialised nature of Radiotherapy and the variations between departments it would not be expected that GE Healthcare provide scripts but that they are written locally. o It would be advisable for GE Healthcare could make the JScript functions already developed by them available to the software developer at a site. Pre-requisites for implementing CfH PACS archive of RT DICOM o RA600 capital and revenue consequences. o Technical ability to set-up the and the necessary scripting. o Technical ability to resolve any problems in association with the supplier. o Administrative support for the daily operation. The level of this would depend on the local circumstances. Locally this person would be responsible for other aspects of the archive such as the archive from the XVI s so we would be considering a WTE of a band 3/4. The benefit of employing someone specifically to undertake archive would be that it would ensure the task is performed and monitored. Other Considerations Cone Beam images require to be converted (integrated) to conventional at a user specified slice thickness. Any department deciding to archive these images needs to decide on an appropriate slice thickness. Local Potential for the utilisation of the RA600 In this section the potential for the RA600 to meet local problems will be outlined. The RA600 can be configured to automatically distribute RT Objects as required throughout our. It could act as a local short term server for RT Objects. On that basis the three XVI s could use it on a Q/R basis as a source of the scans, RT Structure Set, and RT Beams required to perform plan matching. It could act as a replacement for the existing bbrad to remove the NACS code (RBV) from incoming /MR/PET images. As there is more than one RA600 within the trust there would be a greater resilience than at present. Report on the Potential use of CfH PACS for Archiving Radiotherapy Information Page 8 of 11

9 By implementing these simple tasks confidence in the operation of the RA600 could be gained while the business case for the PACS archive is being written. Proposed Workflow This is an indication of how we would implement CfH PACS locally Manual Automatic Notes RIS entry for Radiotherapy Archive Do not do for Superficial (skin) or Electron treatments Send DICOM objects to RA600 Removes the necessity to archive on the treatment planning, Pinnacle. It is a simplification of the current of sending Objects to the required destinations. Q/R from any of the XVI s to acquire, RT Structure Set, & RTPlan for this patients who will have an XVI scan Post Treatment Generate a list of patients who have completed treatment Mosaiq report DICOM send CB (as ) from XVI s and EPIDS (electronic MV portal images) from iview and Vision on completion of treatment Auto Match on the RA600 Acknowledgements Auto Forward to a required destinations depending on the Object (RT Plan to Mosaiq, RT Image to iview or Vision depending on Accelerator) Archive to PACS For the iview s this would be a simple change to an established process. For XVI s it requires an agreement of what z-axis resolution is appropriate. For Vision it would be a new process. The authors would firstly like to acknowledge the support of the North West SHA, through Dr Rhidian Bramley, for supplying the RA600. Having access to the has resulted in us having a much better understanding of the capabilities of the which will allow us to make informed decisions about whither to implement CfH PACS for our Radiotherapy Archive. The engineers that we have worked with at GE Healthcare have been exceptionally helpful. In particular David Bacon has been a source of much of our knowledge about the and he has always been very enthusiastic about the project. Finally we wish to thank Carl Walker and Julie Mead at OSL Limited ( ) for the loan of the ProSoma. At the time the project was initiated ProSoma was the only commercial which would visualise DICOM RT Objects. It also provided a non-clinical destination to test the Auto Routing. Report on the Potential use of CfH PACS for Archiving Radiotherapy Information Page 9 of 11

10 Appendix I Software Listings within the scripting options. Listings of the Match script // D Bacon ok for pat id fix // // D Mott // These have been included to provide an insight into what is possible function Rule::Evaluate() { var ToMosaiq = "IMAPC_DCM_SCP :104"; var ToIview = "AE_Title IP Address and Port to iview"; var ToVision = "AE_Title IP Address and Port to Vision"; var ToProsoma = "PROSOMA :104"; var TestForward = true; // This section is the Auto Forward based on object type, source and destination accelerator var Manufacturer = dcmsetimage.getvalue(0x ); Manufacturer.slice(0,4); Manufacturer.toUpperCase(); // Get Manufacturer - used a couple of times // Just get the first four letters as some are verbose // Convert to upper case var FileContent = dcmsetimage.getvalue(0x ); // Get object type var SerInstUID = dcmsetimage.getvalue(0x e); // Get Series Instance UID var CommandLine = "D:\\RA600\\ForwardDICOMfile.bat "; // Command line starts with the batch file name & path CommandLine += SerInstUID + " " // Continue to build Command Line if (TestForward) CommandLine += ToProsoma var ForwardFile = false; switch (FileContent) { case "RTPLAN": if (!TestForward) CommandLine += ToMosaiq; ForwardFile = true; break; case "RTIMAGE": if (Manufacturer!= "ADAC") break; var Accelerator = dcmsetimage.getvalue(0x ); switch (Accelerator) { case "Suite 5": case "Suite 7": if (!TestForward) CommandLine += ToVision; ForwardFile = true; break; default: if (!TestForward) CommandLine += ToIview; ForwardFile = true; } break; default: } if (ForwardFile) { var WshShell = new ActiveXObject("WScript.Shell"); var Exec = WshShell.Run((CommandLine)); } // Basic fixes - Check there is a valid Study Date as Pinnacle has a problem when writing this script. var StudyEarliestDate = dcmsetimage.getvalue(0x ); var i = StudyEarliestDate.length; // Get study date // Make sure there is a study date and string is not empty if (!i) var StudyEarliestDate = dcmsetimage.getvalue(0x ); var i = StudyEarliestDate.length; if (!i) var StudyEarliestDate = dcmsetimage.getvalue(0x ); var i = StudyEarliestDate.length; if (!i) var StudyEarliestDate = dcmsetimage.getvalue(0x ); var i = StudyEarliestDate.length; if (!i) var StudyEarliestDate = dcmsetimage.getvalue(0x ); // No Study Date so try Series Date // No Series Date so try Acquisition Date // No Acquisition Date so try Content Date // Last hope try Instance Creation Date // Check and repair if old DICOM format with. separator being used NOT DONE YET dcmsetrepair.setvalue(0x , StudyEarliestDate); // Need to ensure Study Date is in fact populated } return true; Report on the Potential use of CfH PACS for Archiving Radiotherapy Information Page 10 of 11

11 Listings for DICOM file forwarding batch file ForwardDICOMfile.bat ForwardDICOMfile Series Instance UID (0020,000E), Destination AET, Destination IP address and Port David Mott 12th May 2010 Identifies a DICOM file by its Series Instance UID and sends it to the required destination This batch file is kept in D:\RE600 It assumes the dicom files are being temporarly kept in D:\RA600\Connect\WORK\C-Store Copy with comments set PATH=%PATH%;C:\Program Files\Centricity\RA600\8.0\Bin Add PATH to dcmsend2.exe - needed so that the programme dcmsend2.exe is found cd /D D:\RA600\Connect\WORK Move to directory above C-Store del /q TransferTemp\*.* Delete everything in directory TransferTemp This is a temporary store used to keep the files currently in C-Store directory copy C-Store\*.tmp TransferTemp Copy all files in C-Store into TransferTemp cd TransferTemp Move to TransferTemp for /F %%F in ('findstr /M %1 *.*') do dcmsend2 %2 %3 %%F Search for Series Instance UID and send file to destination using dcmsend2 The use of TransferTemp could be avoided by changing the script to set PATH=%PATH%;C:\Program Files\Centricity\RA600\8.0\Bin cd /D D:\RA600\Connect\WORK\C-Store for /F %%F in ('findstr /M %1 *.*') do dcmsend2 %2 %3 %%F It simply depends on what deletes the files from C-Store The other potential problem is almost simultaneous reception of files into C-store and how the RA600 copes with this. set PATH=%PATH%;C:\Program Files\Centricity\RA600\8.0\Bin cd /D D:\RA600\Connect\WORK del /q TransferTemp\*.* copy C-Store\*.tmp TransferTemp cd TransferTemp for /F %%F in ('findstr /M %1 *.*') do dcmsend2 %2 %3 %%F Report on the Potential use of CfH PACS for Archiving Radiotherapy Information Page 11 of 11