Add new extension SlicerDeid

[payabvashlab]

https://github.com/payabvashlab/SlicerDeid

New extension

Tier 1

Any extension that is listed in the Extensions Catalog must fulfill these requirements.

• [ X] Repository name is Slicer+ExtensionName (except if the repository that hosts the extension can be also used without Slicer)
• [ X] Repository is associated with 3d-slicer-extension GitHub topic so that it is listed here. To edit topics, click the settings icon in the right side of "About" section header and enter 3d-slicer-extension in "Topics" and click "Save changes". To learn more about topics, read https://help.github.com/en/articles/about-topics
• [ X] Extension description summarizes in 1-2 sentences what the extension is usable (should be understandable for non-experts)
• [ X] Any known related patents must be mentioned in the extension description.
• [ X] LICENSE.txt is present in the repository root and the name of the license is mentioned in extension homepage. We suggest you use a permissive license that includes patent and contribution clauses. This will help protect developers and ensure the code remains freely available. MIT (https://choosealicense.com/licenses/mit/) or Apache (https://choosealicense.com/licenses/apache-2.0/) license is recommended. Read here to learn more about licenses. If source code license is more restrictive for users than MIT, BSD, Apache, or 3D Slicer license then describe the reason for the license choice and include the name of the used license in the extension description.
• [ X] Extension URL and revision (scmurl, scmrevision) is correct, consider using a branch name (main, release, ...) instead of a specific git hash to avoid re-submitting pull request whenever the extension is updated
• [ X] Extension icon URL is correct (do not use the icon's webpage but the raw data download URL that you get from the download button - it should look something like this: https://raw.githubusercontent.com/user/repo/main/SomeIcon.png)
• [ X] Screenshot URLs (screenshoturls) are correct, contains at least one
• [ X] Content of submitted json file is consistent with the top-level CMakeLists.txt file in the repository (dependencies, etc. are the same)
• Homepage URL points to valid webpage containing the following:
  • [ X] Extension name
  • [ X] Short description: 1-2 sentences, which summarizes what the extension is usable for
  • [ X] At least one nice, informative image, that illustrates what the extension can do. It may be a screenshot.
  • [ X] Description of contained modules: at one sentence for each module
  • [ X] Publication: link to publication and/or to PubMed reference (if available)
• Hide unused github features (such as Wiki, Projects, and Discussions, Releases, Packages) in the repository to reduce noise/irrelevant information:
  • [ X] Click Settings and in repository settings uncheck Wiki, Projects, and Discussions (if they are currently not used).
  • [ X] Click the settings icon next to About in the top-right corner of the repository main page and uncheck Releases and Packages (if they are currently not used)
• The extension is safe:
  • [ X] Does not include or download binaries from unreliable sources
  • [ X] Does not send any information anywhere without user consent (explicit opt-in is required)

Tier 3

Community-supported extensions.

• Extension has a reasonable name (not too general, not too narrow, suggests what the extension is for)
• Documentation, tutorial, and test data are provided for most modules. A tutorial provides step-by-step description of at least the most typical use case, include a few screenshots. Any sample data sets that is used in tutorials must be registered with the Sample Data module to provide easy access to the user.
• Follows programming and user interface conventions of 3D Slicer (e.g., GUI and logic are separated, usage of popups is minimized, no unnecessary custom GUI styling, etc.)
• The extension can be successfully built and packaged on all supported platforms (Windows, macOS, Linux)
• Maintainers respond to issues and pull request submitted to the extension's repository.
• Maintainers respond to questions directly addressed to him/her via @mention on the Slicer Forum.
• Permissive license is used for the main functions of the extension (recommended Apache or MIT). The extension can provide additional functionality in optional components that are distributed with non-permissive license, but the user has to explicitly approve those before using them (e.g., a pop-up can be displayed that explains the licensing terms and the user has to acknowledge them to proceed).
• All requirements of tiers < 3.

Tier 5

Critically important extensions, supported by Slicer core developers. New Slicer Stable Release is released only if all Tier 5 extension packages are successfully created on all supported platforms.

• Slicer core developers accept the responsibility of fixing any issues caused by Slicer core changes; at least one Slicer core developer (anyone who has commit right to Slicer core) must be granted commit right to the extension's repository.
• Automated tests for all critical features.
• Maintainers respond to questions related to the extension on the Slicer Forum.
• All requirements of tiers < 5.

[fedorov]

I looked at the repository, and there is no information about what exactly it does and how.

"This is a Slicer extension to anonymize a 'batch' of head DICOM CT images."

What do you mean by that?

[payabvashlab]

Thank you very much for your comment.
We updated information and methods:

Head Computed Tomography (CT) scans contain identifiable data in Digital Imaging and Com-munications in Medicine (DICOM) metadata as well as facial features, raising privacy concerns. This demonstrates the need for effective de-identification tools to protect patient privacy. =>This is a Slicer extension removing Personally Identifiable Information (PII) from both metadata and image content. The de-tagging procedure has been shown to be effective and accurate on multiple head CT datasets, whereas morphology-based or AI-based methods have effectively reduced the visibility of faces in images without significantly affecting the diagnostic quality of the scans.

Our method: The de-identification process in this study consisted of three main steps: reading the DICOM file, re-de-identifying sensitive tags from the metadata, and removing facial features from the image. First, a DICOM reader accessed and loaded the CT data, and specific metadata tags containing identifiable information were removed. For image-based de-identification, a morphology-based and artificial intelligence-based method was applied to detect and blur facial structures, enhancing privacy while preserving relevant diagnostic information.

[pieper]

@payabvashlab thank you for the contribution 🙏 and also for the extra text clarifying what what the extension does.

In order to give potential users some context, I think you should also include a note indicating that de-identification is a complex topic and that this extension addresses a specific use case.

I think you should also include links to these documents for people who want to know more:

https://pmc.ncbi.nlm.nih.gov/articles/PMC10081345/

https://dicom.nema.org/medical/dicom/current/output/html/part15.html#chapter_E

[payabvashlab]

Yes, thank you very much.
We updated:
More information about DICOM Standards
https://dicom.nema.org/medical/dicom/current/output/html/part15.html#chapter_E

References:
[1] David A Clunie 1, Adam Flanders 2, Adam Taylor 3, Brad Erickson 4, Brian Bialecki 5, David Brundage, et. al., (2023). Report of the Medical Image De-Identification (MIDI) Task Group - Best Practices and Recommendations, arXiv:2303.10473v2
[2] Scott A. Collins, Jing Wu, Harrison X. Bai. (2020). Facial De-identification of Head CT Scans. Radiology, 296(1), doi:10.1148/radiol.2020192617

[fedorov]

Our method: The de-identification process in this study consisted of three main steps: reading the DICOM file, re-de-identifying sensitive tags from the metadata, and removing facial features from the image. First, a DICOM reader accessed and loaded the CT data, and specific metadata tags containing identifiable information were removed. For image-based de-identification, a morphology-based and artificial intelligence-based method was applied to detect and blur facial structures, enhancing privacy while preserving relevant diagnostic information.

@payabvashlab the description above is absolutely not sufficient.

De-identification of DICOM metadata is complex topic.

Your description does not provide any details of what exactly you do for "re-identifying sensitive tags from the metadata". The reference you inserted in the previous comments describes the part of the DICOM standard that defines how de-identification of DICOM metadata should be done. You must include a statement of how your de-identification procedures compare to what is defined in the standard.

A description like the one you provided can create a false sense of security in the users of your tool, which can be extremely dangerous.

Note that there is already a Slicer extension serving similar purpose: https://github.com/hina-shah/SlicerBatchAnonymize.

There are also several python libraries that have been around for quite some time:

• https://github.com/pydicom/deid
• https://github.com/KitwareMedical/dicom-anonymizer
• https://github.com/blairconrad/dicognito
• https://github.com/RSNA/anonymizer

You need to justify why you are introducing a new extension and a new method (and if you are using any of the above, you should say so) for de-identification, potentially confusing the users and arguably increasing risks for inadvertent exposure of patient data.

[payabvashlab]

Yes, thank you very much for your comments.
We update and give more details:
-Our module focus on removing Personally Identifiable Information (PII) from head CT dicom
and the contributions of our module is to remove PII from metadata, face [2], and text within images.
It is different from other tools.
-We also give the tag list that we check and remove

[fedorov]

and removing facial features from the image

Aside from DICOM metadata de-id, you should inform the user how you are "removing facial features", and how you validated your approach.

Again, there are several open source, validated and published solutions for facial de-identification - with some being not CT-specific!

• https://surfer.nmr.mgh.harvard.edu/docs/synthstrip/
• https://pmc.ncbi.nlm.nih.gov/articles/PMC7943842/
• https://doi.org/10.1016/j.neuroimage.2021.117845

What is the justification for coming up with another defacing algorithm, and offering it to the users without any validation of its robustness?

If you were introducing yet another segmentation tool, I would not scrutinize your submission at all, but in this case the risk of potential damage is too significant to not require supporting evidence and rigor in describing the details of your approach, and adding very prominent warnings for the users of your tool.

[payabvashlab]

Thank you very much for your comment.
as we cite, we follow the method of paper [2]. The implement code of paper: https://github.com/kitamura-felipe/face_deid_ct
The idea of de-face:

• eroding the skin and subcutaneous fat of the head
• replacing the air around the head with a customizable pixel value.

[2] Scott A. Collins, Jing Wu, Harrison X. Bai. (2020). Facial De-identification of Head CT Scans. Radiology, 296(1), doi:10.1148/radiol.2020192617
[3] https://github.com/kitamura-felipe/face_deid_ct

Please check. Thank you

[payabvashlab]

Yes, we also updated the warning when using our tools:
There is a risk of accidental exposure of patient information if de-identification is not performed correctly. Always double-check the output before sharing or using the data.
Thank you very much for your help.