Auto-Routing of DICOM Images

[marr...@gmail.com]

Hi, I wrote a LUA script for a multi-modality auto-routing. When my Orthanc instance receives a study it auto-forwards received study to four different remote AE (workstation) In the script, I wrote these simple four line:

SendToModality(instanceId, 'WS1')
SendToModality(instanceId, 'WS2')
SendToModality(instanceId, 'WS3')
SendToModality(instanceId, 'WS4')

Everything work fine if each remote AE is powered on. If one or more AE is powered off Orthanc isn't able to forward to relevant AE (this is obviously) and it (this is the trouble) stops the auto-routing process.
For instance, if WS2 is powered off but WS3 and WS4 are powered on, Orthanc fails to send to WS2 and doesn't send to WS3 and WS4. I haven't been able to figure out how to adapt it. Any help would be appreciated!

[Sébastien Jodogne]

Hi,

Thanks for the feedback!

Please could you try and run the attached patch?

TIA,

Sébastien-

[marr...@gmail.com]

Thank you for your prompt reply!
I have to setup the environment to apply the patch and rebuild Orthanc.
I'll update you as soon as I have more information available.
Michele

[Michele Arrivato]

Hi Sébastien,

I applied the patch and everything goes ok! Thank you.

I've an other question about Orthanc: can it listen on two or more different TCP port number? For example, I have to configure two DICOM node (same AE-Title, same hostname but different port number) on the same AE to implement different behaviour (e.g, first port correspond to a standard behaviour while second one is a forwarder).

I hope I explained myself clearly.

Thanks in advance

Michele

[Sébastien Jodogne]

Fine! :)

Since Orthanc is lightweight and standalone, you can very easily deploy several instances of Orthanc on the same computer. This is the standard way of listening on several TCP ports with Orthanc. Nothing prevents you from using the same AET on these multiple instances of Orthanc, provided they listen on separate TCP ports.

In your case, you could for example setup 1 "automation" instance of Orthanc to act as the receiver/forwarder (possibly with its HTTP server disabled), and 1 "public" instance of Orthanc to serve the images. Whenever the automation instance receives an image, it duplicates it to the public Orthanc (e.g. through Lua forwarding). 

HTH,

Sébastien-

[Sébastien Jodogne]

FYI, Orthanc 0.8.2 has just been released, with the patch included.

[Sergio Azevedo]

Hi Sébastien,

The patch you provide, protects the code with a try catch instruction. But, how can i proceed, in the case i want to retry the file rerouting?

Best regards,

[Sébastien Jodogne]

Hi,

To implement a more complex logic such as this one, you will have to drive Orthanc from an external script (e.g. Python) using the REST API.

HTH,

Sébastien-

[Sergio Azevedo]

Thanks Sébastien. I'll do that.

Cheers.

[Sergio Azevedo]

Hi Sébastien, 

I followed your advice, and start a implementation of auto-routing with Ruby script. 

The main idea was to use the former lua script, mentioned by you, to call a system instruction (my ruby script), to enqueue the instanceID.

After that, another script (a consumer), it would read this queue and fires a POST request to "http://localhost:8042/modalities/mymodality/store".

But during this process, I realized two things.

1 - Empty response (no response) for POST request

  When I do a POST request against the resource "modalities/mymodality/store", the result is "no response". Even when you use curl instruction, it returns code 52.

2 - I still have lack of assurance about the DICOM transfer success.

  Supose that the POST request mentioned above, returns a 200 status code to me. What it means? For me, (after reading the source code of Orthanc), the meaning is: "Ok man, I  scheduled a transfer Dicom operation for you with success"

  And that is the big issue. Because if the sender or the receiver looses your internet connection that operation can fail, without I have noticed.

In my opnion, one possible solution for this issue is automatically reschedule the failured job .

I looked the OrthancRestApi source code. But my inexpressive C++ skills limited me just to read the code. 

So I would to know if you think that is possbile to do this in ServerScheduler::SignalFailure. 

Or maybe add a RetryJob method to ServerScheduler, in order to use them from the ServerCommandInstance::Execute.

Best regards,

[Sébastien Jodogne]

Hi Sergio,

Sorry for the delay.

You should not call your Ruby script from the embedded Lua engine of Orthanc. As the Lua engine is at the core of Orthanc, you face many constraints that stem from the fact that the DICOM is not fully registered by the Orthanc database at the time your script is called.

Instead, you should implement a separate Ruby script with a polling loop that continuously monitors the "/changes" URI of the REST API to be informed of the arrival of new DICOM instances. This script must not be called from Lua, but must be launched as a separate process. The standard distribution of Orthanc contains a folder with several Python scripts that demonstrate this API (sorry, no Ruby here, but you can contribute by submitting your scripts to the GitHub "OrthancContributed" repository):

http://goo.gl/esHlQW (notably "ChangeLoops.py")

If you use the REST API from the external, you will not encounter your problems anymore.

HTH,

Sébastien-