Add new entity: "coil" ?

[SiyaMRPhy]

Hi BIDS,

It would be great if BIDS could add an optional -coil to the entity table. Example - subject scanned in the Parallel transmit coil and Single transmit coil or other coils for the same session. The coil is the same for most of the studies. However, some studies use different coils. The coil info is in the JSON. However, it's better to have the '-coil' option in the main name to distinguish the image.

Best

Siya

[TheChymera]

As I understand it, the main concern here is convenience for accessing these values (always more tricky to extract from and inspect in JSON). For that purpose, the best (and fastest) solution is to agglutinate this with the acq- entity. Note that this does not require (nor will it generally imply) transforming the acq- value into a list, since it is highly unlikely you would be running the same acquisition on different coils. Generally the purpose of switching coils (other than having to work with multiple coils of the same type due to lack of reliability) is precisely to enable different variations of acquisition.

Additionally, the coil — as seen in the examples you provided — is described by a set of parameters. Unlike, for instance, contrast agents, there is far less standardization, so while ce-endorem might provide more immediately meaningful information about the dataset, coil-TRfirstonewebuilt might be comparatively meaningless. So if the coil parameters vary and this is established as a meaningful source of variation, the coil information would need to be documented more extensively in the JSON in any case. Here again, coil- turns out to be a very symbolic (“custom” as per our current nomenclature) entity, similar to acq-. I think there is something to be said for trying to minimize symbolic entities or encourage agglutination wherever possible — which might not always be the case, but I would say it is here.

[SiyaMRPhy]

For this study, i am using -acq for the test and retest in the same session. In addition, i am performing the same in a different coil. PTx coils are different from STx coils. We might use a parallel transmit pulse (example, Universal pulse) for the PTx coil in future. I think that coils (-coil) are not symbolic. Typical studies use the same coil. But, it's not true. Its important to have a coil (-coil) option in BIDS since the number of sites using pTx coils are increasing (especially at high field)

[effigies]

Just a note that there is already a coil- proposal #425 that uses it differently.

[SiyaMRPhy]

@effigies Thank you for posting the link to the coil proposal. Proposal 425 discuss the receive channels in the coil. I am adding the transmitter channels in addition to the receiver channels. For end-user studies, the coil remains constant. In that case, one doesn't need to use -coil. However, it's not the case for sequence testing. It's better to have an option for -coil.

[tsalo]

For end-user studies, the coil remains constant. In that case, one doesn't need to use -coil. However, it's not the case for sequence testing. It's better to have an option for -coil.

@SherS2 could you expand on this? I don't know what you mean by "the coil remains constant", nor which proposal you're referring to when you say "better to have an option for -coil", given that both proposals use the term coil.

[SiyaMRPhy]

@tsalo Eg: for fMRI studies, users won't change the coil once the sequence is optimized for the study. The study population is scanned with the same coil. In this case, there is no need to mention the coil in the 'entity'.

Example for using -coil When same subjects are scanned with different coils

1. for MR physics, we are testing single transit coil (sTx) and parallel transmit (pTx). We would like clearly label the coil.
2. Also, there are coils with a various number of receiver channels (20, 32 and 64 channels). If a study is using different coils with different receivers, then it's better to label it in the entity.

[TheChymera]

For this study, i am using -acq for the test and retest in the same session.

If the only difference is re-testing, this sounds like a job for run-. From the documentation “If several data acquisitions (for example, MRI scans or EEG recordings) with the same acquisition parameters are acquired in the same session, they MUST be indexed with [...] run-<index>”.

In any case, I would recommend leveraging acq- to capture the coil parameter, at least for the time being.

[SiyaMRPhy]

@TheChymera ye, the run could handle test-retest. Using the acq- for coil type is a temporary solution. But, it is not ideal. By definition: The acq- key/value pair corresponds to a custom label the user MAY use to distinguish a different set of parameters used for acquiring the same modality. Coil is not a parameter is an "MRI hardware component."

It's better to have a -coil entity for addressing the hardware component. For the time being, I created a -coil entity to handle the coil. 1Tx and 8Tx for single and parallel transmit coils, respectively. I will use it until BIDS finds a permanent solution. Ideally, this could be expanded if someone is using different receiver coils 1Tx32Rx, 8Tx64Rx, etc.