I’m looking at writing a StorageArea plugin and want to use attributes of the study and the image to choose the directory in which to store each file. StorageCreate and StorageRead receive a UUID argument, but I believe this is a different value to the Orthanc Instance UUID that would be used in REST calls - is there a way from a StorageArea plugin to use this UUID to look up other data about the instance?
When writing the file, you may query Orthanc to get some DICOM tag values … and have access to some meta-data such as patient name, …
I would recommend you to check the VPI Reveal plugin source code: https://github.com/jodogne/OrthancContributed/blob/master/Plugins/orthancVPIRevealPlugin/Plugin/Plugin.cpp
Hello,
Indeed, the UUID argument is an unique identifier that is assigned by Orthanc to each file attachment it stores:
http://book.orthanc-server.com/faq/orthanc-storage.html
The UUID is chosen randomly by Orthanc, and is totally unrelated to the identifiers associated by Orthanc to the DICOM resources. The signature of the “OrthancPluginStorageCreate()” callback is important:
http://sdk.orthanc-server.com/group__Callbacks.html#ga77039105ee05cbf152a2005bd8d421ed
The “type” argument allows you to know whether the attachment to be stored is actually a DICOM instance (it would be equal to “OrthancPluginContentType_Dicom”). If it is the case, and if compression is disabled, the “content” argument contains the DICOM buffer. At this point, you could use the function “OrthancPluginDicomBufferToJson()” to convert the DICOM buffer to JSON, which would allow you to recover the value of the DICOM tags, then accordingly choose the target directory:
http://sdk.orthanc-server.com/group__Toolbox.html#gaaac5b1abc89eaa7c931d8361bf673690
You will of course have to keep a separate database that maps the UUID to the target folder: This database is needed for the “OrthancPluginStorageRead()” and “OrthancPluginStorageRemove()” callbacks to find out where the attachments are stored.
HTH,
Sébastien-
I wrote myself a little plugin to extend the REST API so that I can GET “/storageIDs/$uuid” to retrieve the instanceID information for a given storage UUID. This can then be used with “/instances/$instanceID” (and “/instances/$instanceID/study”, etc) to look up the necessary info to calculate the path for StorageRead to retrieve from without having to maintain a separate database of the location of each UUID. I’m making sure to only use information that’s available in the maindicomtags table and available through the summary REST calls, so I don’t expect to run into problems with StorageRead being indirectly recursive.
I did look into whether I can use that REST extension from StorageCreate but, alas, it seems that the database is only populated with the InstanceID and other details after StorageCreate has returned successfully. I guess the OrthancPluginDicomBufferToJson call is going to still be necessary there.
I’d share the code for my storageIDs API plugin, but… a) I have to convince my employer that sharing our toys is a good thing, and b) it’s of only limited usefulness because it relies on the PostgreSQLIndex plugin being in use.