Community Review: BEP042 - Electromyography (EMG)

[effigies]

We are pleased to announce the community review period for BIDS Extension Proposal (BEP) 042!

BEP042 extends the BIDS standard to include electromyography recordings.

The draft specification may be found at: https://bids-specification--1998.org.readthedocs.build/en/1998/, and the eye-tracking specification may be found in the Electromyography section.

The proposed changes may be found at #1998. To view the source difference, click the Files changed tab.

Example datasets may be found at:

• emg_CustomBipolar
• emg_CustomBipolarFace
• emg_IndependentMod
• emg_MultiBodyParts
• emg_TwoHDsEMG
• emg_TwoWristbands
• emg_concurrentIndependentUnits

Procedure

Review period

Community review is open from September 29 - October 10, 2025.

Voting

This discussion is a poll, which you can vote in once and cannot change your response. Therefore, please vote once you are satisfied that your answer will not change.

If you vote "No", you may create a thread to explain your reasoning or send a private email to bids.maintenance [at] gmail.com so that your position can be fully understood.

How to review

Use threads in this discussion to request clarification or changes to the BEP. Each independent topic or proposed change should have its own thread. Please review existing threads and consider adding comments to those, if your topics are already being discussed. If your concerns are adequately represented by an existing comment or comments, consider using the 👍🏻 reaction button to indicate agreement in place of extending the discussion.

Where possible, propose the specific text you would like to see added or removed.

For minor issues, such as typos, feel free to make code suggestions only, using the suggest feature on the BEP042 pull request. These suggestions may be accepted or rejected without discussion, so do not make substantial proposals in this way.

Finalization

Once the review period is finished, the BEP leads and maintainers will consider the entire discussion, identify outstanding points to be resolved, and work toward finalizing the BEP. Community members may be asked to participate in this process to provide the necessary expertise.

Before being merged, the BEP will be integrated into the BIDS validator, and the examples must pass the validator.

This is the first of three review periods scheduled for this fall. A BIDS 1.11.0 release is anticipated in December 2025/January 2026 if any BEPs are merged during these periods, regardless of the conclusion of this specific BEP.

If, for any reason, a critical issue is found after the BEP is merged, the BEP will be reverted while the issues are addressed. At the discretion of the BIDS steering group and maintainers group, depending on the scope of changes, a new community review period may be opened.

[sjeung]

Hi, I have a comment about the following part in "Describing Sensor Locations" section.

"placement information is given either in the EMGPlacementSchemeDescription field of *_emg.json (when the placement approach is the same for all sensors), or in the placement_description column of *_channels.tsv (when the placement approach varied across sensors)."

I think it's good that the spec considers the case where different channels have different locations but having this information saved in either of the two separate files may be error-prone. What do you think of having a reserved keyword like "mixed" in the emg.json in the latter case, or saving the information in channels.tsv in both cases so that the information is consistently found in the same place?

[neuromechanist]

Thanks very much for your comment. *_emg.json has a REQUIRED EMGPlacementScheme, with specific levels: ChannelSpecific, Measured, and Other. Does the ChannelSpecific key satisfy your concern? I believe only when Other key is mentioned, the EMGPlacementSchemeDescription key is needed.

[klotz-t]

Hi,

