Difference between revisions of "IHERO UseCase Plan Treat Record"

From IHE Wiki
Jump to navigation Jump to search
Line 3: Line 3:
 
==1. Proposed Workitem: ''Radiotherapy Planning and Treatment Record''==
 
==1. Proposed Workitem: ''Radiotherapy Planning and Treatment Record''==
  
* Proposal Editor: ''C.Field, T.McNutt''
+
* Proposal Editor: ''T.McNutt, C.Field''
* Editor: ''C.Field, T.McNutt''  
+
* Editor: ''T.McNutt, C.Field''  
 
* Date:    N/A (Wiki keeps history)
 
* Date:    N/A (Wiki keeps history)
 
* Version: N/A (Wiki keeps history)
 
* Version: N/A (Wiki keeps history)

Revision as of 12:10, 23 October 2007


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, this ability must use established standards for data storage to insure longevity of the information.

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
Fundamentally, the use cases reflect the need for a standard PACS-like repository for RT information which would allow for long term storage and retrieval of patient data. Such repositories could exist locally in the department, hospital wide, or multi-institutionally. In every case the ability to store and retrieve accurate and complete records of the RT treatment is required. And, in a standard format across institutions providing record transfer capabilities as well as data longevity. Patient Re-Treatment: Patient presents with a re-occurrence of cancer in an area close to a region previously treated with radiation. The physician requests the prior simulation CT and superimposed dose distributions to develop a strategy for re-treating the patient to the same region. If image registration is possible between the prior treatment and the current planning, then a composite plan may be generated showing the total radiation dose to the patient between the prior treatment and the new plan.

Departmental Case Review: This use case reflects the ability for a physician to review past patient records to understand complications or to learn from their technique to apply to new patients. In the prior case, the patient returns presenting with a long term complication from the radiation. The physician would be able to recall the treatment planning information to assess where the dose was delivered to understand whether or not it is attributable to the radiation and how to change the treatment strategy for future patients to avoid such complications. An important item in this case is the ease of performing the task. This should be able to be accomplished by the physician as easy as reviewing a past CT or MR scan of the patient in a PACS system. This use case can also be extended to encompass multiple patient review in the context of retrospectively studying a specific patient population for research or quality purposes.

Clinical Trials:

  • Central Repository: From a treatment planning system, virtual simulator, record and verify system, or imaging modality, the user selects a patient, the type of data required for export (e.g. CT, MR, structures, plans, doses, DVH, DRRs, treatment records), specific subsets of data (e.g. which structures to export and which DVHs to export), select tags to anonymize, select data repository to receive the data. The data should then be anonymized, encrypted, and transmitted to the selected data repository.
  • Local Archive: In this use case, the clinical trial archive is assumed to be distributed across the multiple institutions participating. Rather than submitting the patient’s data to a central repository, the patient data would be stored locally in a standard way. Then the patient’s record is made available to the study group. In this case new data about the patient would only need to be handled by the institution, and the data would be kept current as a normal medical record.

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, caBIG

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.