BIDS-BodyPart extracted from BEP025

[jomasator2]

Your idea

To whom it may concern,
I am Jose Manuel Saborit. Responsible for BEP025. I wanted to inform you that I am currently working on the simplification of BEP025 to include it in other more simplified BEPs. Currently, I have a document ready to upload that would correspond to add the tag body parts to BIDS. This document not only determines that a tag has to be added but also specifies various aspects of when it is possible to use it, what rules have to be followed and whether this change affects the associated metadata.

I would therefore like to include a new BEP for this feature to be extended to other parts of the body.

I remain at your disposal for any consultation and confirmation in order to upload this BEP. Best regards.

[sappelhoff]

cc @VisLab for the potential HED ontology/vocabulary of body parts

[Remi-Gau]

For those who may not know: there is already some body part metadata in the spec.

https://bids-specification.readthedocs.io/en/stable/glossary.html#bodypart-metadata

[sappelhoff]

is this issue perhaps also a duplicate of:

• New BEP extracted from BEP025 ("MIDS") #1275

@jomasator2?

[jomasator2]

Jomasator2 is my new account, I lost the previous one and I couldn't recover my old account. That's why I'm doing a new issue.

[VisLab]

We will definitely want to add metadata tags for this to HED. In reading the glossary, I am not sure what tags would be good and how much BIDS will be checking when, for example it suggests using NCBITaxonomy (for species) or a specific ontology.

Any advice on tag names and properties we should specify would be appreciated as would suggestions about other tags that are needed as these new BEPs are coming in.

We are in the process of adding metadata tags to accommodate some of the additions to the participants.tsv file.
See HED issue #109.

[jomasator2]

Hello @VisLab , regarding which tags we define this "BodyPart" where we advise using some standard like UMLS snomed-ct, the document dicom PS3.16 - L DICOM Content Mapping Resource, Correspondence of Anatomic Region Codes and Body Part Examined Defined Terms, OMOP,... The idea is to use the coding defined in the above standards or use the descriptive name of the standards. For example, use the code in snomed-tc "39607008" or use the keyword "lung".

If you want to add this information in participants.tsv I would add it as a list of anatomical parts in keyword format and give it the meaning of what anatomical parts are present in each subject. Always with an informative character to have an initial discretisation. The reason why I put it this way is because a study can have different anatomical parts. In the new BEP, I support the storage of this data in the "_scans.tsv" since it is data that is integrally related to the image.

I don't know if this information can help in accommodating the "BodyPart" tag in "participants.tsv".

Any suggestions are welcome.

[VisLab]

To clarify, we aren't trying to accommodate BodyPart in participants.tsv in particular. It is up to the user in which files .tsv to place HED columns.

From the validation point of view, it is a matter of feeding the .tsv and their associated .json to the HED validator... they are all validated in the same way. We do need to figure out what HED tags should be used to encode whatever is being standardly being placed in the columns of these .tsv files.

We would appreciate links to example datasets of how the information you mentioned is being incorporated in a BIDS dataset.
@dorahermes @tpatpa could you comment -- the body part issue came up with SCORE as well.

[sappelhoff]

transferring @tsalo's comment from the closed duplicate issue:

• New BEP extracted from BEP025 ("MIDS") #1275 (comment)

Just to clarify, this issue is related to one proposed new entity, like bodypart-? If so, I don't think that necessitates an entirely new BEP. We've added entities outside of BEPs in the past.

From a schema perspective, adding a new entity to indicate the body part is pretty easy. Tooling would be affected, but it would be a lot like part, where, if the entity is missing entirely, we assume the data are magnitude values, so most tools need to look for part-mag or no part at all when selecting files.

The main question, I guess, would be whether this falls within BIDS's scope. To gauge that, this issue will need input from the community, I think.

[jomasator2]

transferring @tsalo's comment from the closed duplicate issue:

• New BEP extracted from BEP025 ("MIDS") #1275 (comment)

Just to clarify, this issue is related to one proposed new entity, like bodypart-? If so, I don't think that necessitates an entirely new BEP. We've added entities outside of BEPs in the past.
From a schema perspective, adding a new entity to indicate the body part is pretty easy. Tooling would be affected, but it would be a lot like part, where, if the entity is missing entirely, we assume the data are magnitude values, so most tools need to look for part-mag or no part at all when selecting files.
The main question, I guess, would be whether this falls within BIDS's scope. To gauge that, this issue will need input from the community, I think.

In my opinion, it's not just adding a tag right now. In the BEP I have added another tag related to bodyPart which is Laterality and rules or tips to correctly apply these tags. I would like this to be discussed with the community through the BEP to improve or correct this new addition. Also as I said before. It also affects the scans.tsv file where up to 5 optional fields can be added with respect to BodyPart and are described in the document.

