Skip to content

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.

Samples and the sample-<label> Entity

The sample-<label> entity identifies the biological sample from which a recording was made, and is used to distinguish between different samples from the same subject. The label MUST be unique per subject and is RECOMMENDED to be unique throughout the dataset.

The entity is REQUIRED for icephys data and OPTIONAL for ecephys data. Intracellular recordings are always made from a discrete sample, so the entity is required even when a subject yields only a single sample, and even when the recording is made in vivo, because the patched cell is itself the sample. Requiring the entity in the single-sample case avoids having to rename files if a second sample is added later. Extracellular recordings are frequently made in vivo without an identifiable sample, so the entity is kept optional for ecephys so that such datasets are not forced to define one. It SHOULD be used when an extracellular recording is made from a sample such as an acute slice or a cultured cell population.

A sample corresponds to the finest granularity of biological material from which signals are measured. For patch clamp recordings this is the individual cell (for example, sample-cell001), and for in vitro extracellular recordings it is typically the slice or the cell population.

Where several samples are obtained from a common source, for example several cells patched from one slice, the source MAY also be described as a sample in samples.tsv and linked to the samples derived from it using the derived_from column. Such a parent sample generally does not appear as a sample-<label> entity in recording filenames, since it is not itself what was measured.

Whenever the sample-<label> entity is present in a filename, the dataset MUST include a samples.tsv file describing each sample. This applies to both icephys and ecephys data. See the Intracellular Electrophysiology example below for a dataset organized this way.

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, RRID:SCR_016196) .nix An open standard data model and API for annotated research data with an HDF5 file backend and a defined interface to many microephys formats via the Neo library ( RRID:SCR_000634). The .nix file has to contain a valid Neo structure.
Neurodata Without Borders (NWB, RRID:SCR_015242) .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 (RRID:SCR_003931)).

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>][_space-<label>]_electrodes.json
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<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>][_space-<label>]_electrodes.json
            sub-<label>[_ses-<label>][_sample-<label>][_acq-<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. The tables below group top-level JSON keys by topic for readability only and do not imply any nesting in the file.

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 OPTIONAL string The address of the institution in charge of the equipment that produced the measurements.
InstitutionalDepartmentName OPTIONAL 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 OPTIONAL string Manufacturer's model name of the equipment that produced the measurements.
ManufacturersModelVersion OPTIONAL string Manufacturer's model version of the equipment that produced the measurements.
RecordingSetupName OPTIONAL 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 OPTIONAL 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 OPTIONAL string Name of the software that was used to present the stimuli. The name of the software suite used to record the data.
SoftwareVersions OPTIONAL 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"}}.

Pharmaceuticals

Key name Requirement Level Data type Description
PharmaceuticalName OPTIONAL string Name of administered pharmaceutical. Note that this is distinct from any radiotracer or contrast agent used in the scan protocol. This partly matches DICOM Tag (0018,0034) Intervention Drug Name.
PharmaceuticalDoseAmount OPTIONAL number or array of numbers Dose amount of administered pharmaceutical. Corresponds to DICOM Tag (0018,0028) Intervention Drug Dose.
PharmaceuticalDoseUnits OPTIONAL string Unit format relating to pharmaceutical dose (for example, "mg" or "mg/kg").
PharmaceuticalDoseRegimen OPTIONAL string Details of the pharmaceutical dose regimen. Either adequate description or short-code relating to regimen documented elsewhere (for example, "single oral bolus").
PharmaceuticalDoseTime OPTIONAL 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. Corresponds to a combination of DICOM Tag (0018,0027) Intervention Drug Stop Time and DICOM Tag (0018,0035) Intervention Drug Start Time.

Sample

Key name Requirement Level Data type Description
BodyPart RECOMMENDED string Body part of the organ / body region scanned. Corresponds to DICOM Tag (0018,0015) Body Part Examined.
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 OPTIONAL 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 OPTIONAL 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 OPTIONAL string Longer description of the task.
Instructions OPTIONAL 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 OPTIONAL string URI of the corresponding Cognitive Atlas Task term.
CogPOID OPTIONAL 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 REQUIRED 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.
stream_identifier OPTIONAL string Identifier of the data stream within the data file that holds the signal, for example the internal path of the neurodata object in an NWB file.

This column may appear anywhere in the file.
description OPTIONAL string Brief free-text description of the channel, or other information of interest. For a channel that is not generated by an electrode, and so has n/a in the electrode_name column, use this column to state what the signal is, for example, Synchronization pulse from the behavioral control system. The category of such a channel is given by the type column, for example, SYNC or BEH.

This column may appear anywhere in the file.
software_filter_types OPTIONAL string 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 OPTIONAL 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_identifier Column

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

For NWB files (.nwb): The stream_identifier 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_identifier 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_identifier 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_identifier 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:

nameelectrode_namereferencetypeunitssampling_frequencygainstatusstatus_description
ch001e001ref01LFPuV1000500goodn/a
ch002e002ref01LFPuV1000500goodn/a
ch003e003ref01HPuV30000500goodn/a
ch004e004ref01HPuV30000500badhigh_noise
ch005e005ref02LFPuV1000500goodn/a
ch006n/an/aSYNCV300001goodn/a

Intracellular electrophysiology example:

nameelectrode_nametypeunitssampling_frequencyrecording_modegaingroundstatus
patch01patch01VMmV20000current-clamp10AgClgood
patch02patch02VMmV20000current-clamp10AgClgood
sharp01sharp01IMpA20000voltage-clamp5AgClgood

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.

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 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 OPTIONAL 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.
anatomical_location RECOMMENDED string The anatomical structure in which the electrode is located (for example, cortical layer 3, CA1, MOp). Terms from a species-specific atlas are acceptable, and are often preferable to species-independent terms. The ontology or atlas the terms are taken from SHOULD be documented in the corresponding *_electrodes.json file, using TermURL for the column and, where the individual terms are resolvable, Levels to map each term to its own TermURL (see Tabular files).

This column may appear anywhere in the file.
localization_method OPTIONAL string The method used to determine the anatomical location of the electrode, for example, histology, atlas registration, stereotaxic coordinates, or post-operative imaging. Where the same method applies to every electrode in the file, it MAY instead be given once in the LocalizationMethod field of the corresponding *_electrodes.json file. It MUST NOT be given in both places.

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.

Anatomical Location

Anatomical location is described at two levels of detail. The anatomical_location column of *_probes.tsv names the structure in which the probe as a whole is placed, which for a probe spanning several structures MUST be a structure containing all of them, and may be as coarse as brain or a single hemisphere. The anatomical_location column of *_electrodes.tsv names the structure in which an individual recording site is located, and is where a per-contact localization belongs. Only the electrode-level column can describe a probe that passes through several structures, which is common for long shank probes.

Terms may be taken from a species-independent ontology such as Uberon or from a species-specific atlas or ontology such as the Mouse Brain Atlas Ontology, and a species-specific is often the better choice. The source the terms come from SHOULD be documented in the sidecar file, in the way BIDS documents any other tabular column, as described in Tabular files. Where the individual terms resolve, give each one its own TermURL under Levels. Where they do not, name the atlas in the ReferenceAtlas field of the sidecar.

The method used to determine the location SHOULD be recorded. Where it differs between recording sites, use the localization_method column of *_electrodes.tsv. Where the same method applies to every electrode in the file, it MAY be given once in the LocalizationMethod field of the corresponding *_electrodes.json file instead, but it MUST NOT be given in both places.

Key name Requirement Level Data type Description
LocalizationMethod OPTIONAL string The method used to determine the anatomical location of the electrodes described in the corresponding *_electrodes.tsv file, for example, "histology", "atlas registration", "stereotaxic coordinates", or "post-operative imaging". This field applies to every electrode in the file. Where the method differs between electrodes, use the localization_method column of *_electrodes.tsv instead. The method MUST NOT be specified in both places.
ReferenceAtlas OPTIONAL string Name and, where applicable, version of the reference atlas from which the values of anatomical_location in the corresponding *_electrodes.tsv file are taken, for example, "Allen Mouse Brain Common Coordinate Framework v3" or "D99 macaque atlas v2.0". Some atlases publish region names but no identifiers that can be looked up, so that the terms cannot be documented with a TermURL. Where anatomical_location is taken from such an atlas, this field is what makes the names interpretable and SHOULD be given.

In the following *_electrodes.json example the atlas resolves its individual structures, so each term used in the table is given its own TermURL:

{
  "anatomical_location": {
    "Description": "Structure the electrode is located in, from the Allen Mouse Brain Atlas",
    "Levels": {
      "MOp": {
        "Description": "Primary motor area",
        "TermURL": "https://atlas.brain-map.org/atlas?atlas=602630314#structure=985"
      },
      "CA1": {
        "Description": "Field CA1",
        "TermURL": "https://atlas.brain-map.org/atlas?atlas=602630314#structure=382"
      }
    }
  },
  "LocalizationMethod": "histology",
  "ReferenceAtlas": "Allen Mouse Brain Common Coordinate Framework v3"
}

In the next example the atlas publishes region names but nothing to resolve them to, so there are no TermURL values to give and ReferenceAtlas is what makes the names in anatomical_location interpretable:

{
  "LocalizationMethod": "stereotaxic coordinates",
  "ReferenceAtlas": "D99 macaque atlas v2.0"
}

In both examples the localization method is given once in the sidecar because it is the same for every electrode in the file.

Because a dataset may contain more than one *_electrodes.tsv file for the same recording, distinguished by the space-<label> entity, localizations produced by different atlases or different methods can be provided alongside one another, each with its own ReferenceAtlas and LocalizationMethod.

Example *_electrodes.tsv

Extracellular electrophysiology example (probe-relative coordinates):

nameprobe_namexyzhemisphereimpedanceshank_idsizematerialanatomical_locationlocalization_method
e001probe01000L1.2015iridium-oxideMOphistology
e002probe010025L1.1015iridium-oxideMOphistology
e003probe010050L1.3015iridium-oxideMOphistology
e004probe010075L1.4015iridium-oxideMOphistology
e005probe02000R2.1n/a12tungstenCA1histology
e006probe020015R2.3n/a12tungstenCA1histology
e007probe020030R1.9n/a12tungstenCA1histology
e008probe020045R2n/a12tungstenCA1histology

Intracellular electrophysiology example:

nameprobe_namexyzhemisphereimpedancepipette_solutioninternal_pipette_diameterexternal_pipette_diametermaterialanatomical_location
patch01pipette01000L5.2K-gluconate1.52.5borosilicate-glassVISp2/3
patch02pipette02000R4.8K-gluconate1.52.5borosilicate-glassVISp2/3
sharp01pipette03000L803M KCl0.51borosilicate-glassPL5

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 (neurological convention).

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 -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 -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 OPTIONAL 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 OPTIONAL 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 -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, but REQUIRED if AP, ML, or DV are present string Anatomical reference point from which the stereotaxic coordinates of the probe are measured (for example, Bregma, Lambda). This column MUST be defined whenever any of the AP, ML, or DV columns are present, for every species, since those coordinates cannot be interpreted without it.

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".
anatomical_location RECOMMENDED string The anatomical structure in which the probe is placed, for example, brain, left hemisphere, isocortex, or CA1. This column describes the probe as a whole, so the structure named here SHOULD be one that contains every recording site on the probe. A probe that spans several structures SHOULD therefore be described here by a containing structure, with the location of each recording site given in the anatomical_location column of the *_electrodes.tsv file. Terms from a species-specific atlas are acceptable, and are often preferable to species-independent terms, and the source they come from SHOULD be documented in the corresponding *_probes.json file as described for the anatomical_location column of *_electrodes.tsv.

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_nametypeAPMLDVAP_angleML_anglerotation_anglehemispheremanufacturerdevice_serial_numberelectrode_countwidthheightdepthcoordinate_reference_pointanatomical_reference_pointanatomical_locationmaterial
probe01silicon-probe-2.51.5-41500LIMECNP1100-2205384702010tipBregmaisocortexsilicon
probe02tetrode-1.2-2.1-3.501045RNeuralynxTT-123454n/an/an/atipBregmaCA1tungsten

Intracellular electrophysiology example:

probe_nametypeAPMLDVAP_angleML_anglerotation_anglehemispheremanufacturerelectrode_countcoordinate_reference_pointanatomical_reference_pointanatomical_location
pipette01patch-pipette-1.80.5-2.23000LSutter1tipBregmaVISp2/3
pipette02patch-pipette-1.8-0.5-2.23000RSutter1tipBregmaVISp2/3
pipette03sharp-electrode-3.21.2-3.82050LWPI1tipBregmaPL5

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 (part of SpikeInterface, RRID:SCR_021150) 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 "pixels" if MicroephysCoordinateSystem is Pixels.

Must be one of: "pixels", "m", "mm", "cm", "um".
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.

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:

filenameacq_time
ephys/sub-P001_task-pull_run-01_ephys.nix2018-07-15T09:45:30
ephys/sub-P001_task-pull_run-02_ephys.nix2018-07-15T13:24:00
ephys/sub-P001_task-push_run-01_ephys.nix2018-07-15T14:24:00
ephys/sub-P001_task-push_run-02_ephys.nix2018-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 supported data formats (NIX and NWB) can store several separate recordings in a single data file. This is convenient when the recordings share numerous characteristics, for example subsequent sweeps obtained from a single cell in intracellular electrophysiology, or an extracellular acquisition that was paused and resumed several times within one session. Because BIDS otherwise assumes that each data file holds one continuous recording, the start and duration of every recording stored in such a file MUST be described in the *_events.tsv file, and in this case that file is REQUIRED.

Each recording MUST be described by one row of the *_events.tsv file. The standard onset and duration columns give the start time and duration of that recording relative to the start of the data file. The row MUST also identify the recording within the data file using the stream_identifier column, which follows the same conventions as the stream_identifier column of the *_channels.tsv file: for NWB files this is the internal HDF5 path of the neurodata object holding the recording, and for NIX files it is the corresponding block or data array. Rows that describe other events in the same file (for example, stimuli or behavior) MUST use n/a in the stream_identifier column. The HED column SHOULD be used to annotate these rows with the HED tag Recording, which makes the nature of the event explicit to tools that read the *_events.tsv file. As for any use of HED, the HEDVersion field SHOULD then be given in dataset_description.json (see the HED Appendix). The trial_type column SHOULD NOT be used to label recordings, since it is reserved for the categorization of experimental trials. Further columns MAY be added, as for any *_events.tsv file, and SHOULD be described in the accompanying *_events.json sidecar.

Example of a *_events.tsv describing three recordings stored in a single NWB file, together with a stimulus event that occurred during the second recording:

onsetdurationstream_identifierHED
0120/acquisition/ElectricalSeries_000Recording
131.2300/acquisition/ElectricalSeries_001Recording
2500.5n/aSensory-event, Auditory-presentation
473.9180/acquisition/ElectricalSeries_002Recording

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"
}

The other option available to organize such data consists in storing several recordings in a single data file, as described in Multiple recordings in a single data file.

Examples of Real Datasets

Example datasets formatted according to this specification are maintained in the bids-examples repository and can be used for practical guidance when curating a new dataset:

Further real-world datasets are being organized according to this specification in the bids-dandisets project, which mirrors datasets from the DANDI Archive in BIDS layout.