Uploading multiple session UIDs under a single session in XNAT

[Ashley Teraishi]

Hi XNAT Team,

In our lab, we often work with patients who undergo both clinical and research scans during the same visit. These scans follow different protocols and therefore have distinct SOPInstanceUID and AccessionNumber values. However, we would still like to add them to a single session in XNAT. 

Currently, when we attempt to upload this data, we receive a "Conflict" message in the prearchive. Is there a recommended workaround or best practice that would allow us to include multiple session UIDs within a single XNAT session?

Thank you so much,

Ashley

[Moore, Charlie]

Hi Ashley,

SOP Instance UIDs should be unique for every instance (file) already, so I'm guessing you mean you have two different Study Instance UIDs in the data? If so, there isn't really a supported way to force these into one session because a session is supposed to be (roughly) the XNAT equivalent of a DICOM study. There's probably some way to disable the conflict that someone else could find, but the best practice is to not do this, especially because it will likely break all sorts of downstream processes such as the OHIF viewer which assumes an XNAT session contains only a single study.

Thanks,

Charlie Moore

---

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of Ashley Teraishi <ater...@g.ucla.edu>
Sent: Wednesday, July 30, 2025 11:37 AM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: [XNAT Discussion] Uploading multiple session UIDs under a single session in XNAT

 

--
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 visit https://groups.google.com/d/msgid/xnat_discussion/b7c79a7b-7dcd-47c8-804c-1135faf3106fn%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.

[Simon Doran]

Hi Ashley,

  Reinforcing what Charlie said: "Don't go there!" Having multiple DICOM StudyInstanceUIDs in a single session will cause you problems.

  We have experimented in the past with the mechanisms in the prearchive to allow you to override the conflict and archive the second batch of scans anyway, but ignoring the warning message that XNAT displays will almost certainly cause problems down the line if you try to view the images, as the OHIF viewer follows the DICOM model closely.

  We occasionally encounter the issue when one of our MRI scanners fails to perform its "retro-recons" in a timely fashion (meaning that these parts of the original study are sent with a different StudyInstanceUID).

  In cases like yours, we would employ one of two solutions:

(1) Acknowledge formally the fact that these are two different scans (even if it's the same patient visit). In this case we would just create two XNAT sessions (e.g., VISIT1_CLINICAL and VISIT1_RESEARCH).

(2) Use a tool like DicomBrowser to change manually the StudyInstanceUID tag in the "Research" scans so that they match the UIDs in the "Clinical" scan. You can also write a short bit of code in Java to use the DicomEdit 6 library to perform this programmatically, or code in Python and call DicomEdit 6 via Python's subprocess module. If you do, the supplementary images should import fine with no "merge" issue at the prearchive stage.

  Best wishes,

Simon