Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


The details of how the queue works will be discussed in more detail in a future section, but for now all you need to know is that the data you requested should show up soon in the XNAT prearchive or in the project itself (if the project is set up to auto-archive, which is viewable from the Define Prearchive Settings section of the Manage tab on the project page). If it does not show up, you should make sure the PACS is configured to send to the correct place and that PACS Threads Check Frequency is set to some low time interval.

Importing with Relabeling

A more advanced feature of DQR is the ability to request an import and tell XNAT to relabel the data once it's received by XNAT. The actual DICOM files are modified and those modified values are then what gets used by XNAT to assign the data to the appropriate subject and session. This feature can be used through the UI by entering values in the Subject and Session columns as shown below:

Image Added

This will only work if you have configured the SCP receiver you're using to use custom processing and to be using a dqr DICOM Object Identifier.

If you leave a value blank, no relabeling will be performed for that value. For non-empty values, the following relabelings will be performed when XNAT receives the data:

  1. Patient's Name = value entered for Subject
  2. Patient ID = value entered for Subject
  3. Study ID = value entered for Session
  4. Accession Number = value entered for Session

Being able to import with relabeling can provide two main benefits:

  1. Sensitive fields in the DICOM can be replaced by non-sensitive values, making it easier to work with the data in the future.
  2. The fields used to route data to a subject and session in XNAT can be changed so the data gets routed to the place you want it.

However, there are some points of caution.

  1. The data still has to be received by XNAT in non-relabeled form, so if the data contains PHI that is not allowed to be sent to your XNAT instance (even if the PHI is immediately removed) then you will either have to do the relabeling first on an XNAT that can briefly contain PHI and then route it to your other XNAT (perhaps using XSync), or you will have to make sure the data is somehow cleaned up before touching an XNAT (CNDA handles this by having JAAT retrieve imaging sessions from a PACS and then passing them through CTP before they reach XNAT).
  2. Using DQR relabeling to route data will not work if it is a problem that the DICOM itself is being changed (rather than just the location in XNAT that the data gets routed). If there is demand for it, one possible future enhancement would be to have a way to have DQR only relabel the data (while leaving the DICOM unchanged), possibly by creating a new dqr DICOM Object Identifier to manage this.
  3. XNAT determines whether data should be relabeled by StudyInstanceUID, so if multiple users are requesting sessions with the same StudyInstanceUID at the same time, data may be modified incorrectly. Additionally, it is only when data is archived or deleted from the prearchive that these mappings are deleted, so if data remains in your preachive, new imports of the same StudyInstanceUID could still be affected.

Relabeling is a powerful tool (and the UI hides some of it's power, which will be discussed in the Import with REST section), but it should be used with care and is not currently appropriate for all use cases. We would love to hear feedback on what your specific needs are so we can target our future development efforts to what would be most useful to you.