protocol parameters variations

[bpinsard]

Hi there!

I am working on a very preliminary small tool for continuous multi-site/multi-vendor protocol compliance check, and the spine-generic dataset came to my mind as one of the best for testing, as it features many repeated sites/vendors/models/head-coils and protocol variations for the same model (eg. ZoomIt/no-Zoomit) with a clear open versioned protocol.

While the parameters are overall very homogeneous, I am surprised to observe variations of metadata including MR parameters between sites with the same scanner model, receive-coil and software version (while accounting for zoom-like option).

If I am not mistaken, intra-model/version variations can be observed in fields such as ImageType (eg. with or without "NORM" or "DIS*" options), ReceiveCoilActiveElements, ReconMatrixPE, and some very slight variations are also observed on EchoTime and RepetitionTime.

Do these variations come from varying versions of the protocol? Is there an easy way to get the exact version and the protocol variant (eg ZoomIt/no-Zoomit) used for each subject. Ideally, this could be included in the participants.tsv table. If these are "random" changes forced when importing the protocol into a specific scanner, maybe this should be documented too?

I also noted that pavia subjects are acquired on an unpublished "syngo_MR_D13C" protocol, was this adapted by loading another procotol? Maybe this should be documented.

Thanks!

[jcohenadad]

Do these variations come from varying versions of the protocol?

Good question. It is possible and could easily be verified (someone needs to invest 15min to look at previous versions and see if the old parameters match with some sites). However, I think a more frequent cause for this variation is coming from sites which did not use the EXAR, for multiple possible reasons:

