Page tree
Skip to end of metadata
Go to start of metadata

Once you have finished configuring everything, you should be ready to search your PACS! Let's just check that your PACS is responsive. You can go to Administer→ Plugin Settings→ DICOM QRS Settings→ Manage DICOM AE (PACS) Connections and click the "Ping" button next to your PACS. If you get a green notification at the top of the screen saying that the PACS is Up, you should be all set. If not, please review the earlier steps to make sure everything is configured correctly.

Then go to a project that you want to import PACS data into and click "Import from PACS" in the Actions box.

You will then see a Source PACS dropdown in the top right of the page. If you only have one PACS configured (and set to Queryable), you can ignore this, but if your XNAT can talk with multiple PACS, you should select the one you want to search. If you don't like the text that is displayed in this dropdown, you can edit your PACS in Plugin Settings and change their "Label" fields, which are what are used to populate the dropdown.

If you are certain that your PACS only has a small amount of data (for example, if it's a test PACS you configured to experiment with the DQR plugin before deploying it on your production XNAT), you can then click "Search PACS" to execute a search with no criteria and get all the sessions on the PACS returned to you as shown below:

Or you can enter other criteria to view only a subset of the studies on the PACS. Below is an example of such a search:

The more data on the PACS, the more search criteria you will want to include. A search that returns a large number of studies will not be very efficient. Still, on some PACS, it will be hard to avoid sometimes getting large sets of results. In such cases, you can click on a column heading to toggle between the rows being unsorted, sorted based on that column's values in ascending order, and sorted based on that column's values in descending order. If any values, such as Patient Name, are cut off because they are longer than the width of the columns, you can mouse over the value to see the unabridged value.

Now that you know how to find the data you want, it's time to learn how to import it.

Importing from a PACS

Let's say you've done your search and found the data you want to import. You can then check the box for every row you want to import and click "Begin Import" at the bottom of the page. Though if you have multiple SCP receivers configured, you should first make sure the "Select SCP Receiver" dropdown has the correct receiver selected. Only receivers that have custom processing enabled and that are using a DQR DICOM Object Identifier will be available in this dropdown. The "Subject" and "Session" columns can be ignored for now. They will be discussed in the "Import with Relabeling" section.

After clicking "Begin Import", you will see a modal pop up with a list of the Series Descriptions for the series in the studies you selected. If this modal takes a long time to appear or does not appear, that might mean you selected too many studies. Unfortunately, even selecting 20 or so studies could cause such problems due to a limitation of the DICOM standard preventing single queries from gathering series level information. Improving this UI is on our list of improvements we want to make to DQR, but for now, we advise to import studies in smaller batches, such as twelve studies at a time. If the studies you select each contain multiple series and you only want some of them, the modal that appears after clicking "Begin Import" is your opportunity to uncheck those you don't want. This modal simply displays all the Series Descriptions in the studies selected for import and how many studies have a series with each of those series descriptions. For example, if I try to import two studies from our test dataset where each patient is named after a cat and each study only contains a single series whose Series Description is "CAT_SCAN", I get the modal shown below:

Since I want to import all of the listed series descriptions, I do not uncheck anything, simply clicking "Import Selected" to continue. I then see a new modal saying that the request has been queued. It gives me links to click on if I want to check on the progress in the queue or go back to the project page. The modal should look something like this:

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:

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.

  • No labels