Add attributes describing safe or unsafe private elements Status June 2015 Voting Packet Date of Last Update 2015/03/23 Person Assigned David Clunie Submitter Name Justin Kirby Submission Date 2014/06/19 Correction Number CP-1411 Log Summary: Add attributes describing safe or unsafe private elements Name of Standard PS3.2, PS3.3, PS3.5, PS3.15 Rationale for Correction: Though most do not, private data elements may contain identifying information that needs to be removed during de-identification. Documentation of this is often not readily available. A mechanism is proposed to describe whether or not private blocks and/or individual elements do or do not contain identifying information, as well as suggested actions to be taken during de-identification. Correction Wording:

Amend DICOM PS3.3 section C.12.1 SOP Common Module by adding the following attributes:

...

SOP Common Module Attributes

Attribute Name	Tag	Type	Attribute Description
...	...	...	...
Private Data Element Characteristics Sequence	(gggg,eee0)	3	Characteristics of Private Data Elements within the current SOP Instance
>Private Group Reference	(gggg,eee1)	1	Odd group number within which the Private Data Element block is reserved.
>Private Creator Reference	(gggg,eee2)	1	The value of the Private Creator Data Element value used to reserve the block of Private Data Elements whose characteristics are described in this Item. Private blocks are identified by their Private Creator Data Element value, rather than their numeric block number, since instances may be modified and numeric block numbers reassigned but the Private Creator Data Element value, which is required to be unique within a Group of Private Data Elements, will be preserved.
>Block Identifying Information Status	(gggg,eee3)	1	Specifies whether some or all of the Private Data Elements in the block are safe from identity leakage as defined by PS3.15 Section E.3.10. SAFE no data elements within the block contain identifying information UNSAFE all data elements within the block may contain identifying information MIXED some data elements within the block may contain identifying information
>Nonidentifying Private Elements	(gggg,eee4)	1C	List of Private Data Elements in block that do not contain identifying information (are safe from identity leakage). Elements are identified by the lowest 8-bits of the attribute tag (i.e. with a value from 0000H to 00FFH) within the block, stored as an unsigned short integer. Multiple values shall be in increasing order and a given value shall be listed at most once. Required if Block Identity Leakage Status (gggg,eee3) equals MIXED.
>Deidentification Action Sequence	(gggg,eee5)	3	Actions to be performed on element within the block that are not safe from identify leakage.
>>Identifying Private Elements	(gggg,eee6)	1	List of Private Data Elements in block that may contain identifying information (are unsafe from identity leakage).. Elements are identified by the lowest 8-bits of the attribute tag (i.e. with a value from 0000H to 00FFH) within the block, stored as an unsigned short integer. Multiple values shall be in increasing order and a given value shall be listed at most once.
>>Deidentification Action	(gggg,eee7)	1	Recommended action to be performed during de-identification on elements listed in Identifying Private Elements (gggg,eee6) within this Item. A specific type of action is suggested in order to minimize the impact of de-identification on the behavior of recipients that use the Private Data Elements. D replace with a non-zero length value that may be a dummy value and consistent with the VR Z replace with a zero length value, or a non-zero length value that may be a dummy value and consistent with the VR X remove U replace with a non-zero length UID that is internally consistent within a set of Instance No C (clean) action is specified, since replacement with values of similar meaning known not to contain identifying information and consistent with the VR requires an understanding of the meaning of the value of the element. Whether or not to clean rather than remove or replace values is at the discretion of the implementer. No suggested dummy value is provided, since the encoding of the value would depend on the VR of the data element.

Amend DICOM PS3.6 section 6 to add the following data elements:

Registry of DICOM Data Elements

Tag	Name	Keyword	VR	VM
(gggg,eee0)	Private Data Element Characteristics Sequence	Private​Data​Element​Characteristics​Sequence	SQ	1
(gggg,eee1)	Private Group Reference	Private​Group​Reference	US	1
(gggg,eee2)	Private Creator Reference	Private​Creator​Reference	LO	1
(gggg,eee3)	Block Identifying Information Status	Block​Identifying​Information​Status	CS	1
(gggg,eee4)	Nonidentifying Private Elements	Nonidentifying​Private​Elements	US	1-n
(gggg,eee6)	Identifying Private Elements	Identifying​Private​Elements	US	1-n
(gggg,eee5)	Deidentification Action Sequence	Deidentification​Action​Sequence	SQ	1
(gggg,eee7)	Deidentification Action	Deidentification​Action	CS	1

Amend DICOM PS3.5 section 7.8.1 as follows:

