Free DICOM de-identification tools in clinical research: functioning and safety of patient privacy

by David Clunie (dclunie@dclunie.com)

Aryanto KYE, Oudkerk M, van Ooijen PMA (2015) Free DICOM de-identification tools in clinical research: functioning and safety of patient privacy. Eur Radiol 25(12):3685–95.

Dear Editor,

I read with interest the excellent article by Aryanto et al. [1] about the requirements for, and efficacy of, various DICOM de-identification tools.
As the editor of DICOM Supplement 142 [2a], now DICOM PS3.15 Annex E [2b], I would like to draw attention to the design principles that we (DICOM Working Group 18) used in drafting that standard, which consisted of:
1. enumerating a conservative list of all possible attributes might that need attention
2. establishing subsets that need to be retained for specific use cases

In DICOM, we identified that there was a critical need to preserve specific attributes, such as the study date for longitudinal comparison of cancer progression, or the patient sex for computation of PET SUV, etc. These were codified in the form of “Options” to the Application Level Confidentiality Profile, such as the Retain Longitudinal Temporal Information options and the Retain Patient Characteristics Option [3].

The purpose of the DICOM profile is to standardize what applications do by defining a strict conformance mechanism.
Implicit in that aim are reduction of the variability between tools, and the expectation that users should be able to select a tool based on its compliance with the DICOM profile and its options.

Though Aryanto et al correctly draw attention to the danger of inadequate de-identification, despite their thorough analysis, they have, in my opinion, perhaps done the reader a disservice by oversimplifying the requirements and the comparison of the tools. They failed to stratify their comparison to consider different use cases in which de-identification is required. They failed to explicitly consider that overzealous de-identification results in data that is unusable for its intended purpose.

In emphasizing the “default” configuration of the various tools, and failing to consider the relative “ease” with which the default behavior can be modified (user interface selection of the equivalent of one of the DICOM PS3.15 Options, as distinct from manually editing lists of attributes), the comparison is less helpful than it might otherwise have been.

The de-identification software designer faces the interesting challenge of how to best configure their tool’s defaults to be suitable for its intended use, as well as either limiting its capability to protect against inexperienced users, or enabling complete flexibility for use by a nominal de-identification “expert”.

As a case in point, I designed the PixelMed DicomCleaner tool for use primarily in longitudinal cancer therapeutic clinical trials, which involve PET and for which submitting sites sent DICOM studies as they were acquired. Accordingly, the tool’s default behavior is to apply the DICOM Application Level Confidentiality Profile with the Retain Longitudinal Temporal Information with Full Dates, Retain Patient Characteristics, Retain Device Identity and Retain Safe Private Options.

Yet, the configuration of the tool by the user to perform differently (more or less conservatively for specific use cases) is trivially addressed by check boxes for each of these categories in the user interface [4]. E.g., there are check boxes to “Remove patient characteristics” or “Remove device identity”, which do not require an intimate understanding of the DICOM encoding.

Other tools, such as RSNA’s Clinical Trial Processor (CTP) [5] address such issues by the provision of a set of scripts for typical use cases, which may be customized by experts, but which are intended to be used “as is” when appropriate, as for example in the Cancer Image Archive submission process [6,7].

In passing I also note that PixelMed DicomCleaner is incorrectly described in Table 2 as a “command line utility”. It does in fact have a GUI, and though it can be invoked from the command line or on-line via Java Web Start or as a Windows or Mac executable, it is entirely operated through its GUI [4].

If you would like to comment on this letter, please send your comments together with full contact data to office@european-radiology.org. Replies and comments will be reviewed by the Editorial Office and published on this website.