search

didymo / OnkoDICOM

OnkoDICOM was created with Radiation Oncologists to allow Radiation Oncologists to do research on DICOM standard image sets (DICOM-RT, CT, MRI, PET) using open source technologies, such as pydicom, dicompyler-core, PySide6, PIL, and matplotlib. OnkoDICOM is cross platform, open source software, and welcomes contributions. OnkoDICOM was inspired by dicompyler.
https://onkodicom.com.au
GNU Lesser General Public License v2.1
60 stars 41 forks source link

SOP Class UID for RT Ion Plan is not supported #9

Closed sjswerdloff closed 4 years ago

sjswerdloff commented 4 years ago

The use of RT Plan is currently limited to sequences that are shared with RT Ion Plan. Support for RT Ion Plan would only require addition of the SOP Class UID as a match...

In src/View/ProgressBar.py: 175 (approximately) and In src/Model/LoadPatient.py: 100 (approximately)

Current code:

                    elif read_file.SOPClassUID == '1.2.840.10008.5.1.4.1.1.481.5':
                        self.read_data_dict['rtplan'] = read_file
                        self.file_names_dict['rtplan'] = file

Proposed code change:

                    elif read_file.SOPClassUID == '1.2.840.10008.5.1.4.1.1.481.5':
                        self.read_data_dict['rtplan'] = read_file
                        self.file_names_dict['rtplan'] = file
                    elif read_file.SOPClassUID == '1.2.840.10008.5.1.4.1.1.481.8':
                        self.read_data_dict['rtplan'] = read_file
                        self.file_names_dict['rtplan'] = file

While there aren't quite as many Particle Therapy centers as conventional, for a few lines of code it would be nice to have the support.

oismaster commented 4 years ago

Dear Stuart,

Really good to see you on board!

Just as an initial start, I should explain that currently the team is made up of software engineers and me (radiation oncologist), so there is lots about DICOM knowledge in the RO space that you have but we don't. I am engaging some of our local ROMPs but would love more to come on board.

I think that I get what the 'deficiency' is, and I agree with you that Particle Therapy Centres should be able to use OnkoDICOM also. If I have the issues correct my questions should make sense, so am I right in the following statements?

  1. Proton & C ion plans are stored as RTIONPLANs, not as RTPLANs,
  2. RTPLAN & RTIONPLAN structures are identical
  3. The dose unit differs (RTPLAN in cGy; RTIONPLAN in cGyE (equivalent)

And answers to these questions?

  1. Is there any occasion where a DICOM-RT dataset will have an RTPLAN and an RTIONPLAN together?
  2. If an RTPLAN and an RTIONPLAN can occur together, do they ever need to be overlain?

And a request?

  1. Can you get an anonymised & dead patient Proton/C ion DICOM-RT to put out for test? (I'll put out some of my anonymised DICOM-RT datasets soon)

I ask this because this is the information that the rest of the team need to understand why a change should be made.

I have a long list of changes to be made to the OnkoDICOM base as it appears today. I can share these with you, or should they be put onto the Github site? Happy for the advice.

A

sjswerdloff commented 4 years ago

Dear Stuart,

Really good to see you on board!

Just as an initial start, I should explain that currently the team is made up of software engineers and me (radiation oncologist), so there is lots about DICOM knowledge in the RO space that you have but we don't. I am engaging some of our local ROMPs but would love more to come on board.

I think that I get what the 'deficiency' is, and I agree with you that Particle Therapy Centres should be able to use OnkoDICOM also. If I have the issues correct my questions should make sense, so am I right in the following statements?

1. Proton & C ion plans are stored as RTIONPLANs, not as RTPLANs,

Correct. And the RT Ion Plan Storage SOP Class UID is: 1.2.840.10008.5.1.4.1.1.481.8

  1. RTPLAN & RTIONPLAN structures are identical

No. They are not, however, for the Modules/Sequences that the current OnkoDICOM application uses, the exact same sequences and elements are present. My suggestion came after I made the modification and ran against sample data that I have.

  1. The dose unit differs (RTPLAN in cGy; RTIONPLAN in cGyE (equivalent)

The dose units depend on what is expressed. So GyE (now referred to as Effective) is a common option in RT Ion Plan, and in RT Dose, "Dose Type" (3004,0004) is often set to EFFECTIVE. Formally, the Beam Dose Type (300A,0090) in the Referenced Beam Dose sequence in RT and RT Ion Plan is used to express whether the dose is PHYSICAL or EFFECTIVE. There is now also the Alternate Beam Dose (300A,0091) and the Alternate Beam Dose Type (300A,0092) so that one can express both the PHYSICAL dose and the EFFECTIVE dose for a beam, although some will argue that an individual beam does not have an EFFECTIVE dose without being considered in context with the other beams. I am of the opinion that the value in the book-keeping is sufficient to warrant treating the individual beams as if they do have their own independent EFFECTIVE dose. In the commercial product I am most familiar with, the Beam Dose is considered to be PHYSICAL, and conversion to EFFECTIVE is addressed through scaling of the value provided elsewhere (either a constant for Protons, which is nominally 1.10, or a separately defined RBE value, per Beam). But the standard is now sufficient in its allowing clear expression of the appropriate interpretation.

And answers to these questions?

1. Is there any occasion where a DICOM-RT dataset will have an RTPLAN and an RTIONPLAN together?

It is not uncommon for there to be both RT Plan and RT Ion Plan used in determining treatment for the same patient using the same RT Structure Set and CT. There are "alternate" plans (preference given to treatment with particles (RT Ion Plan), but in the event the equipment is not available, then treatment with conventional/Photon (RT Plan)). There are also "boost" plans, where the RT Ion Plan is used to deliver a boost when conventional therapy would result in too high a dose to Organ At Risk. But in either case, there will be a different RT Dose object for each plan (and perhaps a composite dose object whose Dose Type is necessarily EFFECTIVE for it to be clinically meaningful). However, I imagine that the primary use case when using a tool such as OnkoDICOM would be in separate data sets (it's not that hard for someone to just copy or soft link the CT and RT SS in to a separate directory).

2. If an RTPLAN and an RTIONPLAN can occur together, do they ever need to be overlain?

The plans themselves do not need to be seen together. The dose from the two individual plans does need to be reviewed in the appropriate context (comparison for alternate plans, in combination for boost).

And a request?

1. Can you get an anonymised & dead patient Proton/C ion DICOM-RT to put out for test? (I'll put out some of my anonymised DICOM-RT datasets soon)

I will investigate. It may be easier for me to get data from a phantom. While that isn't as useful for Radiomics, it does allow for exercising the rest of the software.

I ask this because this is the information that the rest of the team need to understand why a change should be made.

I think the primary use case is for analysis across individual prescriptions (single RT Plan, RT SS, CT, RT Dose (of Dose Summation Type (3004,000A) PLAN)), and given that I was able to successfully add the RT Ion SOP Class UID and run against sample RT Ion Plan data sets that I have, it seems like low hanging fruit for gaining interest by a community that is highly research oriented already. I have a long list of changes to be made to the OnkoDICOM base as it appears today. I can share these with you, or should they be put onto the Github site? Happy for the advice.

In my opinion, Open Source should have open change request lists. While the authors and collaborators don't have an obligation to do anything specific about those lists, its a good way to find out what people are interested in, and if you open the project up to other collaborators, they are likely to put in pull requests that scratch their particular itch. I'm reading through how GitHub suggests collaboration, but if I understand correctly, the GitHub Flow is through forking, and then creating a pull request from a fork, but that doesn't make sense to me. I'm accustomed to being allowed to branch (from master, or whatever the working branch is if using a different flow technique), and then make a pull request in to master. But I'm also used to having the CI/CD environment being somewhat visible as well (in an Enterprise based situation, rather than a public project situation). Given that I wasn't quite ready to push forward and fork or request collaborator status, I just proposed code changes that I had already tried out in my own environment (described in a separate issue comment). I'm not a Python expert (but I've done more than toy coding in it, just for scripting, not for OOD), nor familiar with the public git based projects. I'm used to using Open Source, but I never learned how to contribute back (it was not typically in my expertise).

A