Microelectrode Electrophysiology

Support for Microelectrode Electrophysiology was developed as a BIDS Extension Proposal BEP032: Animal electrophysiology (ephys). Please see Citing BIDS on how to appropriately credit this extension when referring to it in the context of the academic literature.

This BEP was initiated by members of the INCF Working Group on Standardized Data Structures in 2020 to develop specifications and tools for standardizing experimental data recorded with animal models in neuroscience and its associated metadata.

Example datasets

Several example microelectrode electrophysiology datasets have been formatted using this specification and can be used for practical guidance when curating a new dataset.

Terminology: Modality and Datatypes

The Microelectrode Electrophysiology modality encompasses recordings made with micrometer-scale electrodes, distinguishing it from related BIDS modalities (EEG, MEG, iEEG) that use larger electrodes. This modality is primarily used in animal research.

Within this modality, BIDS defines two datatypes based on fundamentally different recording techniques (see Issue #1800):

• ecephys (Extracellular Electrophysiology): Electrodes remain in the extracellular space without specifically targeting the membrane of neurons, measuring field potentials (μV) from nearby neurons. Examples: Recordings with microelectrode probes, tetrodes, multi-electrode arrays.

• icephys (Intracellular Electrophysiology): Electrodes penetrate or attach to cell membranes to directly measure intracellular potentials (mV) and cellular dynamics. Examples: cell-attached patch clamp, whole-cell patch clamp, intracellular sharp electrode recordings.

These datatypes differ in recording technique, signal amplitude, required metadata (for example, pipette_solution and recording_mode for icephys; probe geometry for ecephys), and analysis pipelines. The terms are established and used in Neurodata Without Borders (NWB).

Both datatypes share a unified BIDS structure (probes, electrodes, channels) with technique-specific optional metadata fields. Files are organized into ecephys/ or icephys/ subdirectories with corresponding file suffixes.

Primary Data File Formats

Microelectrode electrophysiology data (of icephys or ecephys datatypes) MUST be stored in an open file format, while the native format, if different, can be stored in an optional sourcedata/ directory. The native file format is used in case conversion elicits the loss of crucial metadata specific to manufacturers and specific acquisition systems. Metadata should be included alongside the data in the .json and .tsv files. The current list of allowed data file formats:

Format	Extension(s)	Description
Neuroscience Information Exchange Format	.nix	A generic and open framework with an hdf5 backend and a defined interface to many microephys formats via the Neo library. The .nix file has to contain a valid Neo structure.
Neurodata Without Borders	.nwb	An open data standard for neurophysiology, including data from intracellular and extracellular electrophysiology experiments.

Both of these formats can also store essential metadata of the datasets. Some of this metadata needs to be duplicated in BIDS .tsv and .json sidecar files. Even though the duplication requires additional effort to ensure the consistency of the data, it provides several advantages:

• It makes the dataset easier for humans to scan, as essential information is easily accessible without loading the data files.
• The dataset adheres to the BIDS standard and can benefit from tools built on top of this standard, such as bids-validator.
• It simplifies the separation of data and basic metadata, enabling, for example, the publication of a dataset in a lightweight fashion with access to the data files on request (as implemented by DataLad).

icephys

Template:

sub-<label>/
    [ses-<label>/]
        icephys/
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>]_channels.json
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>]_channels.tsv
            sub-<label>[_ses-<label>][_task-<label>][_acq-<label>]_space-<label>_coordsystem.json
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_proc-<label>][_space-<label>]_electrodes.json
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_proc-<label>][_space-<label>]_electrodes.tsv
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_events.json
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_events.tsv
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_icephys.json
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_icephys.nix
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_icephys.nwb
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>]_probes.json
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>]_probes.tsv

Legend:

• For more information about filename elements (for example, entities, suffixes, extensions), follow the links embedded in the filename template.

• <matches> is a placeholder to denote an arbitrary (and valid) sequence of entities and labels at the beginning of the filename (only BIDS "raw").

• <source-entities> is a placeholder to denote an arbitrary sequence of entities and labels at the beginning of the filename matching a source file from which the file derives (only BIDS-Derivatives).

• Filename entities or directories between square brackets (for example, [_ses-<label>]) are OPTIONAL.

• Some entities may only allow specific values, in which case those values are listed in <>, separated by |.

• _<suffix> means that there are several (>6) valid suffixes for this filename pattern.

• .<extension> means that there are several (>6) valid extensions for this file type.

• [.gz] means that both the unzipped and gzipped versions of the extension are valid.

ecephys

Template:

sub-<label>/
    [ses-<label>/]
        ecephys/
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>]_channels.json
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>]_channels.tsv
            sub-<label>[_ses-<label>][_task-<label>][_acq-<label>]_space-<label>_coordsystem.json
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_proc-<label>][_space-<label>]_electrodes.json
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_proc-<label>][_space-<label>]_electrodes.tsv
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_events.json
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_events.tsv
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_ecephys.json
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_ecephys.nix
            sub-<label>[_ses-<label>][_sample-<label>][_task-<label>][_acq-<label>][_run-<index>]_ecephys.nwb
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>]_probes.json
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>]_probes.tsv

Legend:

• For more information about filename elements (for example, entities, suffixes, extensions), follow the links embedded in the filename template.

• <matches> is a placeholder to denote an arbitrary (and valid) sequence of entities and labels at the beginning of the filename (only BIDS "raw").

• <source-entities> is a placeholder to denote an arbitrary sequence of entities and labels at the beginning of the filename matching a source file from which the file derives (only BIDS-Derivatives).

• Filename entities or directories between square brackets (for example, [_ses-<label>]) are OPTIONAL.

• Some entities may only allow specific values, in which case those values are listed in <>, separated by |.

• _<suffix> means that there are several (>6) valid suffixes for this filename pattern.

• .<extension> means that there are several (>6) valid extensions for this file type.

• [.gz] means that both the unzipped and gzipped versions of the extension are valid.

Sidecar JSON (*_icephys.json and *_ecephys.json)

All metadata that is not directly related to one of the other metadata files (probe/electrode/channel information) should be stored in a single JSON file corresponding to the datatype: _icephys.json or _ecephys.json for intracellular and extracellular, respectively.

There should be one such JSON file for each data file.

The *_ecephys.json or *_icephys.json file can be used to store any microephys-specific metadata for the dataset. All setup-related metadata should be stored in a dedicated node of the JSON file called Setup. We recommend using the following keys to describe the setup:

Institution Information

Key name	Requirement Level	Data type	Description
InstitutionName	RECOMMENDED	string	The name of the institution in charge of the equipment that produced the measurements.
InstitutionAddress	RECOMMENDED	string	The address of the institution in charge of the equipment that produced the measurements.
InstitutionalDepartmentName	RECOMMENDED	string	The department in the institution in charge of the equipment that produced the measurements.

Setup Information

