Siemens: dcm2niix should use 0019,1029 for slice timing if present

[jstorrs]

I have DICOM where the CSA groups have been purged, but the 0019,* private tags are preserved on DTI and EPI. dcm2niix is able to successfully find the DTI parameters for diffusion, but ignores slice timing for EPI.

My understanding is slice timings for the mosaic are stored in 0019,1029 MosaicRefAcqTimes

https://en.wikibooks.org/wiki/SPM/Slice_Timing#Siemens_scanners

[neurolabusc]

dcm2niix should leverage the Siemens private tag 0019,1029 ([the CSA header](siemens csa header)) to extract many features, including gradient directions and slice timing. You may want to look at the messages generated when dcm2niix converts your files to see if there are any issues (e.g. some Siemens EPI sequences generated scrambled slice times). Further, dcm2niix will only populate the BIDS SliceTImes tag for 4D data (e.g. not created for 3D acquisitions or EPI sequences where only a single volume is saved). If you have issues, perhaps you could send me an example (direct to me via Box or DropBox).

[neurolabusc]

Closing issue. dcm2niix should exploit 0019,1029. No examples where dcm2niix fails have been provided. Unable to replicate issue.

[jstorrs]

I think there is a bit of confusion. 0019,1029 is not the CSA blob. It's a float vector containing the slice time offsets for the mosaic. It duplicates the MosaicRefAcqTimes that's present in the CSA header. The CSA blobs are 0029,1010 and 0029,1020. Sample data showing that dcm2niix ignores 0019,1029 can be found here:

https://drive.google.com/open?id=15XRX69ywIK7WXlaMghzDll1hu7UUMEHI

The reason using 0019,1029 would help is that 0019,1029 is easy to audit for compliance with the "Retain Safe Private Option" of DICOM's Basic Application Level Confidentiality Options.

http://dicom.nema.org/medical/dicom/current/output/chtml/part15/sect_E.3.10.html

The CSA blobs themselves are very difficult to audit and it would be difficult to "Retain Safe Private Option" using 0029,1010 and 0029,1020. I do have a prototype that can rebuild minimized/stripped/audited CSA blobs that parse correctly under non-Siemens CSA blob parsers. This would allow passing whitelisted CSA variables for the "Retain Safe Private". However, the problem with the reverse-engineered CSA approach is that it's not at all clear what would happen if these images hit an actual Siemens device. It's not an option because I couldn't guarantee it won't cause unexpected behavior of clinical devices.

[neurolabusc]

I did add support for reading 0019,1029 to the developmental branch. I understand the desire to remove the complicated CSA header, in particular since once upon a time Siemens did not zero the arrays used, and therefore private information would leak into unused crevices of this CSA header. However, I do worry your approach will miss some important information. In particular, without the "SliceNormalVector", dcm2niix does not know image numbering for mosaics, and may assume the wrong order. I updated the code to assume the default F>H for axial mosaics, but the spatial order will be wrong if the user changed this to H>F (and I did not test coronal or sagittal ordering). Likewise, you can not determine the phase encoding polarity (used for TOPUP/Eddy), readout time, etc. Tags we rely on from the binary portion of the CSA header include:

SliceNormalVector
DiffusionGradientDirection
SliceMeasurementDuration
BandwidthPerPixelPhaseEncode
PhaseEncodingDirectionPositive

but dcm2niix also extracts a lot of data from the ASCII portion. In addition, future version of dcm2niix may extract additional information from these tags as they become useful (a recent example is the ability to extract post-label delay and other ASL parameters for FSL's BASIL).

Personally, we never share DICOMs, but we store them on a secure redundant system for auditing. It is much easier to ensure that the simpler BIDS/NIfTI files are de-identified.

Do you know of any private information (by your definition) that is stored in the CSA header? I had always assumed this was sequence information. If no private information is explicitly stored in the CSA header, and alternative approach would seem to be to just zero-fill the unused sections of the binary part of the CSA header (the bytes where data was leaked once upon a time).