I am a bit new to Orthanc and currently evaluating it for the following use case:
I would like to have Orthanc receive DICOM studies from a modality and instead of say, doing a regular DICOM routing, I’d like to package the study into a tarball and upload it in one shot to an https REST backend.
I am not really sure what the best way to do this would be or if this can even be done easily within Orthanc.
Can I do this with a Lua script?
My apologies I am quite new to both Orthanc and Lua, and I am trying to evaluate if it fits into my use case before really digging in and giving it a go.
Thanks in advance,
Yeppers, you can. Check out the Orthanc REST API, search for ZIP. Allows you to make an archive based on a study. So you would in the Lua script initiate an archiving based on function OnStableStudy.
Thanks for the reply!
Please allow me a follow-up question.
Say I want to do the reverse - instead of pushing something to another backend based on an Orthanc event, I want to poll a remote backend (arbitrary REST API) in a Lua script say every 30 seconds (purpose being to download new series from elsewhere as they come in)…
I presume I could just have a Lua script w/ a for loop and a sleep timer that does this periodic polling, right? But looking at the source code I am not sure if this can be achieved in a non-blocking fashion … does anyone know if this can be achieved in a truly non-blocking manner?
If the answer is no, it cannot be done would I need to dive into the core c++ code and add another thread that does this polling in the server’s “main”, compile and thus resort to using my own custom binary, etc? Or would I be able to achieve it via a Plugin? I am assuming a Plugin could spawn it’s own thread and do this polling as required without interfering with the other parts of Orthanc? Yes?
Thanks very much in advance.
Small world. You helped the company I work for in our old DCM4Chee implementation last year!
Back to your question…
You can query the REST API for changes, you would just need to remember the last changes queried and only query since then. Another option if you can communicate bidirectional is from Orthanc when a study is complete send a message via HTTP Get/Post to your backend server notifying it of a new study with the study information, then have the backend server retrieve that zipped study. This, off the top of my head would be pretty simple using Orthanc and some sort of Engine on the backend. (I use Mirth and have done things much like this before).
Actually, I may have read your question wrong. If you are looking for Orthanc to perform a query on a scheduled instance, I do not believe there is currently that option without some sort of kick-start. Maybe with building a timed script via function Initialize() but I haven’t looked into it too much. It could easily be done with, as I mentioned above, using something like Mirth or a scheduler on the Orthanc server to push Orthanc to perform that sort of action.
Thanks Bryan, I will look into these options and see if I can get something along these lines working.
I presume I could just have a Lua script w/ a for loop and a sleep
timer that does this periodic polling, right? But looking at the
source code I am not sure if this can be achieved in a *non-blocking*
fashion ... does anyone know if this can be achieved in a truly non-
AFAIK this cannot be done (i.e. there is no threading or asynchronous
API available to Orthanc Lua scripts).
If the answer is no, it cannot be done would I need to dive into the
core c++ code and add another thread that does this polling in the
server's "main", compile and thus resort to using my own custom
binary, etc? Or would I be able to achieve it via a Plugin? I am
assuming a Plugin could spawn it's own thread and do this polling as
required without interfering with the other parts of Orthanc? Yes?
You're right, a plugin would have total freedom in this regard.
What we usually do in practice for such scenarios is to set up a small
microservice on the side that polls the /changes Orthanc resource. If
the events you're looking for are indeed exposed as changes, this
service only needs to remember the last change ID and you'll be good to
go. Whenever new events come up, you can trigger the desired operations
(targeting the Orthanc API again from that same service).
This is usually a more straightforward alternative, especially if
you're already using a microservices-friendly infrastructure (e.g.
container engines). Otherwise, a plugin remains your best bet.
For my use case I want to preserve as much as possible the ‘one-click-install’ greatness of Orthanc as much as possible.
From this perspective it seems like a plugin might be a better bet than the microservice via container engine solution, however I will consider both possibilities.