questions > FrameOfReferenceUID
Showing 1-4 of 4 posts
Display:
Results per page:
Sep 11, 2018  07:09 AM | Aidan Murphy - University of Florida
FrameOfReferenceUID
I'm in the process of anonymizing our dicom metadata, and The Powers That Be have determined that the date of an MRI scan is a HIPAA identifier. Our Siemens dicoms have a field "FrameOfReferenceUID" which I understand can be useful in determining the spatial relationship of images. Unfortunately, the field contains the procedure date and time embedded within the string (e.g. '1.3.12.2.1107.5.2.30.27854.1.YYYMMDDHHMMSS000.0.0.0'). I was wondering whether this field is used in the dicom to nifti conversion process? And if so, would any harm come of selectively zeroing out the bolded portion of the field?

I've attempted a conversion of dicoms with that particular field wiped, and no problems seemed to occur.
Sep 11, 2018  09:09 AM | Chris Rorden
RE: FrameOfReferenceUID
dcm2niix does not use the Frame of Reference UID (0020,0052). Anonymizing DICOM images is a delicate step - you want to be careful to preserve CSA data for Siemens. Also, in my experience many anonymizers can completely destroy Philips enhanced DICOM data (the enhanced version is very different from the classic version). Choose your tool wisely - one option is gdcmanon which has the option to use encryption to provide reversible DICOM anonymization. The other option would be to store all the raw DICOM data in an encrypted form and using methods that satisfy your IRB and only share anonymized NIfTI/BIDS data. The NIfTI format is much simpler and therefore easier to ensure that no private data has been leaked.
Sep 14, 2018  09:09 AM | Aidan Murphy - University of Florida
RE: FrameOfReferenceUID
Thanks very much for the suggestion. I checked several nifti headers and they don't seem to carry nearly as much information as the dicoms.
Sep 14, 2018  10:09 AM | Chris Rorden
RE: FrameOfReferenceUID
NIfTI and DICOM fill different niches. The NIfTI format is simple and explicit. This is ideal for science as it is easy to write software that supports this format, and they are fast to read and analyze. In contrast, DICOM is interpreted differently by different vendors, many unusual conventions are used, and personal data can be hidden into many of the crevices. I think that DICOM is ideal for archival work, but must be stored carefully. Even a thorough DICOM de-anonymization system will fail if the software that created the tags has an issue like buffer overflow (which has been seen in data from the major vendors). Further, many anonymization tools created for classic DICOM simply destroy the meta-data in enahnced DICOM. To create truly archival quality anonymized DICOM is a tremendous challenge, in particular if your IRB feels that facial features seen on T1 scans is identifiable data. 

The BIDS standard lies adds a lot of details useful for MRI processing to the NIfTI images. So a happy compromise might be to keep a private encrypted DICOM archive and share a NIfTI/BIDS dataset that has gone through a face-stripping step.