Anonymization processes in IMAIOS applications

Available on IDV (iOS: Version 2.2+ and Android: Version 2.1+) and e-Cases.

When you use our solutions, you may be asked to send us DICOM files, which will then be anonymized. This feature may occur, for example, when you send feedback in the IDV applications for mobile devices. DICOM anonymization is a crucial step in data protection when sharing medical images. It protects the privacy of patients by removing or modifying any data that could identify them. 

In this article, we will describe our internal anonymization process in detail.
For more information on DICOM anonymization in general, you can read our blog post: DICOM Image Anonymization Update 2020.

The major part of the work involved analyzing which data to keep or not and therefore focused on DICOM metadata. The DICOM standard encapsulates the acquired image in a file containing a set of metadata relating to the identification (patient, physician), the exam (date and time, dosimetry), the dynamics and characteristics of the acquired image (resolution, allocated machine words), the description of the equipment (make, model, components) and a set of descriptors allowing interoperability with hospital and radiological information systems. There are hundreds of such metadata, and some are mandatory to maintain compliance with this standard.

Responsibility for the data sent

The DICOM anonymization service allows users to NOT disseminate private patient, facility and physician information that is typically stored in the DICOM files. However, private information may be stored in other tags and/or in the image or video content of the DICOM files. Therefore,the user remains responsible for the information he/she distributes

Anonymizing DICOM tags

To anonymize a DICOM file we will empty, protect or remove metadata, so this action does not affect the images.
In order to inform our users about the processing of each data, we have listed all the metadata we process. You will find the corresponding table at the end of this article.
Important: All tags not listed in this table are automatically removed for security reasons, as we cannot guarantee that their content is not sensitive.

To help decide how to process the different data, we first used the Table E.1-1. in the DICOM documentation, which lists the actions to be taken for the attributes in the Basic Application Level Confidentiality Profile. It defines an extremely conservative approach but removes all information relating to: 

• patient identity and demographics
• the identity of responsible parties or family members
• the identity of any personnel involved in the procedure
• the identity of the organizations involved in the prescription or performance of the procedure
• additional information that could be used to match instances if they had access to the originals, such as UIDs, dates and times
• private attributes

(Nema E.2)
Next, for other attributes we defined our own treatment choices based in part on 3 criteria for determining whether a metadata needs to be anonymized:

Standard: The tag is a component of the DICOM standard.
Anonymous: The content of the tag does not contain any sensitive information (therefore considered as already anonymized).
Required: The DICOM must have a tag in accordance with the standard and cannot be deleted.

If the tag fails to meet any of the criteria, then we will apply an anonymization method depending on the sensitivity of the information to be anonymized, the possibility of deleting it or not, the need to keep a value and/or a unique identifier.

We define the different anonymization methods such as:

¹ VR: Value representation, indicates the type of data encoding (text, date, etc.).

It is possible that in the table, according to the DICOM documentation, the methods separated by "/" are presented as "X/Z/D". In our case we will generally apply the strongest anonymization method, which will correspond to the leftmost value of the enumeration. However, it may be that we choose to use a different value from those listed in order to preserve functionalities in our applications.

To date, it should also be noted that we have not yet found a reliable method to anonymize certain DICOM tags, such as the tags in group 60xx that relate to overlays. Therefore, we have decided to remove these tags from DICOM files rather than anonymize them, but we are still working on this.

In accordance with DICOM documentation (Nema E.1.3), we comply with the basic privacy profile at the application level by describing:

• Which attributes are removed during protection,
• Which attributes are replaced by dummy values and by what process,
• The scope in which the application is able to ensure the referential integrity of replacement values for references such as SOP instance UID, Frame Reference UID, etc. if multiple SOP instances are protected (e.g. in multiple studies, consistent replacement if the same study is processed more than once, etc.).

=> In our process we hash the UIDs, which means that each UID hash is in theory unique. With the hash method we use, its risk of collision with another UID (both 64 characters) is 4.5x10^-38 which is extremely low. In other words, it is very unlikely that a collision will occur between two UIDs.
To give an idea: there are around 10^21 grains of sand on earth, so the probability of finding a particular grain is 10^-21, so there's a much greater chance of finding that particular grain of sand than there is of finding a collision, i.e. a value giving the same hash.

Metadata processing by IMAIOS - User information

Processing override on some attributes depending on the modality.

To conclude, this blog post, intended for users who work with our solutions, is an explanation of our DICOM compliance in our anonymization processes.
Here we detail what data we act on and in what ways to ensure patient and exam privacy while maintaining readability by the various DICOM reader software.
We are committed to providing transparency on our anonymization processes that are compliant with DICOM documentation.
We built on the basic standard by taking the security of your personal data a step further by applying anonymization functions on attributes that we did not need and that were not specified in the documentation.