Re: SOP instance/object UID query

[Peter Somlo]

Hi Sébastien,

thank you for the added functionality and for helping me out with
navigating the Dicom terminology. Thanks to these, and the WADO
support of Dicom server, I was able to build a system where all the
network communication is based on HTTP and JSON communication. The
only part that remains based on Dicom are the images themselves.

I’ve been playing around and studying the source code before, so I’m
already using the mainline version. There was a small change I’ve had
to make to get the find-instance function working with my ClearCanvas
server. I was getting an error message:

"Unexpected Study Root Query/Retrive level:INSTANCE" someone had a
similar issue in [1]

Changing the following line in DicomUserConnection.cpp fixed the problem:
DU_putStringDOElement(dataset.get(), DcmTagKey(0x0008, 0x0052),
"INSTANCE");
to:
DU_putStringDOElement(dataset.get(), DcmTagKey(0x0008, 0x0052), "IMAGE");

Again, I’m not sure what is the correct way as per the Dicom standard.
I can test the function with an OsiriX server and a mini Pacs from
Toshiba, if that is any help.

Regards,

peter

[1] http://www.clearcanvas.ca/Home/Community/OldForums/tabid/526/aff/11/aft/14670/afv/topic/Default.aspx

On Mon, Aug 12, 2013 at 11:30 AM, Sébastien Jodogne <s.jo...@gmail.com> wrote:
> Hi Peter,
>
> Thanks for suggesting this interesting use of Orthanc to ease WADO querying!
>
> I have read the WADO specification (PS 3.18: Web Access to DICOM Persistent
> Objects (WADO)), as found at the following URL:
> http://medical.nema.org/Dicom/2011/11_18pu.pdf
>
> Quoting this document: "Unique identifier of the object - SOP Instance UID
> as defined in the PS 3.3. This parameter is REQUIRED. The parameter name
> shall be 'objectUID'." [page 12, 8.1.4] So, the "ObjectUID" identifier you
> refer to is actually the "SOPInstanceUID" tag (0x0008, 0x0018). This tag
> corresponds to the DICOM_TAG_SOP_INSTANCE_UID constant inside the Orthanc
> source code.
>
> Given this information, your question is answered in the following FAQ
> entry:
> https://code.google.com/p/orthanc/wiki/FAQ#Using_Orthanc_to_Ease_WADO_Querying
>
> Please however note that Orthanc 0.6.0 does not feature the "find-instance"
> API (it will be released with Orthanc 0.6.1). You will have to synchronize
> to the mainline version using Mercurial:
> https://code.google.com/p/orthanc/source/checkout
> http://orthanc.googlecode.com/hg/INSTALL
>
> HTH,
> Sébastien-
>
>
>
> On Monday, July 29, 2013 5:31:08 PM UTC+2, Peter Somlo wrote:
>>
>> Hi,
>>
>> thank you for your previous answer Sebastien. The updated FAQ helped a
>> lot in figuring out how to interact with the API. It provides all the
>> functionality I need except for one. I'm not really sure how it is
>> specified by the DICOM standard, so my question will be a bit
>> confused.
>>
>> I have a DICOM server, which I'm querying through Orthanc's
>> "modalities" API. After identifying the correct IDs of the study and
>> series, I would like to issue a WADO request - directly to the DICOM
>> server, bypassing Orthanc.
>>
>> To accomplish this, I need the following IDs for the request:
>> StudyUID
>> SeriesUID
>> ObjectUID
>>
>> The only ID causing some confusion is the last one. I've researched
>> some DICOM documentation and it might be the same as the SOP Instance
>> UID, but I'm not quite sure (well, it is the name of the DICOM file
>> stored in the filesystem).
>>
>> I've looked around the code and found some functions, which seemed
>> like they have something to do with the ObjectUID, namely:
>>
>> DicomUserConnection::FindInstance, where I supply both the
>> DICOM_TAG_STUDY_INSTANCE_UID and DICOM_TAG_SERIES_INSTANCE_UID
>>
>> in the DicomUserConnection::Find method and the FindRootModel_Instance
>> case the
>>
>> fields.HasTag(0x0008, 0x0018) evaluates to false, which is a bit odd
>> as compared to the other cases, as it seems to me that the DICOM
>> server has not been queried yet. However in the other cases
>> (FindRootModel_Series...) the value that the query should return is
>> already known.
>>
>> Can you please point me in the right direction? I'm a bit lost :)
>>
>> Best,
>>
>> peter

