Black box testing remote DICOM Q / R server

Question

I am wondering if anyone has ever tried to work on the following issue. I need to run a series of tests on a remote DICOM Q / R server. This would make it easy to verify the DECOM Conformance Statement.

As part of the implementation of the test suite, I run the following command (DCMTK style command):

$ findscu --study --cancel 1 --key 0020,0010=* --key 8,52=STUDY --aetitle MINE --call THEIR dicom.example.com 11112 

The goal is to find a valid StudyID (later I will use this StudyID to execute C-FIND lower-level keys and some related C-MOVE queries). Of course, it would be much easier if I could upload my own dataset and try to return it, but I cannot do it against working PACS in the clinical environment. I need to determine with a minimum number of queries how to find a valid StudyID .

However, I am afraid that some DICOM implementations may have policies where it is forbidden to query the entire database.

So I was wondering if anyone wrote down a list of these policies and possibly described a way to get a valid StudyID from a remote server with a minimum of C-FIND requests.

Answer 1

I think I can just go with:

 TODAY=`date +"%Y%m%d"` findscu --study --key 0008,0020="$TODAY-" --key 0020,0010=* --key 8,52=STUDY --aetitle MINE --call THEIR dicom.example.com 11112 

If this does not work (return empty), I will check the results yesterday .

Answer 2

Welcome to DICOM-wonderland.

You are correct that you should very, very, very, very carefully run random requests in clinical PACS. I saw that commercial PACses send the entire (!) Database as a result of a query that he did not understand. Not a beautiful sight. This (and confidentiality) is one of the reasons why in many hospitals around the world, PACS administrators are very afraid to give direct access to PACS through DICOM.

In general, I would say that standardization will not help you. Therefore, you need to find something that works for you, and which does not make PACS work. There are no guarantees.

Just a list of observations from PACS requests in hospitals:

• Some of them are case sensitive when matching, some are not.
• Most support some kind of wild card. Usually this "*". but I also saw "%" (since it is a conditional SQL character, and the query is simply passed as an SQL string). I do not think that this is not so.
• The list you get may be limited to say the first 500 entries. Or 1000. Or a random number from 500 to 1000. Or the whole PACS. You just don’t know.
• DICOM and cancel do not play well. Canceling a request does not work well. Typically, PACS perceives this as an unsuccessful transfer and after a while will try again. And the retry queue is limited in size, so it can ignore new requests. Therefore, always allow the STORE-SCP server to start this queue.
• Sometimes requests take minutes, especially for retrieval. The next time he might have been removed (from the tape?) And will be quick for a while.
• A DICOM request can take a lot of resources from PACS, depending on the PACS. Don't be surprised if the PACS administrator appears, if you experiment too much.
• Supported queries are very different. Only basic queries are supported by everyone: a list of patients, a list of StudyID / study instanceid for patients, a list of series per study, receipt of a study or series. If you do not get a funky research department that uses Osirix, which does not support patient-level queries, only research-level questions.

So, what would I recommend if you want to work on any random PACS:

• Use an empty return key instead of '*'. This is the DICOM way to get information.
• Do not use '-cancel'. If you really need to cancel, just close the TCP connection (not supported in DCMTK)
• Use the query for PatientId, PatientName, Datedate, StudyDate to get a list of StudyIDs / StudyInstanceUids.

The simplest is the use of a fixed StudyID, assuming that it remains in PACS for quite some time. If not, consider limiting your request so as not to overload PACS (the sentence "TODAY" is that you matched this description).

Good luck