Query on DICOM tags: "RETIRED_OtherPatientIDs" vs. OtherPatientIDs. More of an observation.

[Stephen Douglas Scotti]

I might be interested in modifying either RETIRED_OtherPatientIDs or OtherPatientIDs, if they don't already have a value.

They can be modified by: (-nb is for no backup, not recommended) using DCMTK.  Not sure that you can do that via the REST API.  Thre is a field for RETIRED_OtherPatientIDs, and a sequence for
OtherPatientIDsSequence.  I tried that using DCMTK.

dcmodify  -nb -i "(0010,1002)[0].(0010,0020)=Test ID" "/Users/sscotti/Downloads/teststudies/MR-MONO2-12-shoulder"  OtherPatientIDsSequence/PatientID

dcmodify  -nb -i "(0010,1002)[0].(0010,0021)=Some Place" "/Users/sscotti/Downloads/teststudies/MR-MONO2-12-shoulder" OtherPatientIDsSequence/IssuerOfPatientID

dcmodify  -nb -i "(0010,1002)[0].(0010,0022)=Internal MRN for Outside Study" "/Users/sscotti/Downloads/teststudies/MR-MONO2-12-shoulder" OtherPatientIDsSequence/TypeOfPatientID

dcmodify  -nb -i "(0010,1000)=Test" "/Users/sscotti/Downloads/teststudies/MR-MONO2-12-shoulder" RETIRED_OtherPatientIDs

I then uploaded the modified study to Orthanc, and the Explorer displays the OtherPatientIDs as Test.

However, if I then query for Studies with that value for OtherPatientIDs, I get what is below.  It throws an error.

ERROR:

host-168-236:~ sscotti$ curl --request POST --url http://localhost:8042/tools/find \
>   --data '{
>             "Level" : "Study",
>             "Query" : {
>               "OtherPatientIDs" : "Test"
>             }
>           }'
{
    "HttpError" : "Internal Server Error",
    "HttpStatus" : 500,
    "Message" : "Unknown DICOM tag",
    "Method" : "POST",
    "OrthancError" : "Unknown DICOM tag",
    "OrthancStatus" : 27,
    "Uri" : "/tools/find"
}

If I query again using RETIRED_OtherPatientIDs, I get a result.  Just wondering if that is the expected behavior, or if it depends on the DICOM study or DICOM version somehow ?  The Retired Tag would be fine if that is supported by Orthanc but is it possible to use the other ones also so that you can perform a query on them ?  Is there some sort of .dot notation to traverse down the tree ?


RESULT:

host-168-236:~ sscotti$ curl --request POST --url http://localhost:8042/tools/find \
>   --data '{
>             "Level" : "Study",
>             "Query" : {
>               "RETIRED_OtherPatientIDs" : "Test"
>             }
>           }'
[ "660e7608-23e3eecb-da0a810a-c4e4619f-eb394b26" ]

The Header from the image is:

# Dicom-Meta-Information-Header
# Used TransferSyntax: Little Endian Explicit
(0002,0000) UL 184                                      #   4, 1 FileMetaInformationGroupLength
(0002,0001) OB 00\01                                    #   2, 1 FileMetaInformationVersion
(0002,0002) UI =MRImageStorage                          #  26, 1 MediaStorageSOPClassUID
(0002,0003) UI [1.3.46.670589.11.0.4.1996021610440011]  #  38, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =JPEGLossless:Non-hierarchical:Process14 #  22, 1 TransferSyntaxUID
(0002,0012) UI [1.2.276.0.7230010.3.0.3.6.5]            #  28, 1 ImplementationClassUID
(0002,0013) SH [OFFIS_DCMTK_365]                        #  16, 1 ImplementationVersionName

and the dump:

. . . .

(0010,0010) PN [Anonymized]                             #  10, 1 PatientName
(0010,0020) LO [DEV0000002]                             #  10, 1 PatientID
(0010,1000) LO [Test]                                   #   4, 1 RETIRED_OtherPatientIDs
(0010,1002) SQ (Sequence with explicit length #=1)      #  90, 1 OtherPatientIDsSequence
  (fffe,e000) na (Item with explicit length #=3)          #  82, 1 Item
    (0010,0020) LO [Test ID]                                #   8, 1 PatientID
    (0010,0021) LO [Some Place]                    #  20, 1 IssuerOfPatientID
    (0010,0022) CS [Internal MRN for Outside Study]         #  30, 1 TypeOfPatientID
  (fffe,e00d) na (ItemDelimitationItem for re-encoding)   #   0, 0 ItemDelimitationItem

. . . .

There is some mention of those tags here also:  orthanc-tests (# Tags for compatibility with DCMTK 3.6.0)

The tag definitions are like this.  Just wondering why that works when using the retired tag name for the Query, but it displays in the Explorer as OtherPatientIDs.

Thanks.

/sds

[Michel Rozpendowski]

Hi,

What version of Orthanc are you running?

With Orthanc 1.5.8, I can see RETIRED_OtherPatientIDs in the explorer:

Kind regards,

Michel

[Stephen Douglas Scotti]

Orthanc version: 1.6.1  on that server.  I will probably upgrade it to 1.7.x shortly though.

[Sébastien Jodogne]

The DICOM dictionaries that are internally used by DCMTK follow the evolution of the DICOM standard.

Some tags are progressively marked as RETIRED. In the case of the "OtherPatientIDs" (0010,1000) tag, it was renamed to "RETIRED_OtherPatientIDs" in DCMTK 3.6.2. This explains the following behavior, that reflects the fact that DCMTK 3.6.5 is installed on our demo server:

$ curl -v https://demo.orthanc-server.com/tools/find -d '{"Level":"Study","Query":{"OtherPatientIDs":"Test"}}'

  => error, with message "Unknown DICOM tag"

$ curl -v https://demo.orthanc-server.com/tools/find -d '{"Level":"Study","Query":{"RETIRED_OtherPatientIDs":"Test"}}'

  => success

In general, it is preferable to query using the hexadecimal identifier of the tag in order to be robust against any version of DCMTK, for instance:

$ curl -v https://demo.orthanc-server.com/tools/find -d '{"Level":"Study","Query":{"0010,1000":"Test"}}'

  => success, whatever the version of DCMTK

Also, please note that as of Orthanc 1.7.1, the C-FIND SCP server cannot be used to filter on sequence tags (but does return sequences), except if doing C-FIND on worklists.

HTH