I appreciate that there’s nothing really in DICOM that allows you to 100% guarantee that a study has finally made it from one node to another. 99/100 most solutions use a timeout and I believe that Orthanc is no exception to this (I believe the default config setting of “StableAge” : 60 denotes this). However, I do wonder if perhaps Orthanc can go above and beyond others with it’s functionality in this regard and potentially include an API call that can be made to made a study “stable”?
For example, I receive a 3 instance study from a DICOM node. I have processing put into place and I know that I have to add another series to this particular study in the form of a local DICOM file I’ve created: I ensure that the StudyInstanceUID is the same as the study I want to add it to (the SeriesInstanceUID and InstanceUID are unique). I then use DCMTK to send the created local file to Orthanc. However, now I have to wait at least 60 sec for Orthanc to register that there’s a new series (I check with Postman and a looping script, sometimes it takes 90 sec for the additional series to be added to the study).
Wouldn’t it be a lovely feature to be able to call an endpoint and have the study be flagged as stable immediately? Unless of course something like this already exists and I can’t see it in the API calls?
You are most probably looking for the so-called “DICOM storage commitment” feature (a search on Internet will provide you with more information). We plan to implement storage commitment in a near future.
Thanks to storage commitment, your sending modality is sure that your receiving modality has received all the images. The source modality can then inform the receiving modality that further processing can be launched.
There’s indeed no such endpoint right now. That’s actually the first time we get this kind of request so I would assume that it’s quite specific to your particular use case.
There are some plans to implement DICOM storage commitment in Q1 2020 that might help you achieve what you need. From an API point of view, we’ve no idea yet how it will be implemented.
In the meantime, if you’re already working with lua callbacks, instead of working with OnStableStudy, you could work with OnStoredInstance that is triggered earlier. In this callback, you could detect that the instance is the “special one you push at the end of the study”
Sebastien,
I’ve read up on the accelerator plugin, and appreciate that it enables “chunking” (for large DICOM sets) as well as collating smaller sets. However, this differs in what the approach I’m looking for is.
Now, one thing that I need to ensure I’m correct in, is as follows:
I’m currently using DCMTK’s storescu to send the additional series to Orthanc, and that’s certainly subject to the StableAge setting.
If I were to use the API to send the additional series, does the StableAge timeout still apply? I can only assume that it does?
If so, and being familiar to Storage Commit permit me to confirm that yes, that’s pretty much what I’d be looking for, but from an API point of view, as opposed to a DICOM one.
From an API point of view I got to thinking that, after sending an instance (containing my new series, but attached to an existing stored study):
$ curl -X POST http://localhost:8042/instances --data-binary @CT.X.1.2.276.0.7230010.dcm
I could then call the “storage commit” API for that study, something like
$ curl -X GET http://localhost:8042/study/9ad2b0da-a406c43c-6e0df76d-1204b86f-78d12c15/commit
Which would bypass the StableAge setting and set all internal paths, databases et al to IsStable:1
Indeed for the storage commit, we’ll have to somehow force the “stability” of the study when Orthanc receives the DICOM storage commit message. It makes a lot of sense to add a route to “commit” through HTTP as well as part of this implementation.
Alain / Sebastien
I’ll look forward to testing the new functionality next year.
Additionally, I would’ve loved to have attended OrthancCon this year but couldn’t make it work. I’m hoping to attend next year and (if all goes according to plan) will even put myself up for a presentation as to how we plan on using Orthanc in 2020 here in the US. I’ve been using DCM4CHEE for the last 10 years but Orthanc has a much better featureset and I love the way the API works. Congratulations to all, it’s really something.
I love the idea of being able to send a commit signal over REST. It would be especially useful for me while debugging. Even if I make the StableAge timeout fairly low, I still spend a lot of time sitting around just waiting for StableStudy to pop up in /changes when I am testing things.
What was the final result for this thread? I know that storage commitment support was added, but I still don’t see a clear way for a StableStudy event to be generated immediately upon storage commitment confirmation. Is that possible?
It would be great if a successful storage commitment response also caused the study to be moved to stable status and the underlying series moved to completed status, immediately.
Still no progress on this topic (I must admit it went out of our minds).
I have just added it in our TODO with a reference to this topic to notify you once it is implemented.