Private groups removal

[Jordi]

Hi everyone,

I have set on of my pipelines' anonymizer configuration to "Remove private groups" to try it out, understanding that it would make the anonymizer service to remove all private groups elements. But when I started processing data with some private metadata the following occurred: All private tags were nicely remove except for 'PrivateCreator' ones (XXXX,0010), (XXXX,0011), which are kept. There's probably a (good) reason for doing so, can anybody please tell me why? Cannot be harmful to keep such tags without handling what's inside? Or is just an unintended behavior of CTP (bug)?

Is CTP maybe following the "keep known safe private" concept? Understanding safe private attributes (i.e. Private creators) as those that are known not to contain individually identifiable information?

[Example] 

   Original file,

(0029,0010) LO [SIEMENS CSA HEADER]                      #  18, 1 PrivateCreator

(0029,0011) LO [SIEMENS MEDCOM HEADER2]            #  22, 1 PrivateCreator

(0029,1008) CS [...]                                                        #  12, 1 CSAImageHeaderType

(0029,1009) LO [...]                                                        #   8, 1 CSAImageHeaderVersion

(0029,1010) OB ...                                                         # 9364, 1 CSAImageHeaderInfo

(0029,1018) CS [MR]                                                     #   2, 1 CSASeriesHeaderType

(0029,1019) LO [...]                                                       #   8, 1 CSASeriesHeaderVersion

(0029,1020) OB ...                                                        # 64768, 1 CSASeriesHeaderInfo

(0029,1160) LO [...]                                                      #   4, 1 SeriesWorkflowStatus

   Anonymized file,

(0029,0010) LO [SIEMENS CSA HEADER]                     #  18, 1 PrivateCreator

(0029,0011) LO [SIEMENS MEDCOM HEADER2]                 #  22, 1 PrivateCreator

By the way, I have the following version: "CTP Build: 2014.03.05 at 10:09:22 CST on Java 1.6". 

Thanks in advanced,

Jordi

[John Perry]

The CTP anonymizer keeps the private creator elements intentionally. As described in http://mircwiki.rsna.org/index.php?title=The_CTP_DICOM_Anonymizer#Precedence, instructions for individual elements take precedence over global commands, and global keep commands take precedence over global remove commands. It is therefore possible to construct a complex set of individual and global keep and remove commands for private data elements that would require the private creator elements to be kept even though the instructions say to remove them. I decided that the safe path was just to keep them always.

 

It might be possible to create an individual remove instruction for a private creator element and thus remove it. I don’t think I ever tested that.

 

JP

--
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.

[Jordi]

Thanks for your prompt answer John,

I see what you mean and is good to know it. I believe in rare cases it might become an issue to keep those, nevertheless and from an output data perspective I see no point on keeping such private group descriptors when no private data is to be processed by the service and/or as far as the rest of the group's attributes are removed. 

To modify the normal behavior of CTP I understand I should include all my potentially-present private groups' privateCreator tags in the DICOM anonymizer script and process them individually. The problem is that I am not supposed to know on beforehand which private data groups might be present in my input datasets. 

Thanks for your aid anyway.

regards,

Jordi

To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user-group+unsub...@googlegroups.com.

[John Perry]

Since the private creator tags don’t contain PHI, I see no harm in keeping them, and there is potential harm in deleting them, so I think what we’re doing makes sense.

To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user...@googlegroups.com.