IHERO UseCase 2012 Advanced Multi Modality Registration
1. Proposed Workitem: Advanced Multi-Modality Registration
- Proposal Editor: Christof Schadt
- Editor: Christof Schadt
- Date: N/A (Wiki keeps history)
- Version: N/A (Wiki keeps history)
- Domain: Radiation Oncology
2. The Problem
The current definition of registrations in Radiation Oncology, as described in the MMRO profile have some limitations in order to realize a very specific workflow in radiotherapy (see Use Case: IHERO_2007UseCase_Multimodality_Registration).
With advancing planning techniques and treatment technology and increased exchange between clinical domains, it is proposed to remove some of the limitations and allow more flexibility for planning and pre-planning use cases.
The main issues with the current MMRO profile are:
- defining a "primary" image data set, to which all registrations have to be performed
- this requires all registrations pointing to one single image set (forming a star, not allowing "chained" registrations)
- defining the primary image data set as a CT
- restricting the registration to spatial registration only, and not including deformable spatial registration
- not allowing registration of a Frame of Reference (FOR) to itself, in order to correct for incorrect hybrid-scanner registrations (e.g. PET-CT)
- not defining the behavior in case an image set is registered to a well-known FOR (e.g. an atlas)
- restricting the number of registrations within a spatial registration object to just one
Additionally, the upcoming multi-dimensional presentation state in DICOM will be able to support storage of the actual fusion result that led to the spatial registration. Incorporating this will create the actual evidence of what was performed.
3. Key Use Case
During pre-planning and in case more than one CT already exists, it might not be clear which of the CTs will be the actual planning CT. Therefore, it may not yet be possible to define the "primary" CT during this step of the process. Therefore, the requirement from the current MMRO profile is an artificial restriction that should no apply, as it has no relevance yet.
The current MMRO profile requires that all data sets are registered to the primary data set, which is defined as a CT. Clinicians on the other hand report, that they do not want to always register MRs to the CT, but rather like to register MRs to MRs. The reasons for this are different, but currently this would not be possible.
Storage of evidence
The above issue "MR Registration" could be solved by letting the users register whatever they want and then calculate the corresponding registrations, as the underlying problem is mathematically well defined. On the other hand, if this new information is then stored to a e.g. a PACS via DICOM, it does not represent what the user actually did, but what the software calculated out of it. Users reported that they want to store the actual information, created by the person performing the registration.
Not necessarily anymore, a CT is the primary source for planning. This could basically any data set and currently new applications are capable to also perform planning on MR.
Patient data from other clinical domains (e.g. neurosurgery) will most likely be registered following the convention defined in the FUS profile (upon the definition of the MMRO profile was based), but the concept of a primary image set is not known there, allowing chained image registrations. If such data is transferred to the radiation oncolog domain, it would violate the MMRO profile and vendors in the RO domain would not be required to support loading such data. Removing the limitation of a primary image set will realize an easier transfer of data between domains.
4. Standards and Systems
- The MMRO profile already addresses the basic functionality required for the new use cases. In fact, the proposed use cases could be solved, by relaxing some of the conditions in the existing profile, basically expanding it be creating a new revision.
- The relaxation of the "primary" data set and not limiting this to "CT" anymore, may be the most effective advance for the above mentioned use cases
- The other issues menioned under "The Problem" definitely have to be discussed to what extent they should be adressed with a new profile