C-Find query with Japanese PatientName

[Hua Cong Danh]

I have used C-Find to query data from server (I use version DCMTK3.5.4). It run correctly when the patient name is romaji (ex. English) only, but incorrectly in case that patient name contains Japanese characters (ex. Kanji).
Then I tried to encode Japanese characters with specific encoder (IR 87), put it in search conditions and then query to server. This query worked with Conquest dicom server, but didn't work with Dcm4chee (it always return no result) .
Could anyone explain what's the problem with this. And is it possible to query with search condition which contains Japanese characters in Patient Name?
Thanks a lot.

[Michael Onken]

Hi,

maybe you have to specify the tag Specific Character Set (0008,0015) in your query to explain to the server in which language your query is; otherwise the server has to guess or just does not find anything if interpreted as ASCII (which is the default character set in DICOM).

Try add that to your query, i.e. do add -k "SpecificCharacterSet=ISO 2022 IR 87" to your findscu query (or add the key in your program). ISO 2022 IR 87 is for JIS X 0208: Kanji. For other values, see description of the SOP Common Module in the standard; in DICOM 2011 this is in section C.12.1.1.2.

Michael

[Hua Cong Danh]

Thanks for your reply.

As you had suggested, I came to a test with finscu. I create command lines like this:

findscu -d -P -aec [AETitle] [IP] [Port] -k 0008,0005="ISO 2022 IR 87" SearchMask.dcm

and

findscu -d -P -aec [AETitle] [IP] [Port] -k SpecificCharacterSet="ISO 2022 IR 87" searchMask.dcm

but in two cases the program return with error message "bad key format or dictionary not found in dictionary..."

Did I make mistake somewhere?

I try another way by adding value "ISO 2022 IR 87" into tag (0008,0005) in SearchMask.dcm file. The value of tag PatientName (0010,0010) is "$B;3ED(B" (which is the encoded string of 山田).
With this SearchMask.dcm file, I queried successfully to ConquestDicom server; but still didn't work wirh DCM4CHEE.

I looked up the status log in ConquestDicom server and found this log:

[CONQUESTSRV1] Values: DICOMPatients.PatientNam LIKE '% $B;3ED (B%'

It seem to be that the CONQUESTSRV1 SCP use the PatientName as it had been sent by SCU (in other word, the SCP would not decode the PatientName in search condition). However, if all SCP act as this way, the result must be the same for all SCP, but in my case ConquestDicom server and DCM4CHEE response differently.
I still doubt about whether the SCP decode the SearchCondition base on the CharacterSet config in tag (0008,0005) or keep it as originally. I have looked up the Dicom specification document but found no answer.
Can you explain this problem for me.

Many thanks.

[Michael Onken]

Hi,

bad key format or dictionary not found in dictionary...

means that findscu is not able to understand one of your -k options. Are you sure you did not mistype the tag? Also, I recommend puting the attribute values into quotes, e.g. -k PatientName="blabla".

Another reason could be that the DICOM dictionary is not found (if you are on a unix-like system). Does it work without the Specific Character Set key?

Michael

P.S: There was an old version of findscu in DCMTK 3.5.4 which had such a bugleading to this output nearly any time. Be sure to use version 3.6.0 or anything newer than a few years

[Hua Cong Danh]

Hi,

Now I can query successfully with fixed version from ftp://dicom.offis.de/pub/dicom/offis/so ... 354/patch/.
I describe the query as below (I sent query to two server ConquestSRV and DCM4CHEE):

In search condition,
Tag PatientName has value: *;3ED* (encoded string of 山田)
Tag SpecificCharacterSet has value: \ISO 2022 IR 87\ISO 2022 IR 13
...

Result from ConquestSRV
1 results.

Result from DCM4CHEE
0 results.

I quite sure that both server contain the data for patient 山田.
So the problem is why the two servers response differently with the same request?
And I also confuse about what does the SCP do with PatientName (Does it decode this tag or not )?
Could you give me some instructions.

Thanks

[Michael Onken]

Hi,

do you get any specific error from DCM4CHE returned? Be sure to use option -d in order to see the complete response status log.

Are you sure DCM4CHE supports japanese character sets, without further configuration?

It is difficult to identify the reason whithout any more specific information. By the way, why not use DCMTK 3.6.0 instead of 3.5.4 (with patch)?

Best regards,
Michael

[Hua Cong Danh]

Hi,

About the DCM4CHEE server:

Are you sure DCM4CHE supports japanese character sets, without further configuration?

I think that this server support Japanese because it can show Japanese character in viewer tool.

I posted as below the responses from server in two cases.

1/ Search condition PatientName=*B;3ED*
Result: 0 item

