If you're an XNAT user that requested some data from a PACS, you might want to check on the status of your request. Or if you're an admin, you might not only want to see information about your own requests, but about all the PACS import requests users have made from your XNAT. The queue and history tables give you access to this information. The queue table contains all the pending requests that have not yet been issued to a PACS. The history table contains all the requests that have already come off the queue and been issued (whether that happened 5 seconds ago or 5 years ago). Regular users can only see their own queue/history, while admins can see the entire queue/history for the site. Each item in the queue and history tables is for only a single study. If you asked for multiple studies at the same time, there will be a row for each study (this is important because XNAT sometimes waits between each study so that the PACS isn't utilized more heavily that the utilization rate an admin configured).
User Queue and History
As any user of XNAT that has been enabled to use DQR (either by an admin editing that users account to add DQR access or by virtue of the Allow DQR for All Users setting being enabled), you can see your personal queue/history by going to Upload→ Import Queue/History. If you have just requested to import some studies from the PACS, your queue might look something like this:
The position column indicates how hugh up in your queue the requests are. The request in position 1 is typically the first request to be issued. However, if you have asked for data from multiple PACS and the first request in your queue is for data from a PACS whose Utilization Schedule is currently set to allow 0 import threads, then requests for data from other PACS may be removed from your queue first. XNAT will keep hitting each PACS with requests according to its Utilization schedule (as long as there are more requests queued up). And even if you know that XNAT is set up to allow imports from a PACS during a given time, there may be other people who have requests ahead of yours. Your individual queue shows what requests you have outstanding and the order in which you might expect to receive them, but there are a lot of other factors to consider.
The ID column contains a unique integer assigned to each request, starting with 1 for the first ever made on the site. One thing you might notice in the screenshot above is that all the requests with a position closer to the top of the list have a lower ID, except for the first request. The requests queue generally operates on a first in first out basis, with newer requests having to wait their turn while older requests complete. However, there is an exception if you only request a single study. If all you want is a single study from a PACS and someone just queued up 1000 studies to be imported from that same PACS, you wouldn't want to have to wait until all 1000 are imported before getting your study. If you just ask for one study, your request will be given higher priority. The queue works by first issuing the highest priority requests in a first in first out basis and then issuing the lower priority requests in a first in first out basis.
The queued column simply shows when the request was queued.
The Patient Name and Study Date columns merely provide information about what data you requested.
The Project column shows what project you asked for the data to be sent to (since it's possible to change the project while a session is in the prearchive, this is not guaranteed to be the same project that the data ends up in).
The PACS column is the current AE Title of the PACS you requested the data from.
The Dest. AE is the AE Title that you requested that the PACS send the data to. If the PACS has a stored asociation between that AE Title and your XNAT, it will send the data to your XNAT.
And finally, there is a Remove column. You can click the 'x' mark in that column to remove an item from your queue. Unless the request has already been issued (and the UI just hadn't been updated to reflect that), that request will disappear and never be issued.
All of these columns are sortable by clicking the column headings to toggle between ascending, descending, and no sorting. You can also type text in the filter text boxes to see only requests that have the value you typed.
Queue entry modal
If you click on the ID of a request in your queue, a modal will come up showing you more detailed information about your request:
This is a fairly raw display of what information is stored in the XNAT database for the request and some of this information isn't very helpful (enabled, disabled, created, and timestamp should all be ignored and the queued time is displayed in a not very helpful format). The seriesIds field is important because it shows what subset of the series in the study (that has the requested studyInstanceUid) were included in the request. Sometimes all series in a study are desired and sometimes you only want a single one. The remappingScript is the text of the DicomEdit anonymization script that will be run on the data once it comes into XNAT. The username is your username (though if you were an admin viewing the admin queue, you would be able to look at the details for requests from other users). The status field for items in the queue/history can be any of these:
When requests are issued to the PACS, they are removed from the queue and converted to executed requests. At that point they will no longer show up in the queue. So you won't often see an item in the queue with a status of PROCESSING or ISSUED, though you may occasionally see some FAILED requests (for example if the PACS is configured to be availale but is down for some reason). You will never see RECEIVED status in entries in the queue, because requests will have already been converted to executed requests before their data is received by XNAT and the status of the request is changed to RECEIVED.
A user's history table looks quite similar to the user's queue table and is viewable by going to Upload→ Import Queue/History and then clicking on "History". The table will look something like this:
The status is included in this table because there is more variation (everything is almost always QUEUED in the queue) and the time the request was executed (issued to the PACS) is displayed as well. Clicking on the ID for a request will still open up a modal with information about that request. This modal will be almost identical to the modal that came up when you clicked on the ID of an item in the queue. It will, however, contain the execution time and will not contain the priority or remapping script.
If you requested data from a PACS and don't see it in the prearchive or in the project you asked it to be sent to, your queue and history tables can help you figure out what might have happened.