determine length of study?

I’d like to determine the length of a study, where I [arbitrarily] define that as the time difference between the earliest and latest InstanceCreationTime.

I could do that by grabbing studies/my-study-id, iterating over Series, grabbing series/my-series-id, iterating over instances, grabbing instances/my-instance-id, and doing the math to determine first and last InstanceCreationTime.

My question is: are there any guarantees I can make use of to avoid this? For instance, in the response to “studies”, are Series guaranteed to be in time order, in which case I could get just the first and last? Similarly are Instances guaranteed to be in time order?

Thanks!

Daniel

Hello,

You could use the “/tools/bulk-content” URI to this end:
https://api.orthanc-server.com/#tag/System/paths/~1tools~1bulk-content/post

For instance:

$ curl http://localhost:8042/tools/bulk-content -d ‘{“Resources”:[“27f7126f-4f66fb14-03f4081b-f9341db2-53925988”],“Level”:“Instance”}’

Sébastien-

That’s much, much slower than grabbing the first and last. In my limited experimentation, grabbing the first and last does work. Am I setting myself up to get wrong answers at some point in the future though?

You could technically query the databat, given knowledge of its structure is available,l. Just be mindful that you may first retrieve all series for the study.

Other option would be to poll the changes API. If I’m not mistaken it is sequential in nature. So the idea here is you call this, then look for the first item from your study, then the last. Then you pull only those two instant and do the math. But this depends on the spec of the changes API.

You cannot make any assumption about the order of the instances within a study.

For instance, if “OverwriteInstances” is set to “true”, if you delete then reimport the same resources, or if the remote modality sends data in other orders, the instances will not be sorted by InstanceCreationTime. Simply running a VACUUM on the underlying SQL database could also change their order.

You could easily improve the speed by setting the “Level” option to “Series” in the “/tools/bulk-content”. This would allow you to sort the series in a reliable way by using the “SeriesDate” and “SeriesTime” DICOM tags.

Sébastien-

Ok, thank you!

PS: I forgot to add a sentence to my previous message: Once the series are sorted, you can then call “/tools/bulk-content” with “Level” set to “Instance” on the first and last series, if you really need the “InstanceCreationTime”.

All this logic could be implemented server-side by a Python plugin in order to avoid making several calls to the REST API:
https://book.orthanc-server.com/plugins/python.html#extending-the-rest-api

Hi Daniel,

I am curious to know why you want to determine the length of a study? How DICOM objects are created (which is when InstanceCreationTime is determined) is highly dependent on the DICOM implementation of the equipment - they could be converted to DICOM from raw data in one go. There is also Acquisition DateTime and Content Time which might be more meaningful depending on your goal - see http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.19.html

Regards
Walco

Simply that researchers sometimes say they get billed for longer than they thought they used, and want an independent (from the MR techs) reminder of how long their scan was.

Hi Daniel,

So probably you are better served with Acquisition DateTime.

Regards
Walco