findscu - Modality is ignored when searching by studydate, patientID and modality

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
bkasmai
Posts: 20
Joined: Tue, 2009-07-28, 11:48

findscu - Modality is ignored when searching by studydate, patientID and modality

#1 Post by bkasmai »

I need to search for a study using patientId, studydate and modality using the command below:

findscu.exe -v -O -k 0008,0052=STUDY -aet MYSCU -aec DICOMNODE 10.145.95.154 104 -k 0008,0060 -k 0008,0020=20210406 -k 0010,0020=patientid -k 0008,0060=US -k 0020,000D

The command succeeds but it appears that 0008,0060=US section of the command is ignored and the returned study is filtered only on patientID and StudyDate. What am i doing wrong? I don't want findscu to return any study performed on the specified study date except the one with the right modality, i.e. US only. Any help on this will be appreciated.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: findscu - Modality is ignored when searching by studydate, patientID and modality

#2 Post by J. Riesmeier »

Modality (0008,0060) is not a STUDY-level attribute, but associated with the SERIES level. If supported by the Q/R SCP, you could use Modalities in Study (0008,0061) instead of it - see DICOM PS3.4 Table C.3-1 for details. Otherwise you would need to issue another query on SERIES level.

By the way, why do you use the retired Patient/Study Only Q/R Information Model? The Study Root Q/R Information Model seems to be more appropriate to me. This also allows for mixing PATIENT and STUDY level, which is not true for Patient/Study Only.

bkasmai
Posts: 20
Joined: Tue, 2009-07-28, 11:48

Re: findscu - Modality is ignored when searching by studydate, patientID and modality

#3 Post by bkasmai »

Forgive my ignorance on not having a grip on Dicom information models. I tried -S, -P and -O switches to get the results I wanted but thanks to your reply I now understand that Modality attribute is associated with the Series level. My aim was to use movescu to move a study using known values for PatientID, StudyDate and Modality. I use findscu first to get the study UID, parse it and then use movescu to move it to my local storage. This has worked but then if a patient is scanned on the same day on different modalities my method fails to move the right study.

findscu.exe -v -S -k 0008,0052=STUDY -aet MySCP -aec DICOMSCP 10.145.95.154 104 -k 0008,0060=MR -k 0008,0020=20210406 -k 0010,0020=123456 -k 0020,000D

I parse the output from above and then use movescu to move the study to my local drive:

movescu -v -S -k 0008,0052=STUDY -aet MYSCP -aec DICOMSCP 10.145.95.154 104 -k 0020,000D=1.2.840.113845.11.1000000001951524609.20210406091830.2551313 -k 0010,0020=123456 -od h:\\study --port 104

This method works but when a patient has more than one studies on the same day on two different modalities it fails to move the right study. I appreciate your guidance on this.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: findscu - Modality is ignored when searching by studydate, patientID and modality

#4 Post by J. Riesmeier »

findscu.exe -v -S -k 0008,0052=STUDY -aet MySCP -aec DICOMSCP 10.145.95.154 104 -k 0008,0060=MR -k 0008,0020=20210406 -k 0010,0020=123456 -k 0020,000D
Since findscu does not support relational queries, you should remove the "-k 0008,0060=MR" from the above call. If you want to filter out all MR series, you have to issue another query on SERIES level (for all studies that are returned by the STUDY-level query). If you are interested in all studies that contain at least a single MR series, you could also try to add Modalities in Study (0008,0061) to the STUDY-level query. Please note, however, that this attribute is not supported by all Q/R SCPs.

But, if you want to retrieve MR series only, you definitely have to query and retrieve on SERIES level.

bkasmai
Posts: 20
Joined: Tue, 2009-07-28, 11:48

Re: findscu - Modality is ignored when searching by studydate, patientID and modality

#5 Post by bkasmai »

Thank you for your advice. At the end I had to issue another findscu at the series level to confirm the study's modality:

findscu -v -d -S -k QueryRetrieveLevel=SERIES -k 0020,000d="1.2.840.113845.11.1000000001951524609.20210406091830.2551313" -k 0008,0060 -aet MYSCP -aec DICOMSCP 10.145.95.154 104

I then parse the output and look for (0008,0060) CS [MR] to confirm that the study is for MR. Notsure this is right or the most effiient way to do a simple way to query/retrieve a study using PatientID,StudyDate and Modality info. Two finscu commands followed by movescu

I also note that most of our studies in PACS do not have (0008,0061) tag!

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: findscu - Modality is ignored when searching by studydate, patientID and modality

#6 Post by J. Riesmeier »

Modalities in Study (0008,0061) is an additional attribute that might be supported by the PACS (Q/R SCP). It should never be contained in a DICOM SOP Instance!

