VR of LO incorrectly encoded padding

Hi guys,

I am currently implementing DICOM server and sometimes testing it with CONQUEST.

My code is reporting that CONQUEST encodes padding incorrectly for value representation of LO (and perhaps some other string value representations)

According to DICOM standard LO value representation may be padded with leading and/or trailing spaces and CONQUEST uses NULL(0 ascii character)
NULL can be used for padding in UI value representation, not in LO. Moreover control characters like NULL are forbidden in LO.

Excerpt from PS 3.5 for LO encoding:
"character string that may be padded with
leading and/or trailing spaces. The character
code 5CH (the BACKSLASH “\” in ISO-IR 6)
shall not be present, as it is used as the
delimiter between values in multiple valued
data elements. The string shall not have
Control Characters except for ESC."

One good thing here is that this bug is usually non fatal. If other DICOM AE parses the value from LO into some numeric value, the NULL value is treated as the end of the string and value is correctly parsed.

If however, somebody would use the value directly as it was received the problem may arise.

Here is a scenario where the problem can occur:

Other server receives from CONQUEST value with VR of LO and uses it directly to query database. The padding is not ommitted since it is not the expected space character.

On other server side we end up with a query like:

SELECT ... FROM ... WHERE patient.id='some odd number padded with NULL'

Now, this *doesn't* match entity in a database with id from the query!!!

The version of CONQUEST I am using is 1.4.16.
The problem can be reproduced by using QUERY/MOVE and entering odd patient id.

Regards,

Bartosz Meglicki

National Centre for Nuclear Research
Department of Nuclear Equipment
ul. Andrzeja Sołtana 7
05-400 Otwock, Poland

Hi Marcel,

You are correct. It is Query/Move tab page of GUI, (Windows 1.4.16 version)

The exact steps to reproduce the problem would be:

1. Start CONQUEST
2. In GUI switch to Query/Move tab page
3. Enter odd length number into Patient ID, for example '111'
4. Click on 'Query selected DICOM system'

Expected output: Patient ID in a data set encoded as '111 ' (111 followed by space character)
CONQUEST output: Patient ID in a data set encoded as '111\0' (111 followed by ascii NULL character)

Rationale: DICOM PS 3.5, table 6.2-1, table row with LO encoding rules:

Possible consequences: CONQUEST GUI, Query/Move tab page will not find Patient, despite supplying correct Patient ID

Example: the queried server passes Patient ID '111\0' received from ConQuest directly to database using ODBC and specifying the length of the string as 4 and not as null terminated string. If exact matching is used '111\0' doesn't match '111'.

Regards,

B.M.

Hi Marcel,

I believe almost any reasonable PACS implementation will handle it correctly. Nontheless the provided example is DICOM conformant and would give unexpected results.

Very strict DICOM implementation might complain about control characters forbidden for value representation of LO (apart from ESC).

I only got this issue using some early test code of our server that behaved as in example (handled padding as in PS 3.5 and passed the result to database query).

btw. as odd numbers supplied into Patient ID I meant odd length naturally.

B.M.