BEP: Transcranial Magnetic Stimulation (TMS)

[olegshevts]

This BIDS Extension Proposal (BEP) introduces support for organizing and describing data from Transcranial Magnetic Stimulation (TMS) experiments. TMS is a non-invasive brain stimulation technique widely used in cognitive neuroscience and clinical research.

The proposed extension includes:

• A new datatype: tms
• Three suffixes: _tms, _markers, and _coordsystem
• Metadata fields covering stimulation parameters (e.g., coil, waveform, amplitude, timing), targeting coordinates, electric field estimations, and device-specific configuration
• JSON and TSV file formats with clear validation rules
• Full integration with the BIDS schema system (objects, sidecars, tabular data)

This BEP is designed to be compatible with both offline and online neuronavigation systems and supports integration with other modalities such as MRI and EEG. Examples of real datasets are provided.

Link to the proposal repository: https://github.com/InstCognNeuro/bids-tms-extension

[robertoostenveld]

For reference, @GiacomoBert who is the lead on BEP037 (non-invasive brain stimulation) and others from BEP037 are in contact with Oleg. We will meet online on Teams this Thursday 11th at 8am Boston time and 3 pm Moscow time to discuss.

[robertoostenveld]

I suggest looking into the discussion at #2108.

[olegshevts]

Dear all,

Thank you for initiating and continuing such an important discussion in this thread. We have carefully reviewed the considerations raised into the discussion at #2108 and would like to offer our perspective in the context of our ongoing work on a dedicated BEP for Transcranial Magnetic Stimulation (TMS). We agree with many of the points raised — particularly those emphasizing the need for clarity, consistency, and a principled decision-making framework when it comes to defining new datatypes and modalities in BIDS. Below, we summarize our position and how it aligns with the larger goals discussed here.

Motivation for a dedicated tms/ data type

1. TMS is a standalone biophysical method.

TMS is widely used in both basic and clinical neuroscience as an independent experimental technique, not just as an auxiliary to EEG, fMRI, or behavior. It has a rich technical landscape, extensive literature, dedicated symposia, and communities of researchers and clinicians. Structurally, it cannot be adequately modeled as a suffix, channel, or metadata-only entity within another data type.

2. Technical complexity requires architectural separation

TMS sessions generate data that require:

• High-dimensional metadata (e.g., coil parameters, train/burst structures, E-field distributions, RMT/AMT intensities)

• Spatial localization (coil position/orientation, marker normal vectors)

• Time-domain stimulus information (e.g., inter-train, inter-pulse intervals)

• Custom coordinate systems and navigation files

These elements do not fit cleanly into any existing datatype such as eeg, beh, or physio.

3. Avoiding data type congestion

As noted by several contributors above, embedding distinct modalities into existing data types often leads to semantic overload and organizational inconsistency. Attempting to embed TMS within another data type would introduce non-intuitive data structures and break expectations of file discovery and structure.

4. Preserving data coherence

TMS data must be recorded, interpreted, and validated as a coherent unit. For example, stimulation coordinates, marker orientation, and electric field estimation are tightly interdependent. This argues in favor of grouping these files under a dedicated tms/ folder rather than distributing them across modalities.

5. Improved usability and discoverability

One of the core strengths of BIDS is that data from a given modality can be easily located and understood by tools and researchers. Adding TMS as a first-class datatype continues this principle, rather than introducing ambiguity about where to store and find TMS-related information.

6. Consistency with BIDS precedent

As has been done with meg/, eeg/, ieeg/, pet/, and motion/, we believe TMS meets the same threshold of complexity and independence. Assigning it a dedicated folder is consistent with these precedents and strengthens the BIDS architecture.

7. Risk of fragmentation within umbrella BEPs

While we appreciate the desire to unify all non-invasive brain stimulation (NIBS) methods under a single proposal (e.g., BEP037), we believe that collapsing very distinct methods under a shared structure risks reducing clarity and reusability. Instead of cohesion, such unification may introduce internal fragmentation. A separate, well-structured TMS extension may serve both the community and the BIDS standard more effectively.

We fully support the idea of developing clear criteria and guidelines for future BEPs, as discussed here. In the meantime, we hope that our BEP-TMS can contribute to this broader reflection by offering a concrete, well-scoped architecture for a technically and scientifically mature method.

Thank you again for your attention and commitment to keeping BIDS coherent, extensible, and community-driven.

Best regards,
Oleg Shevtsov
on behalf of the BEP-TMS authors

[GiacomoBert]

1. TMS is a standalone biophysical method.
   TMS is widely used in both basic and clinical neuroscience as an independent experimental technique, not just as an auxiliary to EEG, fMRI, or behavior. It has a rich technical landscape, extensive literature, dedicated symposia, and communities of researchers and clinicians. Structurally, it cannot be adequately modeled as a suffix, channel, or metadata-only entity within another data type.

I understand the argument, but fMRI and DWI are also standalone biophysical methods, and yet they are not given separate BIDS modalities for each variant. The question is not whether TMS is “independent,” but rather: what data type does TMS generate? The answer is none—TMS itself does not produce biophysical data.

