Is there a DICOM equivalent of ReceiveCoilActiveElements?

1,105 views
Skip to first unread message

Chris Gorgolewski

unread,
Mar 30, 2018, 1:11:10 PM3/30/18
to bids-discussion, Jolinda, RORDEN, CHRIS, <xiangrui.li@gmail.com>, Michael Harms
Hi,
I'm trying to clean up the spec before 1.1 release and there is a new field proposed by Michael Harms called ReceiveCoilActiveElements (see below). We were uncertain if there is something similar already defined in the DICOM spec that we should use instead of coining a new term. Does anyone know of anything in DICOM related to this?

ReceiveCoilActiveElements
: Information describing the active/selected elements of the receiver coil. For Siemens, coil elements are typically activated in “blocks”, and Siemen’s calls this the “Coil String” in its private DICOM fields.  The “Coil String” specifying the activated blocks could go here (e.g,. “HEA;HEP” for the Siemens standard 32 ch coil when both blocks are activated).

Best,
Chris

RORDEN, CHRIS

unread,
Mar 30, 2018, 1:37:35 PM3/30/18
to Chris Gorgolewski, bids-discussion, Jolinda, <xiangrui.li@gmail.com>, Michael Harms
Not that I know of. While 0018,1250 includes the coil name it does not report the active elements, e.g. for GE you would get
  0018,1250 ReceiveCoilName 32Ch Head
If this is added to the spec, it might be worth specifying which private tag should be used, e.g. for GE I think this would be 0043,1080, which would look like this:
  0043,1080 CoilIDData A:0\P1:\MRIIWRPnWfRpDO6fWDbSZ5CCue4GysIA\f700000012881f0f\P2:0\P3:0\P4:0





Chris Rorden, PhD
Endowed Chair of Neuroimaging
Department of Psychology
University of South Carolina
Columbia, SC 29208, USA
phone +1 803 404 2573
email ror...@sc.edu
web www.mricro.com

Xiangrui Li

unread,
Mar 30, 2018, 1:45:17 PM3/30/18
to Chris Filo Gorgolewski, bids-di...@googlegroups.com, jol...@uoregon.edu, RORDEN, CHRIS, Harms, Michael
Hi Chris,
 
As Michael already stated, Siemens stores 'CoilString' in its CSA header. It is also stored in general (but private) tag:
(0051,100F), LO, CoilString
It is something like 'T:HEA;HEP'
 
GE seems to store receive coil in a public tag:
(0018,1250), SH, ReceiveCoilName
It can be something like '8HRBRAIN'
 
I found some coil related info for Philips in their private Stack SQ (2001,105F), but none of them seems meaningful coil name:
MRStackCBBCoil1: 0
MRStackCBBCoil2: 0
MRStackCoilConn: 'DEFAULT'
MRStackCoilFunction: 'R_A'
 
Let me know if you like me to dig into more. Thanks.
_____________

Xiangrui Li, Ph.D.

Center for Cognitive and Behavioral Brain Imaging

The Ohio State University

Harms, Michael

unread,
Mar 30, 2018, 2:42:19 PM3/30/18
to li.2327, Chris Filo Gorgolewski, bids-di...@googlegroups.com, jol...@uoregon.edu, RORDEN, CHRIS

 

Hi Xiangrui,

The proposed tag for ReceiveCoilActiveElements (which ‘dcm2niix’ is already including in its json’s) is intended to be distinct from (0018,1250), ReceiveCoilName (which Siemens chooses not to populate for some reason, although certainly worth including as well).

 

Rather ReceiveCoilActiveElements is intended to capture the actual coil elements that were used, in whatever format a particular vendor describes that particular info.

 

Cheers,

-MH

 

 

-- 

Michael Harms, Ph.D.

-----------------------------------------------------------

Associate Professor of Psychiatry

Washington University School of Medicine

Department of Psychiatry, Box 8134

660 South Euclid Ave.                        Tel: 314-747-6173

St. Louis, MO  63110                          Email: mha...@wustl.edu

 


The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

Chris Gorgolewski

unread,
Mar 30, 2018, 2:44:09 PM3/30/18
to Harms, Michael, li.2327, bids-di...@googlegroups.com, jol...@uoregon.edu, RORDEN, CHRIS
Maybe it's worth adding this clarification to the definition? Michael - could you propose the appropriate language?

Best,
Chris

Jolinda

unread,
Apr 3, 2018, 2:16:58 PM4/3/18
to Chris Gorgolewski, bids-discussion, RORDEN, CHRIS, xiang...@gmail.com, Michael Harms

Siemens uses the “CoilString” in their shadow header (CSASeriesHeaderInfo, usually in 0029, 1020), and also includes the same info in private tag (0051, 100f). I have some older (VA25) data that doesn’t use either, and it’s possible that they added the information to the shadow header before they added the private tag, but if tag 0051, 100f is present that’s probably easier to read than the shadow header. This lists the groups of coil elements that are selected: for example, when using the 32 channel head coil, you can use either the posterior elements, the anterior elements, or both, so you’ll see “HEA;HEP” here rather than a list of all 32 elements.

 

