Hello, I have two points I was hoping for clarification on: 1. We have been working under the assumption that all dates in the DICOM are considered potentially identifying information. However, our discrepancy report shows a couple thousand lines indicating that these "Private Creator" datetimes in the form YYYYMMDDHHMMSS ought to be retained i.e. . One example DICOM of this is in this file: 6736708662/3.4.911.0.0.7452303.1.901.9848250898230174418/3.4.911.0.0.7452303.1.901.2921419100524330748/00000001.dcm Can you please clarify whether these dates are, or are not, identifying information? 2. We also have a couple of thousand lines indicating that certain tags, for example, "View Position" in the file below, be retained , however, our algorithm does not remove any tags at all, we only edit tags, we do not remove the tags. Since we are not removing any tags, I am not sure how to respond to these discrepancies. 5987603999/3.4.387.1.2.9036050.9.289.1698993350714490137/3.4.387.1.2.9036050.9.289.1404201652116759618/00000001.dcm I appreciate any clarification. Thank you

Created by Marco Pereaņez rids_1
Hi @rids_1, For your first point regarding private creators. I'll admit that this was my mistake in the creation of the synthetic set. The dates should have been inserted into elements within that private element group rather than overwriting the private creator. My recommendation is to leave the Private Creator elements alone. Private elements are most commonly entered by device vendors. The private creator is the value that differentiates one vendor's elements from another vendor who may decide to use the same group / element scheme, in this case (0019,0010). They are also used as unique identifiers to locate tag information within a vendor's conformance statements, so leaving them unmarred is important. For your second point. The tag_retained and text_notnull checks are DICOM standard conformance checks based on DICOM type 1 and 2 elements. If it is a type 2 element (DICOM-IOD-2), the answer key includes a tag_retained action check (because the element should be present, but can be empty). If it was a type 1 element (DICOM-IOD-1), the answer key includes both a tag_retained and text_notnull check (because the element should be present, and it should have a value). It is plausible that the original synthetic files were not 100% DICOM compliant, and that non-compliance will carry into your de-identified set if you don't add a valid value and/or tag. This does prevent scores of 100%, but everyone is on an even playing field, and it should all pan out in the final results. Please let us know if you have any further questions or concerns. Michael
Hello @phmoer @Granger.Sutton @mdsage1, I am just wondering if you have a clarification for my question above. Thank you.

Clarification on Private Creator dates and "tag_retained" page is loading…