2. Technical complexity requires architectural separation
   TMS sessions generate data that require:

High-dimensional metadata (e.g., coil parameters, train/burst structures, E-field distributions, RMT/AMT intensities)

Spatial localization (coil position/orientation, marker normal vectors)

Time-domain stimulus information (e.g., inter-train, inter-pulse intervals)

Custom coordinate systems and navigation files

These elements do not fit cleanly into any existing datatype such as eeg, beh, or physio.

I agree with your list of metadata requirements—this is precisely what is already captured in BEP037. The challenge is not data, but metadata organization.

3. Avoiding data type congestion
   As noted by several contributors above, embedding distinct modalities into existing data types often leads to semantic overload and organizational inconsistency. Attempting to embed TMS within another data type would introduce non-intuitive data structures and break expectations of file discovery and structure.

This is exactly why BEP037 evolved the way it did. In early discussions, we considered a dedicated tms.tsv/json (and later a nibs.tsv/json). After years of iteration, the consensus was that embedding stimulation information in existing BIDS structures (e.g. events.tsv for online NIBS) is more consistent. For offline stimulation, we acknowledged the gap and proposed interventions.tsv/json. The only reason why we are proposing the intervention.tev/json pair is that it makes the metadata of an NIBS intervention, such as device, intensity, location of stimulation etc.. easy to read for a machine. Otherwise, 99% of the interventions can be simply described in a txt descriptor without overcomplications.

4. Preserving data coherence
   TMS data must be recorded, interpreted, and validated as a coherent unit. For example, stimulation coordinates, marker orientation, and electric field estimation are tightly interdependent. This argues in favor of grouping these files under a dedicated tms/ folder rather than distributing them across modalities.

What you describe as “TMS data” are in fact metadata. Since TMS does not itself generate data, the question becomes: where should these metadata live? That is precisely what BEP037 addresses. I’d be glad to hear your opinion on the best location.

5. Improved usability and discoverability
   One of the core strengths of BIDS is that data from a given modality can be easily located and understood by tools and researchers. Adding TMS as a first-class datatype continues this principle, rather than introducing ambiguity about where to store and find TMS-related information.

I’m not sure what “first-class data type” means in this context. If the argument is consistency, the precedent is actually mixed: some modalities were added because they generate raw data (EEG, MEG, iEEG, PET), not because of their metadata.

6. Consistency with BIDS precedent
   As has been done with meg/, eeg/, ieeg/, pet/, and motion/, we believe TMS meets the same threshold of complexity and independence. Assigning it a dedicated folder is consistent with these precedents and strengthens the BIDS architecture.

Agree. Again, see BEP037. The extension is designed precisely to handle the technical and organizational challenges you list.

7. Risk of fragmentation within umbrella BEPs
   While we appreciate the desire to unify all non-invasive brain stimulation (NIBS) methods under a single proposal (e.g., BEP037), we believe that collapsing very distinct methods under a shared structure risks reducing clarity and reusability. Instead of cohesion, such unification may introduce internal fragmentation. A separate, well-structured TMS extension may serve both the community and the BIDS standard more effectively.

not sure what "Instead of cohesion, such unification may introduce internal fragmentation" means. Our discussions (including with the BIDS maintainers) began with TMS alone many years ago. Over time, it became clear that TMS, TES, and TUS share far more similarities than differences—particularly in not generating raw data per se and their overlapping metadata descriptors. For this reason, we converged on NIBS-BIDS as a more coherent umbrella, rather than multiplying modality folders.

We are very happy to have new contributors joining BEP037, and all comments are welcome!
After several years of community discussions and conference presentations (2020–2024), we met again with the @bids-maintenance team in January 2025, formally closed the “Google Doc” phase, and are now moving toward the PR. There will be ample opportunity after the PR to comment and refine the metadata, so you are still very much in time to contribute. Given the time and effort that went into the community engagement phase for this BEP, we strongly discourage initiating a separate BEP on TMS alone.

[olegshevts]

First of all, we deeply appreciate the work of BEP037 and sincerely respect the entire community that has been engaged in this multi-year discussion.

However, our project developed independently, and we were not aware of BEP037 until this recent exchange. Our proposal has emerged in parallel, offering an alternative architecture based on a clear and hierarchical structure.

We are not aiming to challenge or oppose BEP037, but rather to contribute a different perspective on data organization — particularly for TMS as a distinct modality. We have carefully reviewed the points raised in the discussion and would like to offer several respectful clarifications and comments.

1. “ The answer is none—TMS itself does not produce biophysical data.” – and therefore does not deserve a data type...

We believe this interpretation could be misleading. In fact:

Many existing BIDS data types represent modalities that do not directly generate signals, but organize metadata-rich paradigms (e.g., beh/, motion/, pet/).

TMS may not generate time-series signals, but it produces and structures stimulation protocols, which:

Are executed, not recorded

Are tightly coupled with the session design

Define the context for downstream measurements (e.g., EMG, EEG, MEPs)

Thus, TMS does generate structured experiment data, which deserves principled organization — especially in the absence of continuous raw signals.

