Hi Alain,
I want to use Orthanc as a larger long-term PACS that will be 80% archive with only little regular read/query access.It will be connected to about 15 larger modalities (CT, MRI, Angio) so I’m expecting quite some amount of data coming through (roughly estimated 10TB to 20TB per year). I’m quite confident that Orthanc can handle this job and I have already gone through all the tips and guides in the Orthanc book for setting up and optimizing Orthanc for performance. That’s also the reason for the minimal approach without lua or python plugins and also without HTTP for the receiver instance of Orthanc.
However, because of the long-term nature of the storage (5+ years) I would very much like the data to be stored in a PatientID/StudyUID/SeriesUID/ directory structure as a fail-safe (in case of database corruption or simply a failure of the database server the data can then still be easily and quickly used without having to first index 50TB+ of DICOMs, even indexing and recreating the database will be easier using this structure because one can index by PatientID and can already use data before indexing is complete).
First I have looked into creating a custom Storage plugin but quickly realized that this would create quite some overhead in StorageRead() because every read event would need to first figure out PatientID, StudyUID and SeriesUID for each instance, probably by a direct database query. For performance reasons I would rather want to avoid this, so I was thinking that maybe it would be possible to simply create symbolic links of the original Orthanc storage area to the PatientID/StudyUID/SeriesUID/ structure, i.e. overwriting StorageCreate() to write to the original Orthanc storage paradigm and create an additional symbolic link based on PatientID/StudyUID/SeriesUID/ in a separate directory. But this would mean to completely reimplement the original Orthanc storage area paradigm in a custom plugin simply to extend it by the symbolic link creation. Just recreating the already existing storage functionality is something I would like to avoid, especially for future compatibility to core Orthanc changes.
So I was thinking next to create a simple plugin that hooks into the OnStoredInstanceCallback() to create symbolic links of the original Orthanc storage area to the PatientID/StudyUID/SeriesUID/ structure. This way Orthanc could still be using the original and efficient UUID-based storage area… and that’s how I ended up not finding a way to get the FileUuid from the Plugin 
I’m aware that this would probably be possible by just running a RestAPI call in OnStoredInstanceCallback() on each instance to get the FileUuid, but for this, I’m very worried about performance in situations where thousands of instances could be transferred per minute and would prefer to avoid this.
best wishes
Martin