Key name	Requirement Level	Data type	Description
PowerLineFrequency	REQUIRED	number or "n/a"	Frequency (in Hz) of the power grid at the geographical location of the instrument (for example, 50 or 60).
Manufacturer	RECOMMENDED	string	Manufacturer of the equipment that produced the measurements. For example, "TDT", "Blackrock".
ManufacturersModelName	RECOMMENDED	string	Manufacturer's model name of the equipment that produced the measurements.
ManufacturersModelVersion	RECOMMENDED	string	Manufacturer's model version of the equipment that produced the measurements.
RecordingSetupName	RECOMMENDED	string	Custom name of the recording setup.
SamplingFrequency	REQUIRED	number	Sampling frequency (in Hz) of all the data in the recording, regardless of their type (for example, 2400). Internal (maximum) sampling frequency (in Hz) of the recording (for example, "24000").
DeviceSerialNumber	RECOMMENDED	string	The serial number of the equipment that produced the measurements. A pseudonym can also be used to prevent the equipment from being identifiable, so long as each pseudonym is unique within the dataset. The serial number of the components of the setup, RECOMMENDED to add serial numbers and versions of ALL components constituting the setup.
SoftwareName	RECOMMENDED	string	Name of the software that was used to present the stimuli. The name of the software suite used to record the data.
SoftwareVersions	RECOMMENDED	string	Manufacturer's designation of software version of the equipment that produced the measurements.
RecordingDuration	RECOMMENDED	number	Length of the recording in seconds (for example, 3600).
RecordingType	RECOMMENDED	string	Defines whether the recording is "continuous", "discontinuous", or "epoched", where "epoched" is limited to time windows about events of interest (for example, stimulus presentations or subject responses). Must be one of: "continuous", "epoched", "discontinuous".
EpochLength	OPTIONAL, but RECOMMENDED if RecordingType is "epoched"	number	Duration of individual epochs in seconds (for example, 1) in case of epoched data. If recording was continuous or discontinuous, leave out the field. Must be a number greater than or equal to 0.

Processing Information

Key name	Requirement Level	Data type	Description
SoftwareFilters	REQUIRED	object of objects or "n/a"	Object of temporal software filters applied, or "n/a" if the data is not available. Each key-value pair in the JSON object is a name of the filter and an object in which its parameters are defined as key-value pairs (for example, {"Anti-aliasing filter": {"half-amplitude cutoff (Hz)": 500, "Roll-off": "6dB/Octave"}}).
HardwareFilters	RECOMMENDED	object of objects or "n/a"	Object of temporal hardware filters applied, or "n/a" if the data is not available. Each key-value pair in the JSON object is a name of the filter and an object in which its parameters are defined as key-value pairs. For example, {"Highpass RC filter": {"Half amplitude cutoff (Hz)": 0.0159, "Roll-off": "6dB/Octave"}}.

Additional Procedure Information

Furthermore, additional information can be stored about the recording procedure. We RECOMMEND to use a dedicated Procedure node with the following keys:

• Pharmaceuticals
• Sample
• Supplementary

Pharmaceuticals

Key name	Requirement Level	Data type	Description
PharmaceuticalName	RECOMMENDED	string	Name of pharmaceutical.
PharmaceuticalDoseAmount	RECOMMENDED	number or array of numbers	Dose amount of administered pharmaceutical.
PharmaceuticalDoseUnits	RECOMMENDED	string	Unit format relating to pharmaceutical dose (for example, "mg" or "mg/kg").
PharmaceuticalDoseRegimen	RECOMMENDED	string	Details of the pharmaceutical dose regimen. Either adequate description or short-code relating to regimen documented elsewhere (for example, "single oral bolus").
PharmaceuticalDoseTime	RECOMMENDED	number or array of numbers	Time of administration of pharmaceutical dose, relative to time zero. For an infusion, this should be a vector with two elements specifying the start and end of the infusion period. For more complex dose regimens, the regimen description should be complete enough to enable unambiguous interpretation of "PharmaceuticalDoseTime". Unit format of the specified pharmaceutical dose time MUST be seconds.

Sample

Key name	Requirement Level	Data type	Description
BodyPart	RECOMMENDED	string	Body part of the organ / body region scanned.
BodyPartDetails	RECOMMENDED	string	Additional details about body part or location (for example: "corpus callosum").
BodyPartDetailsOntology	OPTIONAL	string	URI of ontology used for BodyPartDetails (for example: "https://www.ebi.ac.uk/ols/ontologies/uberon").
SampleEnvironment	RECOMMENDED	string	Environment in which the sample was imaged. MUST be one of: "in vivo", "ex vivo" or "in vitro". Must be one of: "in vivo", "ex vivo", "in vitro".
SampleEmbedding	OPTIONAL	string	Description of the tissue sample embedding (for example: "Epoxy resin").
SliceThickness	OPTIONAL	number	Slice thickness of the tissue sample in the unit micrometers ("um") (for example: 5). Must be a number greater than 0.
SampleExtractionProtocol	OPTIONAL	string	Description of the sample extraction protocol or URI (for example from protocols.io).

Supplementary

Key name	Requirement Level	Data type	Description
SupplementarySignals	OPTIONAL	string	Description of the supplementary signal (additional modalities) recorded in parallel and are also stored in the data file.

Task Information

If the OPTIONAL task-<label> is used, the following metadata SHOULD be used.

Key name	Requirement Level	Data type	Description
TaskName	RECOMMENDED	string	Name of the task. No two tasks should have the same name. The task label included in the filename MAY be derived from this "TaskName" field by removing all non-alphanumeric or + characters (that is, all except those matching [0-9a-zA-Z+]), and potentially replacing spaces with + to ease readability. For example "TaskName" "faces n-back" or "head nodding" could correspond to task labels faces+n+back or facesnback and head+nodding or headnodding, respectively. A RECOMMENDED convention is to name resting state task using labels beginning with rest.
TaskDescription	RECOMMENDED	string	Longer description of the task.
Instructions	RECOMMENDED	string	Text of the instructions given to participants before the recording. This is especially important in context of resting state recordings and distinguishing between eyes open and eyes closed paradigms.
CogAtlasID	RECOMMENDED	string	URI of the corresponding Cognitive Atlas Task term.
CogPOID	RECOMMENDED	string	URI of the corresponding CogPO term.

Example *_ecephys.json

{
  "InstitutionName": "Example University",
  "InstitutionAddress": "123 Main St, City, State 12345, Country",
  "InstitutionalDepartmentName": "Neuroscience Department",
  "PowerLineFrequency": 60,
  "Manufacturer": "ExampleManufacturer",
  "ManufacturersModelName": "Model-XYZ",
  "SamplingFrequency": 30000,
  "SoftwareName": "RecordingSoftware",
  "SoftwareVersions": "1.0.0",
  "SoftwareFilters": {
    "LowpassFilter": {
      "Half-amplitude cutoff (Hz)": 300,
      "Roll-off": "6dB/Octave"
    }
  },
  "HardwareFilters": {
    "HighpassFilter": {
      "Half-amplitude cutoff (Hz)": 0.1,
      "Roll-off": "6dB/Octave"
    }
  },
  "PharmaceuticalName": ["anesthetic1", "anesthetic2"],
  "PharmaceuticalDoseAmount": [1.5, 10],
  "PharmaceuticalDoseUnits": ["percent", "mg/kg"],
  "BodyPart": "BRAIN",
  "BodyPartDetails": "Motor Cortex",
  "SampleEnvironment": "in-vivo",
  "TaskName": "ExampleTask",
  "TaskDescription": "Description of the experimental task"
}

Example *_icephys.json

{
  "InstitutionName": "Example Institute",
  "InstitutionAddress": "456 Science Ave, City, State 67890, Country",
  "PowerLineFrequency": 60,
  "Manufacturer": "PatchClampManufacturer",
  "ManufacturersModelName": "Amplifier-ABC",
  "SamplingFrequency": 20000,
  "SoftwareName": "PatchSoftware",
  "SoftwareVersions": "2.1.0",
  "SoftwareFilters": {
    "BesselFilter": {
      "Half-amplitude cutoff (Hz)": 10000,
      "Roll-off": "12dB/Octave"
    }
  },
  "BodyPart": "BRAIN",
  "BodyPartDetails": "Visual Cortex",
  "SampleEnvironment": "ex-vivo",
  "SliceThickness": 300,
  "TaskName": "MembraneProperties",
  "TaskDescription": "Characterization of intrinsic properties"
}

Channels description (*_channels.tsv)

Channels are recorded signals. These may be of neuronal origin (for example, online filtered LFP signals) or generated by the recording setup (for example, synchronization or behavioral signals).

The channel properties are stored in a .tsv file. It should contain information about reference electrodes, amplifier, filtering, time alignment and other metadata pertinent to the data for each channel.