[Sébastien Jodogne]

Hi Peter,

Thanks for pointing this compatibility issue with ClearCanvas! I have just submitted a change that should solve your problem:

https://code.google.com/p/orthanc/source/detail?r=1b2cdc855bd3121a302fc34498f09e43b795da4e

Because according to the forum, this is a ClearCanvas-specific problem, I have decided to add a a fourth argument to "DicomModalities" inside the Orthanc configuration file. This parameter can be used to enable patches for specific PACS:

https://code.google.com/p/orthanc/source/browse/Resources/Configuration.json?spec=svn1b2cdc855bd3121a302fc34498f09e43b795da4e&r=1b2cdc855bd3121a302fc34498f09e43b795da4e#100

If this parameter is set to the string "ClearCanvas", Orthanc uses "IMAGE" instead of "INSTANCE" in DicomUserConnection:

https://code.google.com/p/orthanc/source/browse/OrthancServer/DicomProtocol/DicomUserConnection.cpp?spec=svn1b2cdc855bd3121a302fc34498f09e43b795da4e&r=1b2cdc855bd3121a302fc34498f09e43b795da4e#296

Please let me know if this indeed solves your problem! If this is the case, I will soon make the Orthanc 0.6.1 release.

Cheers,

Sébastien-

[Peter Somlo]

Hi,

I'm resurrecting this old thread, because I came across the same issue
again. This time with the Dcm4chee server (2.17.1) and Orthanc 0.7.2.

The Dicom modality from the config file:
["DCM4CHEEMOB" : ["DCM4CHEEMOB", "192.168.234.103", 11112],

curl http://192.168.50.115:8042/modalities/DCM4CHEEMOB/find-instance -X POST -d

'{"PatientID":"31xxxxx","StudyInstanceUID":"1.2.276.0.7230010.3.0.3.5.1.6558195.509789231","SeriesInstanceUID":"1.2.276.0.7230010.3.0.3.5.1.6558202.2080404011"}'
[]

after changing the config to:
["DCM4CHEEMOB" : ["DCM4CHEEMOB", "192.168.234.103", 11112, "ClearCanvas"],

curl http://192.168.50.115:8042/modalities/DCM4CHEEMOB/find-instance -X POST -d

'{"PatientID":"31xxxxx","StudyInstanceUID":"1.2.276.0.7230010.3.0.3.5.1.6558195.509789231","SeriesInstanceUID":"1.2.276.0.7230010.3.0.3.5.1.6558202.2080404011"}'
[
{
"AccessionNumber" : "DX005511",
"AcquisitionNumber" : "(null)",
"GenericGroupLength" : "16",
....

It works with the same "ClearCanvas fix". It might a more widespread
behavior, after all. It would be nice, if someone checked those
queries with dcm4chee or even some other servers.

Cheers,

peter

[Sébastien Jodogne]

Hi,

Thanks for reporting this. I am currently working on the release of Orthanc 0.7.3, that should improve the Q/R support. It should be available soon, and it might solve your problem.

Cheers,

Sébastien-

[Sébastien Jodogne]

Hello Peter,

It indeed seems that the "ClearCanvas patch" is also required for Dcm4Chee. I have therefore added a new manufacturer type for Dcm4Chee in the configuration file [1].

This will be part of the Orthanc 0.7.4 release. In the meantime, you can just use the "ClearCanvas" manufacturer type, or you can build the source code from the mainline.

Cheers,

Sébastien-

[1] https://code.google.com/p/orthanc/source/detail?r=b79eda29896da95d89d9050f9cc0eb97630c0181

On Thursday, February 13, 2014 4:27:34 PM UTC+1, Peter Somlo wrote:

[Robert van Ommen]

Just a headsup:

To get Query/Retrieve working from Orthanc with AGFA Impax 6.x i had to add the "SyngoVia" patch to get it working.

 

Regards,

Robert

[Sébastien Jodogne]

Dear Robert,

Thanks for your feedback! I have just added a new "AgfaImpax" modality manufacturer (that is currently only an alias for "SyngoVia" to make things clearer):

https://bitbucket.org/sjodogne/orthanc/commits/3dcf5c0734c9714acfc2ba06ce7328454261ac0c

Regards,

Sébastien-