TCIA staff have accumulated a wealth of knowledge on best practices and procedures for DICOM image de-identification. We’re sharing this information with the wider research community by maintaining this knowledge base as a living document that will be updated as we learn from our experiences. If you have feedback or questions, please contact us at firstname.lastname@example.org.
The DICOM standards committee Working Group 18 (WG18) wrote Supplement 142, now incorporated into the published DICOM Standard. The Attribute Confidentiality Profile (DICOM PS 3.15: Appendix E) provides a standard for image de-identification, reducing the complexity involved in safely de-identifying DICOM image data while retaining the flexibility to preserve certain information for essential quality control and analysis. Application Level Confidentiality Profiles, which include a Basic Profile along with a number of Option Profiles, provide instructions for how to safely clean DICOM elements which may contain PHI. The DICOM Standard, including Part 15, is available at the NEMA web site. We recommend using the published standard above as it will be updated with any change proposals. We have also ported the contents of Table E.1-1 into XLS format for easy access.
Appendix E of PS 3.15 documents a system for protecting attributes; a section is reproduced below:
The Attributes listed in Table E.1-1 for each profile are contained in Standard IODs, or may be contained in Standard Extended IODs. An implementation claiming conformance to an Application Level
Confidentiality Profile as a de-identifier shall protect or retain all instances of the Attributes listed in Table E.1-1, whether contained in the main dataset or embedded in an Item of a Sequence of Items. The following action codes are used in the table:
– 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
– K – keep (unchanged for non-sequence attributes, cleaned for sequences)
– C – clean, that is replace with values of similar meaning known not to contain identifying information and consistent with the VR
– U – replace with a non-zero length UID that is internally consistent within a set of Instances
– Z/D – Z unless D is required to maintain IOD conformance (Type 2 versus Type 1)
– X/Z – X unless Z is required to maintain IOD conformance (Type 3 versus Type 2)
– X/D – X unless D is required to maintain IOD conformance (Type 3 versus Type 1)
– X/Z/D – X unless Z or D is required to maintain IOD conformance (Type 3 versus Type 2 versus Type 1)
– X/Z/U* - X unless Z or replacement of contained instance UIDs (U) is required to maintain IOD conformance (Type 3 versus Type 2 versus Type 1 sequences containing UID references)
PS 3.15: E.2 then defines the Basic Application Level Confidentiality Profile, which describes how to apply the scheme above with a number of options that determine the level of protection provided. These definitions allow a system to follow a standard procedure and document the behavior of that system in a standard way.
We typically retain DICOM private data elements containing parameters that describe the acquisition while removing PHI. Performing this task requires understanding the mechanism defined by DICOM to support private elements. DICOM PS 3.5, section 7.8.1 states:
It is possible that multiple implementors 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.
We use data in group 0009 as an example in the table below:
Private Creator Element
Density Standard Deviation
In the example, the element with tag (0009, 0010) is a private creator element with value "ACME". That reserves a block of elements for this manufacturer. The element (0009, 1001) is part of that block; the 10 in the element tag (1001) corresponds to the 10 in the tag of the Private Creator Element (0009, 0010).
This becomes complex when different manufacturers want to use the same reserved block to store information. When this occurs in a single image, the creator of the image reserves a block (for example, 0010). When a second application wants to add data to that same group, it detects the block written by the creator and creates a separate block (for example, 0011). The creator is not required to start at block 0010, but that appears to be common practice. The second or third application is not required to use 0011 or 0012. Based on this encoding scheme, some observations are:
To simplify implementation of "clean" instructions specified in DICOM PS 3.15, a new tool was developed to help inspect the contents of DICOM elements, allowing free text entry by a technician and Private Tags for potential PHI. This tool scans a folder, includes subfolders for DICOM objects, and produces several different outputs that depend on the mode used and input profiles. The software reads each DICOM object and iterates through each public and private element. The software then uses the profiles below to determine whether or not to retain the value of the element for later inspection:
These outputs are relevant at different stages of the curation and image publication process:
This tool can be useful to the rest of the research community, so it has been made freely available as an open source application. We have also created documentation for its use in the context of a researcher’s own projects.
Data recorded in the documents above are also available through a web-based application with query capabilities. Researchers who obtain images through TCIA or by other means are welcome to search the database to find definitions for private elements.
As discussed above, medical manufacturers include private elements in their DICOM images to convey information not defined in the DICOM Standard. This section documents the information we have gathered from conformance statements.
The sections below describe information by manufacturer. That information is encoded in files that describe the private elements created by those manufacturers. Those files are part of the run-time environment of the Tag Sniffer and are maintained in our code repository:
The information in the documents below is also available through a web based tool with query functions. That tool is found here:
TCIA utilizes the Radiological Society of North America (RSNA) CTP software in conjunction with caBIG's National Biomedical Imaging Archive (NBIA) to de-identify and host the images in the archive. The Cancer Imaging Program's Informatics Team has been working closely with the developer of CTP since 2009 to incorporate support for this standard as it was being defined by WG18. Find the summary and time line of this project here: https://wiki.nci.nih.gov/display/CIP/Incorporation+of+DICOM+WG18+Supplement+142+into+CTP.
CTP provides an interface that allows application of any combination of profiles to a set of images, and allows for an audit trail to retroactively track applied de-identification. When images are submitted to TCIA, the staff begins with the Basic Application Confidentiality Profile (which is the most aggressive) in combination with the following options:
TCIA provides standards-based curation support to ensure safe and thorough de-identification of all images in the archive per federal HIPAA and Health Information Technology for Economic and Clinical Health (HITECH) Act regulations. To achieve this compliance without stripping the data of its scientific utility, TCIA performs a thorough de-identification and analysis procedure based on guidance from the DICOM standards committee WG18. Each collection submitted for publication is analyzed and de-identified as a whole using the steps listed below. All steps are completed before the collection is released for publication.
Only after this inspection is complete are the images made available to the general public. For information on what to expect as an image provider, please see our web site at http://www.cancerimagingarchive.net/provider.html.
Here are some presentations and papers which provide an overview on various aspects of DICOM de-identification and the official Supplement 142 de-identification standards: