findscu - Modality is ignored when searching by studydate, patientID and modality
Moderator: Moderator Team
findscu - Modality is ignored when searching by studydate, patientID and modality
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.
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.
-
- DCMTK Developer
- Posts: 2505
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: findscu - Modality is ignored when searching by studydate, patientID and modality
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.
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.
Re: findscu - Modality is ignored when searching by studydate, patientID and modality
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.
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.
-
- DCMTK Developer
- Posts: 2505
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: findscu - Modality is ignored when searching by studydate, patientID and modality
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.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
But, if you want to retrieve MR series only, you definitely have to query and retrieve on SERIES level.
Re: findscu - Modality is ignored when searching by studydate, patientID and modality
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!
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!
-
- DCMTK Developer
- Posts: 2505
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: findscu - Modality is ignored when searching by studydate, patientID and modality
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).
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).
Re: findscu - Modality is ignored when searching by studydate, patientID and modality
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
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
-
- DCMTK Developer
- Posts: 2505
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: findscu - Modality is ignored when searching by studydate, patientID and modality
This might be the case, but your query would be still invalid, i.e. not DICOM-compliant.It appears it works without Series Instance UID.
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).All I need is to confirm is that the search modality is included in the returned result.
Re: findscu - Modality is ignored when searching by studydate, patientID and modality
Output does not change if i include 0008,0060=MR in the series-level query, no matter which modality i select.
-
- DCMTK Developer
- Posts: 2505
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: findscu - Modality is ignored when searching by studydate, patientID and modality
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?
Re: findscu - Modality is ignored when searching by studydate, patientID and modality
Sorry, i am not that tech savvy. Wish I was!
Re: findscu - Modality is ignored when searching by studydate, patientID and modality
Forgot to thank you for your help - I learned a lot.
Who is online
Users browsing this forum: Majestic-12 [Bot] and 1 guest