wlmscpfs not sending SpecificCharacterSet

[anibal]

Hi,

we have just tried using wlmscpfs (dcmtk 3.5.3) with a CT GE ConnectPRO.

They're sending the following in the query:

Code: Select all

# Dicom-Data-Set
# Used TransferSyntax: LittleEndianImplicit
(0008,0000) UL 108                                      #   4, 1 IdentifyingGroupLength
(0008,0005) CS [ISO_IR 100  ]                           #  12, 1 SpecificCharacterSet
(0008,0050) SH (no value available)                     #   0, 0 AccessionNumber

...

The result set that wlmscpfs sends back does not contain the SpecificCharacterSet (0008,0005) and the scanner complains with a message and does not show anything. The message says that the result does not contain the 0008,0005 tag.

I know we can use the -cs1 option to always send the character set, but my question is why do I have to specify this if the scanner is sending it in its query? You see, the problem is that I have many scanners talking to wlmscpfs, a change like this to the running copy of wlmscpfs could trigger another problem in another scanner. So, I'd rather not have to do this at all.

For now, we're running a second copy of wlmscpfs on another port with the -cs1 option so that we can keep working, but I would like to get a fix (if possible) to the fact that wlmscpfs is not answering back with the query sent by the scanner.

Thanks.

[Marco Eichelberg]

The DICOM standard should really add a "howto" section explaining the correct handling of extended character sets
The attribute SpecificCharacterSet (0008,0005), when sent as part of a query or a response message, is not treated like the rest of the query strings. The attribute, when contained in a query, explains how all other attributes in the dataset have to be interpreted (i. e. the character set in which they are encoded). Similarly, the attribute, when contained in a C-FIND response, only explains how this particular C-FIND response has to be interpreted.
This means that the attribute may be present in the query but absent in the response (if the response does not contain any non-ASCII characters), it may be absent in the query but present in the response (if the response contains extended characters but the query does not), and the content of the attribute may change from dataset to dataset, i. e. the query may contain a different character set than the response, and different responses may contain different character sets. Unfortunately, support for character sets is not negotiated during association negotiation but only documented in the conformance statement, so the application just has to cope with whatever it receives.
In my interpretation of the standard the behaviour of wlmscpfs is absolutely correct and conformant, and the behaviour of the Worklist SCU you describe is not. Since there are a number of applications that choke on character set issues, we have the -cs1 option which allows the Worklist SCP to communicate with these nonconformant clients, but this behaviour is off by default.