XNAT import from PACS/VNA

149 views
Skip to first unread message

Naveena Gorre

unread,
Oct 13, 2022, 11:54:10 AM10/13/22
to xnat_discussion
Hello all,

We have recently implemented the option to import from PACS/VNA on XNAT and performed a test run yesterday. Couple of issues/question
  1.  I have the site-wide anonymization script saved under session upload & anonymization but when the import of data happened none of the dicom headers are de-identified. Any clues on why this is happening. Please let me know how I can resolve this.
  2. We have queried to import almost 210 scans and I have been receiving the email from admin every time which constituted to almost 400 emails. I have checked the disabled option under DQR settings and it's not turned on. Is there anyway to stop continuous emails and just sent one final email after data import completion.

Charlie Moore

unread,
Oct 13, 2022, 12:04:32 PM10/13/22
to xnat_discussion
Hi there,

For (1), what anonymization script are you trying to use? There's also a lot of variables here that critically affect this, such as:
1. How is the data being imported?
2. If it's being imported via DICOM C-STORE [which I assume yes, based on your next question], how is your DICOM SCP receiver configured?
3. Have you modified any of the default archive processors (this is only available via REST, so if you're unsure, the answer is probably no)?

For (2), this is a known issue, but I'm not aware of a workaround right now, other than with an email filter.

Thanks,
Charlie Moore

Naveena Gorre

unread,
Oct 13, 2022, 3:28:06 PM10/13/22
to xnat_discussion
Thanks Charlie, Below is the sample anonymization script I'm using (Did not include all the tags):

//
// Default XNAT anonymization script
// XNAT http://www.xnat.org
// Copyright (c) 2005-2017, Washington University School of Medicine and Howard Hughes Medical Institute
// All Rights Reserved
//
// Released under the Simplified BSD.
//
version "6.1"
project != "Unassigned" ? (0008,1030) := project
(0010,0010) := subject
(0010,0020) := session
-(0008,0050) // Accession Number
-(0008,0080) // Institution Name
-(0008,0081) // Institution Address
-(0008,0090) //    Referring Physician's Name
-(0008,1010) // Station Name
-(0008,1048) // Physician(s) of Record
-(0008,1060) // Name of Physician(s) Reading Study
-(0010,0021) //    Issuer of Patient ID
-(0010,0030) //    Patients Birth Date    

1) I don't see the de-identification of the header which are even included in the script
2) Data is being imported using a search for csv file which contains all the accession numbers and subject names and using search pacs option and then import them onto XNAT.
3) I'm not sure I understand - what details would you need in specific of how it is configured.
4) I don't think we have modified any  
5) Could you please elaborate on this.

Regards
Naveena G


Charlie Moore

unread,
Oct 13, 2022, 4:12:44 PM10/13/22
to xnat_discussion
Hi Naveena,

If you're asking for clarification on the "email filter" part, I didn't mean any sort of XNAT feature. I meant in gmail/Outlook/whatever, you could set up a filter to ignore the emails received for each study import. Yes, I realize that is a terrible "solution", but I'm afraid I'm not aware of anything better right now.

As for the anonymization problem, something is going wrong, but there's too many variables for me to guess what the problem is. For your SCP receiver, I mainly wanted to know if you had unchecked the anonymization switchbox, as that would cause this behavior. You can double check the configuration of that under Administer > Site Administration > DICOM SCP Receivers:
Screen Shot 2022-10-13 at 3.02.21 PM.png
Assuming that's still checked (or it may not present at all if you're on an older version of XNAT), it's unclear to me what the problem is here. It could be anonymization in the context of DQR imports, anonymization in general on your XNAT, something with your script, etc. To try and eliminate some variables, I would try this:
1. Create a new project.
2. Upload this session https://download.nrg.wustl.edu/pub/data/sample1.zip using the compressed uploader (Upload > Images > Compressed Uploader) to the new project.
3. Check the session and see if your anon script has modified the elements.

If after that, you still aren't seeing any modifications to the DICOM, I suspect XNAT is unhappy about something in your full script and is silently failing.

Thanks,
Charlie Moore

Naveena Gorre

unread,
Oct 14, 2022, 11:09:26 AM10/14/22
to xnat_discussion
Thanks again Charlie,

I just tried using the compressed uploader option on XNAT to upload sample.zip folder onto the same project where I was having issues with my imports and it looks like the data is being de-identified, for eg., (0008,0081),(0008,0080) headers. Please find the image attached for reference. I'm not sure why this is not working for the import from PACS option. Please let me know if you any suggestions.

xnat_error.PNG

Charlie Moore

unread,
Oct 14, 2022, 11:25:59 AM10/14/22
to xnat_discussion
Hi Naveena,

