1. Slicer DICOM browser suggestions Andras Lasso

2. #1. Patient list has to be wide. It cannot be limited to the module window, because that is typically just about ¼ of the screen. Make it a full-screen (dockable) window? #2. Different levels (patient/study/series/image) require different column headings. Dummy header items could be inserted into the tree (see next slide) #5. Which levels to keep? Patient&study levels are often merged. #6. Need to show tag names as well #3. There should be a delete button #9. Unclear if these fields belong to the selected study, series, or image #4. There should be filtering controls here #7. Load button should be in a prominent place (somewhere bottom&right) #8. It would be better to have the thumbnails in the second or third column (after the “load list”), as the “load list” is more important #10. Probably the “load list” cannot be instantly generated (need to call all the DICOM plugin modules to find out what can be loaded)

3. Dummy items in the tree view as headings for lower-level items

4. Fields Which fields we should store in the database, which ones we should display, and how to determine the values from the DICOM files? (see analysis in DicomPatientBrowserFields.xlsx)DicomPatientBrowserFields.xlsx Complex logic: the same displayed field (such as series description) should be loaded from different DICOM fields (depending on the IOD type) Patient and study level information may be missing form certain series (typically it’s there in images, but not in other objects, such as structure sets) A study with the same UID may have different attributes in different files (it should not happen) Should we allow adding comments or editing of displayed fields?