This table stores information about the recorded signals, not the electrodes. The distinction is particularly important in cases where multiple signals (such as LFP and high-frequency band-pass filtered signals) are recorded from the same electrode. For more information about the distinction between electrodes and channels, see the corresponding section in iEEG.

Columns in the *_channels.tsv file are:

Column name	Requirement Level	Data type	Description
name	REQUIRED	string	Label of the channel. Values in name MUST be unique. This column must appear first in the file.
electrode_name	REQUIRED	string	Name of the electrode contact point. The value MUST match a name entry in the corresponding *_electrodes.tsv file, linking this channel to its associated electrode contact point. For channels not associated with an electrode, use n/a. This column must appear second in the file.
type	REQUIRED	string	Type of channel; MUST use the channel types listed below. Note that the type MUST be in upper-case. This column must appear third in the file. For a list of valid values for this column, see the associated glossary entry.
units	REQUIRED	string	Physical unit of the value represented in this channel, for example, V for Volt, or fT/cm for femto Tesla per centimeter (see Units). This column must appear fourth in the file.
sampling_frequency	OPTIONAL	number	Sampling rate of the channel in Hz. This column must appear fifth in the file.
low_cutoff	OPTIONAL	number	Frequencies used for the high-pass filter applied to the channel in Hz. If no high-pass filter applied, use n/a. This column may appear anywhere in the file.
high_cutoff	OPTIONAL	number	Frequencies used for the low-pass filter applied to the channel in Hz. If no low-pass filter applied, use n/a. Note that hardware anti-aliasing in A/D conversion of all MEG/EEG/EMG electronics applies a low-pass filter; specify its frequency here if applicable. This column may appear anywhere in the file. Must be a number greater than or equal to 0.
reference	OPTIONAL	string	The reference for the given channel. When the reference is an electrode in *_electrodes.tsv, use the name of that electrode. If a corresponding electrode is not applicable, use "n/a" This column may appear anywhere in the file.
notch	OPTIONAL	string	Frequencies used for the notch filter applied to the channel, in Hz. If notch filters are applied at multiple frequencies, these frequencies MAY be specified as a list, for example, [60, 120, 180]. If no notch filter was applied, use n/a. This column may appear anywhere in the file.
channel_label	OPTIONAL	string	Human readable identifier. Use this name to specify the content of signals not generated by electrodes. For example, 'DAQ internal synchronization signals', 'behavioral signals', 'behavioral cues'. This column may appear anywhere in the file.
stream_id	OPTIONAL	string	Data stream of the recording the signal. This column may appear anywhere in the file.
description	OPTIONAL	string	Brief free-text description of the channel, or other information of interest. This column may appear anywhere in the file.
software_filter_types	OPTIONAL	string or "n/a"	The types of software filters applied to this channel. The Levels for this column SHOULD be defined in the accompanying *_channels.json file, mapping each filter type key to its description. Use n/a if no software filters were applied to this channel. This column may appear anywhere in the file.
status	OPTIONAL	string	Data quality observed on the channel. A channel is considered bad if its data quality is compromised by excessive noise. If quality is unknown, then a value of n/a may be used. Description of noise type SHOULD be provided in [status_description]. This column may appear anywhere in the file. Must be one of: "good", "bad".
status_description	OPTIONAL	string	Freeform text description of noise or artifact affecting data quality on the channel. It is meant to explain why the channel was declared bad in the status column. This column may appear anywhere in the file.
gain	RECOMMENDED	number	Amplification factor applied from signal detection at the electrode to the signal stored in the data file. If no gain factor is provided it is assumed to be 1. This column may appear anywhere in the file.
time_offset	OPTIONAL	number	Time shift between signal of this channel to a reference channel in seconds. This column may appear anywhere in the file.
time_reference_channel	OPTIONAL	string	Name of the channel that is used for time alignment of signals. This column may appear anywhere in the file.
ground	OPTIONAL	string	Information on the ground. For example, 'chamber screw', 'head post', 'ear clip'. Only should be used to optionally override the global ground in the _ecephys.json or _icephys.json file. This column may appear anywhere in the file.
recording_mode	RECOMMENDED	string	The mode of recording for patch clamp datasets (for example, voltage clamp, current clamp). This column may appear anywhere in the file.
Additional Columns	OPTIONAL	n/a	Additional columns are allowed if they are defined in the associated metadata file.

Filtering Information

The global filter parameters for all channels are specified in the sidecar JSON file using HardwareFilters and SoftwareFilters fields. Channel-specific filtering information in the *_channels.tsv file can override or supplement these global settings.

Channel-level filtering can be specified in multiple complementary ways:

1. Cutoff frequencies: Use low_cutoff (high-pass filter frequency), high_cutoff (low-pass filter frequency), and notch (notch filter frequencies) columns to specify the filter cutoff frequencies applied to each channel. These columns are consistent with the iEEG specification.
2. Software filter types with Levels: Use the software_filter_types column to specify which software filters were applied to each channel. The values should correspond to keys defined in the SoftwareFilters field of the *_channels.json JSON file. The Levels for this column SHOULD be defined there, mapping each filter type key to its description.

The stream_id Column

The stream_id column links each channel to its corresponding data stream within the data file. The format of stream_id depends on the data file format:

For NWB files (.nwb): The stream_id SHOULD be the internal HDF5 path to the neurodata object (typically an ElectricalSeries) that contains the voltage recordings for that channel, for example /acquisition/ElectricalSeries. If no path is provided, it is assumed to be /acquisition/ElectricalSeries. If the directory contains multiple NWB files, and not all of those files contain data from the channel, the stream_id SHOULD include the filename(s) that do followed by a colon and the internal path, for example sub-01_ses-01_run-02_ecephys.nwb:/acquisition/ElectricalSeries.

For NIX files (.nix): The stream_id SHOULD reference the data array or signal within the NIX file structure that contains the recordings for that channel, following the NIX/Neo data organization.

Multiple data streams: If a single channel's data spans multiple neurodata objects within a file or across multiple files, the stream_id MUST be specified as a comma-separated list. For example: /acquisition/ElectricalSeries1,/acquisition/ElectricalSeries2 or file1.nwb:/acquisition/ElectricalSeries,file2.nwb:/acquisition/ElectricalSeries.

Example *_channels.tsv

Extracellular electrophysiology example:

name	electrode_name	reference	type	units	sampling_frequency	gain	status	status_description
ch001	e001	ref01	LFP	uV	1000	500	good	n/a
ch002	e002	ref01	LFP	uV	1000	500	good	n/a
ch003	e003	ref01	HP	uV	30000	500	good	n/a
ch004	e004	ref01	HP	uV	30000	500	bad	high_noise
ch005	e005	ref02	LFP	uV	1000	500	good	n/a
ch006	n/a	n/a	SYNC	V	30000	1	good	n/a

Intracellular electrophysiology example:

name	electrode_name	type	units	sampling_frequency	recording_mode	gain	ground	status
patch01	patch01	VM	mV	20000	current-clamp	10	AgCl	good
patch02	patch02	VM	mV	20000	current-clamp	10	AgCl	good
sharp01	sharp01	IM	pA	20000	voltage-clamp	5	AgCl	good

Note: In many datasets multiple sets of identifiers are used for probes, electrodes and channels. We RECOMMEND to include alternative sets of identifiers, for instance identifiers that enumerate electrodes according to their spatial arrangement, as additional custom columns in the .tsv file.

Recommended Channel Type Values

For the type column we recommend to use the following terms (adapted from iEEG)

Keyword	Description
LFP	Low-pass filtered extracellular voltage signal that represents local field potentials
HP	High-pass filtered extracellular voltage signal as used for spike sorting
MUA	High-pass filtered and rectified or thresholded extracellular voltage signal that represents an estimate of multi-unit activity
BB	Unfiltered (broadband) extracellular voltage signal
SPIKES	Discrete signal indicating spike events as derived from spike detection or spike sorting
VM	Membrane voltage
IM	Membrane current
SYNC	Signal used for synchronization between different recording systems / channels
STIM	Electrical stimulation
EEG	Electrode channel from electroencephalogram
ECOG	Electrode channel from electrocorticogram (intracranial)
SEEG	Electrode channel from stereo-electroencephalogram (intracranial)
DBS	Electrode channel from deep brain stimulation electrode (intracranial)
VEOG	Vertical EOG (electrooculogram)
HEOG	Horizontal EOG
EOG	Generic EOG channel if HEOG or VEOG information not available
ECG	ElectroCardioGram (heart)
EMG	ElectroMyoGram (muscle)
TRIG	System Triggers
AUDIO	Audio signal
PD	Photodiode
EYEGAZE	Eye Tracker gaze
PUPIL	Eye Tracker pupil diameter
BEH	Behavioral signals
MISC	Miscellaneous
SYSCLOCK	System time showing elapsed time since trial started
ADC	Analog to Digital input
DAC	Digital to Analog output
REF	Reference channel
OTHER	Any other type of channel

Electrodes description (*_electrodes.tsv)

Electrodes are the physical recording sites that make electrical contact with neural tissue to capture electrophysiological signals.

The electrode positions and properties are stored in a .tsv file (amplifier information is in channels.tsv).

This file contains the following information:

• The electrode name
• The electrode coordinates in 3 columns (xyz) (use n/a for values if a dimension is absent).
• The ID of the probe the electrode is located on

The electrode name MUST be unique within the *_electrodes.tsv file. When a dataset contains multiple probes, electrode names can be constructed by combining the contact identifier (as provided by the probe manufacturer or user-defined) with the probe_name to ensure uniqueness. For example, if two probes each have a contact labeled "1", the electrode names could be "probe01_e1" and "probe02_e1" to distinguish them. The order of the required columns in the *_electrodes.tsv file MUST be as listed below.