It is possible that multiple implementers may define Private Elements with the same (odd) group number. To avoid conflicts, Private Elements shall be assigned Private Data Element Tags according to the following rules. Private Creator Data Elements numbered (gggg,0010-00FF) (gggg is odd) shall be used to reserve a block of Elements with Group Number gggg for use by an individual implementer. The implementer shall insert an identification code in the first unused (unassigned) Element in this series to reserve a block of Private Elements. The VR of the private identification code shall be LO (Long String) and the VM shall be equal to 1. Private Creator Data Element (gggg,0010), is a Type 1 Data Element that identifies the implementer reserving element (gggg,1000-10FF), Private Creator Data Element (gggg,0011) identifies the implementer reserving elements (gggg,1100-11FF), and so on, until Private Creator Data Element (gggg,00FF) identifies the implementer reserving elements (gggg,FF00-FFFF). Encoders of Private Data Elements shall be able to dynamically assign private data to any available (unreserved) block(s) within the Private group, and specify this assignment through the blocks corresponding Private Creator Data Element(s). Decoders of Private Data shall be able to accept reserved blocks with a given Private Creator identification code at any position within the Private group specified by the blocks corresponding Private Creator Data Element. Whether or not Private Data Elements contain identifying information related to de-identification is defined by the Private Data Element Characteristics Sequence (gggg,eee0). See PS3.3 Section C.12.1. The versions of this standard prior to V3.0 described shadow groups. These were groups with a group number one greater than the standard groups. Elimination of conflicts in Private Data Element Tags have made this distinction obsolete and this terminology has been retired. The versions of this standard prior to V3.0 specified private group element numbers (gggg,10FF-7FFF) reserved for manufacturers and private group element numbers (gggg, 8100-FFFF) reserved for users. Elimination of conflicts in Private Data Element Tags has made this distinction obsolete and this specification has been retired. The requirements of this section do not allow any use of elements in the ranges (gggg,0001-000F) and (gggg,01200-0FFF) where gggg is odd. Elements with Tags (0001,xxxx), (0003,xxxx), (0005,xxxx), and (0007,xxxx) shall not be used. Since each Item within a sequence is a self contained Data Set (see on the nesting of Data Sets via Sequences of Items), any Item that contains Private Data Elements shall also have Private Creator Data Elements reserving blocks of Elements for those Private Data Elements. The scope of the reservation is just within the Item. Items do not inherit the Private Data Element reservations made by Private Creator Data Elements in the Data Set in which the Item is nested. If a sequence is itself a Private Data Element and the Items within the sequence also have Private Data Elements, then there will be Private Creator Data Elements both outside the sequence and within the sequence Items. Different Items may reserve the same block of Private Data Elements for different private creators. This is necessary to allow the nesting of Data Sets collected from multiple sources into folders.

Amend DICOM PS3.15 section E.3.10 as follows:

By definition, Private Attributes contain proprietary information, in many cases the nature of which is known only to the vendor and not publicly documented. However, some Private Attributes may be necessary for the desired application. For example, specific technique information such as CT helical span pitch, or pixel value transformation, such as PET SUV rescale factors, may only be available in Private Attributes since the information is either not defined in Standard Attributes, or was added to the DICOM Standard after the acquisition device was manufactured. When this Option is specified in addition to an Application Level Confidentiality Profile, Private Attributes that are known by the de-identifier to be safe from identity leakage shall be retained, together with the Private Creator IDs that are required to fully define the retained Private Attributes; all other Private Attributes shall be removed or processed in the element-specific manner recommended by Deidentification Action (gggg,eee7), if present within Private Data Element Characteristics Sequence (gggg,eee1) (see PS3.3 Section C.12.1). Whether or not an Attribute is known to be safe may be determined by: its presence in a block of Private Data Elements with a value of "SAFE" in Block Identifying Information Status (gggg,eee3) or individually listed in Nonidentifying Private Elements (gggg,0004) (within Private Data Element Characteristics Sequence (gggg,eee1); see PS3.3 Section C.12.1) its presence in Table E.3.10-1 Safe Private Attributes documentation in the Conformance Statement some other means. When this Option is not specified, all Private Attributes shall be removed, as described in Table E.1-1. ...

Amend DICOM PS3.2 section A.9.2 as follows:

Any private Attributes should be specified, including VR and VM, should be specified. Whether or not each private Attribute characteristics are described using Private Data Element Characteristics Sequence (gggg,eee0) should be specified. Private SOP Classes and Transfer syntaxes should be listed.