PHI And Anonymization Using the DQR Plugin
Your XNAT system must be able to accept PHI if you are using the DQR Plugin
The DICOM Query Retrieve plugin is a utility designed to make it easier to pull data from a PACS system directly to your XNAT. It offers enhanced anonymization and relabeling capabilities, but like any XNAT that receives DICOM data directly from a PACS system, it cannot be considered free of PHI. Some PHI embedded in DICOM fields will be part of the initial session-building XML, prior to any anonymization. Additionally, the original values for Patient Name and Accession Number are stored in the DQR Import History.
How DQR Anonymization Adds to the XNAT Anonymization System
To facilitate query-specific relabeling, the DQR Plugin uses two new Archive Processor Instances that have been inserted into the session archiving logic ahead of the core XNAT "site anonymization" processor, as well as a modification for XNAT's SCP Receivers that reworks project routing.
"Update Request" is a new processor that has been inserted by the DQR plugin itself, and is applied immediately after the DICOM is read.
"dqrObjectIdentifier" is a new DQR-enabled DICOM Object Identifier that assigns incoming data to the project that requested it, rather than reading the DICOM and looking for a project assignment there. This must be applied to your import method, whether you are using a DIMSE-enabled PACS connection or DICOMweb. See DQR Admin: Plugin Configuration
"Remapping" is a processor that was introduced in core XNAT 1.7.5, and is primarily used by the DQR plugin. This is applied immediately after the project is set, but before the data hits the Prearchive and before XNAT's site-wide anonymization takes place. This is where DQR-specific subject and session relabeling takes place.
After these steps, XNAT applies the following anonymization steps:
Site-wide Anonymization Script
Project-specific Anonymization Script
So if you have additional relabeling rules specified in your site-wide or project anonymization scripts, those will be applied after your DQR-specific relabeling, and will overwrite those values.
The Limits of DQR Anonymization
The DQR plugin is only designed to impact a very small number of DICOM fields:
Patient ID
Patient Name
Study ID
Accession Number
Study Date
Patient's Birth Date
You can perform subject and session relabeling while using the DQR Plugin to import data, but if your DICOM data contains PHI in other fields – for example, "Other Patient IDs (0010,1000)" or "Patient's Birth Name (0010,1005)" – you must still account for those fields by applying a full anonymization script to your incoming data, either at the site or in the project. See How to Write an Anonymization Script.
Additionally, any incoming DICOM data will have some original DICOM values applied to the session XML while it is being built in the Prearchive. This is a general XNAT import workflow issue, and is not specific to the DQR Plugin.
No XNAT that has data coming in directly from a PACS system can be considered free of PHI.
Some XNAT systems find ways of working around this constraint by routing incoming data through a CTP Relay or by using an external system such as JAAT to route data through an external anonymization process in between the PACS system and XNAT. Inserting that kind of routing logic into the DQR Import process is beyond the scope of this documentation.
PHI Embedded in the Query History
In addition to the original DICOM values used in the Session XML when archiving, the original DICOM Query request is stored in the DQR Query History table, and this can contain PHI. Notably, Patient Name and Accession Number are stored in this table.