• they don't know how to do it (i've seen that)
• they know how to do it but they prefer to create the protocol based on the PDF because they are more used to it (i've seen that)
• they had an error, eg: Syngo patch that created an incompatibility, resulting in an error/warning, and they decided to drop the EXAR import and create the protocol based on the PDF instead of trying to figure out how to address these import issues (i've seen that)

And of course, creating the protocol by hand from the PDF is prone to human error.

[bpinsard]

Thanks @jcohenadad, that explains a lot.

Also in that topic the participants.tsv lists a single ReceiveCoilName per scanner, while there seems to exist within-scanner variations across subjects.

eg.

grep ReceiveCoil sub-*/dwi/sub-*_dwi.json
sub-cmrrb01/dwi/sub-cmrrb01_dwi.json:    "ReceiveCoilName": "Spine_32",
sub-cmrrb01/dwi/sub-cmrrb01_dwi.json:    "ReceiveCoilActiveElements": "HC7;NC1,2;SP1",
sub-cmrrb02/dwi/sub-cmrrb02_dwi.json:    "ReceiveCoilName": "HeadNeck_64",
sub-cmrrb02/dwi/sub-cmrrb02_dwi.json:    "ReceiveCoilActiveElements": "HC5-7;NC1,2;SP1",
sub-cmrrb03/dwi/sub-cmrrb03_dwi.json:    "ReceiveCoilName": "HeadNeck_64",
sub-cmrrb03/dwi/sub-cmrrb03_dwi.json:    "ReceiveCoilActiveElements": "HC7;NC1,2",
sub-cmrrb04/dwi/sub-cmrrb04_dwi.json:    "ReceiveCoilName": "HeadNeck_64",
sub-cmrrb04/dwi/sub-cmrrb04_dwi.json:    "ReceiveCoilActiveElements": "HC7;NC1,2",
sub-cmrrb05/dwi/sub-cmrrb05_dwi.json:    "ReceiveCoilName": "HeadNeck_64",
sub-cmrrb05/dwi/sub-cmrrb05_dwi.json:    "ReceiveCoilActiveElements": "HC7;NC1,2",
sub-cmrrb06/dwi/sub-cmrrb06_dwi.json:    "ReceiveCoilName": "HeadNeck_64",
sub-cmrrb06/dwi/sub-cmrrb06_dwi.json:    "ReceiveCoilActiveElements": "HC7;NC1,2",
sub-cmrrb07/dwi/sub-cmrrb07_dwi.json:    "ReceiveCoilName": "HeadNeck_64",
sub-cmrrb07/dwi/sub-cmrrb07_dwi.json:    "ReceiveCoilActiveElements": "HC5-7;NC1,2",

sub-pavia01/dwi/sub-pavia01_dwi.json:    "ReceiveCoilName": "HeadNeck_20",
sub-pavia01/dwi/sub-pavia01_dwi.json:    "ReceiveCoilActiveElements": "HE3,4;NE1,2",
sub-pavia02/dwi/sub-pavia02_dwi.json:    "ReceiveCoilName": "Spine_32",
sub-pavia02/dwi/sub-pavia02_dwi.json:    "ReceiveCoilActiveElements": "HE1-4;NE1,2;SP1,2",
sub-pavia03/dwi/sub-pavia03_dwi.json:    "ReceiveCoilName": "Spine_32",
sub-pavia03/dwi/sub-pavia03_dwi.json:    "ReceiveCoilActiveElements": "HE1-4;NE1,2;SP1,2",
sub-pavia04/dwi/sub-pavia04_dwi.json:    "ReceiveCoilName": "Spine_32",
sub-pavia04/dwi/sub-pavia04_dwi.json:    "ReceiveCoilActiveElements": "HE3,4;NE1,2;SP1",
sub-pavia05/dwi/sub-pavia05_dwi.json:    "ReceiveCoilName": "Spine_32",
sub-pavia05/dwi/sub-pavia05_dwi.json:    "ReceiveCoilActiveElements": "NE1,2;SP1",
sub-pavia06/dwi/sub-pavia06_dwi.json:    "ReceiveCoilName": "HeadNeck_20",
sub-pavia06/dwi/sub-pavia06_dwi.json:    "ReceiveCoilActiveElements": "HE3,4;NE1,2",

sub-tehranS01/dwi/sub-tehranS01_dwi.json:   "ReceiveCoilName": "HeadNeck_64",
sub-tehranS01/dwi/sub-tehranS01_dwi.json:   "ReceiveCoilActiveElements": "HC3-7;NC1,2",
sub-tehranS02/dwi/sub-tehranS02_dwi.json:   "ReceiveCoilName": "Spine_32",
sub-tehranS02/dwi/sub-tehranS02_dwi.json:   "ReceiveCoilActiveElements": "HC3-7;NC1,2;SP1",
sub-tehranS03/dwi/sub-tehranS03_dwi.json:   "ReceiveCoilName": "Spine_32",
sub-tehranS03/dwi/sub-tehranS03_dwi.json:   "ReceiveCoilActiveElements": "HC3-7;NC1,2;SP1",
sub-tehranS04/dwi/sub-tehranS04_dwi.json:    "ReceiveCoilName": "HeadNeck_64",
sub-tehranS04/dwi/sub-tehranS04_dwi.json:    "ReceiveCoilActiveElements": "HC3-7;NC1,2;SP1",
sub-tehranS05/dwi/sub-tehranS05_dwi.json:   "ReceiveCoilName": "HeadNeck_64",
sub-tehranS05/dwi/sub-tehranS05_dwi.json:   "ReceiveCoilActiveElements": "HC2-7;NC1,2;SP1",
sub-tehranS06/dwi/sub-tehranS06_dwi.json:   "ReceiveCoilName": "HeadNeck_64",
sub-tehranS06/dwi/sub-tehranS06_dwi.json:   "ReceiveCoilActiveElements": "HC7;NC1,2",

sub-tokyoSkyra01/dwi/sub-tokyoSkyra01_dwi.json: "ReceiveCoilName": "Spine_32",
sub-tokyoSkyra01/dwi/sub-tokyoSkyra01_dwi.json: "ReceiveCoilActiveElements": "NE1,2;SP1",
sub-tokyoSkyra02/dwi/sub-tokyoSkyra02_dwi.json: "ReceiveCoilName": "HeadNeck_20",
sub-tokyoSkyra02/dwi/sub-tokyoSkyra02_dwi.json: "ReceiveCoilActiveElements": "HE3,4;NE1,2",
sub-tokyoSkyra03/dwi/sub-tokyoSkyra03_dwi.json: "ReceiveCoilName": "HeadNeck_20",
sub-tokyoSkyra03/dwi/sub-tokyoSkyra03_dwi.json: "ReceiveCoilActiveElements": "HE3,4;NE1,2",
sub-tokyoSkyra04/dwi/sub-tokyoSkyra04_dwi.json: "ReceiveCoilName": "HeadNeck_20",
sub-tokyoSkyra04/dwi/sub-tokyoSkyra04_dwi.json: "ReceiveCoilActiveElements": "HE3,4;NE1,2",
sub-tokyoSkyra05/dwi/sub-tokyoSkyra05_dwi.json: "ReceiveCoilName": "HeadNeck_20",
sub-tokyoSkyra05/dwi/sub-tokyoSkyra05_dwi.json: "ReceiveCoilActiveElements": "HE3,4;NE1,2",
sub-tokyoSkyra06/dwi/sub-tokyoSkyra06_dwi.json: "ReceiveCoilName": "HeadNeck_20",
sub-tokyoSkyra06/dwi/sub-tokyoSkyra06_dwi.json: "ReceiveCoilActiveElements": "HE3,4;NE1,2",
sub-tokyoSkyra07/dwi/sub-tokyoSkyra07_dwi.json: "ReceiveCoilName": "HeadNeck_20",
sub-tokyoSkyra07/dwi/sub-tokyoSkyra07_dwi.json: "ReceiveCoilActiveElements": "HE3,4;NE1,2",

Regarding the variations in ReceiveCoilActiveElements for the same ReceiveCoil, is it possible that the scanner automatically (de-)activates coil-elements based on pre-scan measurements? However, other sites are very consistent.

[jcohenadad]

Regarding the variations in ReceiveCoilActiveElements for the same ReceiveCoil, is it possible that the scanner automatically (de-)activates coil-elements based on pre-scan measurements?

yes, the scanner automatically selects coils, not based on pre-scan measurements but on the physical location/coverage of the FOV (last line):

[bpinsard]

Thanks, that is a very helpful detail to better design the protocol compliance tool. Unfortunately, this parameter is not extracted by dcm2niix, but it is visible in the Siemens dicoms PhoenixMetaProtocol. I don't know if that function exists for other manufacturers.