Respiratory Correlated Imaging - Brief Proposal

From IHE Wiki
Revision as of 17:45, 7 September 2018 by Kevino (talk | contribs)
Jump to navigation Jump to search

1. Proposed Workitem: Respiratory Correlated Imaging

  • Proposal Editor: Scott Hadley University of Michigan Radiation Oncology swhadley@umich.edu, Chris Pauer Sun Nuclear Corporation chrispauer@sunnuclear.com
  • Proposal Contribtors: Kevin O'Donnell
  • Editor: <Name of candidate Lead Editor for the Profile, if known>
  • Domain: Radiology

Summary

Imaging modalities are inconsistent about how they encode the respiratory phase information in studies used for RT treatment planning.

This creates safety and efficiency problems.

The profile could mandate standard encoding for how the information is stored by the modality and interpreted by the planning system. DICOM has fields for this.

Several vendors are interested in addressing this, as is IHE RO, AAPM and RSNA.

2. The Problem

Respiratory correlated imaging is a requirement for motion management in radiation therapy. The motion of tumors and normal tissue is used in the planning process to develop RT plans. Treatment delivery devices acquire 4D images (3D over time) that need to be compared to previous 4D images to complete patient treatment.

Currently there are variations in implementation by vendors producing and consuming these types of images. In particular, different methods are used to communicate the respiratory phase for each image series. As a result, users often need to manually update or correct the data in the DICOM images so that the consuming software system can correctly display and use the 4D image for treatment planning.

Safety hazards exist. If 4D images are tagged incorrectly, this may produce incorrect treatment plans. Users could make a mistake correcting this data for use with planning systems. Time is wasted by users modifying data for treatment planning.

Standardized implementation of 4D reparatory correlated imaging would resolve these problems.

3. Key Use Case

  • Imaging device produces several imaging series in the same FOR where each series represents a different phase of respiration of the patient.
  • User sends 4D respiratory correlated CT/MRI/PET/… images of the abdomen for planning a free breathing pancreas radiotherapy plan.
  • The treatment planning system is expecting that the inhale phase is tagged “0%” and the exhale phase as “50%” with other phases with corresponding tags.
  • 4D respiratory correlated data instead sends text descriptions of “inhale” and “exhale”.
  • User is required to edit series descriptions to add the text “0%” or “50%” for correct interpretation by the planning system.

4. Standards and Systems

Systems

  • Acquisition Modality (CT, MR, etc)
  • PACS
  • Treatment Planning System

Standards

  • DICOM IODs
  • Series Description is currently being used as a workaround.
  • Respiratory Syncronization Macro is perhaps the correct technical solution
  • DICOM WG7 may also be working on a future solution


5. Technical Approach

<This section can be very short but include as much detail as you like. The Technical Committee will flesh it out when doing the effort estimation.>

<Outline how the standards could be used/refined to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>

<If a phased approach would make sense indicate some logical phases. This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>

Existing actors

<Indicate what existing actors could be used or might be affected by the profile.>

New actors

<List possible new actors>

Existing transactions

<Indicate how existing transactions might be used or might need to be extended.>

New transactions (standards used)

<Describe possible new transactions (indicating what standards might be used for each).>

<Transaction diagrams are very helpful here. Go into as much detail as seems useful.>

Impact on existing integration profiles

<Indicate how existing profiles might need to be modified.>

New integration profiles needed

<Indicate what new profile(s) might need to be created.>

Breakdown of tasks

<As the basis for the effort estimation, enumerate the tasks to develop the Profile text. E.g.>

  • <Discuss/Confirm use case list (currently 5) to decide in/out of scope and details>
  • <Analyze/choose which report guidelines to use>
  • <Resolve open issue on the degree of computer parsability>
  • <Draft/Review content definition for Oncology Report (profile use of CCDA)>
  • <Draft/Review transaction for Retrieve Report>

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

<Identify anyone who as indicated an interest in implementing/prototyping the Profile if it is published this cycle.>

7. Risks

<List technical or political risks that will need to be considered to successfully field the profile. Demonstrate to the TC/PC your understanding/appreciation of the problem space>

8. Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

9. Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Cmte Bandwidth):

  • 35% for ...

Candidate Editor:

TBA