Private tag anonymization differences between zip upload and dcmqr

[akluiber]

I'm experiencing a strange difference in results dealing with private tag sequences when uploading via the dicom zip uploader, vs importing via the dcmqr plugin.

I'm trying to retain the private dose information sequence in a Siemens Patient Protocol series image for later use. The relevant portion of  anonymization script is as follows:

//private tags
if ( (0008,103E) = "Patient Protocol" ){
   tagsToRetain := {
        (0029,{SIEMENS MEDCOM HEADER}40),
        (0029,{SIEMENS MEDCOM HEADER}41),
        (0029,{SIEMENS MEDCOM HEADER}42),
        (0029,{SIEMENS MEDCOM HEADER}43),
        (0029,{SIEMENS MEDCOM HEADER}44)
    }
    retainPrivateTags[tagsToRetain]
}
else{
    removeAllPrivateTags
}

When I query and pull in a study via the QR plugin, it breaks the dicom, compared to uploading the same image via zip uploader... These differences are apparent in the in the header output on XNAT's webUI and the dcmdump command line tool from dcm4che... See attached screenshots.

The only relevant errors/warnings I can see in the logs relate to attribute resolution below... I get these errors in both cases: qr plugin and zip upload.

2025-01-17 17:20:36,620 [threadPoolExecutorFactoryBean-13114] WARN  org.nrg.dicom.dicomedit.functions.RetainPrivateTagsReplaceFunction - Can not resolve attribute for deletion: 0029"SIEMENS MEDCOM HEADER"1040[0]/0029"SIEMENS MEDCOM HEADER"0010

2025-01-17 17:20:36,620 [threadPoolExecutorFactoryBean-13114] WARN  org.nrg.dicom.dicomedit.functions.RetainPrivateTagsReplaceFunction - Can not resolve attribute for deletion: 0029"SIEMENS MEDCOM HEADER"1040[0]/0029"SIEMENS MEDCOM HEADER"1041

2025-01-17 17:20:36,620 [threadPoolExecutorFactoryBean-13114] WARN  org.nrg.dicom.dicomedit.functions.RetainPrivateTagsReplaceFunction - Can not resolve attribute for deletion: 0029"SIEMENS MEDCOM HEADER"1040[0]/0029"SIEMENS MEDCOM HEADER"1042

2025-01-17 17:20:36,620 [threadPoolExecutorFactoryBean-13114] WARN  org.nrg.dicom.dicomedit.functions.RetainPrivateTagsReplaceFunction - Can not resolve attribute for deletion: 0029"SIEMENS MEDCOM HEADER"1040[0]/0029"SIEMENS MEDCOM HEADER"1043

2025-01-17 17:20:36,620 [threadPoolExecutorFactoryBean-13114] WARN  org.nrg.dicom.dicomedit.functions.RetainPrivateTagsReplaceFunction - Can not resolve attribute for deletion: 0029"SIEMENS MEDCOM HEADER"1040[0]/0029"SIEMENS MEDCOM HEADER"1044

I'm not sure what's happening, but the private sequence seems to be getting modified in some way via the QR plugin that isn't happening with the zip uploader.

[Simon Doran]

Hi,

  I'm not sure whether it is related, but we experienced some issues with DicomEdit6 "breaking" private tag sequences. Did you see the discussion here? I don't know why the two upload methods would be different, but there is a fix that we think may need to be included in the next release of DicomEdit.

  Best wishes,

Simon

[akluiber]

Hi, yes, I did see that thread and I wonder if your finding about assumptions regarding VR are related here?

After more testing, having setup a xnat docker compose stack with orthanc, Here is my experience...

1. Success or failure of the private tag sequence anonymization via DCMQR seems to depend on the transfer syntax of the incoming dicom file. ImplicitVRLittleEndian will fail, while ExplicitVRLittleEndian, or something like JPEG2000Lossless will succeed.
   
2. ZIP upload will succeed in any case.
   
3. The private tag with VR OB in this sequence (0029,1044) seems to be getting modified - such that the '\00' slash delimited NUL character gets replaced with \5c\30\30 for literal "\00"
   

I've attached the IVRLE, EVRLE and J2K copies of the original and resulting dicoms, and the simple anonymization script.

[Simon Doran]

Hi,

  To me, that makes perfect sense and is entirely consistent with what we deduced. When the transfer syntax is ImplicitVRLittleEndian, DicomEdit doesn't have a dictionary for what VR the private tag is supposed to have. It makes the "wrong" choice; IIRC, my colleague Alex traced back in the source code exactly where this happens. Not only does it lead to the wrong VR for this element, as we observed, but what you have found is that it seems actually to break the DICOM by writing something that's invalid.

  We'd be happy to share the code for our temporary solution as described in the other thread, but it really needs to be fixed by the core XNAT team.

  Note that Charlie Moore emailed me a while back to say that this might be an already-identified issue that hasn't yet been fixed, so maybe it's a case of pressing to get this moved up the priority list.

> That sounds somewhat like https://radiologics.atlassian.net/issues/DE-119 to me. If that is actually the case, you'll be able to recreate the issue without even using the retainPrivateTags function.

  Best wishes,

Simon