IHERO UseCase Plan Treat Record

1. Proposed Workitem: Radiotherapy Planning and Treatment Record

• Proposal Editor: T.McNutt, C.Field
• Editor: T.McNutt, C.Field
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiation Oncology

2. The Problem

Official patient records in radiotherapy remain paper based and rarely capture the full 3 dimensional record of what was planned or delivered during the course of treatment in a clean fashion. PACS technology has been deployed in radiology that provides full electronic access to imaging studies for patients with hospital wide access. This ability has not trickled down to radiotherapy. The ability to store, retrieve and transfer RT information electronically is paramount for supporting clinical trials, patient re-treatments, and for maintaining the full record of patient care. Furthermore, the use of open agreed standards for data storage will solve the problem of longevity of the information, and eliminate the effect of vendor changes on clinical departments.

The selection, anonymization, and electronic submission of radiotherapy data for clinical trials quality assurance (QA) and storage in a central RT data repository requires significant development. The current process does not support the storage of all radiotherapy data, and is currently a tedious, potentially insecure, and partially complete process. For example:

• RT plan is not supported in some situations:

• IMRT fields
• Compensators
• Electron fields

• Selection of which structures to export is often not possible (it is either all structures or none)
• Specification of which DICOM tags to anonymize is generally not available (a configuration file which specifies which tags would be really nice)
• There is ambiguity in shared pixels on some systems e.g. on Tomotherapy a pixel can only belong to one target and one organ at risk. Recalculating DVH may produce different results
• others?
  

A complete definition of the data required for radiotherapy data clinical trials (and a patients electronic record) is required. The range of data includes: CT, MR, structures of each modality, plan (supporting photon and electron fields, IMRT, compensators, bolus, etc), DRRs, 3D dose distributions, DVHs, treatment record, screen captured or scanned images, …

For clinical trials data submission to a central repository, the electronic transfer should be performed in a secure encrypted environment compliant with HIPPA in USA, FOIP and Health Information Act in Alberta, and regulations from other provinces and countries. Anonymization requirements for local storage would be specified by the local institution.

3. Key Use Case

How it currently works
The official electronic treatment record is currently ill-defined for radiotherapy. Many departments still use paper as the official record and the treatment planning data is reduced to signed documents generated from the treatment plan. The original treatment plans are stored in a proprietary database and do not necessarily reflect what happened during the treatment course. For example if the treatment was adjusted for the patient during the course of treatment, this change may not be reflected in the treatment plan. Retrieval of treatment plans from proprietary databases also requires the same treatment planning software that created it. This becomes a problem if the patient returns for a re-treatment and the planning system has been changed or if the patient has moved and is at a different institution. Often it is possible to reconstruct what has happened to patients, but the official record should not require a complex reconstruction of the treatment – and would more appropriately be stored in a standard format retrievable by systems used in radiotherapy.

For clinical trial submission on a treatment planning system, a user selects the patient to export. The data is exported to a local file system. Somehow the user is required to anonymize the data (the ITC_DICOMpiler provides this tool, but it misses some tags). The data is then FTP’d to the ITC centre in St.Louis, QARC or RPC?. Treatment record information cannot be sent. IMRT field information is not sent. DVHs are recalculated.

One of the current problems is the limited number of data repositories able to support this data transfer. ITC, QARC, RPC, ESTRO’s Genepi, Australia’s SWAN, NCIC CTG (RCET tools), ...

How it should work

The best case use case would reflect the realities of all scenarios and promote interconnectivity at all levels. The treatment record needs to 'connect' to the same clinician later, a different clinician in the same department much later on different hardware and software (decades?), clinicians in different departments, and reviewers in clinical trials offices.

Therefore storage and transfer should be abstracted from the specifics of the use case as the only commonality is a data structure not reliant on proprietary definition. Storage can be local, institutional, provincial, national or commercial. Transfer can be by any means that fulfill the criteria of security prevailing at the time of transfer.

The use case requires certain operational characteristics.

1. it must be assumed that the data will be kept permanently

The cheapness of digital storage and the usefulness of routine planning data (when finally realized) will see an increasing demand to keep data permanently. At the present, radiation departments in New Zealand are required to keep their radiation data for 40 years on living patients, and 10 years on dead patients. This time frame already exceeds the life expectancy of the products used to produce the plans.

2. it is highly likely that the review of data will not occur on the system on which it was produced

The review of treatment data will occur in two clinical settings. Firstly when there has been a recurrence and further treatment is contemplated. Most oncologists will require a substantial elapsed time before seriously considering further therapy. Secondly when there has been a late complication and assignment of causation is required, either because of a judicial process or because of good quality assurance principles.

When treatment data is reviewed contemporaneously in trials offices for the purpose of trial QA, the reviewing system will be different. Where local sites are undertaking research, the data structure should permit the aggregation of data without opening each file to discover data.

This argues that a well defined data structure which is clearly annotated and which will be backwards compatible with any future system, or that file conversion is addressed deliberately when backwards compatibility is lost.

3. the correlation of anatomical imaging with dose deposition is required

In the clinical scenarios listed above, dose deposition is correlated with anatomy (where there was a recurrence or side effect). In trials review it is possible that anatomical information may not be reviewed, but its presence is then of no concern. This argues for the storage of anatomical information within the same data structure as the treatment plan.

4. the planned dose deposition pattern is a poor substitute for the actual dose deposition

The treatment plan does not cause recurrence or side effect, but rather treatment delivered. The effect of altered treatment plans should be reflected in the description of the treatment delivered. The future will include more on-treatment imagining which from which it will be possible to re-construct delivered dose. This argues for a use case where changes to plan parameters are fed back through the treatment plan, and where localization images and isocentre changes are also stored within the treatment 'plan'. While this may not be possible now, it should nevertheless be considered.

clinical trials do not involve greater data needs than the routine treatment of patients. While trials have the need of more uniform data collection, the dataset collected is always a subset of the routine data available.

The clinical trials use case is not fundamentally different from the use case described above, and is satisfied by a treatment plan storage specification where conventions for naming are standardized and a submitted plan is anonymous. The use case of standardized nomenclature for anatomical structures and volumes can and should be addressed by manufacturers and vendors to present a consistency when systems are delivered. Such consistency is unlikely to arise from radiation oncologists. The use case for removing identifying data from submitted plans should also be addressed.

[Note: this is my first major edit. If I have stepped on toes, I apologize]

4. Standards & Systems

Treatment planning systems, virtual simulation system, record & verify systems, CT scanners, MR scanner, PET and other scanners, Picture Archive and Communication Systems (PACS).
DICOM-RT,

Given the small number of radiation oncology vendors, the development of interoperability standards and formats will suffice for larger data efforts such as caBIG, who rely on more on standards that are applied (and are therefore predictable) than on any preference for particular standards in areas where they have little specific expertise.

5. Discussion

Ideal inter-operability problem for IHE-RO to deal with. Collaborate with clinical trials groups ? caBIG compliance ?
An additional profile is required, which could be an extension of the 2005-7 Profile.
This is a very difficult problem to solve.

Counterpoint
The nature of the RO market is such that once the open defined standards for data structures for IHERO are defined and the RO vendors/manufacturers have implemented truly interoperable solutions, clinical trials groups and endeavors such as caBIG will adapt to this new environment where they can get standard data outputs easily - in fact where all outputs are 'standard'. It is my thesis in this discussion that the normal use case is sufficient (if vendor implementation is consistent) and that there is no need for additional use cases for trials, particularly since their required dataset is smaller than that used in routine settings.