questions > FrameOfReferenceUID
Showing 1-4 of 4 posts
Sep 11, 2018 02:09 PM | 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.
I've attempted a conversion of dicoms with that particular field wiped, and no problems seemed to occur.
Sep 11, 2018 04:09 PM | 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 04:09 PM | 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 05:09 PM | 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.
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.