Digital Imaging and Communications in Medicine (DICOM)

11.3 Securing the Data 253
DICOM anonymization software keeps a list of these confidential attributes
(some of them provided in part PS3.6 of the standard, Annex E), and removes
them from DICOM files. As a result, it produces anonymized DICOM files that
still contain the image and nonconfidential data sufficient for adequate image
display, but lack any confidential information. You can freely, publicly, and
safely distribute anonymized DICOM files for any practical reason.
The early implementations of this approach produced a hodgepodge of
DICOM anonymizers varying from simple delete-all-patient-information programs
to intricate manual DICOM editors in which the user had total control
over removing and editing DICOM file content (attributes). The latter choice,
however, is clearly impractical; you do not want to manually edit some 500 files
in your average MR study, it will take forever. 35 Therefore, the automatic approach
has become the most popular; but it, too, has its own shortcomings.
The biggest mistake made by many DICOM anonymizers is the automated
removal of private fields from the files. Consider, for example, an attribute such
as “Patient ID” (element (0010,0020) in the DICOM Data Dictionary, see also
5.6.1). This attribute is clearly confidential because it uniquely points to the
patient. Moreover, many DICOM systems use patient name, social security
number, or date of birth for Patient ID. However, one cannot simply wipe the
Patient ID out of a DICOM file. This attribute is DICOM-required, and its removal
would make the file or DICOM object invalid. Therefore, the attribute
has to be present, but it needs to be changed into something meaningless and
absolutely unrelated to the original ID value.
Let’s say that the original Patient ID value was “1234567” and our DICOM
anonymization software automatically replaced it with “wo4_ejF9h”. Mission
accomplished? Not at all! Not only should this replacement hide the original
data, but it should also consistently reproduce the result regardless of how and
when it was done. Combining hidden and consistent, as you can guess, becomes
the most intricate part of any anonymization. For example, all entries with the
same 1234567 ID that we might encounter later on (say, 2 years later, when this
patent comes for another exam), or all ID entries in a 2000-image CT study for
this patient must be consistently replaced with the same “wo4_ejF9h” string.
Otherwise, we would break a single patient into a mix of unrelated pieces, destroying
the original image and data relationship. Thus, our anonymizing software
should replace the confidential tag value with its meaningless placeholder
in a unique way. This already begins to sound like data encryption.
Furthermore, no two different patients in our example should receive the
same modified ID. If we anonymize another patient ID using the same “wo4_
ejF9h” string, we would glue two totally unrelated people into a single Siamese
twin with all the unpleasant consequences. In the extreme case, if we simply
replace any patient ID with a blank (like many anonymizers do), we would es-
35 Also, remember, that some attributes may depend on the others (see 5.5.6), so you
cannot edit them freely.