• Datetimes in Basic Application Level Confidentiality Profile

    From =?UTF-8?Q?Jo=C3=ABl_Spaltenstein?=@21:1/5 to All on Fri Feb 26 09:52:34 2021
    Hello,

    Looking through the Table E.1-1. Application Level Confidentiality Profile Attributes I'm a bit confused about the logic used to include or not different date time attributes.

    http://dicom.nema.org/medical/dicom/current/output/chtml/part15/chapter_E.html#table_E.1-1

    It appears acquisition times for some IODs are included (Acquisition Date, Study Date, etc) but others are missing. For example the Frame Acquisition DateTime and Frame Reference DateTime used in enhanced IODs are missing.

    Others like Radiopharmaceutical Start DateTime are also missing and will of course leak all the date time information. These seem a bit special since they have obvious important consequences for image interpretation.

    Are these accidental omissions because this part of the standard has not been updated since the inclusions of the enhanced IOD (see note 4.), or is there logic I'm missing?

    Thanks,
    Joël

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Clunie@21:1/5 to All on Fri Mar 5 05:17:14 2021
    Accidental.

    I will put in a CP to add them.

    David

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Jo=C3=ABl_Spaltenstein?=@21:1/5 to All on Mon Mar 8 09:59:46 2021
    Thanks!

    Here are a few more things that made me scratch my head.

    Referenced Image Sequence Attribute (0008,1140) and Source Image Sequence (0008,2112) are X/Z/U*, but Referenced Instance Sequence Attribute (0008,114A) and Source Instance Sequence Attribute (0042,0013) are not in the list at all.

    My first question is about consistency, why would references to images be considered identifying, but not references to other types of instances?

    Assuming that this is an accidental omission leads me to my second question. Why are these in the basic profile in the first place?!? I see nothing identifying about them.

    We will need to keep these in when de-identifying, so how should we populate the De-identification Method Code Sequence (0012,0064)? The Retain UIDs Option permits keeping these values, but we are not retaining UIDs, we're just using the standard U
    action on the referenced UIDs. Is the right thing to do to just ignore that these attributes are X/Z/U* and keep them without specifying anything in the De-identification Method Code Sequence? Or should the Clean Descriptors Option be somehow considered
    to cover these?

    Cheers,
    Joël

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)