By the way, in your SERIES-level query you also need to add the Unique Key for this level, which is the Series Instance UID (0020,000E).

bkasmai
Posts: 20
Joined: Tue, 2009-07-28, 11:48

Re: findscu - Modality is ignored when searching by studydate, patientID and modality

#7 Post by bkasmai »

By the way, in your SERIES-level query you also need to add the Unique Key for this level, which is the Series Instance UID (0020,000E).

It appears it works without Series Instance UID. See line D: (0008,0060) CS [MR] # 2, 1 Modality in the output below:

All I need is to confirm is that the search modality is included in the returned result.

findscu -v -d -S -k QueryRetrieveLevel=SERIES -k 0020,000d="1.2.840.113845.11.1000000001951524609.20210406091830.2551313" -k 0008,0060 -aet MYSCP -aec DICOMSCP 10.145.95.154 104

D: $dcmtk: findscu v3.6.7 2022-04-22 $
D:
D: Request Parameters:
D: ====================== BEGIN A-ASSOCIATE-RQ =====================
D: Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.7
D: Our Implementation Version Name: OFFIS_DCMTK_367
D: Their Implementation Class UID:
D: Their Implementation Version Name:
D: Application Context Name: 1.2.840.10008.3.1.1.1
D: Calling Application Name: BKWIN10SCP
D: Called Application Name: SSYNNNUHSCP
D: Responding Application Name: SSYNNNUHSCP
D: Our Max PDU Receive Size: 16384
D: Their Max PDU Receive Size: 0
D: Presentation Contexts:
D: Context ID: 1 (Proposed)
D: Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel
D: Proposed SCP/SCU Role: Default
D: Proposed Transfer Syntax(es):
D: =LittleEndianExplicit
D: =BigEndianExplicit
D: =LittleEndianImplicit
D: Requested Extended Negotiation: none
D: Accepted Extended Negotiation: none
D: Requested User Identity Negotiation: none
D: User Identity Negotiation Response: none
D: ======================= END A-ASSOCIATE-RQ ======================
I: Requesting Association
D: setting network send timeout to 60 seconds
D: setting network receive timeout to 60 seconds
D: Constructing Associate RQ PDU
D: PDU Type: Associate Accept, PDU Length: 174 + 6 bytes PDU header
D: 02 00 00 00 00 ae 00 01 00 00 53 53 59 4e 4e 4e
D: 55 48 53 43 50 20 20 20 20 20 42 4b 57 49 4e 31
D: 30 53 43 50 20 20 20 20 20 20 00 00 00 00 00 00
D: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
D: 00 00 00 00 00 00 00 00 00 00 10 00 00 15 31 2e
D: 32 2e 38 34 30 2e 31 30 30 30 38 2e 33 2e 31 2e
D: 31 2e 31 21 00 00 19 01 00 00 00 40 00 00 11 31
D: 2e 32 2e 38 34 30 2e 31 30 30 30 38 2e 31 2e 32
D: 50 00 00 30 51 00 00 04 00 00 fd e8 52 00 00 12
D: 31 2e 32 2e 38 34 30 2e 31 31 33 38 34 35 2e 31
D: 2e 31 55 00 00 0e 53 79 6e 35 2c 37 2c 32 31 32
D: 2c 31 31 31
D: Parsing an A-ASSOCIATE PDU
D: Association Parameters Negotiated:
D: ====================== BEGIN A-ASSOCIATE-AC =====================
D: Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.7
D: Our Implementation Version Name: OFFIS_DCMTK_367
D: Their Implementation Class UID: 1.2.840.113845.1.1
D: Their Implementation Version Name: Syn5,7,212,111
D: Application Context Name: 1.2.840.10008.3.1.1.1
D: Calling Application Name: MYSCP
D: Called Application Name: DICOMSCP
D: Responding Application Name: DICOMSCP
D: Our Max PDU Receive Size: 16384
D: Their Max PDU Receive Size: 65000
D: Presentation Contexts:
D: Context ID: 1 (Accepted)
D: Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel
D: Proposed SCP/SCU Role: Default
D: Accepted SCP/SCU Role: Default
D: Accepted Transfer Syntax: =LittleEndianImplicit
D: Requested Extended Negotiation: none
D: Accepted Extended Negotiation: none
D: Requested User Identity Negotiation: none
D: User Identity Negotiation Response: none
D: ======================= END A-ASSOCIATE-AC ======================
I: Association Accepted (Max Send PDV: 64988)
I: Sending Find Request
D: ===================== OUTGOING DIMSE MESSAGE ====================
D: Message Type : C-FIND RQ
D: Presentation Context ID : 1
D: Message ID : 1
D: Affected SOP Class UID : FINDStudyRootQueryRetrieveInformationModel
D: Data Set : present
D: Priority : medium
D: ======================= END DIMSE MESSAGE =======================
I: Request Identifiers:
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [SERIES] # 6, 1 QueryRetrieveLevel
I: (0008,0060) CS (no value available) # 0, 0 Modality
I: (0020,000d) UI [1.2.840.113845.11.1000000001951524609.20210406091830.2551313] # 60, 1 StudyInstanceUID
I:
D: DcmDataset::read() TransferSyntax="Little Endian Implicit"
D: DcmDataset::read() TransferSyntax="Little Endian Implicit"
I: Received Find Response 1
D: ===================== INCOMING DIMSE MESSAGE ====================
D: Message Type : C-FIND RSP
D: Message ID Being Responded To : 1
D: Affected SOP Class UID : FINDStudyRootQueryRetrieveInformationModel
D: Data Set : present
D: DIMSE Status : 0xff00: Pending: Matches are continuing
D: ======================= END DIMSE MESSAGE =======================
D: Response Identifiers:
D:
D: # Dicom-Data-Set
D: # Used TransferSyntax: Little Endian Implicit
D: (0008,0052) CS [SERIES] # 6, 1 QueryRetrieveLevel
D: (0008,0054) AE [SYNNNUH5DicomSCP] # 16, 1 RetrieveAETitle
D: (0008,0060) CS [MR] # 2, 1 Modality
D: (0020,000d) UI [1.2.840.113845.11.1000000001951524609.20210406091830.2551313] # 60, 1 StudyInstanceUID
D:
D: DcmDataset::read() TransferSyntax="Little Endian Implicit"
D: DcmDataset::read() TransferSyntax="Little Endian Implicit"
I: Received Find Response 2
D: ===================== INCOMING DIMSE MESSAGE ====================
D: Message Type : C-FIND RSP
D: Message ID Being Responded To : 1
D: Affected SOP Class UID : FINDStudyRootQueryRetrieveInformationModel
D: Data Set : present
D: DIMSE Status : 0xff00: Pending: Matches are continuing
D: ======================= END DIMSE MESSAGE =======================
D: Response Identifiers:
D:
D: # Dicom-Data-Set
D: # Used TransferSyntax: Little Endian Implicit
D: (0008,0052) CS [SERIES] # 6, 1 QueryRetrieveLevel
D: (0008,0054) AE [SYNNNUH5DicomSCP] # 16, 1 RetrieveAETitle
D: (0008,0060) CS [SR] # 2, 1 Modality
D: (0020,000d) UI [1.2.840.113845.11.1000000001951524609.20210406091830.2551313] # 60, 1 StudyInstanceUID
D:
D: DcmDataset::read() TransferSyntax="Little Endian Implicit"
I: Received Final Find Response
D: ===================== INCOMING DIMSE MESSAGE ====================
D: Message Type : C-FIND RSP
D: Message ID Being Responded To : 1
D: Affected SOP Class UID : FINDStudyRootQueryRetrieveInformationModel
D: Data Set : none
D: DIMSE Status : 0x0000: Success: Matching is complete
D: ======================= END DIMSE MESSAGE =======================
I: Releasing Association

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: findscu - Modality is ignored when searching by studydate, patientID and modality