[mariamonzon]

How is the status of the BEP? I would be very interested to know if the body part could be somehow extracted to further select data. I think having the metadata would be useful but it would be nice to have the standarized codes for the body parts.

[Remi-Gau]

@mariamonzon @VisLab @jomasator2

Please have a look at this pull request because it does relate to this issue.

#1593

[jomasator2]

@Remi-Gau @VisLab @mariamonzon
Thanks for showing me the reference to the issue #1569 related to the BEP31. Nonetheless, we discussed with clinical researchers the best way to proceed with the files nomenclature in order to facilitate their identification and we agreed about another way to proceed. I would like to illustrate it with some examples.
According to your proposal (if I correctly understood it), the nomenclature scheme would be as follows:

anat/
    sub-xxxxx_ses-yyyyy_chunk-1_T2w.nii.gz
    sub-xxxxx_ses-yyyyy_chunk-1_T2w.json
    sub-xxxxx_ses-yyyyy_chunk-2_T2w.nii.gz
    sub-xxxxx_ses-yyyyy_chunk-2_T2w.json

Referring chunk-1 to head image and chunk-2 to lumbar image. However, we used the chunk entity when multiple nifti images are generated in the same scan (e.g. axial spinal column images transformed that generate one separated nifti file for each vertebra view but just one json file containing metadata). Therefore, we suggest to keep the chunk entity for this type of medical imaging, and generate two new entities that improve the readability by researchers:

• bp-<bodyPart>
• lat-<Laterality>

For example:

anat/
    sub-xxxxx_ses-yyyyy_bp-knee_lat-L_T2w.nii.gz
    sub-xxxxx_ses-yyyyy_bp-knee_lat-L_T2w.json
    sub-xxxxx_ses-yyyyy_bp-knee_lat-R_T2w.nii.gz
    sub-xxxxx_ses-yyyyy_bp-knee_lat-R_T2w.json

So I hope that this can be considered as bep's proposal.

[Remi-Gau]

need to think more about the rest but if anything I would use the hemi entity that already exists for hemisphere that already accounts for L and R

[dorahermes]

This seems an important discussion. If the fields proposed for body parts are standardized (per the note on DICOM above - PS3.16, it should be specified how these values should be used in BIDS. For example, if a bodypart tag from this DICOM document is used, it needs to be clear whether the code or description should be used and to what extend the BodyPart/BodyPartDetails/BodyPartDetailsOntology + hemi works to describe the body part sufficiently. @jomasator2 it would be great to see some examples of where it would work or not work.

For the HED-SCORE locations, the clinical epilepsy field standardized how a 'somatotopic identified' (body part) can be used to describe the seizure semiology (see SCORE 2017 paper). It therefore has quite specific descriptions that are not necessarily itended to match what researchers in different settings would use.

[jomasator2]

@Remi-Gau I understand that your proposal is to use the entity hemi to describe laterality. I think this entity corresponds to a very specific part related to brain imaging and for another part of the body it could be confusing. From my point of view, my idea is not to modify BIDS with what is already there, but to expand it. I don't see a problem in using hemi for brain and lat for another part of the body.

@dorahermes I can share the BEP document I am working on where there are examples of tabular information and example usage for each modality accepted in BIDS. Here is the link

[Remi-Gau]

• Regarding body part see this message [ENH] Add sample metadata to MRI and PET #1593 (comment)

We already have metadata fields to describe the body part from where some data was recoreded but AFAICT we make no restriction on which ontology to use.

This does not cover the use of BodyPart in event tags.

I am not enthused by the idea of creating a new entity to mention the body part in the filename, given that this information could be available in the JSON sidecar with the metadata mentioned above (if only because having the same info in the metadata and the filename leads to redundancy that needs to be validated).

If a user wants to add what body part was acquired, I think I would default for using the acq entity.

anat/
    sub-xxxxx_ses-yyyyy_acq-knee_T2w.nii.gz
    sub-xxxxx_ses-yyyyy_acq-knee_T2w.json

[Remi-Gau]

I think this entity corresponds to a very specific part related to brain imaging and for another part of the body it could be confusing. From my point of view, my idea is not to modify BIDS with what is already there, but to expand it. I don't see a problem in using hemi for brain and lat for another part of the body.

Well the problem is the explosion of number of entities that we can have in BIDS, especially when we already have one entity that describe the side of the body (originally hemi'sphere' for the brain, but could be hemi'field' to be made more generic) then adding another entity to mean almost the same thing feels redundant.