Column name	Requirement Level	Data type	Description
name	REQUIRED	string	Name of the electrode contact point. Values in name MUST be unique. This column must appear first in the file.
probe_name	REQUIRED	string	A unique identifier of the probe, can be identical with the device_serial_number. The value MUST match a probe_name entry in the corresponding *_probes.tsv file, linking this electrode to its associated probe. For electrodes not associated with a probe, use n/a. This column must appear second in the file.
x	REQUIRED	number	Recorded position along the x-axis. When no space-<label> entity is used in the filename, the position along the local width-axis relative to the probe origin (see coordinate_reference_point in *_probes.tsv) in micrometers (um). When a space-<label> entity is used in the filename, the position relative to the origin of the coordinate system along the first axis. Units are specified by MicroephysCoordinateUnits in the corresponding *_coordsystem.json file. This column must appear third in the file.
y	REQUIRED	number	Recorded position along the y-axis. When no space-<label> entity is used in the filename, the position along the local height-axis relative to the probe origin (see coordinate_reference_point in *_probes.tsv) in micrometers (um). When a space-<label> entity is used in the filename, the position relative to the origin of the coordinate system along the second axis. Units are specified by MicroephysCoordinateUnits in the corresponding *_coordsystem.json file. This column must appear fourth in the file.
z	REQUIRED	number or "n/a"	Recorded position along the z-axis. For 2D electrode localizations, this SHOULD be a column of n/a values. When no space-<label> entity is used in the filename, the position along the local depth-axis relative to the probe origin (see coordinate_reference_point in *_probes.tsv) in micrometers (um). When a space-<label> entity is used in the filename, the position relative to the origin of the coordinate system along the third axis. Units are specified by MicroephysCoordinateUnits in the corresponding *_coordsystem.json file. For 2D electrode localizations (for example, when the coordinate system is Pixels), this SHOULD be a column of n/a values. This column must appear fifth in the file.
hemisphere	RECOMMENDED	string	The hemisphere in which the electrode is placed. This column may appear anywhere in the file. Must be one of: "L", "R".
impedance	RECOMMENDED	number	Impedance of the electrode, units MUST be in kOhm. This column may appear anywhere in the file.
shank_id	OPTIONAL	string	A unique identifier to specify which shank of the probe the electrode is on. This is useful for spike sorting when the electrodes are on a multi-shank probe. This column may appear anywhere in the file.
size	OPTIONAL	number	Surface area of the electrode, units MUST be in um^2. This column may appear anywhere in the file.
electrode_shape	OPTIONAL	string	Description of the shape of the electrode (for example, square, circle). This column may appear anywhere in the file.
material	OPTIONAL	string	Material of the electrode (for example, Tin, Ag/AgCl, Gold). This column may appear anywhere in the file.
location	RECOMMENDED	string	An indication on the location of the electrode (for example, cortical layer 3, CA1). This column may appear anywhere in the file.
pipette_solution	OPTIONAL	string	The solution used to fill the pipette. See also [openMINDS Pipette] (https://github.com/openMetadataInitiative/openMINDS_ephys/blob/v1/schemas/device/pipetteUsage.schema.tpl.json). This column may appear anywhere in the file.
internal_pipette_diameter	OPTIONAL	number	The internal diameter of the pipette in micrometers. This column may appear anywhere in the file.
external_pipette_diameter	OPTIONAL	number	The external diameter of the pipette in micrometers. This column may appear anywhere in the file.
Additional Columns	OPTIONAL	n/a	Additional columns are allowed if they are defined in the associated metadata file.

Electrode Position Coordinates

The x, y, and z columns in the electrodes table specify electrode positions, but their meaning depends on whether a space-<label> entity is used in the filename. When no space-<label> entity is used in the filename, the x, y, z coordinates describe the relative positions of electrodes on the probe, NOT their position in the brain or any anatomical coordinate system. These probe-relative positions are REQUIRED for all electrodes. The probe origin (0, 0, 0) is typically at the probe tip or a standard reference point on the probe and SHOULD be specified in the coordinate_reference_point column of *_probes.tsv. The *_coordsystem.json file should not be provided for probe-relative coordinates. If there is just one electrode, the x, y, and z values should be 0.

This rule is different from the electrodes.tsv table of the iEEG modality, where electrode positions are always specified in anatomical space. The distinction is necessary because microelectrode probes often have many electrodes with known relative positions on the probe, but their anatomical positions may not be precisely known without additional localization procedures. The probe-relative positions are essential for interpreting the recorded signals in relation to the probe geometry and for analyses such as spike sorting.

To specify electrode positions in surgical space, individual anatomical space, or a common coordinate system (such as the Allen CCF), use an additional *_electrodes.tsv file with a space-<label> entity. See the *_coordsystem.json section for details on defining these coordinate systems.

Example *_electrodes.tsv

Extracellular electrophysiology example (probe-relative coordinates):

name	probe_name	hemisphere	x	y	z	impedance	shank_id	size	material	location
e001	probe01	L	0	0	0	1.2	0	15	iridium-oxide	MOp
e002	probe01	L	0	0	25	1.1	0	15	iridium-oxide	MOp
e003	probe01	L	0	0	50	1.3	0	15	iridium-oxide	MOp
e004	probe01	L	0	0	75	1.4	0	15	iridium-oxide	MOp
e005	probe02	R	0	0	0	2.1	n/a	12	tungsten	CA1
e006	probe02	R	0	0	15	2.3	n/a	12	tungsten	CA1
e007	probe02	R	0	0	30	1.9	n/a	12	tungsten	CA1
e008	probe02	R	0	0	45	2	n/a	12	tungsten	CA1

Intracellular electrophysiology example:

name	probe_name	hemisphere	x	y	z	impedance	pipette_solution	internal_pipette_diameter	external_pipette_diameter	material	location
patch01	pipette01	L	0	0	0	5.2	K-gluconate	1.5	2.5	borosilicate-glass	VISp2/3
patch02	pipette02	R	0	0	0	4.8	K-gluconate	1.5	2.5	borosilicate-glass	VISp2/3
sharp01	pipette03	L	0	0	0	80	3M KCl	0.5	1	borosilicate-glass	PL5

Probes description (*_probes.tsv)

Probes are electrode-bearing devices that interface with neural tissue to record electrophysiological activity, ranging from single recording pipettes to multi-electrode arrays. They can be permanently implanted (chronic recordings) or inserted temporarily for the recording (acute recordings).

The probe positions and properties are stored in a .tsv file. This file contains the probe ID, the type of recording (acute/chronic), and the probe coordinates.

Column name	Requirement Level	Data type	Description
probe_name	REQUIRED	string	A unique identifier of the probe, can be identical with the device_serial_number. Values in probe_name MUST be unique. This column must appear first in the file.
type	REQUIRED	string	The type of the probe. This column must appear second in the file.
AP	RECOMMENDED	number	Probe position along the Anterior-Posterior axis. Positive values are anterior to the reference point. This column must appear third in the file.
ML	RECOMMENDED	number	Probe position along the Medial-Lateral axis. Positive values are to the right (as seen from behind). This column must appear fourth in the file.
DV	RECOMMENDED	number	Probe position along the Dorsal-Ventral axis. Positive values are ventral. This column must appear fifth in the file.
AP_angle	RECOMMENDED	number	Anterior-Posterior rotation angle measured as rotation from the vertical axis in the sagittal plane. 0° represents vertical along DV axis. Positive values indicate anterior rotation. This column must appear sixth in the file. Must be a number greater than or equal to -180 and less than or equal to 180.
ML_angle	RECOMMENDED	number	Medial-Lateral rotation angle measured as rotation from the vertical axis in the coronal plane. 0° represents vertical along DV axis. Positive values indicate rightward/clockwise rotation (as seen from behind). This column must appear seventh in the file. Must be a number greater than or equal to -180 and less than or equal to 180.
manufacturer	RECOMMENDED	string	Manufacturer of the probes system (for example, 'openephys', 'alphaomega','blackrock'). This column may appear anywhere in the file.
model	RECOMMENDED	string	The model name or number of the probe (for example, Neuropixels 1.0, A1x32-Poly3-5mm-25s-177). This column may appear anywhere in the file.
device_serial_number	RECOMMENDED	string	The serial number of the probe (provided by the manufacturer). This column may appear anywhere in the file.
electrode_count	OPTIONAL	number	Number of miscellaneous analog electrodes for auxiliary signals (for example, '2'). This column may appear anywhere in the file.
width	OPTIONAL	number	Physical width of the probe in mm, for example, '5'. This dimension corresponds to the x-axis of the probe's local coordinate frame. This column may appear anywhere in the file.
height	OPTIONAL	number	Physical height of the probe in mm, for example, '0.3'. This dimension should be omitted or set to 0 for one-dimensional (linear) probes. This dimension corresponds to the y-axis of the probe's local coordinate frame. This column may appear anywhere in the file.
depth	OPTIONAL	number	Physical depth of the probe in mm, for example, '0.3'. This dimension should be omitted or set to 0 for two-dimensional (shank-type) probes. This dimension corresponds to the z-axis of the probe's local coordinate frame. This column may appear anywhere in the file.
rotation_angle	RECOMMENDED	number	Rotation angle around the probe axis. 0° when probe features align with the coronal plane. Positive rotation is clockwise when viewed from above. This column may appear anywhere in the file. Must be a number greater than or equal to -180 and less than or equal to 180.
coordinate_reference_point	RECOMMENDED	string	Point of the probe that is described by the probe coordinates and on which the yaw, pitch, and roll rotations are applied. This column may appear anywhere in the file.
anatomical_reference_point	OPTIONAL	string	Anatomical reference point for stereotaxic coordinates (for example, Bregma, Lambda). If not specified, Bregma is assumed for rodents. MUST be defined for species other than rodents. This column may appear anywhere in the file.
hemisphere	RECOMMENDED	string	Hemisphere in which the probe is placed. This column may appear anywhere in the file. Must be one of: "L", "R".
associated_brain_region	RECOMMENDED	string	A textual indication on the location of the probe, preferably species-independent terms as obtained, for example from Uberon. This column may appear anywhere in the file.
associated_brain_region_id	RECOMMENDED	string	An identifier of the associated brain region based on the Uberon ontology for anatomical structures in animals, for example "UBERON:0010415" This column may appear anywhere in the file.
associated_brain_region_quality_type	RECOMMENDED	string	The method used to identify the associated brain region (estimated
reference_atlas	RECOMMENDED	string	Name of reference atlas used for associated brain region identification, preferably an ebrains supported atlas. This column may appear anywhere in the file.
material	OPTIONAL	string	A textual description of the base material of the probe. This column may appear anywhere in the file.
Additional Columns	OPTIONAL	n/a	Additional columns are allowed if they are defined in the associated metadata file.

Example *_probes.tsv

Extracellular electrophysiology example:

probe_name	type	AP	ML	DV	AP_angle	ML_angle	rotation_angle	hemisphere	manufacturer	device_serial_number	electrode_count	width	height	depth	coordinate_reference_point	anatomical_reference_point	associated_brain_region	associated_brain_region_id	reference_atlas	material
probe01	silicon-probe	-2.5	1.5	-4	15	0	0	L	IMEC	NP1100-2205	384	70	20	10	tip	Bregma	Primary Motor Cortex	MOp	Franklin-Paxinos	silicon
probe02	tetrode	-1.2	-2.1	-3.5	0	10	45	R	Neuralynx	TT-12345	4	n/a	n/a	n/a	tip	Bregma	Hippocampus CA1	CA1	Paxinos-Watson	tungsten

Intracellular electrophysiology example:

probe_name	type	AP	ML	DV	AP_angle	ML_angle	rotation_angle	hemisphere	manufacturer	electrode_count	coordinate_reference_point	associated_brain_region	associated_brain_region_id	reference_atlas
pipette01	patch-pipette	-1.8	0.5	-2.2	30	0	0	L	Sutter	1	tip	Visual Cortex Layer 2/3	VISp2/3	AllenCCFv3
pipette02	patch-pipette	-1.8	-0.5	-2.2	30	0	0	R	Sutter	1	tip	Visual Cortex Layer 2/3	VISp2/3	AllenCCFv3
pipette03	sharp-electrode	-3.2	1.2	-3.8	20	5	0	L	WPI	1	tip	Prefrontal Cortex Layer 5	PL5	Franklin-Paxinos

For details on the surgical coordinate system used to describe probe placement during surgery (AP, ML, DV, angles, and anatomical reference points), see the Microelectrode Surgical Coordinates appendix.

ProbeInterface Library

ProbeInterface is a standard for specifying electrode layouts on probes. The ProbeInterface library includes layouts for many common probes.

Probe information is specified in the probes.json sidecar file using the model field with Levels to define each probe model.

For probes listed in the ProbeInterface library, use TermURL to reference the probe definition:

"model": {
    "Levels": {
        "A1x32": {
            "Description": "A1x32-Poly3-10mm-50-177, a 1-shank probe",
            "TermURL": "https://raw.githubusercontent.com/SpikeInterface/probeinterface_library/refs/heads/main/neuronexus/A1x32-Poly3-10mm-50-177/A1x32-Poly3-10mm-50-177.json"
        }
    }
}

If the probe is not listed in the ProbeInterface library, you SHOULD define it using the ProbeInterface format and include it in a directory called probes/ in the root of the dataset. Custom probe files MUST comply with the ProbeInterface specification and JSON schema.

For custom probes, reference them using a BIDS URI with the bids:: prefix in the TermURL field:

"model": {
    "Levels": {
        "customprobe1": {
            "Description": "Custom experimental probe",
            "TermURL": "bids::probes/customprobe1.json"
        }
    }
}

Example file structure:

└─ probes/
   ├─ customprobe1.json 
   ├─ customprobe2.json 
   └─ ... 

Coordinate System JSON (*_coordsystem.json)

Template:

sub-<label>/
    [ses-<label>/]
        ecephys/
            sub-<label>[_ses-<label>][_task-<label>][_acq-<label>]_space-<label>_coordsystem.json
        icephys/
            sub-<label>[_ses-<label>][_task-<label>][_acq-<label>]_space-<label>_coordsystem.json

Legend:

• For more information about filename elements (for example, entities, suffixes, extensions), follow the links embedded in the filename template.

• <matches> is a placeholder to denote an arbitrary (and valid) sequence of entities and labels at the beginning of the filename (only BIDS "raw").

• <source-entities> is a placeholder to denote an arbitrary sequence of entities and labels at the beginning of the filename matching a source file from which the file derives (only BIDS-Derivatives).

• Filename entities or directories between square brackets (for example, [_ses-<label>]) are OPTIONAL.

• Some entities may only allow specific values, in which case those values are listed in <>, separated by |.

• _<suffix> means that there are several (>6) valid suffixes for this filename pattern.

• .<extension> means that there are several (>6) valid extensions for this file type.

• [.gz] means that both the unzipped and gzipped versions of the extension are valid.

To describe the location of electrodes in an anatomical or stereotaxic coordinate system, a space entity is used in the filename, and a corresponding *_coordsystem.json file is used alongside the corresponding *_electrodes.tsv file. This *_coordsystem.json file contains the coordinate system in which electrode positions are expressed. The associated MRI, CT, X-Ray, or operative photo can also be specified. The x, y, and z columns indicate the positions of the center of each electrode in Cartesian coordinates.

This file is REQUIRED when the space-<label> entity is used in the filename to specify electrode positions in an anatomical or stereotaxic coordinate system. When a *_space-<label>_coordsystem.json file is present, the corresponding *_space-<label>_electrodes.tsv file with the same space label MUST also be present.

General fields:

Key name	Requirement Level	Data type	Description
IntendedFor	OPTIONAL	string or array	The paths to files for which the associated file is intended to be used. Contains one or more BIDS URIs. Using forward-slash separated paths relative to the participant subdirectory is DEPRECATED. This field can be used to indicate the data files for which this coordinate system applies.

Fields relating to the microelectrode electrophysiology electrode positions:

Key name	Requirement Level	Data type	Description
MicroephysCoordinateSystem	REQUIRED	string	Defines the coordinate system for the microelectrode probes. See the Coordinate Systems Appendix for a list of restricted keywords for coordinate systems. If "Other", provide definition of the coordinate system in "MicroephysCoordinateSystemDescription". If positions correspond to pixel indices in a 2D image (of either a volume-rendering, surface-rendering, operative photo, or operative drawing), this MUST be "Pixels". For more information, see the section allowed 2D coordinate systems. For a list of valid values for this field, see the associated glossary entry. For a list of valid values for this field, see the associated glossary entry.
MicroephysCoordinateUnits	REQUIRED	string	Units of the coordinates of "MicroephysCoordinateSystem". Must be one of: "m", "mm", "cm", "um", "pixels".
MicroephysCoordinateSystemDescription	RECOMMENDED, but REQUIRED if MicroephysCoordinateSystem is "Other"	string	Free-form text description of the coordinate system. May also include a link to a documentation page or paper describing the system in greater detail.
MicroephysCoordinateSystemPhoto	OPTIONAL, but REQUIRED if MicroephysCoordinateUnits is "pixels"	string	Path to the photo or image file defining the coordinate system when MicroephysCoordinateUnits is "pixels". Should be a BIDS URI.

*_coordsystem.json files SHOULD NOT be duplicated for each data file, for example, across multiple tasks. The inheritance principle MUST be used to find the appropriate coordinate system description for a given data file. If electrodes are repositioned, it is RECOMMENDED to use multiple sessions to indicate this.

Recommended 3D coordinate systems

It is preferred that electrodes are localized in a 3D coordinate system, with respect to anatomical reference images, stereotactic coordinates, or in a standard space as specified in the BIDS Coordinate Systems Appendix.

For example:

• *_space-Stereotaxic (electrodes are localized in stereotaxic coordinate system with bregma origin)
• *_space-individual (electrodes are localized in subject-specific anatomical coordinate system)
• *_space-AllenCCFv3 (electrodes are mapped to Allen Common Coordinate Framework v3)
• *_space-WaxholmSpace (electrodes are mapped to Waxholm Space rat brain atlas coordinates)
• *_space-WistarRatAtlas (electrodes are mapped to Wistar Rat Atlas coordinates)

When referring to the *_electrodes.tsv file in a certain space as defined above, the space-<label> of the accompanying *_coordsystem.json MUST correspond.

Allowed 2D coordinate systems

If electrodes are localized in 2D space (only x and y are specified and z is "n/a"), then the positions in this file MUST correspond to the locations expressed in pixels on the photo/drawing/rendering of the electrodes on the brain. In this case, MicroephysCoordinateSystem MUST be defined as "Pixels", and MicroephysCoordinateUnits MUST be defined as "pixels" (note the difference in capitalization). Furthermore, the coordinates MUST be (row,column) pairs, with (0,0) corresponding to the upper left pixel and (N,0) corresponding to the lower left pixel.

Multiple coordinate systems

If electrode positions are known in multiple coordinate systems (for example, probe-relative, Stereotaxic, and AllenCCFv3), these spaces can be distinguished by the space-<label> entity. Note that the space-<label> fields must correspond between *_electrodes.tsv and *_coordsystem.json if they refer to the same data.

For example:

└─ sub-01/
   ├─ sub-01_electrodes.tsv 
   ├─ sub-01_space-Stereotaxic_electrodes.tsv 
   ├─ sub-01_space-Stereotaxic_coordsystem.json 
   └─ ... 

Photos of the electrode positions (*_photo.<extension>)

Template:

sub-<label>/
    [ses-<label>/]
        ecephys/
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_space-<label>]_photo.jpg
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_space-<label>]_photo.png
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_space-<label>]_photo.tif
        icephys/
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_space-<label>]_photo.jpg
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_space-<label>]_photo.png
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<label>][_space-<label>]_photo.tif

