Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ElectricalStimulationParameters: objects instead of string #1669

Open
MatthiasSure opened this issue Dec 13, 2023 · 8 comments
Open

ElectricalStimulationParameters: objects instead of string #1669

MatthiasSure opened this issue Dec 13, 2023 · 8 comments

Comments

@MatthiasSure
Copy link

MatthiasSure commented Dec 13, 2023

Hi,
Is it necessary for the data type for ElectricalStimulationParameters to be a string? Since it is a free text field anyway, would it not be possible to use a nesting of objects as a data type, as with the hardware filters? I can speak here primarily from the perspective of deep brain stimulation and temporal MEG/EEG measurement. Here, information on the stimulation settings is often relevant for later analyses. However, these can differ for the stimulation setting during the measurement and the clinical stimulation setting as well as for the individual electrodes. A three-layer system would therefore be suitable for data such as I use. Here is an example:

"ElectricalStimulationParameters":{
		"StimulationTarget":"STN",
		"CurrentExperimentalSetting":{			
			"StimulationMode":"continuous",
			"StimulationParadigm":"continuous stimulation",
			"SimulationMontage":"monopolar",
			"Left":{
				"AnodalContact":"Ground",
				"CathodalContact":[],
				"AnodalContactDirection":"none",
				"CathodalContactDirection":"omni",
				"CathodalContactImpedance":"n/a",
				"StimulationAmplitude":1.5,
				"StimulationPulseWidth":60,
				"StimulationFrequency":130
			},
			"Right":{
				"AnodalContact":"Ground",
				"CathodalContact":[],
				"AnodalContactDirection":"none",
				"CathodalContactDirection":"omni",
				"CathodalContactImpedance":"n/a",
				"StimulationAmplitude":1.5,
				"StimulationPulseWidth":60,
				"StimulationFrequency":130
			},
		"ClinicalSetting":{			
			"StimulationMode":"continuous",
			"StimulationParadigm":"continuous stimulation",
			"SimulationMontage":"monopolar",
			"Left":{
				"AnodalContact":"Ground",
				"CathodalContact":[],
				"AnodalContactDirection":"none",
				"CathodalContactDirection":"omni",
				"CathodalContactImpedance":"n/a",
				"StimulationAmplitude":1.5,
				"StimulationPulseWidth":60,
				"StimulationFrequency":130
			},
			"Right":{
				"AnodalContact":"Ground",
				"CathodalContact":[],
				"AnodalContactDirection":"none",
				"CathodalContactDirection":"omni",
				"CathodalContactImpedance":"n/a",
				"StimulationAmplitude":1.5,
				"StimulationPulseWidth":60,
				"StimulationFrequency":130
			}
		}

This can all be saved in one long string, but then it becomes unreadable.

I look forward to your feedback.
Greetings,
Matthais

@effigies
Copy link
Collaborator

Permitting arbitrary objects is an invitation for incompatibility. With strings, at least there can be no assumption of compatibility, and they practically demand human intervention.

This seems like a thing to seek agreement on among producers and consumers of these metadata, and at least avoid conflict with iEEG - Electrical stimulation and BEP 26 - Multi-electrode recordings, BEP 32 - Animal electrophysiology, and BEP 37 - Non-Invasive Brain Stimulation.

@dorahermes
Copy link
Member

This is a really nice overview of what type of stimulation parameters could be used! The question seems where to store this information: in the _ieeg.json file or somewhere else?

I am not sure what a good location would be if the _ieeg.json would explode with this information. perhaps linking across to a more detailed specification of other stimuli in general? In issue #153 there is a discussion of a more detailed representation of stimuli conditions.

@Remi-Gau
Copy link
Collaborator

I would definitely urge to discuss with BEP37 to make sure that the standardization of invasive and non invasive brain stimulation are, at a minimum, not in conflict with each other and, at best, overlap as much as possible in terms terminology and where to store what information.

BEP37 has done a lot work trying to map out the different use cases for non invasive brain stimulation. I would be surprised if some common ground could not be found.

@dorahermes
Copy link
Member

Agree that there is lots of overlap with BEP 37 - Non-Invasive Brain Stimulation.

@MatthiasSure
Copy link
Author

Happy New Year, and thanks for the feedback.
Do you know if I have to contact someone or is it fine if I just add a comment to the google docs of BEP 37?

@sappelhoff
Copy link
Member

Do you know if I have to contact someone or is it fine if I just add a comment to the google docs of BEP 37?

as per BIDS rules, all BEP documents that are open should allow comments from the public :-) so you should be able to just comment. However, if you intend to give extensive feedback, then getting in touch with the BEP leads beforehand can't hurt!

@yarikoptic
Copy link
Collaborator

Is this a good candidate for BIDS 2.0 and be moved/copied to https://github.com/bids-standard/bids-2-devel/ ?

@sappelhoff
Copy link
Member

Is this a good candidate for BIDS 2.0 and be moved/copied to https://github.com/bids-standard/bids-2-devel/ ?

I don't think there are blockers to implement this in BIDS 1.0, so it's a future item, but not necessarily BIDS 2.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants