IHERO UseCase 2012 Advanced Multi Modality Registration

From IHE Wiki
Revision as of 01:45, 3 July 2012 by CSchadt (talk | contribs) (typo)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


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

Pre-Planning

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.

MR Registration

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.

MR planning

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.

Inter-domain usage

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.

5. Discussion

  • 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
Retrieved from "http://wiki.ihe.net/index.php?title=IHERO_UseCase_2012_Advanced_Multi_Modality_Registration&oldid=61225"