There are two tasks critical to enabling DQR functionality:
- Configuring a PACS connection with your XNAT
- Configuring a DQR-enabled DICOM SCP Receiver in your XNAT
Additional configuration to user permissions, project setup, and other settings can be done at setup, or at any time down the road.
Navigating to Plugin Settings
Once the DQR plugin is installed, you should log in as a site administrator and go to Administer > Plugin Settings in the top navigation. You'll see a set of tabs related to the DICOM Query-Retrieve plugin.
Note: All installed plugins can place tabs on this page. DQR settings may not be the top of the list.
Adding a new PACS or DICOM AE Connection
Connecting a PACS system with an XNAT server requires configuration at both ends. Work with your local PACS Administrator to complete this process.
By default, no PACS will be connected to your DQR setup, so you will see an empty table at the top of your DQR Plugin Settings page. In order to add a new PACS or DICOM AE connection, follow the steps here: DQR Admin: Connecting XNAT with a PACS for DQR Usage
Managing Connected PACS / DICOM AEs
Once you have a PACS connection established, you can manage various settings on the PACS.
Basic PACS Configuration
To edit an existing PACS configuration, click on the highlighted name of the PACS to open a configuration dialog.
|AE Title||This should be the AE Title broadcast by the PACS or DICOM AE you are connecting to|
This is a network address, and could be an IP address, "localhost" for a dev setup, or a URL.
Note: The "http/s" protocol is not required
|Label||This is used internally by XNAT to identify this PACS in the UI|
|Port||This is the network port used by the PACS system to accept requests and send or receive data|
|Queryable||No||Toggles whether to allow users to send C-FIND queries and C-MOVE requests to this PACS in order to find and import data|
|Default Q/R AE||No||If multiple PACS are configured to be "Queryable", only one can be the "Default" for querying new data. This affects the select menu on the "Import Studies" UI|
|Storable||No||Toggles whether to allow users to push data from XNAT to this PACS|
|Default Storage AE||No||If multiple PACS are configured to be "Storable", only one can be the "Default" for storing data. This affects the select menu on the "Send To PACS" UI|
Advanced PACS Configuration: Setting an Availability Schedule
In a high-use, data-rich environment, PACS Administrators may have specific business rules regarding how much network traffic they want to allow to and from their PACS system. The "Schedule" setting allows XNAT Administrators to restrict all use of each connected PACS to certain hours of the day. You can also throttle the data transfer rate, if desired.
To edit the Availability Schedule for a PACS, see: DQR Admin: Setting A PACS Availability Schedule
Configuring a DQR-Enabled DICOM SCP Receiver
In order to receive data requested by the DICOM Query-Retrieve interface, your XNAT's image session import process must be properly configured. For many XNAT administrators, this will require dealing with "DICOM Object Identifiers" for the first time.
The DICOM Object Identifier is a part of XNAT's core image session import and archive process. However, it has not surfaced in the XNAT Admin UI until now, because the DQR Plugin requires a custom-defined DICOM Object Identifier in order to function properly. Here's how these identifiers fit into a DQR-enabled session import workflow, starting with a C-MOVE request being received by the PACS. (Note the connection between the DICOM SCP Receiver and the DICOM Object Identifier)
When XNAT receives a DICOM image session file, it uses a set of identifier objects to determine to which project the newly received DICOM file belongs, and to assign subject and session labels within that project. This functionality is critical when receiving files sent from a PACS terminal, as those terminals have no XNAT interface to select a destination project or relabel subjects or sessions.
There is a default DICOM Object Identifier in XNAT, named "dicomObjectIdentifier", which makes multiple passes through the DICOM data to map its parameters to XNAT objects as described here: How XNAT Scans DICOM to Map to Project/Subject/Session. The DQR plugin adds a new DICOM Object Identifier, named "dqrObjectIdentifier". This is set up to coordinate with the DQR workflow, which involves a user in XNAT making a C-MOVE request for DICOM session files, and pre-assigning a project and new labels for the subject and session.
Here's how the dqrObjectIdentifier handles these field assignments:
|XNAT Project||Ignores DICOM values. Project is assigned to the user's selection in PACS Query interface or API. If no project was set, image data shows up in the "Unassigned Prearchive".|
|Subject Label||The subject label is set to the value of the DICOM Patient's Name field (0010,0010), or else is left blank.|
|Session Label||The session label is set to the value of DICOM Study ID field (0020,0010), or else is left blank.|
Associating SCP Receivers with DICOM Object Identifiers
The DQR Plugin Settings Admin UI has a table listing all installed DICOM Object identifiers. This is for reference only. There is no configuration required here, but you will need to add or edit your XNAT's DICOM SCP Receivers to use one of the "DQR-enabled" DICOM Object Identifiers.
Identifiers designed to work with DQR, including the relabeling feature, should have been assigned a name that contains the String "dqr", which lets XNAT know that the identifier should work with DQR (custom DICOM Object Identifers can be written and included in plugins and any ones designed to work with DQR should include "dqr" in their name).
To associate a DICOM SCP Receiver with your newly-installed identifier, click on the "Configure SCP Receivers" button to navigate to the the appropriate panel in the core XNAT Admin UI. By default, your XNAT will only have one SCP Receiver, and this panel will look like this:
You can either edit the existing SCP Receiver to use the DQR-enabled Object Identifier, or create a new one. We recommend creating a new one, to avoid affecting any existing DICOM import behavior that uses the default receiver.
Enable An Existing Receiver: Click on the highlighted AE Title in the table, and you will see an edit dialog open up.
Set Up A New DQR-Enabled Receiver: Click the "New DICOM SCP Receiver" button. You'll see an empty version of the above dialog.
For either scenario, fill in your settings as needed:
|AE Title||This is the identity that your PACS will look for, when receiving any C-FIND, C-MOVE, or C-STORE requests. Each SCP Receiver in your XNAT system should have a unique AE Title.|
|Port||This refers to the network port for allowed transfers. Ask your PACS Network Administrator if you do not know what value to use.|
|Custom Processing||Set this to Enabled. This enables Custom Image Import Processors, which can be used to fine-tune how and when anonymization is applied, and this enables DQR relabeling for subjects and sessions.|
|Identifier||Select an identifier labeled with "dqr"|
Click "Save" to finalize your changes.
Once you have defined a DQR-enabled SCP Receiver, copy the AE Title of that receiver into the "Calling AE Title" setting further down on this page.
Other DQR Preferences
|Calling AE Title||XNAT||This should be the same as your DQR-enabled SCP Receiver's AE Title|
|PACS Threads Check Frequency||1 minute||This instructs XNAT how often to check for new PACS availability rules in a given day. This should be set to 1 minute in most cases, so that there is not a long delay in behavior when the number of threads available for import changes.|
|Allow DQR for All Users||Disabled||When disabled, an XNAT Administrator must manually enable DQR usage for each user, including themselves.|
|Allow DQR for All Projects||Disabled||When disabled, each XNAT project owner must manually enable DQR import and export for their project, in Project Settings.|
|Notify Admin on Import||Disabled||When enabled, the site admin notification email address will get a receipt for every data import from PACS|
|Assume Same Session If Arrived Within||30 Minutes||This setting was added to help deal with low-utilization schedules. If DICOM files with the same Study Instance UID, but different Study ID, arrive within this time period of each other, XNAT will assume that they belong in the same session.|
The "Allow DQR For All Users" and "Allow DQR For All Projects" let you choose how much fine-grained control you want to have over who can use DQR. If these are set to false, an admin will have to edit a user account (by going to Administer→Users in the top bar, clicking on the user, clicking on Edit Advanced Settings, and checking the box for DQR Access) to add the DQR role before they can use DQR and an admin will have to edit a project's settings to enable users to use DQR on that project. If these are set to true, all users will instantly be able to use DQR on all projects. If "Allow DQR For All Projects" is set to false and a project owner wants users to be able to use DQR on their project, they can go into the project's Project Settings and add an IRB number and IRB file. Once they have completed this information, the admin will be sent an email and will be able to decide whether to enable DQR for that project. However, this is not the required workflow, and an admin can always enable DQR on a project regardless of whether an IRB number and file have been submitted.
And finally, Assume Same Session If Arrived Within gives you a way of addressing the case where for a given study on a PACS (with a given StudyInstanceUID), some of the DICOM files have one Study ID and some have a different Study ID. If Assume Same Session If Arrived Within is set to 30 minutes, XNAT will assume that DICOM files with the same StudyInstanceUID belong in the same session (if subsequent files arrived within 30 minutes of the first such file) and it will give them all the Study ID of the first session that was received. If inconsistent Study IDs are a problem with the data your XNAT imports and the data for a given session takes more than 30 minutes to be received, the interval can be increased. If inconsistent Study IDs is not a problem with your data and you want to turn this feature off, you can set it to 0 minutes. If you are importing test studies with the same StudyInstanceUID and different Study IDs, you may want to turn this feature off, though such test data may lead to other problems since StudyInstanceUID is used in multiple places in XNAT to distinguish between what session imported data belongs in. Like PACS Threads Check Frequency, this time period should be written in PostgreSQL interval notation (http://www.postgresql.org/docs/9.0/static/functions-datetime.html).