Missing JSON headers after Siemens software upgrade to XA30

[josephmje]

Describe the bug

After the upgrade, some metadata in the JSON headers are missing:
DwellTime
SequenceName -> changed to PulseSequenceName in DICOM
BaseResolution
ConsistencyInfo
PhaseResolution
ReceiveCoilName
ScanningSequence
PhaseEncodingSteps
PulseSequenceDetails
InversionTime -> changed to InversionTimes in DICOM
RefLinesPE
VendorReportedEchoSpacing
DiffusionScheme
Interpolation2D

Version

Chris Rorden's dcm2niiX version v1.0.20210317 (JP2:OpenJPEG) (JP-LS:CharLS) GCC5.5.0 x86-64 (64-bit Linux) v1.0.20210317

I'm happy to share some data if that helps.

[neurolabusc]

Can you upload two complete JSON text files - one prior to the upgrade and one after the upgrade. Was the site upgraded from a V* generation (e.g. VE11) to an X* generation (e.g. XA30)? The X* generation does not have a CSA header which contains a lot of meta data.

[josephmje]

Thank you for looking into this @neurolabusc. Yes, the site was upgraded from VE11 to XA30.

I've uploaded a zip with JSON files for a few of the different sequences pre- and post-scanner upgrade.

XA30_upgrade.zip

[neurolabusc]

Wow, I have never seen data from a Prisma upgraded to XA30. Historically, the Siemens, Trio, Allegra, etc. were all V* systems (e.g. VB13, VB15...VE11), while the X* systems were both new hardware (Sola and Vida) as well as software. The X series moves from classic DICOM to a very lean enhanced DICOM. The original XA10 was perhaps too lean. But thanks to a good dialog with the Siemens engineers, the recent releases seem to have a nice balance of having the information we need without much extraneous information.

I have not seen an XA30 system, but with earlier X* systems the crucial thing was to never save data as mosaics. With the V* series, datasets would be much smaller and saved faster if the EPI images are saved as mosaics (where all 2D slices of a volume are saved as a single file). Hopefully, with XA30 they removed the feature to save as mosaics, but with earlier releases the mosaics were not saved with required meta data.

As I noted previously, the X* images no longer contain the proprietary CSA header. The benefit is that the required meta data is all reported in common DICOM tags. However, as you found the X* is much less verbose in reporting meta data.

While I tried to work carefully with the manufacturer to ensure that we extract the required information, I do think you should be vigilant. You are on the bleeding edge of this transition. There are clear benefits to enhanced DICOM, but there may be some unintended consequences. So be alert as you process the images from this system, and contact me if you have any specific issues. I should note that I have never seen any ASL data from a X* scanner, so be particularly vigilant if you have an ASL license. Since we have a Prisma at my site, I am very invested in helping.

[josephmje]

Thank you for the detailed response!

For my use case, it would be important to at least be able to get the DwellTime, RefLinesPE and VendorReportedEchoSpacing as those are important for pre-processing diffusion MRI data. But perhaps these can also be obtained from the exam card.

I should note that I have never seen any ASL data from a X* scanner, so be particularly vigilant if you have an ASL license.

I don't think we're collecting any ASL data on this scanner but that's a good thing to double check!

Since we have a Prisma at my site, I am very invested in helping.

We did a few phantom scans after the software upgrade. I would be able to send over that data if it helps.

[neurolabusc]

Why don't you work with your Siemens Research Collaboration Manager to see if the values you are interested in can be derived from the XA data. If so, feel free to send me a sample dataset with known values and the formula used (e.g. which DICOM tags are required).

The TotalReadoutTime, EchoSpacing, DwellTime is a little confusing as FSL (and subsequently BIDS) use a very unintuitive definition for TotalReadoutTime. You may also want to look in the comments in the dcm2niix code for deriving required details fro Siemens X*. I think ultimately someone needs to replicate @mharms TotalReadoutTime work for V*. I suspect a Siemens RCM has the inside knowledge to help with this, analogous to the way that GE engineers were able to supply the TotalReadoutTIme formula that includes the unintuitive Round_factor parameter.

[josephmje]

Will do! Thank you for linking all of these resources.