2. “this is precisely what is already captured in BEP037”

We believe that merging TMS, TES, and TUS into a single umbrella may obscure critical differences:

TMS involves electromagnetic pulses, coil geometry, neuronavigation, and often relies on electric field modeling.

TES involves continuous current stimulation with fundamentally different timing, targeting, and metadata.

Conflating the two into a single metadata structure risks complexity and internal fragmentation.

Finally, we would like to add that from our view:

BIDS must remain accessible not only to machines and pipelines, but also to researchers, students, and clinicians. Human-readable, intuitive folder structures play a crucial role in open science and adoption.

3. “What you describe as “TMS data” are in fact metadata.”

This point recurs frequently. However:

In BIDS, metadata can be just as important as the data themselves. For example:

coordsystem.json, events.tsv, and channels.tsv are all metadata, yet critical.

TMS sessions involve multi-level metadata structures, including:

Session-wide configuration

Coil parameters

Per-stimulation parameters (amplitude, train/burst structure)

Coil placement & targeting

These components are semantically and structurally inseparable.

Placing them across multiple unrelated folders introduces unnecessary complexity and loss of coherence.

Thus, the TMS folder is not just convenient — it is necessary for integrity and clarity.

4. “For this reason, we converged on NIBS-BIDS as a more coherent umbrella, rather than multiplying modality folders.”

This reasoning, while pragmatic, poses multiple challenges:

In BEP037, metadata appear to be split into:

events.tsv for online stimulation

interventions.tsv for offline stimulation

additional suffixes for specific contexts

This results in scattered and non-predictable file structures depending on study design.

In contrast, our approach:

Places all TMS-relevant files in a single /tms/ folder

Follows a predictable structure, as done in eeg/, meg/, pet/, etc.

Reduces lookup complexity for humans and tools alike

We believe this better aligns with BIDS principles of clarity, accessibility, and coherence.

The discussion in Issue #2108
underscores how BIDS lacks formal criteria for deciding between new data types, modalities, or suffixes.

Rather than undermining BEP037, our proposal addresses that very need — offering:

A clear, modular architecture

Consistent application of datatype/ principles

Preservation of metadata coherence

Accessibility for both algorithms and human users

We are happy to continue the discussion and explore paths toward harmonization, but we hope these arguments illustrate why TMS deserves a dedicated, standalone structure — not only technically, but also conceptually and practically.

[GiacomoBert]

Thank you very much for your thoughtful response.

We are always open to new ideas and discussion. Over the years BEP037 has changed and improved precisely thanks to constructive input from the community.

We are also glad to see that more and more researchers are confronting the issue of TMS data reporting and considering BIDS extensions for it. A good example is @nigelrogasch, who before joining NIBS-BIDS had been working independently on TMS in BIDS and has since made invaluable contributions to the effort. In the same way, the work you and your group have already invested in thinking carefully about TMS reporting is extremely valuable. Even if you were not aware of BEP037 earlier, none of that effort is wasted — these are exactly the kinds of perspectives that can strengthen the extension, and we are keen to integrate them into the ongoing discussion.

We fully agree that TMS, TES, and TUS each have their own characteristics and will require different metadata. At the same time, we believe their similarities are greater than their differences at this level of description. For example, single-pulse TMS combined with EMG for MEP recording is quite different from rTMS in a clinical research context; conversely, rTMS protocols often resemble tDCS designs more than single-pulse TMS, although with different metadata associated. It was precisely these kinds of considerations that led us to unify them under a single BEP. Importantly, being under one BEP does not mean metadata must be reported identically across methods — we could, for instance, have separate subsections in the specification page for TMS, TES, and TUS. This remains an open area of discussion, and we would welcome your input.

On the idea of a dedicated TMS file: as I mentioned, that was our original approach, and we have gone back and forth on it many times; the most recent of these discussions was in fact two weeks ago. I realize that someone joining the BEP037 discussion now may not have the full background on why we moved toward reusing existing BIDS files instead (most of it was in the Google doc comments). I should make sure to add that context back in. That said, we are absolutely open to continuing the debate. There are clear advantages to a dedicated TMS (or NIBS) file — clarity being one of them — but also real downsides, such as proliferation of files containing only minimal metadata, or ambiguities about where exactly such files should sit relative to the protocol they describe. In BEP037 we have tried to keep things as minimally prescriptive as possible, given the huge diversity of stimulation protocols. Happy to continue with this debate.

As I mentioned, there will be plenty of time during the PR phase for everyone to weigh in, and we are more than open to adapting the final structure if better solutions emerge. The PR will be coming soon, and we’d be very happy to continue the discussion there or on the BEP037 issue page. For this reason, I would still not recommend starting a new BEP on TMS — but I do want to emphasize again that all the thinking and work you’ve already put into this is precious, and a very welcome contribution to the BIDS community.

[olegshevts]

Presentation from the meeting at 17.09.25
https://docs.google.com/presentation/d/1dUQNcCMzik0PpCEFrs1WVoZpp8PdLbAf/edit?usp=sharing&ouid=110389466890611734752&rtpof=true&sd=true