LGG-1p19qDeletion: conversion of NIfTI segmentations into DICOM SEG

[fedorov]

Collection: https://doi.org/10.7937/K9/TCIA.2017.dwehtz9v

Data description: These MRIs are pre-operative examinations performed in 159 subjects with Low Grade Gliomas (WHO grade II & III). Segmentation of tumors in three axial slices that include the one with the largest tumor diameter and ones below and above are provided in NiFTI format. Tumor grade and histologic type are also available. All of these subjects have biopsy proven 1p19q results, performed using FISH. For the 1p/19q status "n/n" means neither 1p nor 19q were deleted. "d/d" means 1p and 19q are co-deleted.

[fedorov]

Segmentations uploaded to this folder: https://console.cloud.google.com/storage/browser/tcia-idc-datareviewcoordination/issue-1/?project=idc-tcia

I also tested one dataset, and segmentations seem to line up with the part of the image consistent with tumor in Slicer.

The main challenge at the moment is that segmentations are shared without including reference to the MR series they correspond to. Each patient has 2 MR series, with SeriesDescription not initialized consistently. Also, there is no discussion in the documentation of the dataset whether tumor was always segmented in the same sequence type or not. I am going to see if I can use details from segmentation image geometry (pixel spacing + number of slices + rows*columns) to map segmentation NIfTIs to the corresponding MR series for each patient. But - going forward - I recommend that TCIA asks data submitters to include this kind of information unambiguously at the time of submission of the derived datasets. Would this be possible, @kirbyju?

[fedorov]

Upon further investigation, it is not going to be possible to distinguish specific series based on combination of matrix resolution and pixel spacing, since there are at least some of the studies that have identical resolution and spacing.

The solution will probably be to reference all series for a given patient when resolution/spacing match that of the segmentation.

For the reference, a spreadsheet looking at the matrix/spacing is here: https://docs.google.com/spreadsheets/d/1xAscO55xry0V53NVjtgWwUTgJktn6k7r4AHgN8G7Gfs/edit?usp=sharing

[fedorov]

Converted segmentations are here: https://console.cloud.google.com/storage/browser/tcia-idc-datareviewcoordination/issue-1/DICOM_segmentations/?project=idc-tcia. Did selective verification, will do few more checks.

Script used to convert using dcmqi is here: https://console.cloud.google.com/storage/browser/tcia-idc-datareviewcoordination/issue-1/scripts/?project=idc-tcia

@kirbyju FYI issues identified during conversion:

• (minor) inconsistent naming of the segmentation files for subjects 223, 310, 326, 344, 348
• subject 518 has 4 slices segmented, using 2 different labels:
• subject 223 segmentation file is not a segmentation:

@dclunie I am using the following to describe segmentation (I know I should replace with SCT codes):

      "SegmentedPropertyCategoryCodeSequence": {
          "CodeValue": "M-01000",
          "CodingSchemeDesignator": "SRT",
          "CodeMeaning": "Morphologically Altered Structure"
        },
        "SegmentedPropertyTypeCodeSequence": {
          "CodeValue": "M-8FFFF",
          "CodingSchemeDesignator": "SRT",
          "CodeMeaning": "Neoplasm"
        }

Is there anything we can do to indicate that those segmentations are not of complete finding, but just 3 slices (specifically, citing the collection wiki page: "Segmentation of tumors in three axial slices that include the one with the largest tumor diameter and ones below and above are provided").

[kirbyju]

@fedorov did you already approach Brad regarding these issues? Or would you prefer that we do it?

[fedorov]

@kirbyju I think it is easier if I do it, BUT I will cc you, and I would appreciate if you guys follow up if there is no response.

It would be equally helpful if you followed up on the communication with Nick Heller re #2 - I emailed him twice, but did not hear back. Maybe you will have better luck?

[fedorov]

Per @dclunie , there is no standard way to indicate that segmentation is not for the entire finding.

[fedorov]

@dclunie would it be acceptable to have a code equivalent to "Partial" assigned to "Segmented Property Type Modifier"? Since it allows for multiple modifiers, this would be a minimal and non-breaking change.

[fedorov]

[dclunie]

@fedorov, yes, I think doing this as a modifier makes sense (both for SEG as well as RTSS and SR) ... see the attached proposed DICOM CP for codes and structures. cp_dac544_Extensiveness.pdf

[fedorov]

Sounds good, thank you.

To me, "Extensiveness" does not sound like the right concept for this, but I did read the preamble on the CP, and I can't think of a term I would prefer instead. "Extent" would not work, right?

[dclunie]

I don't think so ... the SNOMED relationships are shown in the attached screenshot

[fedorov]

On the topic of the MR series that was used for creating the segmentation - communication with the author, Brad Erickson (in chronological order, just for the sake of keeping those bits in a single place visible to others).

[fedorov]

The dataset received from Brad turned out to be incomplete, waiting for the missing segmentations.

[fedorov]

This week updated dataset received from Brad, now with 158 segmentations, so just need to do the conversion now ...

https://console.cloud.google.com/storage/browser/tcia-idc-datareviewcoordination/issue-1/Revised_segmentations_from_Drive/?forceOnBucketsSortingFiltering=false&project=idc-tcia

[fedorov]

Converted segmentations are in https://console.cloud.google.com/storage/browser/tcia-idc-datareviewcoordination/issue-1/DICOM_Segmentations_20200504/?forceOnBucketsSortingFiltering=false&project=idc-tcia

DICOM store with images and segmentations: idc-tcia/issues/issue1-1p19q

OHIF visualization confirmed:

https://idc-sandbox-000.firebaseapp.com/projects/idc-tcia/locations/us/datasets/issues/dicomStores/issue1-1p19q/study/1.3.6.1.4.1.14519.5.2.1.3344.2526.176385223083190446159647826451

https://idc-sandbox-000.firebaseapp.com/projects/idc-tcia/locations/us/datasets/issues/dicomStores/issue1-1p19q/study/1.3.6.1.4.1.14519.5.2.1.3344.2526.871705010486651831957949593409

[fedorov]

@kirbyju I put the segmentations in a Box folder (here: https://app.box.com/s/gjpefbxsiuyde2lf3y9ux36w131vx3oo), and shared with you. Let me know if I should do anything else.

[kirbyju]

It sounds like Brad had to fix the input NIFTI data before your conversion. I don't think he has provided a copy of the corrected NIFTI data to us. Could you also put these files in the same box folder? And do you have a brief (2-3 sentences?) explanation of what he fixed before you did the conversion so that we can make a note in the "versions" tab for this collection?

[fedorov]

Justin, Brad put them in this folder - https://drive.google.com/drive/folders/13KDdXBln8vwDbwbxaHYLy20fS4Px3dxF?usp=sharing.

As I understand, he re-did all of the segmentations to be volumetric, instead of fixing the few that were missing.

Relevant communication from Brad on file naming (from this email):

---

Andrey:

some cases have files named like this:

LGG-104-OldSegmentation.nii.gz LGG-104_T1.nii.gz LGG-104-Segmentation.nii.gz LGG-104_T2.nii.gz

while others have this pattern:

LGG-651-NewSegmentation.nii.gz LGG-651_T1.nii.gz LGG-651-Segmentation.nii.gz LGG-651_T2.nii.gz

Which segmentation files should I be using?

Brad:

I think ‘Segmentation.nii.gz’ is the correct file. The other names are left-overs when I played with some semi-autmoated segmentations.

[kirbyju]

Ok, thanks. I think we're good. I'll ask Kirk to assign this to one of our curation teams.

[fedorov]

TODO: run conversion from SEG and do pixel-wise comparison with NIfTI ...