Segment Identification Sequence is required in Shared Functional Groups Sequence

[vsaase]

Hi,

I just tried to view a DICOM Segmentation I created with itkimage2segimage in OHIF viewer with DICOM-segmentation extension. It tells me that SharedFunctionalGroupsSequence.SegmentIdentificationSequence is undefined, and indeed it is missing in the produced DICOM file. The standard says that this field is required: http://dicom.nema.org/medical/Dicom/2018d/output/chtml/part03/sect_C.8.20.3.html

This is my JSON file:

{
  "ContentCreatorName": "Reader1",
  "ClinicalTrialSeriesID": "Session1",
  "ClinicalTrialTimePointID": "1",
  "SeriesDescription": "Segmentation",
  "SeriesNumber": "300",
  "InstanceNumber": "1",
  "BodyPartExamined": "Prostate",
  "segmentAttributes": [
    [
      {
        "labelID": 1,
        "SegmentDescription": "Prostate",
        "SegmentAlgorithmType": "MANUAL",
        "SegmentedPropertyCategoryCodeSequence": {
          "CodeValue": "123037004",
          "CodingSchemeDesignator": "SCT",
          "CodeMeaning": "Anatomical Structure"
        },
        "SegmentedPropertyTypeCodeSequence": {
          "CodeValue": "41216001",
          "CodingSchemeDesignator": "SCT",
          "CodeMeaning": "Prostate"
        },
        "recommendedDisplayRGBValue": [
          230,
          158,
          140
        ]
      }
    ]
  ],
  "ContentLabel": "SEGMENTATION",
  "ContentDescription": "Image segmentation",
  "ClinicalTrialCoordinatingCenterName": "dcmqi"
}

Thanks, Victor

[fedorov]

@vsaase I see your point, and I agree that SegmentIdentificationSequence, in the case of a single segment, could have been encoded in the SharedFunctionalGroups sequence.

But there is no requirement that items that are identical across frames must be included in the SharedFunctionalGroups. Instead, the receiving application should be robust to consider both per-frame and shared. I do not think this is a bug, and if you run @dclunie dciodvfy validator, you can confirm those objects are correct.

I admit I did not think about this when we worked on the converter, and whether it was a conscious decision to keep SegmentIdentificationSequence in case of a single segment in the per-frame, or it just slipped through our initial testing. Perhaps @michaelonken can comment on that. But I do not think this is a bug, there are a lot of objects that follow this convention, and I believe the robustness of the receiving application should be improved in this situation.

You mentioned a problem with OHIF Viewer, but this is most likely a regression in a specific version of the viewer. As you can see for this dataset hosted in Imaging Data Commons: https://viewer.imaging.datacommons.cancer.gov/viewer/1.3.6.1.4.1.14519.5.2.1.6279.6001.224985459390356936417021464571?seriesInstanceUID=1.2.276.0.7230010.3.1.3.0.57823.1553343864.578877,1.3.6.1.4.1.14519.5.2.1.6279.6001.273525289046256012743471155680 (linked from the front page of IDC https://imaging.datacommons.cancer.gov/), that example of DICOM SEG has SegmentIdentificationSequence in per-frame, and is handled by the viewer without problems. You may want to report the issue, if it is reproducible in the latest version of OHIF, in the OHIF bug tracker, and we will make sure it is addressed.