We are currently creating a TDR using the user-level 'TDR' class (i.e. NOT TDRModule).
We'd like to add some private attributes to this TDR before saving, which requires us to obtain an AttributeManager. Unlike a TDRModule, there seems to be no way to obtain an AttributeManager other than saving the TDR to disk and then reloading it in a new AttributeManager instance.
We can do this save/read/save process if we have to (and it does work), but it seems rather painful, it's a particular pain when, rather than writing to disk, we actually want to send the TDR via the network - now we need to save to a temporary file, re-read into the AttributeManager, add the private attributes and then send over the network.
Clearly there is an AttributeManager somewhere behind the TDR class - is there any way to get to it, or should we really be re-writing everything to use TDRModule instead?
Thanks.
Answers
Will,
The use of private tags is strongly discouraged as that results in a non-standard and non-interoperable environment. Even though the standard technically supports them, the healthcare industry is a good model to show that their use causes significant problems -- as DICOS is based on DICOM which is used in healthcare.
If you elaborate on the information you would like to store perhaps we can help you find a different way to store it within DICOS that does not use private tags.
If we cannot find a way to store the data without using private tags, a long term solution is to modify the DICOS specification itself, we can assist in that process to formally include the information within a DICOS tag so that it is properly handled within the NEMA framework -- as NEMA has complete oversight of DICOS.
As a last resort, we are looking into using a separate downloadable as a staging area for things that should be included in future DICOS versions. This would essentially be derived classes from our current ones, but with interfaces to support the added capability. By doing it this way, Stratovan can assist in storing the data in the ideal place within DICOS and also provide interfaces based on our SDK. This would also allow others to access the same information consistently via the add-on download -- rather than each entity adding their own private tags for the same information which would cause interoperability problems.
When the updates are added to the next DICOS specification we can move the interfaces into the new version of the DICOS SDK. Then, from your code perspective, you can use the same function calls but just change the object type you use for access -- underneath it all, Stratovan handles the infrastructure to change from using a private tag to the newly created DICOS tag that supports each capability. We feel this is the simplest long term solution considering all parties involved.
Thanks,David
David,
Many thanks for the reply. The data we wish to associate with the TDR/PTO are the low-level results of a novel imaging technique - they're not an 'image' per se, and not likely to be useful to a 3rd party, nor at a state of maturity where standardising the format would seem appropriate right now. The benefits to us of putting this data into the DICOS file are that it's permanently associated with the PTO, and we can transport it across the network using DICOS transport mechanism. We could roll our own container format (perhaps using something like zip), but then we'd be responsible for the whole pipeline (transport, archiving, etc).
From the point of view of DICOS we're just putting a blob of binary data (i.e. an array of bytes) into a private attribute - if there is a standardized way of putting a blob of binary data into each PTO then that would be great, and we could use that instead of custom attributes.
I will clarify at this end what scope of discussion is permitted by our current contracts, because I image there's a great deal of useful guidance we could get from you.
Many thanks,
Will