Hello,
Browsing through older discussions, it seems like scripts will need to be developed to achieve this custom process.
But I wanted to confirm, just in case I missed documentation and/or discussion.
Question
In short, at this time, can you configure Orthanc to automatically archive images?
For example, based on age and/or whether the disk is getting full?
Thanks!
Srey Seng
Hello,
The Orthanc core basically acts as a VNA (DICOM server), i.e. it can receive/store/browse/transmit DICOM files through the DICOM network protocol.
The needs you have clearly go beyond these core features. You’ll have to resort either to scripting in Lua, exploiting the REST API, or developing a C/C++ plugin.
In your case, I would suggest you to take the following sample Python script that uses the REST API as a starting point:
https://bitbucket.org/sjodogne/orthanc/src/default/Resources/Samples/Python/ArchiveStudiesInTimeRange.py
As you’ll see, don’t panic, using the REST API is quite simple. Other samples are available as well:
https://bitbucket.org/sjodogne/orthanc/src/default/Resources/Samples/Python/
HTH,
Sébastien-
As always, thanks for confirming & providing link to specific script examples!
In looking at the scripts, one of the things that appear “missing” is the verification step.
How can one verify that indeed, the dicom instance that is downloaded to disk for safekeeping is “good” before deleting the original**?
Any insights much appreciated!
**I am working on understanding an older discussion “Check MD5”. Is this applicable to current version of Orthanc?
Thanks!
Srey
How can one verify that indeed, the dicom instance that is downloaded to disk for safekeeping is “good” before deleting the original**?
**I am working on understanding an older discussion “Check MD5”. Is this applicable to current version of Orthanc?
You can get the expected MD5 hash of any DICOM instance by issuing:
This MD5 corresponds to the hash of the DICOM file in memory, before it was written to the disk by Orthanc. This information is safely stored inside the database for any incoming DICOM file (provided that the “StoreMD5ForAttachments” configuration option is set to “true”). It is of course available in the current version 1.1.0 of Orthanc.
As a consequence, you can simply check the MD5 hash of what your archive script writes to the disk.
To verify my understanding, given two Orthanc installations, SourceA and TargetB, when I (1) send an instance from SourceA to TargetB, I should expect to get the (2) same MD5 hash when calling the api.
Getting (3) the same MD5 hash from the server SourceA and server SourceB means that indeed the DICOM instance have been transferred correctly.
Orthanc Installation:
SourceA
TargetB
(1) Send instance from SourceA to TargetB
Api: {SourceA}/modalities/TargetB/store (w/ instance identifier in body)
(2) Retrieve MD5 hash
Source A instance MD5 hash: {SourceA}/instances/{instance_identifier}/attachments/dicom/md5
Target B instance MD5 hash: {TargetB}/instances/{instance_identifier}/attachments/dicom/md5
(3) Compare MD5 hash
If Source A instance MD5 hash = Target B instance MD5 hash, then we are good!
Question
From the scenario above, do all Orthanc docker installations (current & prior versions) calculate the MD5 hash the same way? That is to say, it is unaffected by differences in Orthanc versions, OS, and whether docker or “compiled” version is running, etc?
What is the implication if the MD5 hash doesn’t match?
I am seeing MD5 hash mismatch, but also slight differences in size as well (Api: /instances/{instance_identifier}/attachments/dicom/size).
All the versions of Orthanc will compute the MD5 hash in the same way.
However, if you send one DICOM instance through the DICOM protocol, you simply cannot assume the files on both side will be byte-to-byte identical. Indeed, the padding or the transfer syntax might change (e.g. from implicit to explicit). As a consequence, the MD5 or the file size between the source and the target might be different (which is what you observe).
Otherwise, if you send one DICOM instance through the Orthanc REST API, the files are guaranteed to be byte-to-byte identical, and the MD5 hash will be the same between the source and the target.
HTH,
Sébastien-
Thank you, this makes sense to me!
When I change how I send an instance from SourceA to TargetB (from Method #1 to Method #2), I am getting desired outcome of matching MD5 hash.
Before: Method #1
(1) Send instance from SourceA to TargetB
Api: {SourceA}/modalities/TargetB/store (w/ instance identifier in body)
After: Method #2
(1) Send instance from SourceA to TargetB
a. download dicom instance from SourceA, Api: {SourceA}/instances/{instanceIdentifer}/file
b. upload dicom instance via rest to TargetB, Api: {SourceB}/instances
What I find a little strange though, is when using Method #2, there was absolutely no errors.
However, when I was using Method #1, I would get some errors, with response like the following:
{ "HttpError" : "Not Found", "HttpStatus" : 404, "Message" : "Inexistent tag", "Method" : "POST", "OrthancError" : "Inexistent tag", "OrthancStatus" : 21, "Uri" : "/modalities/TargetB/store" }
Question:
From the Orthanc Book section on Orthanc Identifiers, I understand this error to mean that some required tags are missing from the DICOM instance and Orthanc cannot process it.
Why does Method #1 have this error, but Method #2 doesn’t, even though the same instance is being processed?
Why does Method #1 have this error, but Method #2 doesn’t, even though the same instance is being processed?
This is impossible to tell without having access to a sample problematic DICOM file. Please provide one such file so that we can help you.
Sébastien-
For sure!
The files are obtained from a sample data set.
I have also attached a single, sample problematic DICOM file.
Thanks,
Srey
MR000000.dcm (74.8 KB)
Hello,
Thanks! The DICOM file you sent causes problems because it does not contain the mandatory tag “PatientID”, making it invalid wrt. the DICOM standard.
I have just made Orthanc more tolerant to such an invalid file. The patch is now available in the mainline of Orthanc:
https://bitbucket.org/sjodogne/orthanc/commits/1824a02e095181d31ef12bf4db7f64bee12f0e52
HTH,
Sébastien-
Great!
In general, what is the lag time, so to speak, from when something is available in the mainline of Orthanc, to the docker version of Orthanc?
For instance, jodogne/orthanc-plugins?
I rebuild the docker image of the Orthanc mainline whenever someone asks me to.
Following your message, I have just triggered the build. You can follow the process at the following pages (check out the tag “latest”):
https://hub.docker.com/r/jodogne/orthanc/builds/
https://hub.docker.com/r/jodogne/orthanc-plugins/builds/
Sébastien-