Currently, to my knowledge, semgentions written to DICOM generate there relevant DICOM IDs not before they are stored.
I think this is to late and I would open a discussion about it to clarify how we handle it in the future. Especialle with the advent of the new segmentation design and the introduced PropertyRelations this is an important thing to do as early as possible.
Reason: If we generate the DICOM UID on saving, we cannot establish PropertyRelationRules that are based on ths information. Example: Generation of perfusion maps by using a ROI (that is defined by a segmentation). The cleanist way would be by using a relation rule that establishes the relation on the data layer by setting the DICOM source information in the paramter image by using the DICOM UID information of the segmentation.
This is only possible whe nthe UID of the segmentation is already there. You could think of lazy mechanisms that establish a connection and propagetes the UID as soon as it exists and also requests the UID when it is needed ther first time. But I think this is not a good road to go and leads to code that is ugly to maintaine and understand without solving the underlying problem.
Motivation for the UID-generation-on-writing was the fact, that segmentations could be altered while MITK is running and thus the UID has to be another. (Comment but this strategy will only work if you always generat a new UID when writing the segmentation, even when the content has not changed and it is the same IOD; otherwise you cannot cope with a DICOM-seg-loaded-altered-stored scenario)
I think the best and cleanest solution would be to generate the UIDs as soon as a segmentation is "accepted" (meaning that it is "publicly" in the data storage and can be seen and referenced by other (plugins/data). If a segmentation is altered again it must be cloned. And you alter the clone.
How to deal with the original is a usability thing e.g.
- just keep it, but clone has its "position" now. So it looks like the orginal has been added.
- just keep it, but orginal keeps its "position". So it looks like the clone has been added.
- clone replaces the original
We surely have to look carefully on the usability/workflows to make them slike and not cumbersome due to the cloning, but I think that is doable and would end in a much cleaner solution.
What do you think?