We have attempted to BIDSify a few EMG datasets while adhering to the CEDE guidelines (i.e., a series of consensus papers from the International Society of Electromyography and Kinesiology; see, for example, https://www.sciencedirect.com/science/article/pii/S1050641122000992). Two items recommended for reporting in the CEDE guidelines but missing within the BIDS specification are (i) pre-amplification and (ii) gain.

Furthermore, I recall that earlier versions of the BIDS-EMG examples included EMGElectrodeGroups, which enabled specifying properties such as "InterelectrodeDistance" or "ElectrodeMaterial" for heterogeneous EMG sensors / grids. Is that still the intended way of reporting such metadata, or where should the details on multiple, potentially heterogeneous electrodes be reported?

[neuromechanist]

Thanks very much for your comment.

pre-amplification and gain

One thing that is not mentioned is the possibility to add arbitrary columns to _emg.json as well. But, both of these instrument-bound parameters can be easily added to recognized fields.

Channel- or Electrode specific ElectrodeMaterial, InterElectrodeDistance

Yes, there are edge cases where heterogenous recordings are available in the same datafile. (Please note that we recommend NOT to combine multiple data files, such as from different instruments, and rather using the _recording- entity). As a result there is a material column under electrodes.tsv and a interelectrode_distance under channels.tsv (as inter-electrode distance is not "one" electrode's feature, but rather a system/channel feature) as it also happens that with custom electrode placements, the inter electrode distance would be different for each channel.

We should probably add cross reference mentions in both places (for example, mentioning under ElectrodeMaterial that it can be also mentioned per electrode in electrodes.tsv)

[klotz-t]

Thank you for your detailed response. Indeed, the current EMG-BIDS specification already mentions that such information can be reported in the electrodes.tsv file. So this makes perfect sense, with the downside that when using array electrodes, information such as "ElectrodeManufactureModelName" (etc.) needs to be repeated multiple times, and, hence, each electrode.tsv file will contain a lot of redundant metadata.

I would not consider a case with two types of electrode arrays too "edgy". E.g. simply recording from an agonist-antagonist pair of muscles can require such a choice due to the diversity of muscle shapes. Anyhow, I guess the overhead is manageable.

[JuliusWelzel]

Hi team,

thank you for working on extending BIDS for electromyography data! I've reviewed this proposal in comparison with the existing motion BIDS specification, and I have a few suggestions to ensure consistency:

Channel Types and Descriptions

• It would be helpful to verify that all channel type descriptions use consistent language and detail across both specifications.
• I noticed that the latency description differs between this EMG extension and the motion specification. It would be beneficial to harmonize these descriptions for consistency.

Synchronization with Other Modalities

I suggest adding a paragraph similar to the motion spec regarding synchronization, perhaps something like:

"When EMG recordings are used alongside other BIDS modalities (such as EEG or motion) and recordings should be interpreted together, it is advised to define how recordings are synchronized. The RECOMMENDED way to do so is to use the acquisition time of the first data point of recordings and to store this information in the acq_time column of the *_scans.tsv file. Note that the BIDS date time format allows optional fractional seconds, which SHOULD be used to maximize the precision of the synchronization. Only if the precision of the synchronization is not high enough, the *_events.tsv file SHOULD be used to synchronize recordings. In this case, the start- and stop time of the EMG recording are specified in relation to the system to synchronize with. For multi-modal setups involving EMG with motion capture and other modalities, it is up to the user to identify the 'main' system for synchronization purposes."

Additional Suggestions

• Consider adding examples showing EMG data alongside other modalities (especially eeg or motion). I have to admit this is currently missing for motion :D

[TheHandLab]

Hi BEP042 team,

this is really impressive, very clear and logical, and i really don't have any comments - I am not sufficiently BIDS-ified myself to spot any problems here, not even any typos ;-)

I work in the TMS field, and EMG methods over here are often under-specified, sometimes only the muscle name is given. It would be great if TMS-EMG folk come to use BEP042 - I will certainly try to make that happen. There is a BEP037 proposal for brain stimulation methods underway (NIBS-BIDS) - many of these users record EMG as dependent variables.

My only question: my understanding is that the _events.tsv and _events.json files will contain stimulation events - these could be (relatively) discrete events like an electrical pulse, or the onsets of sounds or lights etc - would we also put electrical or magnetic nerve / brain stimulation parameters in there, or in the separate electricalstimulation object used in iEEG? Stimulation of peripheral nerves (and brain/spine) raises very similar problems to recording from the muscles - placement, montage, etc. I wonder if this will need more specification in future (perhaps under the NIBS BEP037)?

https://bids-specification--1998.org.readthedocs.build/en/1998/glossary.html#electricalstimulation-metadata

thanks again!
Nick

[drammock]

thanks for the review! To answer your question: the sidecar *_emg.json MAY contain any additional fields that the researcher believes to be relevant for full dataset description or reproducibility. So in the case of an EMG recording that included electrical stimulation, option 1 would be to add fields ElectricalStimulation and ElectricalStimulationParameters to the *_emg.json file, even though those fields are not expressly mentioned in the EMG spec. As with EEG or iEEG, the actual onset times of the electrical stimulation would go in *_events.tsv.

Alternatively, option 2 is that you could omit the extra fields from *_emg.json and add extra columns to *_events.tsv for describing the electrical/magnetic stimulation parameters (strength, shape, location, etc) --- as long as you added corresponding descriptions in *_events.json to describe each column that you add.

Option 3 would be for us to incorporate the ElectricalStimulation and ElectricalStimulationParameters fields in the EMG spec; for a dataset creator the steps taken would be equivalent to option 1. I think it's worth a bit of discussion whether that makes sense to do now, or whether we should wait for a fuller picture to emerge through the discussions around BEP037.

Stimulation of peripheral nerves (and brain/spine) raises very similar problems to recording from the muscles - placement, montage, etc. I wonder if this will need more specification in future (perhaps under the NIBS BEP037)

I would hope that the expansion in this BEP of how coordinate systems can be defined could be straightforwardly applied to stimulation electrodes/probes too. If so, then assuming that stimulation probes are in an *_electrodes.tsv or similar file, then location could be given with x,y(,z) and coordinate_system columns, and coordinate system details could be specified in the JSON file(s) as in this BEP.

[effigies]

Thank you all for your thoughtful reviews. We will be rereading carefully over the next few weeks to be sure that all concerns are addressed. If necessary, we will reach out to individual reviewers for further discussion.