New CTP DICOM Anonymizer Feature

[John Perry]

A new CTP installer is available on the RSNA site at http://mirc.rsna.org/download/CTP-installer.jar.

The DICOM Anonymizer in this version has an internal index of safe private elements, and the DICOM Anonymizer Configurator has a "Keep safe private elements" checkbox allowing you to invoke the feature. The line appears at the end of the list of global keep commands near the bottom of the configurator window.

New installations and upgrades have updated default anonymizer scripts that include the "Keep safe private elements" command, but it is deselected for backward compatibility.

Upgrades do not automatically add the command to existing scripts. To add the command to an existing script, use the Edit menu in the configurator.

In any case, after adding the command to a script, you must check its box to enable it.

Steve Moore at Mallinckrodt Institute of Radiology maintains the list of safe private elements on behalf of the National Cancer Institute. I will try to keep CTP current with his index.

There are also new releases of CTPClient and ISN with the new anonymizer on the RSNA MIRC site.

JP

[Chuck Theobald]

Nice! Thanks, John!

Chuck

[Andrey Fedorov]

John,

This sounds like a great feature! I have few clarification questions:

- is there a URL with that safe private elements database that you use as the reference?

- what is the procedure of modifying the list of safe private elements used by CTP? Is it hard-coded, or somewhere in a config file?

- private elements depend on vendor and software version - how do you manage this? will CTP check the vendor/software version in the input data and apply rules accordingly? this would be tought!

AF

[Kirby, Justin (NIH/NCI) [C]]

Hi Andriy,

 

The index is in a file called PrivateTagIndex.xml contained in CTP/libraries/CTP.jar which will be updated in new releases.  The source of that information is coming from WUSTL’s team managing The Cancer Imaging Archive (specifically Steve Moore) which has been gathered in the process of de-identifying all the collections we post.  It does as you suspected in terms of keeping a vendor/software/version specific list of when elements are safe.  JP would have to discuss how that’s actually implemented in the CTP code if you’re curious.

 

We have discussed some options for allowing other people to add to the database in the past.  At this point I’m not convinced that any kind of complex process is worthwhile, so just talking to WUSTL and JP directly is probably the easiest way to propose new elements.  This may change to something more formal if we start to get lots of feedback down the road.

 

Justin

 

Justin Kirby

Bioinformatics Analyst III

Applied/Developmental Research Directorate

Frederick National Laboratory for Cancer Research

Leidos Biomedical Research, Inc.

Support to: Cancer Imaging Program

240-276-6016 office

240-367-3626 blackberry

justin...@fnlcr.nih.gov

 

Check out The Cancer Imaging Archive (TCIA) : a  large archive of medical images of cancer accessible for download.

 

Notice: This email and any attachments to it are intended only for the identified recipient.  It may contain proprietary or otherwise legally protected information for Leidos Biomedical Research, Inc.  Any unauthorized use or disclosure of this communication is strictly prohibited.  If you have received this communication in error, please notify the sender and delete or otherwise destroy the email and all attachments immediately.

--
You received this message because you are subscribed to the Google Groups "RSNA's CTP/MIRC User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrey Fedorov]

Thanks Justin! Very cool!

Can you explain the content of that xml file? I can only guess that vm and vr stand for DICOM value multiplicity and value representation, but not the rest... Is the format documented somewhere?

        <e

            code="KB"

            n="91"

            vm="N"

            vr="FL"/>

On Monday, March 30, 2015 at 10:12:15 AM UTC-4, John Perry wrote:

[John Perry]

I haven’t documented the schema yet because I want the flexibility to change it, The schema currently looks like this:

 

<Tags>

    <group

        block="BRAINWAVE: 1.2.840.113819.3"

        n="1001">

        <e

            code="X"

            n="11"

            vm="1"

            vr="SH"/>

        ...

    </group>

    ...
</Tags>

 

The group element’s n attribute specifies the group number. The block attribute specifies the PrivateCreatorElement value of the corresponding block.

 

The e element’s n attribute specifies the element number within the block.

 

If (1001,0003) contains BRAINWAVE: 1.2.840.113819.3, then the e element above refers to (1001,0311).

 

The e element’s code attribute refers to the action codes specified in PS 3.15 Appendix E. I think Steve Moore invented a couple of his own, but he told me that in a future release, he will return to using just those in Appendix E.

 

The CTP anonymizer considers a private element to be safe if its code is K. The anonymizer doesn’t use the vr or vm attributes; I just kept them in case I want them in the future.

 

As I look at the schema now, maybe it would have been prettier to structure it like this:

 

Tags

    Group

        Block

            Element

 

The PrivateTagIndex class is a singleton that keeps a static Hashtable indexed by a String in this form:

 

    1001,[BRAINWAVE: 1.2.840.113819.3]11

 

JP

 

From: Andrey Fedorov

Sent: Friday, May 08, 2015 7:49 AM

To: rsnas-ctpmir...@googlegroups.com

Subject: CTP-MIRC Group Re: New CTP DICOM Anonymizer Feature

 

--

[Andriy Fedorov]

