C-FIND zero-length vs asterisk key attribute

[Aljaž]

Hi all,

I need your help regarding C-FIND and key attributes. The software I am working on receives only a SOP instance UID from an external system. Based on the received SOP instance UID the software needs to retrieve the corresponding DICOM instance. For retrieval, study instance UID and series instance UID are mandatory parameters (C# fo-dicom library requires them), so first I need to perform C-FIND at IMAGE level with the received SOP instance UID and empty (zero-length) study instance UID and series instance UID. The problem I have is that what works for dcm4chee does not work for orthanc and vice-versa.

Orthanc performs the query when zero-length attributes are used, but fails if asterisks are used as values. On the other hand, dcm4chee performs the query when asterisks are used, but fails when zero-length attributes are used. Based on the references below, I am guessing that the correct way is using zero-length for attributes of type UI (e.g., study instance UID) and not asterisks. Is this correct or am I missing something? Also, is it even allowed to do this kind of query as mentioned above (IMAGE level query with SOP instance UID and unknown study and series instance UIDs)?

C.2.2.2.3 Universal Matching (https://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_C.2.2.2.3.html)

• If the value specified for a Key Attribute in a request is zero length, then all entities shall match this Attribute. An Attribute that contains a Universal Matching specification in a C-FIND request provides a mechanism to request the selected Attribute Value be returned in corresponding C-FIND responses.
  

C.2.2.2.4 Wild Card Matching (https://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_C.2.2.2.4.html):

• If the Attribute is of VR of AE, CS, LO, LT, PN, SH, ST, UC, UR, UT and the value specified in the request contains any occurrence of an "*" or a "?", then "*" shall match any sequence of characters (including a zero length value) and "?" shall match any single character.
  
• Wild Card Matching on a value of "*" is equivalent to Universal Matching.
  

Best regards,

Aljaž

[Gunter Zeilinger]

Can't reproduce any failure to process C-FIND RQs with empty UI attributes by dcm4chee-arc 5:


12:59:03.654 INFO  - FINDSCU->DCM4CHEE(1) << 1:C-FIND-RQ[pcid=1, prior=0
  cuid=1.2.840.10008.5.1.4.1.2.2.1 - Study Root Query/Retrieve Information Model - FIND
  tsuid=1.2.840.10008.1.2 - Implicit VR Little Endian]
12:59:03.654 DEBUG - FINDSCU->DCM4CHEE(1) << 1:C-FIND-RQ Command:
(0000,0002) UI [1.2.840.10008.5.1.4.1.2.2.1] AffectedSOPClassUID
(0000,0100) US [32] CommandField
(0000,0110) US [1] MessageID
(0000,0700) US [0] Priority
(0000,0800) US [0] CommandDataSetType

12:59:03.672 DEBUG - FINDSCU->DCM4CHEE(1) << 1:C-FIND-RQ Dataset:
(0008,0020) DA [19950608] StudyDate
(0008,0052) CS [STUDY] QueryRetrieveLevel
(0020,000D) UI [] StudyInstanceUID

12:59:03.682 INFO  - FINDSCU->DCM4CHEE(1) >> 1:C-FIND-RSP[pcid=1, status=ff00H
  cuid=1.2.840.10008.5.1.4.1.2.2.1 - Study Root Query/Retrieve Information Model - FIND
  tsuid=1.2.840.10008.1.2 - Implicit VR Little Endian]
12:59:03.683 DEBUG - FINDSCU->DCM4CHEE(1) >> 1:C-FIND-RSP Command:
(0000,0002) UI [1.2.840.10008.5.1.4.1.2.2.1] AffectedSOPClassUID
(0000,0100) US [32800] CommandField
(0000,0120) US [1] MessageIDBeingRespondedTo
(0000,0800) US [0] CommandDataSetType
(0000,0900) US [65280] Status

12:59:03.683 DEBUG - FINDSCU->DCM4CHEE(1) >> 1:C-FIND-RSP Dataset:
(0008,0005) CS [] SpecificCharacterSet
(0008,0020) DA [19950608] StudyDate
(0008,0052) CS [STUDY] QueryRetrieveLevel
(0008,0054) AE [DCM4CHEE] RetrieveAETitle
(0008,0056) CS [ONLINE] InstanceAvailability
(0008,0201) SH [] TimezoneOffsetFromUTC
(0020,000D) UI [1.2.840.113674.514.212.200] StudyInstanceUID

12:59:03.683 INFO  - FINDSCU->DCM4CHEE(1) >> 1:C-FIND-RSP[pcid=1, status=0H
  cuid=1.2.840.10008.5.1.4.1.2.2.1 - Study Root Query/Retrieve Information Model - FIND
  tsuid=1.2.840.10008.1.2 - Implicit VR Little Endian]
12:59:03.683 DEBUG - FINDSCU->DCM4CHEE(1) >> 1:C-FIND-RSP Command:
(0000,0002) UI [1.2.840.10008.5.1.4.1.2.2.1] AffectedSOPClassUID
(0000,0100) US [32800] CommandField
(0000,0120) US [1] MessageIDBeingRespondedTo
(0000,0800) US [257] CommandDataSetType
(0000,0900) US [0] Status

[Aljaž]

Thank you for the response. I tried to do image level query where SOP instance UID was known and I needed to find study and series instance UIDs. I am not sure if this kind of query is allowed based on DICOM. Here are two examples with zero-lengh and asterisks values (tested with dcmtk tools v3.6.7):

Zero-length does not work:

I: Requesting Association I: Association Accepted (Max Send PDV: 16366) I: Sending Find Request (MsgID 1) I: Request Identifiers: I: I: # Dicom-Data-Set I: # Used TransferSyntax: Little Endian Explicit I: (0008,0018) UI [1.2.840.10008.5.1.4.1.1.481.3.1577704327] # 40, 1 SOPInstanceUID I: (0008,0052) CS [IMAGE] # 6, 1 QueryRetrieveLevel I: (0010,0020) LO (no value available) # 0, 0 PatientID I: (0020,000d) UI (no value available) # 0, 0 StudyInstanceUID I: (0020,000e) UI (no value available) # 0, 0 SeriesInstanceUID I: (0020,0013) IS (no value available) # 0, 0 InstanceNumber I: I: Received Final Find Response (Error: DataSetDoesNotMatchSOPClass) I: Releasing Association

Asterisks do work:

I: Requesting Association I: Association Accepted (Max Send PDV: 16366) I: Sending Find Request (MsgID 1) I: Request Identifiers: I: I: # Dicom-Data-Set I: # Used TransferSyntax: Little Endian Explicit I: (0008,0018) UI [1.2.840.10008.5.1.4.1.1.481.3.1577704327] # 40, 1 SOPInstanceUID I: (0008,0052) CS [IMAGE] # 6, 1 QueryRetrieveLevel I: (0010,0020) LO [*] # 2, 1 PatientID I: (0020,000d) UI [*] # 2, 1 StudyInstanceUID I: (0020,000e) UI [*] # 2, 1 SeriesInstanceUID I: (0020,0013) IS (no value available) # 0, 0 InstanceNumber I: I: --------------------------- I: Find Response: 1 (Pending) I: I: # Dicom-Data-Set I: # Used TransferSyntax: Little Endian Implicit I: (0008,0005) CS [ISO_IR 100] # 10, 1 SpecificCharacterSet I: (0008,0018) UI [1.2.840.10008.5.1.4.1.1.481.3.1577704327] # 40, 1 SOPInstanceUID I: (0008,0052) CS [IMAGE ] # 6, 1 QueryRetrieveLevel I: (0008,0054) AE [DCM4CHEE] # 8, 1 RetrieveAETitle I: (0008,0056) CS [ONLINE] # 6, 1 InstanceAvailability I: (0008,0201) SH (no value available) # 0, 0 TimezoneOffsetFromUTC I: (0010,0020) LO [4586A29B2 ] # 10, 1 PatientID I: (0020,000d) UI [1.2.276.0.7230010.3.1.2.1263924744.880.1577705818.1536] # 54, 1 StudyInstanceUID I: (0020,000e) UI [1.2.276.0.7230010.3.1.3.1263924744.880.1577705818.1543] # 54, 1 SeriesInstanceUID I: (0020,0013) IS (no value available) # 0, 0 InstanceNumber I: I: Received Final Find Response (Success) I: Releasing Association  

sreda, 11. oktober 2023 ob 13:05:24 UTC+2 je oseba gunt...@protonmail.com napisala:

[Aljaž]

Also, I used dcm4chee 5.31.0 running in docker.

sreda, 11. oktober 2023 ob 13:43:02 UTC+2 je oseba Aljaž napisala:

[Gunter Zeilinger]

You have to negotiate Relational Queries for queries on Instance level, without specifying a Study and Series Instance UID in the C-FIND RQ. Seems the check by dcm4chee-arc can be fooled by setting "*" as UID value.
You may disable the check by setting Archive Device attribute Relational Query Negotiation Lenient = true

[Aljaž]

Thank you, I will try this.

V V sre., 11. okt. 2023 ob 14:00 je oseba 'Gunter Zeilinger' via dcm4che <dcm...@googlegroups.com> napisala:

--
You received this message because you are subscribed to a topic in the Google Groups "dcm4che" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dcm4che/-DYAtoA4g_A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dcm4che+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dcm4che/77fcebda-4551-43c9-9fec-a2af796c090fn%40googlegroups.com.

[Gunter Zeilinger]

5.31.1 will also Reject query/retrieve requests with wildcard values for unique keys for levels above the query/retrieve level