#8 Post by J. Riesmeier »

It appears it works without Series Instance UID.
This might be the case, but your query would be still invalid, i.e. not DICOM-compliant.
All I need is to confirm is that the search modality is included in the returned result.
If I were you, I would use the Modality (0008,0060) attribute as a Query Key with Single Value Matching, i.e. "-k 0008,0060=MR" in your SERIES-level query. Each Q/R SCP has to support it (see DICOM PS3.3 Table C.6-3).

bkasmai
Posts: 20
Joined: Tue, 2009-07-28, 11:48

Re: findscu - Modality is ignored when searching by studydate, patientID and modality

#9 Post by bkasmai »

Output does not change if i include 0008,0060=MR in the series-level query, no matter which modality i select.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: findscu - Modality is ignored when searching by studydate, patientID and modality

#10 Post by J. Riesmeier »

Then the Q/R SCP might not be DICOM-compliant. By the way, did you already check the DICOM Conformance Statement of this particular system?

bkasmai
Posts: 20
Joined: Tue, 2009-07-28, 11:48

Re: findscu - Modality is ignored when searching by studydate, patientID and modality

#11 Post by bkasmai »

Sorry, i am not that tech savvy. Wish I was!

bkasmai
Posts: 20
Joined: Tue, 2009-07-28, 11:48

Re: findscu - Modality is ignored when searching by studydate, patientID and modality

#12 Post by bkasmai »

Forgot to thank you for your help - I learned a lot.

Post Reply

Who is online

Users browsing this forum: Amazon [Bot], Bing [Bot], Google [Bot] and 1 guest