I have DCMTK Server running on Linux machine with the number of test studies loaded.
I used several DICOM clients (and DCMTK FINDSCU utility) to query this Server for studies with specific modalities (CT, MR etc...)
and always got back all studies (with all modalities) and Modality field just empty .
Looks like DCMTK Server doesn't send the modality of the study in the response.
Is there anything in Server configuration which can resolve this ?
Thanks in advance
DCMTK PACS Server ignores the modality
Moderator: Moderator Team
-
- DCMTK Developer
- Posts: 2505
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: DCMTK PACS Server ignores the modality
Could you give us more details, e.g. what does your query look like and what are the responses (log output)?
Re: DCMTK PACS Server ignores the modality
Thanks for quick reply.
This is the query:
findscu -S -aec FSS_CTWIN_STORE -aet SIMON_PC localhost 104 -k QueryRetrieveLevel=STUDY -k PatientName -k Modality -k ModalitiesInStudy=CT
I query all CT studies for all patients. Expect only CT studies, but server responds with all studies (CT, MR, OT, XA etc...)
When I run similar query from other clients (OSIRIX,SLICER,RADIANT), Modality Column is empty for all studies.
Same studies stored on another PACS behave properly. THanks again. Log follows....
I: ---------------------------
I: Find Response: 1 (Pending)
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [STUDY ] # 6, 1 QueryRetrieveLevel
I: (0008,0054) AE [FSS_CTWIN_STORE ] # 16, 1 RetrieveAETitle
I: (0008,0060) CS [CT] # 2, 1 Modality
I: (0010,0010) PN [DVOINENKO O V ] # 14, 1 PatientName
I:
I: ---------------------------
I: Find Response: 2 (Pending)
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [STUDY ] # 6, 1 QueryRetrieveLevel
I: (0008,0054) AE [FSS_CTWIN_STORE ] # 16, 1 RetrieveAETitle
I: (0008,0060) CS [OT] # 2, 1 Modality
I: (0010,0010) PN (no value available) # 0, 0 PatientName
I:
I: ---------------------------
I: Find Response: 3 (Pending)
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [STUDY ] # 6, 1 QueryRetrieveLevel
I: (0008,0054) AE [FSS_CTWIN_STORE ] # 16, 1 RetrieveAETitle
I: (0008,0060) CS [XA] # 2, 1 Modality
I: (0010,0010) PN [Centerline Study 1] # 18, 1 PatientName
I:
I: ---------------------------
I: Find Response: 4 (Pending)
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [STUDY ] # 6, 1 QueryRetrieveLevel
I: (0008,0054) AE [FSS_CTWIN_STORE ] # 16, 1 RetrieveAETitle
I: (0008,0060) CS [MR] # 2, 1 Modality
I: (0010,0010) PN [Pogrebinsky^Simon ] # 18, 1 PatientName
I:
I: ---------------------------
I: Find Response: 5 (Pending)
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [STUDY ] # 6, 1 QueryRetrieveLevel
I: (0008,0054) AE [FSS_CTWIN_STORE ] # 16, 1 RetrieveAETitle
I: (0008,0060) CS [CT] # 2, 1 Modality
I: (0010,0010) PN [Somewhat^Healthy] # 16, 1 PatientName
I:
I: ---------------------------
I: Find Response: 6 (Pending)
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [STUDY ] # 6, 1 QueryRetrieveLevel
I: (0008,0054) AE [FSS_CTWIN_STORE ] # 16, 1 RetrieveAETitle
I: (0008,0060) CS [CT] # 2, 1 Modality
I: (0010,0010) PN [Plastic Skull ] # 14, 1 PatientName
I:
This is the query:
findscu -S -aec FSS_CTWIN_STORE -aet SIMON_PC localhost 104 -k QueryRetrieveLevel=STUDY -k PatientName -k Modality -k ModalitiesInStudy=CT
I query all CT studies for all patients. Expect only CT studies, but server responds with all studies (CT, MR, OT, XA etc...)
When I run similar query from other clients (OSIRIX,SLICER,RADIANT), Modality Column is empty for all studies.
Same studies stored on another PACS behave properly. THanks again. Log follows....
I: ---------------------------
I: Find Response: 1 (Pending)
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [STUDY ] # 6, 1 QueryRetrieveLevel
I: (0008,0054) AE [FSS_CTWIN_STORE ] # 16, 1 RetrieveAETitle
I: (0008,0060) CS [CT] # 2, 1 Modality
I: (0010,0010) PN [DVOINENKO O V ] # 14, 1 PatientName
I:
I: ---------------------------
I: Find Response: 2 (Pending)
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [STUDY ] # 6, 1 QueryRetrieveLevel
I: (0008,0054) AE [FSS_CTWIN_STORE ] # 16, 1 RetrieveAETitle
I: (0008,0060) CS [OT] # 2, 1 Modality
I: (0010,0010) PN (no value available) # 0, 0 PatientName
I:
I: ---------------------------
I: Find Response: 3 (Pending)
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [STUDY ] # 6, 1 QueryRetrieveLevel
I: (0008,0054) AE [FSS_CTWIN_STORE ] # 16, 1 RetrieveAETitle
I: (0008,0060) CS [XA] # 2, 1 Modality
I: (0010,0010) PN [Centerline Study 1] # 18, 1 PatientName
I:
I: ---------------------------
I: Find Response: 4 (Pending)
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [STUDY ] # 6, 1 QueryRetrieveLevel
I: (0008,0054) AE [FSS_CTWIN_STORE ] # 16, 1 RetrieveAETitle
I: (0008,0060) CS [MR] # 2, 1 Modality
I: (0010,0010) PN [Pogrebinsky^Simon ] # 18, 1 PatientName
I:
I: ---------------------------
I: Find Response: 5 (Pending)
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [STUDY ] # 6, 1 QueryRetrieveLevel
I: (0008,0054) AE [FSS_CTWIN_STORE ] # 16, 1 RetrieveAETitle
I: (0008,0060) CS [CT] # 2, 1 Modality
I: (0010,0010) PN [Somewhat^Healthy] # 16, 1 PatientName
I:
I: ---------------------------
I: Find Response: 6 (Pending)
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [STUDY ] # 6, 1 QueryRetrieveLevel
I: (0008,0054) AE [FSS_CTWIN_STORE ] # 16, 1 RetrieveAETitle
I: (0008,0060) CS [CT] # 2, 1 Modality
I: (0010,0010) PN [Plastic Skull ] # 14, 1 PatientName
I:
-
- DCMTK Developer
- Posts: 2049
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
Re: DCMTK PACS Server ignores the modality
Hi,
there are two issues with your query:
findscu -S selects Study Root information model. And in that model you query the STUDY level (-k QueryRetrieveLevel=STUDY).
First issue: On STUDY level you are not allowed to query for a non-STUDY level tag, i.e. a query for the series level attribute "Modality" is not allowed.
Thus, you send an invalid query and it is "random" what a specific product will return to you (garbage in - garbage out). You could get an error, or the server could treat the tag as "optional" and ignore it, or, it tries to guess the purpose of your invalid query.
The second "issue" is that you send ModalitiesInStudy (which is fine!) but you do not get the tag back in the results. The reason is that the server does not support this optional query key!
That is the correct behaviour of the server since the DICOM standard says that unsupported keys are removed from the query/results.
So overall, what happens in your case? The server removes ModalitiesInStudy and does not filter for it. So you get all studies returned. The server recognizes that you send a SERIES level tag which is not allowed but returns the tag anyway, probably filling in the value for any of the series of the study. But you can only guess that. Actually, as the server, I would have no idea what kind of result you actually would expect...
If you run dcmqrscp as the server, you can use --check-find in order to check the search keys more thoroughly. Also, you should enable debug mode (--debug) on the server, I guess it spits out some details of what it is doing to answer your invalid query.
In order to work around missing ModalitiesInStudy support, you would have to query the server a second time on SERIES level for each of the studies in order to find out what kind of Modalities are in the study.
Best,
Michael
there are two issues with your query:
findscu -S selects Study Root information model. And in that model you query the STUDY level (-k QueryRetrieveLevel=STUDY).
First issue: On STUDY level you are not allowed to query for a non-STUDY level tag, i.e. a query for the series level attribute "Modality" is not allowed.
Thus, you send an invalid query and it is "random" what a specific product will return to you (garbage in - garbage out). You could get an error, or the server could treat the tag as "optional" and ignore it, or, it tries to guess the purpose of your invalid query.
The second "issue" is that you send ModalitiesInStudy (which is fine!) but you do not get the tag back in the results. The reason is that the server does not support this optional query key!
That is the correct behaviour of the server since the DICOM standard says that unsupported keys are removed from the query/results.
So overall, what happens in your case? The server removes ModalitiesInStudy and does not filter for it. So you get all studies returned. The server recognizes that you send a SERIES level tag which is not allowed but returns the tag anyway, probably filling in the value for any of the series of the study. But you can only guess that. Actually, as the server, I would have no idea what kind of result you actually would expect...
If you run dcmqrscp as the server, you can use --check-find in order to check the search keys more thoroughly. Also, you should enable debug mode (--debug) on the server, I guess it spits out some details of what it is doing to answer your invalid query.
In order to work around missing ModalitiesInStudy support, you would have to query the server a second time on SERIES level for each of the studies in order to find out what kind of Modalities are in the study.
Best,
Michael
Who is online
Users browsing this forum: Bing [Bot], Google [Bot] and 1 guest