dcmqi
dcmqi copied to clipboard
ENH: revise initialization of TrackingUID
If not provided by the user, initialize it. This can't hurt, but will come handy if measurements are done later using this segmentation.
This can't hurt
This potentially can hurt, since if not initialized by the user explicitly in a longitudinal tracking situation, TrackingUID will be different even if the structure is the same, and the user may be unaware of this. It can also happen that the TrackingUID in SR may need to be different from SEG, which will become messy... No longer 100% sure this is a good idea!
if not initialized by the user explicitly in a longitudinal tracking situation, TrackingUID will be different even if the structure is the same
I'd say this is appropriate - if the the user doesn't explicitly affirm that the lesions are the same then the should have different UIDs.
Well, I think the question becomes what is the significance of something not being said. Let's say we have two time points with segmentations, and there are three situations for SEG (all of which are valid):
- tracking UID is assigned, and is different
- tracking UID is assigned, and it is the same
- tracking UID is not assigned
Then let's say someone wants to do measurements over that SEG, and that someone wants to assign consistent UID for the timepoints. If option 2 or 3 above is followed, this is possible, but otherwise producer of SR is locked between two unfavorable choices:
- violate the standard by assigning the same TrackingUID in SR (since it says "[Tracking UID] will have the same value as the value of the (112040, DCM, "Tracking Unique Identifier") content item in SR instances that reference this Segment in this Segmentation Instance.")
- propagate TrackingUID from SEG, and not express the longitudinal connection between the items.
The problem is SEG and SR may be created by different entities, with SEG generator not aware of consequences of not populating an optional parameter.
I am leaning towards not initializing TrackingUID in SEG by default, unknown to the user.
TODO:
- [ ] revise tid1500writer to check TrackingUID from SEG and propagate/issue error/warning if mismatched
@fedorov Regarding the "tid1500writer": The setReferencedSegment() method from TID 1411 class also sets (i.e. copies) the tracking information from the referenced segment if parameter "copyTracking" is true (which is the default). Not sure whether this information is helpful, but I just wanted to let you know.
Thank you Jörg, this is indeed helpful to know!