Barring the DICOM SCP receiver being configured to not perform anonymization, the only other thing I can think of is some confusion around the DICOM dump in the screenshot. The DICOM dump UI utility doesn't handle sequences very well, so headers that are actually within sequences look to some extent to be in the root level of the DICOM object in that view. Is it possible that the headers you're expecting to be modified are actually within sequences? The syntax your script is using (e.g. -(0008,0080) ) will only remove DICOM elements in the root level of the DICOM object. I would check element (0012,0064) in the data where you're not seeing the anonymization you would expect. If you see something like this, that means XNAT at least thinks it ran an anonymization script:
Screen Shot 2022-10-14 at 10.22.27 AM.png

Thanks,
Charlie

Naveena Gorre

unread,
Oct 14, 2022, 11:44:32 AM10/14/22
to xnat_discussion
Thanks Charlie,

It looks like XNAT did ran the anonymization script since I can see (0012,0064) elements on the dicom headers (please find the attached). But I'm not sure where it's going wrong.

Regards
Naveena G 

xnat_error2.PNG

Charlie Moore

unread,
Oct 14, 2022, 12:33:03 PM10/14/22
to xnat_discussion
Hi Naveena,

You should check (0012,0064) on the data you imported from the PACS, not on the sample data I provided, (but please don't post a screenshot if there's any PHI in there). Assuming this isn't sensitive either...could you post a screenshot of the first two columns of the DICOM headers (i.e. no values) for the data you've imported from the PACS?

Thanks,
Charlie Moore

Naveena Gorre

unread,
Oct 14, 2022, 1:04:29 PM10/14/22
to xnat_discussion
Sure, Please find the attached.

Regards
Naveena G

xnat_erro4.PNG
xnat_erro3.PNG

Charlie Moore

unread,
Oct 14, 2022, 1:14:45 PM10/14/22
to xnat_discussion
Hi Naveena,

Those screenshots confirm that anonymization is working correctly. All of those elements are embedded within a private sequence, so attempting to delete them in the root level of the DICOM object (what your current script is doing) will not have any effect. You could probably remove this individual block by deleting that individual private element. Or you could be more aggressive with the "removeAllPrivateTags" operation. Detailed information on writing a DicomEdit 6 anonymization script can be found here: https://wiki.xnat.org/display/XTOOLS/DicomEdit+6.3+Language+Reference .

Thanks,
Charlie Moore

Naveena Gorre

unread,
Oct 14, 2022, 1:23:42 PM10/14/22
to xnat_discussion
Thanks Charlie,

 Could you please elaborate on this  - "You could probably remove this individual block by deleting that individual private element". Apologies for my naïve questions as I'm still learning about XNAT.

Charlie Moore

unread,
Oct 14, 2022, 2:07:46 PM10/14/22
to xnat_discussion
Hi Naveena,

XNAT's DICOM dump feature handles sequences poorly, but from looking at the screenshot you have, your dataset has private tags with the private creator ID [not included in your screenshot, it will be the value in the third column] in (0029,00E1) responsible for (0029,E131), which looks to be a sequence element with a single item, containing a bunch of standard elements with [presumably] PHI. However, none of that data topology is really related to XNAT at all; that's all just general DICOM.

Now for XNAT, there's a variety of different ways to handle this, but it all depends on your specific needs. What comes to mind for me is:
1. Delete the entire (0029,E131) element. As this is a private element, you don't do this in DicomEdit 6 as -(0029,E131) as there's no guarantee that's the tag path it will actually reliably be at. It would be more like -(0029,{WHATEVER THE PRIVATE CREATOR ID ACTUALLY IS HERE}31).
2. You could try removing the standard elements more globally. That is, instead of lines like this in your script: -(0008,0080), you would do -*/(0008,0080). That's the equivalent of "wherever you find Institution Name nested away in sequences, remove it".
3. You could try just adding "removeAllPrivateTags" as a line in your script. That's the keyword to just remove all private elements.

Each of these approaches has pros/cons, weaknesses/strengths, and I can't prescribe which is most appropriate for your use case. Anonymization is an art, rather than a science, at least in my view :).

Thanks,
Charlie Moore

Will Horton

unread,
Oct 14, 2022, 2:30:13 PM10/14/22
to xnat_discussion
Naveena, 
If you haven't already been working from the DicomEdit documentation for writing anonymization scripts, here is the link: https://wiki.xnat.org/display/XTOOLS/DicomEdit+6.3+Language+Reference

You can see an example of deleting groups of vendor-specific private tags by using the creator ID in brackets, listed under the "Operations" header, which is the first suggestion that Charlie just made. (You'll want to replace {SIEMENS MEDCOM HEADER} with the appropriate creator ID.)

// delete private tags
// delete all SIEMENS MEDCOM HEADER attributes, regardless if they are mapped to (0029,10XX), or (0029,11XX) , or ...
- (0029,{SIEMENS MEDCOM HEADER}XX) 

There are examples of the other suggestions that he makes as well. Hope this is helpful. 

Regards,
Will 
Reply all
Reply to author
Forward
0 new messages