Requesting Association
Association Accepted (Max Send PDV: 16340)
DcmMetaInfo: Group Length of MetaInformation Header has incorrect value.
Find SCU RQ: MsgID 1
REQUEST:

# Dicom-Data-Set
# Used TransferSyntax: Little Endian Implicit
(0008,0005) CS [\ISO 2022 IR 87\ISO 2022 IR 13] # 30, 3 SpecificCharact
erSet
(0008,0020) DA (no value available) # 0, 0 StudyDate
(0008,0052) CS [PATIENT ] # 8, 1 QueryRetrieveLe
vel
(0008,1030) LO (no value available) # 0, 0 StudyDescriptio
n
(0010,0010) PN [B;3ED ] # 6, 1 PatientsName
(0010,0020) LO (no value available) # 0, 0 PatientID
(0010,0040) CS (no value available) # 0, 0 PatientsSex
(0020,000d) UI (no value available) # 0, 0 StudyInstanceUI
D
--------
C-Find RSP: MsgID: 1 [Status=Success]
AffectedSOPClassUID: =FINDPatientRootQueryRetrieveInformationModel
Data Set: Not Present
Releasing Association

2/ Search condition PatientName ==$B;3ED(B;
Result: 13 items

...
RESPONSE: 13 (Pending: WarningUnsupportedOptionalKeys)

# Dicom-Data-Set
# Used TransferSyntax: Little Endian Implicit
(0008,0000) UL 70 # 4, 1 IdentifyingGrou
pLength
(0008,0005) CS [\ISO 2022 IR 87\ISO 2022 IR 13] # 30, 3 SpecificCharact
erSet
(0008,0020) DA (no value available) # 0, 0 StudyDate
(0008,0052) CS [PATIENT ] # 8, 1 QueryRetrieveLe
vel
(0008,1030) LO (no value available) # 0, 0 StudyDescriptio
n
(0010,0000) UL 94 # 4, 1 PatientGroupLen
gth
(0010,0010) PN [Yamada^Tarou=$B;3ED(B^$BB@O:(B=$B$d$^$@(B^$B$?$m$&(B] #
60, 1 PatientsName
(0010,0020) LO [123456789 ] # 10, 1 PatientID
(0010,0040) CS (no value available) # 0, 0 PatientsSex
(0020,0000) UL 8 # 4, 1 ImageGroupLengt
h
(0020,000d) UI (no value available) # 0, 0 StudyInstanceUI
D
--------
C-Find RSP: MsgID: 1 [Status=Success]
AffectedSOPClassUID: =FINDPatientRootQueryRetrieveInformationModel
Data Set: Not Present
Releasing Association

So the problem could be my search condition (PatientName).
Maybe I made mistake when combine Japanese character with wildcard "*".

Thanks

[Michael Onken]

Hi,

so it works now for you, right?

In your first query, the request does not show the wildcards in the dump, so they are not sent if your quote was correct. Make sure to always use quotes around your commandline arguments, i.e. findscu ... -k "PatientName=*B;3ED*" ... You should see the wildcards also in the dump of findscu, otherwise they have not been sent.

Michael

[Hua Cong Danh]

Hi,

so it works now for you, right?

Yes, it work now after set the value for tag 0008,0005.

In your first query, the request does not show the wildcards in the dump

I posted the wrong response. Sorry about that.
The correct response is:
PatientName: *;3ED*

Requesting Association
Association Accepted (Max Send PDV: 16340)
DcmMetaInfo: Group Length of MetaInformation Header has incorrect value.
Find SCU RQ: MsgID 1
REQUEST:

# Dicom-Data-Set
# Used TransferSyntax: Little Endian Implicit
(0008,0005) CS [\ISO 2022 IR 87\ISO 2022 IR 13] # 30, 3 SpecificCharact
erSet
(0008,0020) DA (no value available) # 0, 0 StudyDate
(0008,0052) CS [PATIENT ] # 8, 1 QueryRetrieveLe
vel
(0008,1030) LO (no value available) # 0, 0 StudyDescriptio
n
(0010,0010) PN [*;3ED*] # 6, 1 PatientsName
(0010,0020) LO (no value available) # 0, 0 PatientID
(0010,0040) CS (no value available) # 0, 0 PatientsSex
(0020,000d) UI (no value available) # 0, 0 StudyInstanceUI
D
--------
C-Find RSP: MsgID: 1 [Status=Success]
AffectedSOPClassUID: =FINDPatientRootQueryRetrieveInformationModel
Data Set: Not Present
Releasing Association

It maybe just because the search condition "*;3ED*" is wrong.
Thanks