Hello,

I wonder what the reasoning is behind the Value Representation of Integer String. Why for example is Series Number not a VR of Signed Long?
And does it matter if I do a series query with SeriesNumber "4" or "+4"?

Best regards,
Kai

Hi Kai

Historical - the original ACR-NEMA 1985 standard defined Series (0010,2011) as alpha (AN FF S) not binary (and did so for pretty much every element that was not directly pixel data related) - see "https://dicom.nema.org/medical/dicom/1985/ACR-NEMA_300-1985.pdf".

I don't think there are any provisions in the definition of query attribute matching that specifically address equivalence of numeric value representations (unlike dates and times). So whether literal string matching is to be expected, as opposed to matching equivalent numeric values of numeric string VR attributes, seems to be undefined. In the absence of any normative or informative text about this, interpretation of the PS3.5 VR in the context of the query is not forbidden and it could argued is expected. But in practice, I would not expect "+4" and "004" to always match "4". It probably depends on the implementation decision of whether the database behind the query maps numeric string DICOM VRs like IS to INTEGER or VARCHAR (in the case of a conventional SQL database). Nor is there any requirement for a C-FIND SCP to document this in the Conformance Statement (there probably should be).

David

On Tuesday, March 28, 2023 at 5:49:45 AM UTC-4, kai.s...@gmail.com wrote:
> Hello,
>
> I wonder what the reasoning is behind the Value Representation of Integer String. Why for example is Series Number not a VR of Signed Long?
> And does it matter if I do a series query with SeriesNumber "4" or "+4"?
>
> Best regards,
> Kai

Hi David,

> I don't think there are any provisions in the definition of query attribute matching that specifically address equivalence of numeric value representations (unlike dates and times). So whether literal string matching is to be expected, as opposed to matching equivalent numeric values of numeric string VR attributes, seems to be undefined. In the absence of any normative or informative text about this, interpretation of the PS3.5 VR in the context of the query is not forbidden and it could argued is expected. But in practice, I would not expect "+4" and "004" to always match "4". It probably depends on the implementation decision of whether the database behind the query maps numeric string DICOM VRs like IS to INTEGER or VARCHAR (in the case of a conventional SQL database). Nor is there any requirement for a C-FIND SCP to document this in the Conformance Statement (there probably should be).

I checked the definition of Single Value Matching in PS3.4 Section C.2.2.2.1. It says: "Except for Attributes with a PN VR, only entities with values that match exactly the​ value specified in the request shall match. This matching is case-sensitive, i.e., sensitive to the exact encoding of the key Attribute​ Value in character sets where a letter may have multiple encodings (e.g., based on its case, its position in a word, or whether it is​ accented).​" By the way, it should read "Key Attribute" instead of "key Attribute".

Of course, the question remains what the "value" of an IS data element is: Is it the character string or the integer number it represents. PS3.5 defines the VR "Integer String" (IS) as "A string of characters representing an Integer in base-10​ (decimal)..."

Maybe, an explaining note should be added to PS3.4 that Single Value Matching of Key Attributes with a VR of IS or DS is implementation dependent. Other types of matching are probably not relevant in this context.

Regards,
Jörg

On Tuesday, March 28, 2023 at 7:10:39 PM UTC+2, Jörg Riesmeier wrote:
> Hi David,
> > I don't think there are any provisions in the definition of query attribute matching that specifically address equivalence of numeric value representations (unlike dates and times). So whether literal string matching is to be expected, as opposed to matching equivalent numeric values of numeric string VR attributes, seems to be undefined. In the absence of any normative or informative text about this, interpretation of the PS3.5 VR in the context of the query is not forbidden and it could argued is expected. But in practice, I would not expect "+4" and "004" to always match "4". It probably depends on the implementation decision of whether the database behind the query maps numeric string DICOM VRs like IS to INTEGER or VARCHAR (in the case of a conventional SQL database). Nor is there any requirement for a C-FIND SCP to document this in the Conformance Statement (there probably should be).
> I checked the definition of Single Value Matching in PS3.4 Section C.2.2.2.1. It says: "Except for Attributes with a PN VR, only entities with values that match exactly the​ value specified in the request shall match. This matching is case-sensitive, i.e., sensitive to the exact encoding of the key Attribute​ Value in character sets where a letter may have multiple encodings (e.g., based on its case, its position in a word, or whether it is​ accented).​" By the way, it should read "Key Attribute" instead of "key Attribute".
>
> Of course, the question remains what the "value" of an IS data element is: Is it the character string or the integer number it represents. PS3.5 defines the VR "Integer String" (IS) as "A string of characters representing an Integer in base-10​ (decimal)..."
>
> Maybe, an explaining note should be added to PS3.4 that Single Value Matching of Key Attributes with a VR of IS or DS is implementation dependent. Other types of matching are probably not relevant in this context.

Agreed. That would make it obvious why there are no Range Matching for IS/DS then.

Thanks a lot for your very good explanations. I think in my use case (a system that communicates with multiple different PACS servers), it is better to filter the series number programmatically then.

By the way, I've written a CP on this issue and submitted it to WG-06 for consideration at the next meeting.

Regards,
Jörg