Legend:

• For more information about filename elements (for example, entities, suffixes, extensions), follow the links embedded in the filename template.

• <matches> is a placeholder to denote an arbitrary (and valid) sequence of entities and labels at the beginning of the filename (only BIDS "raw").

• <source-entities> is a placeholder to denote an arbitrary sequence of entities and labels at the beginning of the filename matching a source file from which the file derives (only BIDS-Derivatives).

• Filename entities or directories between square brackets (for example, [_ses-<label>]) are OPTIONAL.

• Some entities may only allow specific values, in which case those values are listed in <>, separated by |.

• _<suffix> means that there are several (>6) valid suffixes for this filename pattern.

• .<extension> means that there are several (>6) valid extensions for this file type.

• [.gz] means that both the unzipped and gzipped versions of the extension are valid.

These can include photos of the electrodes on the brain surface, photos of anatomical features or landmarks (such as cortical vasculature, stereotactic coordinates), and fiducials. Photos can also include histological sections showing electrode tracks, microscope images of electrode placements, or screenshots of a brain atlas with electrode positions. The photos may need to be cropped and/or blurred to conceal identifying features or entirely omitted prior to sharing, depending on obtained consent and institutional protocols.

If there are photos of the electrodes, the acq-<label> entity should be specified with:

• *_photo.<extension> in case of an operative or in-vivo photo
• *_acq-<label>_photo.<extension> where <label> describes the acquisition type (for example: histology for histological sections showing electrode tracks, microscopy for microscope images of electrode placements, atlas for screenshots showing electrodes overlaid on brain atlas)
• *_acq-drawing#_photo.<extension> in case of a drawing or sketch of electrode placements

