从服务器检索所有DICOM对象

Question

All, Forgive me I just began to learn the DICOM. I knew all the DICOM objects would be stored in a DICOM server. In the really words . It should be a PACS server. Basically, It works like the SQL record stored in the Table from the Database (like SQL server). So in the DICOM world . There should have the equivalent commands (select , insert, update) like in the SQL? Right?

My question is

Is there any command to retrieve all the DICOM object stored in the DICOM server?

BTW . Currently, I am working on the .Net. Please help to recommend a good open source DICOM client SDK to me. Thanks.

Answer 1

What you are looking for is dicom Query/Retrieve service http://dicom.nema.org/dicom/2013/output/chtml/part04/sect_C.3.html

It is a basic service, so all dicom implementations should support it.

I don't have experience with Dicom under .Net, but there are a few open source libraries available (see https://www.google.fr/search?q=dicom+api+.net ) and SO doesn't allow asking for tool recommendations, so I don't want to randomly pick one...

Answer 2

There are two different questions that you put:

1. How can I talk DICOM for the purpose of retrieving images?
2. How can I put a vaild DICOM query that instructs the server to transfer all images to a particular destination

ad 1. This question has been partially answered. To be more specific I recommend you to have a look at the DICOM toolkit by OFFIS . For your task you need to set up a storescp and movescu (and probably findscu - see 2). The tools are open source work out of the box from the command line. They are not .NET based, but maybe you do not want/need to write an application for that tasks.

ad 2. In theory you can do this by putting a C-MOVE request without any restrictions. However, only a few systems will accept this because it looks like a malformed request ("give me everything you got" is rarely what the user wants to do and may effect terabytes of data to be transferred with potential negative consequences for both systems involved in the transaction).

So you have to provide query criteria that limit that number of results matched by the C-MOVE request. In practice it depends on your use case what the most appropriate way of doing this would look like.

I assume that you want to do a data migration, so you really want to make sure not to miss a single dataset. In this case, I would use a query that imposes study date criteria. DICOM supports open and closed intervals. So you could split the packages of datasets to transfer into chunks of - let's say - one month. You should have an information or at least a reasonable assumption what the minimum study date residing on the server is. Then your first C-MOVE would move everything before that date, eg (for everything until Jan 01, 1990).

(0x0008, 0x0020) = [-19900101]

And then you put one query for each month:

(0x0008, 0x0020) = [19900102-19900201]
(0x0008, 0x0020) = [19900202-19900301]

...and so on...

It is worth a try if the remote DICOM node you are referring to accepts C-MOVE Requests formed in this way. However, it does not have to. For a valid C-MOVE you will have to provide unique matching keys for each study (yes, I am over-simplyfing here omitting the theory of the entire DICOM information model) you want to move. In this case you use the above mentioned strategy to C-FIND the Study Instance UIDs which fall into the provided date range. You can instruct any DICOM Server to return the Study Instance UID with each match just by appending an empty Study Instance UID attribute to your request, eg

    (0x0008, 0x0020) = [-19900101]
    (0x0008, 0x0052) = [STUDY]
    (0x0020, 0x000d) = []

Then you use the output of the server in the Study Instance UID attribute of each response as an input to the C-MOVE operation, eg

    (0x0008, 0x0052) = [STUDY]
    (0x0020, 0x000d) = [1.2.360.3234.345345.64575782356.23424.21.3]

This scenario would require you to set up C-FIND and C-MOVE clients ("Service Class Users", SCUs) and a C-STORE SCP (Service Class Provider) which is the target for the C-MOVE operation.

Sorry not to provide easier instructions, but these are DICOM's nasty little details...