Thank you John! This will be very helpful to related efforts we have in QIN.

I have two suggestions:

1) Would it make sense to include description of the tag in the schema?

2) Did you think about publishing this schema on github, to organize the process of contributing and tracking changes? 

I am very happy to help set up a github repository for this file if you need help (by the way, is CTP source code on github?). 

Basically, what this would allow is for people to propose changes as pull requests, explain the motivation and reference the source of information, such as the specific page in a specific DICOM conformance statement, so we would be able to track who did what change and why. I can give specific examples from other projects, if you are interested.

Let me know what you think.

The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[John Perry]

CTP is at https://github.com/johnperry

 

The PrivateTagIndex.xml file is at https://github.com/johnperry/CTP/blob/master/source/resources/PrivateTagIndex.xml

 

I don’t want to be the one to adjudicate what tags are safe. Steve Moore and the group at Mallinckrodt have a process that involves reading DICOM Conformance Statements, so I think their decision is ground truth – at least as far as ground truth exists. I’d rather have people send their documentation to Steve.

 

Justin Kirby suggested that I might extend the anonymizer to allow sites to supply a local index of safe private elements to overlay on the official one – just for their installation. Do you think that would be useful?

 

JP

[Tarbox, Lawrence]

John,

 

Just  a thought, but many toolkits (including the dcm4che version that CTP uses) simply hardcode the VR of private elements as UN.  Since you are capturing that information in the private tag index, it would be nice if the CTP Anonymizer also converted the VR from UN to the one in the table.

 

(Better would be the ability to include private tags in the dictionary of the underlying toolkit.  I’m not sure that is possible for dcm4che v1.)

 

Lawrence

---

The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

[Andriy Fedorov]

John, this makes sense. Thank you for the github pointer.

What do you think about the other suggestion about including the description of the private tag to make this resource more comprehensive?

[John Perry]

There is nothing currently in CTP that would use the description, but we could put it in there if people want it.

 

I wrote a program that reads Steve’s xlsx files and builds an intermediate XML structure from which the index used by CTP is abstracted. The intermediate data contains everything, including the description (processed into something like the DICOM standard keyword). The file intermediate file is attached.

[Andriy Fedorov]

I like this a lot John!

My motivation is to have a single, self-contained, structured resource
that could be reused as a lookup dictionary for people confused about
private tags. It would also help CTP users, as I might be interested
in, for example, preserving the tags that correspond to some
measurement of my interest, but I do not know where exactly that
measurement may be hiding.

What you have also seems to be easier to navigate than multiple xml
files you used to build it (and I didn't even know about the existence
of the source xml files!).

Are there any objections from this group about including the keys as
John did in the example attached?

[Tarbox, Lawrence]

TCIA (The Cancer Imaging Archive) maintains the private tag data as a public service. In addition to our own research using conformance statements and various contacts, we have been encouraging manufacturers to directly submit to us information about the private tags that they use. (See Item 3 in the Minutes of the November 29, 2012 of the DICOM Standards Committee, found at http://medical.nema.org/Dicom/minutes/Committee/2012/DSC-2012-11-29-Min.docx.) We publish the results of this research and information gathering into a knowledge base on TCIA's wiki at https://wiki.cancerimagingarchive.net/display/Public/De-identification+Knowledge+Base. We do not put anything into the knowledge base that has not been confirmed either by a manufacturer's DICOM Conformance Statement, or through correspondence with manufacturer representatives. On our wish list is to make the knowledge base more accessible and create tools to make it easier to maintain. But we do not have budget to do that. (Sadly, even non-profit universities still depend on money.)

Naturally, we are always on the lookout for contributions. If anyone has discovered information about private tags that is not in the Knowledge Base, especially if you have documentation from the creators of those private tags, we (TCIA) would love to get it. After reviewing and confirming the information, we'd be happy to add it to the knowledge base. Please contact us (e.g. send a note to he...@cancerimagingarchive.net) with any contributions of information. Please be sure to include the source of the information and your contact information, in case we have questions.

As mentioned by John, Steve Moore is the primary curator of the Knowledge Base.

Lawrence

[Andrey Fedorov]

Lawrence, this sounds like a great plan!

Let's keep the descriptions of the tags in John's xml for users' reference, but suggest users go through the TCIA vetting service for making modifications.

On Monday, March 30, 2015 at 10:12:15 AM UTC-4, John Perry wrote:

[John Perry]

LT:

 

Now that we have a dictionary containing the VR and VM for private elements, it occurs to me that we could add a feature to the DicomCorrector stage that would use the dictionary to fix the VRs of private elements (at least those that appear in the dictionary and that have the vr UN in the object).

 

Is this consistent with what you are suggesting?

 

JP

[Tarbox, Lawrence]

That would work.

 

For NBIA, certain of the private elements actually get added by the DICOM Anonymizer (e.g. the group 13 provenance info added to images submitted to NBIA).  One could also have the anonymizer add the VR. 

 

We would have to add the NBIA Group 13 stuff to the DB of safe private attributes.  I’ll talk to Steve about that.