Hello,
A lot of our failures are around <(0008,1111)>[<0000>]<(0008,1155)> Referenced SOP Instance UID
We failed the check.
What we did was hash the the value with the same root as we did for the rest of the UI data.
So, for example:
File D:\input_data\31780971\3.1.874.1.3.8955936.3.406.3275461099748359143\3.1.874.1.3.8955936.3.406.2571635843887543751\00001932.dcm
The original value of <(0008,1111)>[<0000>]<(0008,1155)> = 3.1.874.1.3.8955936.3.406.1925443172982664609
We de-id to <(0008,1111)>[<0000>]<(0008,1155)> = 1.2.840.113654.2.174.69.288088263163193226019384943346399402313
The Discrepancy Report says the action text should be 3.1.874.1.3.8955936.3.406.1925443172982664609 which is the original value.
Should we have left <(0008,1111)>[<0000>]<(0008,1155)> unaltered ? Or have we somehow hashed it incorrectly ? It is easy to leave unaltered I would just be surprised as if we hash the Sop Instance UID we should surely has the Referenced Sop Instance Uid.
Regards,
Chris
Created by Chris Ablett ChrisAb Thanks, I forgot to add it to the mapping file ! I would not leave it unaltered. I suspect you would then throw a uid_changed error.
If you are getting a uid_consistent error, either you are neglecting to add the uid mapping (old id: 3.1.874.1.3.8955936.3.406.1925443172982664609, new id: 1.2.840.113654.2.174.69.288088263163193226019384943346399402313) to the uid mapping file or the old id is getting hashed inconsistently for two different cases. Is the old id: 3.1.874.1.3.8955936.3.406.1925443172982664609 in the uid mapping twice with two different new ids?
We can't predict what pseudonymization method you might use, so the validation relies on your uid mapping to check consistency.
Michael