Limits of DICOM Anonymization in XNAT

This page is intended to provide information you should consider when sending DICOM files to the XNAT system. Your institution will have guidelines concerning the use and storage of files that contain Protected Health Information (PHI). The creators of the XNAT software do not claim that the software will meet your institution's guidelines. We do provide guidance that will be useful in your internal discussions.

Disclaimer on PHI Storage Prior to Anonymization

When a DICOM file is sent to XNAT through a DICOM C-Store operation, web upload or application upload, XNAT writes the file to disk, stores DICOM metadata in internal XNAT files and writes log files that will also contain DICOM metadata. This happens before the XNAT de-identification software is invoked. That means that if your original DICOM file contains PHI, that data might reside in an internal XNAT file. That file may or may not be accessible through the user interface. That file may or may not be accessible by someone with credentials that can query XNAT using the XNAT RESTful API. Someone with access to the file system might also be able to see data with patient information.

XNAT de-identification software does process each image that is received, but that process depends on rules that your administrator and/or project owners write. The XNAT team does not provide the rules nor claim that any rules will faithfully remove all PHI from any DICOM file. You will be responsible for the effectiveness of this step which depends both on the de-identification rules you write and whether the input images behave according to the assumptions made in those rules. Even with perfect image de-identification, the initial act of accepting data may result in the retention of PHI within the XNAT system.

We have XNAT systems in our institution that accept clinical images and de-identify those images for each project. In light of the fact that PHI has crossed the XNAT boundary, we advise our Internal Review Board that these systems are PHI repositories. We believe this is the safest policy within our institution, and we make great effort to make sure that our internal users are aware of how the images are to be used internally.

Strategies for Working Around These Limitations

If you are collecting data that you intend to publish, you have a few choices available to you. These are not mutually exclusive, and your eventual implementation strategy may contain a combination of these concepts.

• Perform DICOM anonymization on imported data (i.e. data sent from a PACS system via a C-MOVE operation) through an intermediate service, such as a dedicated Clinical Trial Processor (CTP) relay, prior to routing the data to your XNAT server
• Use the external XNAT Desktop Client for managing uploads of data, as this application performs client-side anonymization before streaming data to your XNAT server
• Use two separate XNAT systems – one for internal data gathering, processing, cleaning and packaging that you keep behind a network firewall, and a second public-facing XNAT for data distribution
• Convert your image data to a format with more restricted space for PHI to lurk, such as NIFTI, prior to packaging your data for distribution

Images that are posted on public-facing XNAT instances are de-identified using one or more of these methods before they are sent to those XNAT systems to avoid any internal storage of PHI.

Future Development Goals

The XNAT team will be exploring architectures that will include a de-identification system that is outside of the XNAT boundaries. This may simplify discussions with security officers as we hope to clearly delineate those areas in the overall system that may have PHI and those areas that will be free of PHI.