The ses-<label> entity may be used to specify when the photo was taken.

The sample-<label> entity may be used to specify the tissue sample for histological photos.

The space-<label> entity may be used to specify the coordinate system for atlas overlay photos.

Recording Events (*_events.tsv)

The *_events.tsv and corresponding *_events.json sidecar files are OPTIONAL and can be used to indicate time points of recording events. Each task events file requires a corresponding task data file. These events can be internal recording system events, task-related events, or events triggered by the experimentalist (for example, manual reward). Note that these events must share a common clock with the corresponding microephys recording data. For more details, see the Task Events documentation. Note that this file can also be used to describe stimulation performed during the recording. For this, please follow the iEEG stimulation documentation.

Multi-part Recordings

Two different procedures are supported to handle multi-part recordings. The two options are:

1. each recording is stored in an independent data file, and the corresponding metadata is described in the *_scans.tsv file; or
2. several recordings are stored in a single data file, and the corresponding metadata is described in the *_events.tsv file.

These two options are made available to support different usages and habits of the experimenters, as well as to benefit from the capability of the supported data formats (NWB and NIX). They are described in the following subsections, and made explicit through some of the example data sets.

Multiple tasks / runs in separate files (*_scans.tsv)

The *_scans.tsv should be used to provide information about multiple parts of an acquisition session (for example, recording start times in case the recording was paused and restarted) when the data from each of these different recordings is stored in separate files. Each data file should have a name that contains a _task-XX and/or _run-XX suffix, and should be described by one row in the *_scans.tsv file. See also the BIDS Scans specification. Relative paths to files should be used under a compulsory "filename" header. If acquisition time is included, it should be with the acq_time header. Datetime should be expressed in the RFC3339 "date-time" format, for example 2009-06-15T13:45:30 (year, month, day, hour (24h), minute, second). Time zone is always assumed as local time. The run and task keywords and the corresponding *_scans.tsv file are OPTIONAL and can be ignored if the dataset consists of only one continuous recording and a single or no task.

Optional: Yes

Example of a *_scans.tsv:

filename	acq_time
ephys/sub-P001_task-pull_run-01_ephys.nix	2018-07-15T09:45:30
ephys/sub-P001_task-pull_run-02_ephys.nix	2018-07-15T13:24:00
ephys/sub-P001_task-push_run-01_ephys.nix	2018-07-15T14:24:00
ephys/sub-P001_task-push_run-02_ephys.nix	2018-07-15T15:24:00

It is recommended to accompany the *_scans.tsv file with a corresponding *_scans.json sidecar file, as described in the BIDS specifications.

Multiple recordings in a single data file (*_events.tsv)

The *_events.tsv should be used to provide information about multiple parts of an acquisition session when the data from each of these different recordings is stored in a single data file. In such a case, this file is REQUIRED. This allows benefiting from the capability of the supported data formats (NIX and NWB) to store multiple recordings in a single file, which can be convenient when these recordings share numerous characteristics (for example, for subsequent recordings obtained on a single cell in intracellular electrophysiology). In such case, the information about these recordings should be stored in columns added in the *_events.tsv file, which are listed now.

Optional column names in events.tsv to support multiple recordings in a single data file:

Microelectrode Electrophysiology Examples

Toy datasets

Extracellular Electrophysiology

This dataset contains data from a single subject (subject A), that was recorded on two days (2022-01-01 and 2022-01-02). On the first day the subject performed three tasks (nose-poke, reach-to-grasp, and rest), and on the second day only a rest task was performed. The electrophysiology data for each of the four recordings are stored in the corresponding session and ecephys directories in the nix format. Metadata about the probes, their electrodes and the corresponding recording channels are stored in tsv format. Note that in this case, this information is shared between data files (see BIDS Inheritance Principle): in the first session, the probe, electrode and channel files apply to all data files of that session, as they do not contain a task entity in their name. For the behavioral tasks (nose-poke and reach-to-grasp), additional behavioral timestamps (events) were recorded and stored in task-specific events.tsv files.

├─ dataset_description.json 
├─ participants.tsv 
└─ sub-A/
   ├─ sub-A_sessions.tsv 
   ├─ ses-20220101/
   │  ├─ sub-A_ses-20220101_scans.tsv 
   │  └─ ecephys/
   │     ├─ sub-A_ses-20220101_task-nosepoke_ecephys.nix 
   │     ├─ sub-A_ses-20220101_task-nosepoke_ecephys.json 
   │     ├─ sub-A_ses-20220101_task-nosepoke_events.tsv 
   │     ├─ sub-A_ses-20220101_task-reachtograsp_ecephys.nix 
   │     ├─ sub-A_ses-20220101_task-reachtograsp_ecephys.json 
   │     ├─ sub-A_ses-20220101_task-reachtograsp_events.tsv 
   │     ├─ sub-A_ses-20220101_task-rest_ecephys.nix 
   │     ├─ sub-A_ses-20220101_task-rest_ecephys.json 
   │     ├─ sub-A_ses-20220101_channels.tsv 
   │     ├─ sub-A_ses-20220101_electrodes.tsv 
   │     └─ sub-A_ses-20220101_probes.tsv 
   └─ ses-20220102/
      ├─ sub-A_ses-20220102_scans.tsv 
      └─ ecephys/
         ├─ sub-A_ses-20220102_task-rest_ecephys.nix 
         ├─ sub-A_ses-20220102_task-rest_ecephys.json 
         ├─ sub-A_ses-20220102_channels.tsv 
         ├─ sub-A_ses-20220102_electrodes.tsv 
         └─ sub-A_ses-20220102_probes.tsv 

Example sub-A_ses-20220101_task-nosepoke_ecephys.json:

{
  "TaskName": "Nose Poke Task",
  "TaskDescription": "Subject performs nose-poke responses to visual cues for reward",
  "InstitutionName": "Example University",
  "PowerLineFrequency": 60,
  "SamplingFrequency": 30000,
  "HardwareFilters": {
    "HighpassFilter": {
      "Half-amplitude cutoff (Hz)": 0.1,
      "Roll-off": "6dB/Octave"
    }
  },
  "SoftwareFilters": "n/a",
  "RecordingType": "continuous",
  "PharmaceuticalName": ["ketamine", "xylazine"],
  "PharmaceuticalDoseAmount": [10, 1],
  "PharmaceuticalDoseUnits": ["mg/kg", "mg/kg"],
  "BodyPart": "BRAIN",
  "SampleEnvironment": "in-vivo"
}

Example sub-A_ses-20220101_task-reachtograsp_ecephys.json:

{
  "TaskName": "Reach to Grasp Task",
  "TaskDescription": "Subject reaches and grasps objects of different shapes and sizes",
  "InstitutionName": "Example University",
  "PowerLineFrequency": 60,
  "SamplingFrequency": 30000,
  "HardwareFilters": {
    "HighpassFilter": {
      "Half-amplitude cutoff (Hz)": 0.1,
      "Roll-off": "6dB/Octave"
    }
  },
  "SoftwareFilters": "n/a",
  "RecordingType": "continuous",
  "PharmaceuticalName": ["ketamine", "xylazine"],
  "PharmaceuticalDoseAmount": [10, 1],
  "PharmaceuticalDoseUnits": ["mg/kg", "mg/kg"],
  "BodyPart": "BRAIN",
  "SampleEnvironment": "in-vivo"
}

Example sub-A_ses-20220101_task-rest_ecephys.json:

