Specifying Session routing via DicomEdit and Pre-Archive

[EM LoCastro]

Running XNAT 1.7.5.6. I'm assigning information to the DICOM tags using a DicomEdit script. I want to set the Session ID, specifically (not setting Project or Subject explicitly, only Session).

The XNAT only appears to update the session ID when I change the Patient ID tag.

(0010,0020) := session

However, for our instance want to preserve that field, we don't want to change it.

I've tried modifying the Patient Comment tags with the DicomEdit script. Even though the tag is updated properly, the routing information does not get passed.

(0010,4000) Session:SessionID

and

(0032,4000) Session:SessionID

Is this format correct? 

Much thanks,

Eve

[Moore, Charlie]

Hello Eve,

 

DicomEdit scripts are intended for anonymization/de-identification, not routing. It’s somewhat of a circular problem, since in a perfect world, routing and anonymization could both depend on each other. People often want to use the assigned subject/session labels in the site anonymization script (as is done in the default script). That means that routing has to happen *before* the site anon script is applied. So, the short answer is that I don’t believe you can use the site anonymization script to control routing the outgoing session label. I believe your choices are:

1.       Write a custom DICOM Object Identifier in a plugin which encodes your desired routing rules.

2.       Modify Patient Comments (0010,4000) *before* the data reaches XNAT (for example, on the scanner, or by putting an intermediate CTP instance between the modality sending the data and XNAT itself).

3.       Enable custom processing and move the order of the processors. This option is the one I’m least sure about. Essentially, in 1.7.5, XNAT has support for “custom processors” associated to your SCP receivers. If you enable custom processing on your SCP receiver, XNAT should provide the same site anonymization, but now in a configurable location in the process. If you move it to the very beginning (before routing), this might work. Some caveats:

a.       With anonymization manually moved this far to the front, you definitely wouldn’t be able to use any of the “project”, “subject”, “session” variables (since now anonymization would be before routing!)

b.       There is no UI for this: you’d have to do it all with REST.

 

Thanks,

Charlie

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/422212da-df7a-4fe4-9d3d-bcba6619504d%40googlegroups.com.

 

---

The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. 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.

[EM LoCastro]

Thanks Charlie; I really appreciate the informative reply. We've used CTP for this in the past. For solution 3 you suggest, does one need to necessarily go digging through source code to enable custom processing? Can anyone suggest any pointers for making that simple change quickly (ie, target the scripting file that would need to be edited)? I'm only loosely familiar with how it works.

Best,

Eve

To unsubscribe from this group and stop receiving emails from it, send an email to xnat_di...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/422212da-df7a-4fe4-9d3d-bcba6619504d%40googlegroups.com.

[EM LoCastro]

Also, it's too bad about the DicomEdit routing limitation, because the createSessionLabel option is really great for incrementing the session relative to the patient's previous stored exams.

[McKay, Mike]

We're currently working on a lot of documentation relevant to this, and hopefully we'll add more to it and have it split up into separate pages soon, but for now you may find it helpful to look at our rough draft of the documentation for the soon-to-be-released DQR plugin:

https://wiki.xnat.org/display/XNAT17/Dicom+Query+Retrieve+Plugin

The entire last section is about Processors, a feature that exists in 1.7.5 XNAT itself but which is used heavily by the DQR plugin. As described in the documentation I linked you to, Swagger would give you a UI for performing the REST call needed to move the site anon script to earlier in the import process, after the project is set, but before subject and session are.

Hope that helps!

-Mike

---

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of EM LoCastro <eloc...@gmail.com>
Sent: Wednesday, January 15, 2020 10:50 AM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: Re: [XNAT Discussion] Specifying Session routing via DicomEdit and Pre-Archive

 

To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/697007fe-613b-4ed0-a7c1-b29b0691dc20%40googlegroups.com.

[McKay, Mike]

And as discussed in an earlier section of that wiki page, you just turn on custom processing by editing your SCP receiver through the Administer-> Site Administration-> DICOM SCP Receivers page.

-Mike

---

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of McKay, Mike <mfm...@wustl.edu>
Sent: Wednesday, January 15, 2020 4:02 PM
To: EM LoCastro <eloc...@gmail.com>; xnat_discussion <xnat_di...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/DM6PR02MB510085DB94087DF0A204C0CABF370%40DM6PR02MB5100.namprd02.prod.outlook.com.

[McKay, Mike]

One caution though, there are some slight differences in the processor code between 1.7.5 and 1.7.6 (which is the version of XNAT the documentation is based on), so while it should be 95% accurate, there will probably be some small differences you'll run into.

-Mike

---

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of McKay, Mike <mfm...@wustl.edu>

Sent: Wednesday, January 15, 2020 4:05 PM

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/DM6PR02MB5100F0037D6F097DF206ECA9BF370%40DM6PR02MB5100.namprd02.prod.outlook.com.

[Simon Doran]

Hi Eve et el.,

  Just thought it might be worth noting that when Charlie says:

DicomEdit scripts are intended for anonymization/de-identification, not routing.

this isn't a limitation of DicomEdit in any way, but rather is a consequence of where in the XNAT import chain DicomEdit is applied. I.e., what you are talking about here is the site-wide anonymisation script, which is something that obviously sits within XNAT.

Exactly as Charlie points out:

routing has to happen *before* the site anon script is applied

Where addition of the routing information occurs prior to sending the data to XNAT, then DicomEdit is a very suitable way of doing things and we make extensive use of DicomEdit scripts for exactly this purpose. We then use either DicomBrowser for interactive use or the command-line client DicomRemap if we want a scriptable solution, both of these at the sender end not on XNAT. However - again, as Charlie pointed out - CTP is also a suitable option.

  In general, for us, routing and anonymisation happen as part of the same process, but it also quite often occurs that we need to move data around without anonymising and so sometimes the DicomEdit "anonymisation script" contains only routing instructions (i.e., modifying tag (0010,4000)).

  From an information governance point of view, I would tend to regard it as the responsibility of the sender to ensure that data are anonymised before leaving the source institution. This means that I end up using the site wide anonymisation script primarily as a "fail-safe" system (e.g., to remove vendor private tags) to protect the platform against accidental ingestion of PHI. But I'm sure the practice varies.

  One additional option for routing that Charlie didn't mention is that you can set up multiple DICOM receivers. So, if you have only a small number of projects and there are enough cases in each to make it worth the time of your PACS administrator to set this up, you can actually define a separate AETITLE for each project and configure the sender to route cases directly from an option in the PACS.

  Best wishes,

Simon

[EM LoCastro]

Thank you again, Charlie, Mike and Simon, for your in-depth replies. These explanations are exceedingly helpful, and you've relieved some of my uncertainty regarding how DicomEdit fits into the import process. It makes sense to me based on my experience with XNAT thus far, that routing takes place almost immediately and before any processing scripts are applied. I'll look into these resources if my needs mandate it. CTP has always been reliable, but it ends up being an additional puzzle piece one needs to keep track of when setting up a production system, and I'd rather not have to worry about it.

Best,
Eve