Enhance DICOM Series Selection Operator

[rahul-imaging]

User Story
As an application developer I would like to be able to select a subset of DICOM Series given one or more DICOM Studies. My selection criteria are based on conditions imposed on DICOM attributes embedded in the SOP instances that belong to one or more series

Background
Often an app developer needs to do some work to identify what type of medical images are applicable given an AI model. As data flows in from sources such as modality or PACS, it becomes challenging to automatically select what data needs to be provided so that an AI model can ingest to produce correct result. As of v0.1.0, this operator always returns the first series given a Study

Success Criteria

• A way to specify selection criteria using key value pairs of DICOM Attributes
• A way to parse through DICOM datasets and identify the right study --> series --> sop instance sets given the criteria
• An example application that showcases such series selection using this operator
• Updated API documentation for the operator
• Unit Test cases that exercise multiple scenarios for this Operator

[CPBridge]

Leaving some thoughts here on series selection capabilities that will be required or highly desirable:

• Ability to allow ranges of numerical tags as well as specific value. E.g. Slice Thickness BETWEEN 2.5mm and 5.0mm, Magnetic Field Strength GREATER THAN OR EQUAL TO 1.5T
• A special rule/operator to select axial/coronal/sagittal series based on the value of the ImageOrientationPatient tag. I can supply the logic needed here. Otherwise this task is a little fiddly for users (requiring some vector manipulation) despite being extremely common.
• Capability to rank series as well apply hard criteria. E.g. choose the image with the lowest value of Slice Thickness from the available series
• Filter out series whose geometry is inconsistent. If a series of images does not have consistent spacing between consecutive slices, it is certain to mess up any downstream volumetric analysis. This is an unfortunately common occurrence in my experience. Checking that the spacing between consecutive slices in the distance perpendicular to the imaging plane (ImageOrientationPatient) is consistent to within some small tolerance (0.05mm) can save a lot of headaches downstream. I'm happy to supply the logic here also.
• Capability to remove individual instances of series where the value of some attribute(s) do not match the rest of the series. For example, there are often series where one or two instances have a different ImageOrientationPatient to the rest of the instances in the series. Typically these are localizer images that should be discarded before analysis

Feel free to assign specific tasks from this to me once the way rules should be specified are sorted out.

Overall, the complexity of series selection is absolutely not to be underestimated. I would suggest that we have classes implementing individual series selection steps that can be composed by the user to form a series selection pipeline in the DICOMSeriesSelector, much like transforms are composed in MONAI Core. The ability to extend via subclassing would be extremely helpful for the trickier situations that may need custom logic.

[dbericat]

@MMelQin @rahul-imaging how are we planning to act upon @CPBridge 's requests? Should we create an issue per request? If so, then @CPBridge could create a PR for #2 and #4 as he seems to have the logic clear? Thoughts?

[MMelQin]

The series selection operator, as describes in the doc and release note, provides a default implementation and can be used as a base class for derived classes for supporting custom and more advanced processing engines.
The Domain classes were introduced partly for this reason and partly for supporting chaining of the series selection operators.
The App SDK provides the framework and bases, anticipating more advanced and derived implementations/contributions.

Hope this answers your question, @dbericat.

[dbericat]

It does. @CPBridge do you feel you know what to do to add your RFEs based on @MMelQin's comments?

[MMelQin]

Marking this one as closed as it has satisfied the original requests, after having created a new issue recording the RFE's from @CPBridge, as well as other the planned traditional computer vision based algorithms to aid the advanced series selection development.

[CPBridge]

It does. @CPBridge do you feel you know what to do to add your RFEs based on @MMelQin's comments?

I think so. For special cases such as view selection (axial/sagittal/coronal) I think this approach of subclassing and overriding filter makes sense. However I still feel that ranges (e.g. Slice Thickness between 1 and 5mm) would be better handled in this base class. Could we somehow add in this functionality in how the conditions are specified. E.g.:

{
    "selections": [
        {
            "name": "CT Series 1",
            "conditions": {
                "StudyDescription": "(?i)^Spleen",
                "Modality": "(?i)CT",
                "SeriesDescription": "(?i)^No series description|(.*?)",
                "SliceThickness": {"range_minimum": 1, "range_maximum": 5}
            }
        }
    ]
}

Thoughts @MMelQin ?

[MMelQin]

@CPBridge It is a good suggestion , and needed in practice. I considered it, but decided delaying the implementation till later releases, for the few reasons below,

• This current implementation supports the DICOM General Series Module Attributes only, and not even all of them but limited to the attributes exposed in the DICOMSeries domain class. The DICOMSeries does have reference to all SOP instances, so later we can expand the support.
• The Slice Thickness is an attribute in the Image Plane Module, Type 2 attribute, and may not be set or present. In the App SDK, the Slice Thickness attribute is actually recalculated in the downstream SeriesToVolume operator, and set as metadata on the converted image object.
• Need to introduce a range evaluator, which should work for this attribute as well as in general, e.g. date range. I did not have sufficient time to gather all the scenarios to create a solution.

[dbericat]

Great discussion. This looks to me like a nice issue @CPBridge could also work on a PR for 0.3 release? :D