Technically, this value will be at (0051, XX0f), and there will be a matching (0051, 00XX) (“PrivateCreator”) with a value “SIEMENS MR HEADER”. Usually XX = 10, but If there’s other private data in the (0051, 10..) block Siemens will move on to another block and XX will equal something else. This is something to keep in mind whenever you read private DICOM tags.

 

The Enhanced MR format things DOES require this information, but the only major vendor to currently use the enhanced MR dicom format that I am aware of is Philips (Siemens can export spectroscopy files in enhanced mr dicom format but generally does not use it). There is a DICOM MR Receive Coil Functional Group Macro (0018, 9042) that is required in the “enhanced mr” dicom format (it’s inside 5200,9229, the  Shared Functional Groups Sequence). Within that macro, (0018, 9046) is “Multi-coil Configuration”, defined as  “A textual description of the configuration of multi-coil elements that was used in the current acquisition.” Unfortunately that element is conditional, not required, and Philips does not use it (at least in these older files I’m looking at, they may have changed). Siemens does use that element, which has the same value as 0051,100f. Philips uses the required “ReceiveCoilName”, (0018, 1250), but this doesn’t tell you what elements are used (for comparison, Siemens would have “Head_32” as the “ReceiveCoilName” and “HEA;HEP” as the “MultiCoilConfiguration”).  The Philips file I have open has “SENSE-Head-8” as the ReceiveCoilName, and “MULTICOIL” as the ReceiveCoilType. MULTICOILs are required to have a “Multi-Coil Definition Sequence”, which should clarify things, as it should list the name of every element in the coil (“MultiCoilElementName”) and whether or not the element is used (“MultiCoilElementUsed”). Siemens does list every single element in the 32 channel coil and whether it was used, but in this Philips file they only list a single “MultiCoilElementName” with a value of “SENSE”, whose “MultiCoilElementUsed” field is “YES”. I believe this is a mistake in interpreting the standard on the part of Philips, to be honest; in my reading the standard requires information on each of the 8 elements. It would be interesting to look at some more recent files to see if they’ve changed this (this is from 2006). I would guess that they are listing selectable groups of elements, and there’s only one group of selectable elements in this particular coil.

 

Jolinda

 

 

From: Chris Gorgolewski <krzysztof....@gmail.com>
Sent: Friday, March 30, 2018 10:11 AM
To: bids-discussion <bids-di...@googlegroups.com>; Jolinda <jol...@uoregon.edu>; RORDEN, CHRIS <ROR...@mailbox.sc.edu>; <xiang...@gmail.com> <xiang...@gmail.com>; Michael Harms <mha...@wustl.edu>
Subject: Is there a DICOM equivalent of ReceiveCoilActiveElements?

 

Hi,

David Clunie

unread,
Apr 6, 2018, 8:27:10 AM4/6/18
to bids-discussion
If you want to add new Attributes to DICOM for this sort of thing, you can propose it to DICOM WG 16, which handles MRI.

This does not mean vendors will implement it, of course, but at least it does mean that there will be a normative definition in the standard that you can refer to, as well as vendor input on what it "means" before standardizing it, and that folks who write tools for pulling out the private data and putting it in DICOM standard attributes can add it to their list.

A bit more "structure" rather than a vendor/implementation specific string would seem desirable, e.g., a list of separate values with standard delimiters perhaps, even if the element identifiers themselves cannot be standardized.

David

Harms, Michael

unread,
Apr 12, 2018, 2:16:16 PM4/12/18
to bids-di...@googlegroups.com, li.2327, jol...@uoregon.edu, RORDEN, CHRIS

 

I’ve proposed appropriate changes to the ReceiveCoilName and ReceiveCoilActiveElement entries in the current BIDS draft spec.

 

-- 

Michael Harms, Ph.D.

-----------------------------------------------------------

Associate Professor of Psychiatry

Washington University School of Medicine

Department of Psychiatry, Box 8134

660 South Euclid Ave.                        Tel: 314-747-6173

St. Louis, MO  63110                          Email: mha...@wustl.edu

 

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/CAAQzouObKcEssbc-x9pmFig7sjgDj3we_ecG4OGkmUv11Zm7Ew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Chris Gorgolewski

unread,
Apr 13, 2018, 8:07:55 PM4/13/18
to bids-discussion, li.2327, jol...@uoregon.edu, RORDEN, CHRIS
Thank you everyone for your feedback and you Michael for summarizing it in the new definitions.

Best,
Chris

--

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

 


The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/22487E4B-3428-4EED-A61F-BDB6EA0B1EB4%40wustl.edu.
Reply all
Reply to author
Forward
0 new messages