- About XNAT
- News & Events
- XNAT Marketplace
- Contact Us
For all non-clinical instances of XNAT, study owners should be very concerned about keeping personal health information (PHI) and personally identifying information (PII) out of their database. This is especially important for any study that operates under the jurisdiction of an Internal Review Board.
The most common (and often inadvertent) means of importing PHI or PII is through DICOM metadata fields in patient scans. Because XNAT's archive stores every version of a file by default, it is not advisable to simply import and archive all data with the expectation that it can be cleaned later.
Here is an overview of the precautions you can take to inspect and anonymize your data before it hits your archive.
An XNAT Administrator can set site-wide anonymization scripts and series import filters. If enabled, these will be applied to all incoming image data imports, before any project-specific scripts are applied. See: Site-wide Session Upload and Anonymization Settings.
The Quarantine feature was introduced in XNAT 1.4, as an early means of handling data that is suspected of containing PHI. If your XNAT is set up to auto-archive imported sessions by default, you may wish to enable the quarantine setting to prevent incoming data from being used in processing until they have been reviewed.There are two possible settings:
The Quarantine feature does not prevent data from being permanently stored in the XNAT archive – it merely adds a flag to the data that prevents its usage. If your goal is to prevent suspect data from ever being archived before it has been examined, we recommend using the Prearchive.
The Prearchive is a file system intended for temporarily housing incoming data files outside of the XNAT Archive. All uploaded image data can be placed into the Prearchive, where you can examine the DICOM headers for PHI, or for proof that the session upload is complete, before archiving the data into your project. There are three possible settings.
If you plan on importing a number of image sessions from the same scanner, it should be easy to browse the DICOM fields and identify fields that will have PHI in them. ("Should" be easy, but often is not, when you consider some scanners' proprietary tags and hard-to-find fields.) You use DicomBrower to browse and edit DICOM fields on existing sessions. But if you want to prevent any future scans from this same source from bringing PHI into your system, you can write an anonymization script using DicomEdit and apply it to your project in this panel. See How to Write an Anonymization Script.
Anonymization Scripts from XNAT 1.6.5 and earlier will not be compatible with XNAT 1.7.0, 1.7.1, 1.7.2, because they are based on DicomEdit 4.2. Using older scripts will cause session archive actions to fail.
XNAT 1.7.0 through 1.7.2 uses DicomEdit 6.0 See: DicomEdit: "Migration to version 6.0 scripts"
XNAT 1.7.3+ can use both DicomEdit 6.1 and 4.2. New scripts should use DicomEdit 6.1. See DicomEdit: "Migration to version 6.1 scripts"
With series import filters, you can direct XNAT to prevent certain data from ever entering your archive. One very important reason to do this might be that your are uploading clinical images to a research project. Clinical images often contain "burned-in PHI," meaning that the image itself (as opposed to the DICOM headers) contains PHI such as Patient Name, Patient ID, etc. You might find this information in an actual image or possibly scanned documents that are also part of the session.
If your filter is enabled, there are two ways you can configure your filter to operate:
|whitelist||only DICOM series with a series description that matches one of series filter patterns will be considered.|
|blacklist||all DICOM series will be considered except for series that have one of the specified series filter patterns.|
The series filters can be written as exact string matches, but also can be regular expressions. The regular expressions are evaluated using the Java regular expression syntax. These expressions are case-insensitive, i.e. the string "SAG LOCALIZER" will also match "Sag Localizer". Each filter should be on its own line. For example, you might have a blacklist that looks like this:
^.*Sheet.*$ ^.*Scanned.*$ ^.*Report.*$ STUDY ACQUIRED OUTSIDE HOSPITAL
This panel controls whether to enable a project-specific list of accepted PET Tracers. When users upload PET Sessions using the Image Session Uploader, they can select a tracer from this list and that value will be stored as a session modifier.
If enabled, this list will overwrite the list of tracers that are set at the site-wide level. See: Site-wide Session Upload and Anonymization Settings
This controls whether data generated by PET-MR scanners are created as a single PET/MR imaging session, created as a single PET imaging session, or separated into PET and MR sessions. To change this simply select your desired option and click 'Save'. If no option is selected, it will default to the site-wide setting.
Site administrators can configure this preference at a site-wide level in the Admin UI. This control panel for your project will override the site-wide preference. See: Site-wide Session Upload and Anonymization Settings
When sessions are imported into XNAT, their scan types are defined in the original DICOM files. This can be useful, but it may also contain tiny variations that are no longer relevant to your project. Scan Type Mapping allows you to define rules for how XNAT should rename scan types after they have been uploaded. If this setting is enabled in the site-wide control panel and in your project, it enables the Scan Type Cleanup action in the project actions menu.