Monitoring Storage Commitment via REST

I’ve looked over the Orthanc documentation relating to handling of Storage Commitment.

Following the guide, I have manually induced a storage commitment interaction, which put the following in the Orthanc job list:

{
“CompletionTime”: “20200722T113107.599535”,
“Content”: {
“CalledAet”: “orthanc”,
“Description”: “”,
“RemoteAet”: “STGCMTSCU”,
“TransactionUid”: “2.25.286583286889332674752959003098305921875”
},
“CreationTime”: “20200722T113107.590424”,
“EffectiveRuntime”: 0.009,
“ErrorCode”: 0,
“ErrorDescription”: “Success”,
“ID”: “b9a92b1c-5ec6-4102-aaf1-39a8554ffbf8”,
“Priority”: 0,
“Progress”: 100,
“State”: “Success”,
“Timestamp”: “20200722T113109.544145”,
“Type”: “StorageCommitmentScp”
}

Is it possible to associate this with a study (or list of instances) in Orthanc? I can see a transaction UID, but I’m not aware of how to use this value to complete the link. Ideally I could do so, and avoid needing to use StableAge to infer when a study is fully transferred.

If it’s not possible via the REST interface, my fallback option will be writing a python plugin to hook into the SC call - though I’d prefer to use the REST interface if possible.

Thanks.

Nick.

Hello,

Making a GET call to “/storage-commitment/{transaction}”, then “/tools/lookup” is probably what you are looking for.

Here is a real-world example using the sample environment of the Orthanc Book:
https://book.orthanc-server.com/users/storage-commitment.html#testing-against-dcm4che

$ curl http://localhost:8042/modalities/scp/storage-commitment -X POST -d ‘{“DicomInstances”: [ { “SOPClassUID” : “1.2.840.10008.5.1.4.1.1.4”, “SOPInstanceUID” : “1.2.840.113619.2.176.2025.1499492.7040.1171286242.109” } ]}’
{
“ID” : “2.25.63198202986384715913886627966944867262”,
“Path” : “/storage-commitment/2.25.63198202986384715913886627966944867262”
}
$ curl http://localhost:8042/storage-commitment/**2.25.63198202986384715913886627966944867262**
{
“Failures” : [],
“RemoteAET” : “DCMQRSCP”,
“Status” : “Success”,
“Success” : [
{
“SOPClassUID” : “1.2.840.10008.5.1.4.1.1.4”,
“SOPInstanceUID” : “1.2.840.113619.2.176.2025.1499492.7040.1171286242.109”
}
]
}

As can be seen, once the “Status” is “Success”, the “Success” field provides the SOPInstanceUID that have been queried by this job (if there are failures, they are reported in the “Failures” field). Once you have the SOPInstanceUID, you could use the “/tools/lookup” route to find back the Orthanc identifier of the instance:

$ curl http://localhost:8042/tools/lookup -d ‘1.2.840.113619.2.176.2025.1499492.7040.1171286242.109’
[
{
“ID” : “66a662ce-7430e543-bad44d47-0dc5a943-ec7a538d”,
“Path” : “/instances/66a662ce-7430e543-bad44d47-0dc5a943-ec7a538d”,
“Type” : “Instance”
}
]

Note that the “/tools/find” route could also be used:

$ curl http://localhost:8042/tools/find -d ‘{“Level”:“Instance”,“Query”:{“SOPInstanceUID”:“1.2.840.113619.2.176.2025.1499492.7040.1171286242.109”},“Expand”:true}’

Finally, note that all these interactions could be scripted by implementing one custom REST route in a Python plugin, so as to avoid multiple calls to the REST API:
https://book.orthanc-server.com/plugins/python.html

HTH,

Sébastien-

PS: For the sake of completeness, the Orthanc identifiers are documented in the Orthanc Book:
https://book.orthanc-server.com/faq/orthanc-ids.html