{
  "TaskName": "Resting State",
  "TaskDescription": "Spontaneous activity recording with no task",
  "InstitutionName": "Example University",
  "PowerLineFrequency": 60,
  "SamplingFrequency": 30000,
  "HardwareFilters": {
    "HighpassFilter": {
      "Half-amplitude cutoff (Hz)": 0.1,
      "Roll-off": "6dB/Octave"
    }
  },
  "SoftwareFilters": "n/a",
  "RecordingType": "continuous",
  "PharmaceuticalName": ["ketamine", "xylazine"],
  "PharmaceuticalDoseAmount": [10, 1],
  "PharmaceuticalDoseUnits": ["mg/kg", "mg/kg"],
  "BodyPart": "BRAIN",
  "SampleEnvironment": "in-vivo"
}

Intracellular Electrophysiology (Patch)

This dataset contains intracellular data from slices acquired from two subjects (20220101-A and 20220101B). Details about the subjects and the sample generation are documented in the samples (tsv/json) files. Data of each subject is stored in separate subject directories (top level directories), each of which contains an 'icephys/' subdirectory. Note that there is no session-level directory in this case. Here, we choose the option of having "multiple tasks/runs in separate files" to demonstrate the high level of readability offered by the filenames in this case.

For the first subject only a single sample (a cell for patch-clamp terminology) was extracted (sample-cell001), on which three different protocol recordings were performed: two runs of current injection to characterize intrinsic properties, and one run of synaptic stimulation. The scans.tsv file stores information such as the starting recording times. The detailed information on the recording channel (such as the recording mode used) is stored in the channels.tsv which, in this case, is common to all available recordings. The probes and electrodes files provide information on the pipette and solutions used for the recordings and are also shared across data files.

For the second subject two samples (sample-cell002 and sample-cell003) were extracted and recordings of different tasks (current injection and synaptic stimulation) were performed on each of them. Each recording was performed using a different probe (listed in the probes.tsv) having specific electrode and channel information. Therefore, each data file has a dedicated channel and electrode file with the same name as the data file.

├─ samples.tsv 
├─ samples.json 
├─ participants.tsv 
├─ dataset_description.json 
├─ sub-20220101A/
│  ├─ sub-20220101A_sample-cell001_scans.tsv 
│  └─ icephys/
│     ├─ sub-20220101A_sample-cell001_task-IVcurve_run-1_icephys.nwb 
│     ├─ sub-20220101A_sample-cell001_task-IVcurve_run-1_icephys.json 
│     ├─ sub-20220101A_sample-cell001_task-IVcurve_run-1_events.tsv 
│     ├─ sub-20220101A_sample-cell001_task-IVcurve_run-2_icephys.nwb 
│     ├─ sub-20220101A_sample-cell001_task-IVcurve_run-2_icephys.json 
│     ├─ sub-20220101A_sample-cell001_task-IVcurve_run-2_events.tsv 
│     ├─ sub-20220101A_sample-cell001_task-synaptic_icephys.nwb 
│     ├─ sub-20220101A_sample-cell001_task-synaptic_icephys.json 
│     ├─ sub-20220101A_sample-cell001_task-synaptic_events.tsv 
│     ├─ sub-20220101A_channels.tsv 
│     ├─ sub-20220101A_electrodes.tsv 
│     ├─ sub-20220101A_probes.tsv 
│     └─ sub-20220101A_events.json 
└─ sub-20220101B/
   ├─ sub-20220101B_scans.tsv 
   └─ icephys/
      ├─ sub-20220101B_sample-cell002_task-IVcurve_icephys.nwb 
      ├─ sub-20220101B_sample-cell002_task-IVcurve_icephys.json 
      ├─ sub-20220101B_sample-cell002_task-IVcurve_events.tsv 
      ├─ sub-20220101B_sample-cell002_task-IVcurve_channels.tsv 
      ├─ sub-20220101B_sample-cell002_task-IVcurve_electrodes.tsv 
      ├─ sub-20220101B_sample-cell002_task-synaptic_icephys.nwb 
      ├─ sub-20220101B_sample-cell002_task-synaptic_icephys.json 
      ├─ sub-20220101B_sample-cell002_task-synaptic_events.tsv 
      ├─ sub-20220101B_sample-cell002_task-synaptic_channels.tsv 
      ├─ sub-20220101B_sample-cell002_task-synaptic_electrodes.tsv 
      ├─ sub-20220101B_sample-cell003_task-IVcurve_icephys.nwb 
      ├─ sub-20220101B_sample-cell003_task-IVcurve_icephys.json 
      ├─ sub-20220101B_sample-cell003_task-IVcurve_events.tsv 
      ├─ sub-20220101B_sample-cell003_task-IVcurve_channels.tsv 
      ├─ sub-20220101B_sample-cell003_task-IVcurve_electrodes.tsv 
      ├─ sub-20220101B_sample-cell003_task-synaptic_icephys.nwb 
      ├─ sub-20220101B_sample-cell003_task-synaptic_icephys.json 
      ├─ sub-20220101B_sample-cell003_task-synaptic_events.tsv 
      ├─ sub-20220101B_sample-cell003_task-synaptic_channels.tsv 
      ├─ sub-20220101B_sample-cell003_task-synaptic_electrodes.tsv 
      ├─ sub-20220101B_probes.tsv 
      └─ sub-20220101B_events.json 

Example sub-20220101A_sample-cell001_task-IVcurve_run-1_icephys.json:

{
  "TaskName": "IV Curve Characterization",
  "TaskDescription": "Current injection protocol to characterize intrinsic membrane properties and generate current-voltage curves",
  "InstitutionName": "Example University",
  "PowerLineFrequency": 60,
  "SamplingFrequency": 20000,
  "HardwareFilters": "n/a",
  "SoftwareFilters": "n/a",
  "RecordingType": "epoched",
  "BodyPart": "BRAIN",
  "SampleEnvironment": "ex-vivo",
  "SliceThickness": 300,
  "SliceThicknessUnits": "um",
  "TissueOrigin": "Visual Cortex",
  "CellType": "pyramidal"
}

Example sub-20220101A_sample-cell001_task-synaptic_icephys.json:

{
  "TaskName": "Synaptic Stimulation",
  "TaskDescription": "Electrical stimulation to evoke synaptic responses and characterize synaptic properties",
  "InstitutionName": "Example University",
  "PowerLineFrequency": 60,
  "SamplingFrequency": 20000,
  "HardwareFilters": "n/a",
  "SoftwareFilters": "n/a",
  "RecordingType": "epoched",
  "BodyPart": "BRAIN",
  "SampleEnvironment": "ex-vivo",
  "SliceThickness": 300,
  "SliceThicknessUnits": "um",
  "TissueOrigin": "Visual Cortex",
  "CellType": "pyramidal"
}

Example sub-20220101B_sample-cell002_task-IVcurve_icephys.json:

{
  "TaskName": "IV Curve Characterization",
  "TaskDescription": "Current injection protocol to characterize intrinsic membrane properties and generate current-voltage curves",
  "InstitutionName": "Example University",
  "PowerLineFrequency": 60,
  "SamplingFrequency": 20000,
  "HardwareFilters": "n/a",
  "SoftwareFilters": "n/a",
  "RecordingType": "epoched",
  "BodyPart": "BRAIN",
  "SampleEnvironment": "ex-vivo",
  "SliceThickness": 350,
  "SliceThicknessUnits": "um",
  "TissueOrigin": "Hippocampus",
  "CellType": "interneuron"
}

This toy data set can be found in this repository, with the content of the metadata files. The other option available to organize such data consists in storing several recordings in a single data file (as described in 3.8.2); the same data set is presented using this latter option in this other repository, so that both options can be compared for the same data set.

Examples of Real Datasets

Several real-world datasets have been formatted using this specification and can be used for practical guidance when curating a new dataset.