dcmqi icon indicating copy to clipboard operation
dcmqi copied to clipboard

ENH: revise initialization of TrackingUID

Open fedorov opened this issue 6 years ago • 6 comments

If not provided by the user, initialize it. This can't hurt, but will come handy if measurements are done later using this segmentation.

fedorov avatar Oct 26 '18 22:10 fedorov

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!

fedorov avatar Oct 29 '18 02:10 fedorov

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.

pieper avatar Oct 29 '18 02:10 pieper

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):

  1. tracking UID is assigned, and is different
  2. tracking UID is assigned, and it is the same
  3. 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.

fedorov avatar Oct 29 '18 02:10 fedorov

TODO:

  • [ ] revise tid1500writer to check TrackingUID from SEG and propagate/issue error/warning if mismatched

fedorov avatar Oct 29 '18 15:10 fedorov

@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.

jriesmeier avatar Nov 08 '18 18:11 jriesmeier

Thank you Jörg, this is indeed helpful to know!

fedorov avatar Nov 08 '18 18:11 fedorov