BEP about non-neuronal physiological (cardiac, respiratory, skin conductance, gastro, ...) data and physiological data derivatives

[smoia]

Your idea

Hello all,

within the physiopy community (website and github) we are facing the issue of talking about physiological data standardisation and physiological data derivatives.

To be clear: the data we're talking about are not M/EEG (no elettrophysiology/neurophysiology). Instead, we refer to data like cardiac or respiratory fluctuations, skin conductance, blood pressure, gas analyses, ...

We know there is already a start of standardisation in the BIDS specification, but having dealt with such data we recognise it might be nice to add more standardisation and information to the specification, including specifications on this data derivatives.

We also know there is a BEP about one type of such data, eyetracking, the BEP020, but we aim at discussing other types of data instead.

I wanted to start sending this message to see if there might be the interest for such a BEP, if there is conflict with other BEPs I'm not aware of, and to see if anyone is interested in joining the effort - we'll discuss about this plenty in our monthly physiopy community meetings starting with the new year to reach a BEP submission.

I hope it's appreciated!

[tsalo]

Can you expand on where the current physio support is insufficient? The physio section is definitely pretty bare bones at the moment, but I think some specific examples would help me understand what you're proposing.

[smoia]

There are a few parts that came up already by talking within the community.

1. Precision: there are at least four different types of data to extract from respiratory-related information (respiratory effort, ventilation, PCO2, PO2, ...); when measuring "cardiac fluctuations", those could come in the form of pulse or heartbeat (PPG vs ECG) - those are very different types of data.

2. Acquisition information: more information should be reported on the type of instrument used for the acquisition, since each of them has its own peculiarity (e.g. MRIs vs specific manufacturers).

3. Peculiar signals with current limitations: another example is continuous blood pressure recordings: at the moment the instruments we have to acquire such data in the MRI is with instruments that do not have a consistent sampling rate - something that is not considered at all by BIDS but is faced by the physio community.

4. User/field customs and possible signal transformations: another thing is the unit of measure - for instance, in the field of cerebrovascular reactivity mapping, the custom is to express gas changes in millimetres of Mercury (mmHg), which is not a SI unit, although all raw signals are measured in (Delta) Volts. Most manufacturers either make the transformation automatically or provide the formula to convert from Volts to whatever other measure is required, and that would be precious information to store. Beside that, it's about enforcing the use of certain unit of measures and alienate a group of users or to ask them to treat their data differently (indicating how).

5. Derivatives: finally, derivatives (e.g. filtering, peak detection, physio models used for denoising) are currently not covered at all - and the problem starts with categorising what is raw data, what is source data, and what is derivative.

Overall, we're talking about moving a few fields from a status of "recommended" to a status of "required" to allow automation of physiological pipelines (e.g. even just plotting respiratory variance over the greyplots in MRIQC, or providing automatic physio data preprocessing based on the modality, and automating the computation of physio fluctuation models like RVT), introducing finer distinctions between modalities, adding a few fields to introduce more information, and discuss derivatives.

[smoia]

Hey! We're currently working on a very rough v0 draft for this BEP, focusing on the derivatives. Once we get to a stage we feel we're ready to open it up, we'll keep you posted!

[tsalo]

Thanks!

Overall, we're talking about moving a few fields from a status of "recommended" to a status of "required"

One issue is that this won't be possible until BIDS 2.0. At a glance, everything else you brought up sounds very doable.

[smoia]

Yeah that is unfortunately clear - although there have been some forms of deprecations already in the specs.

Should we already get a BEP number, or should we wait for a ready draft v0 to do so?

And, would you suggest to split a BEP into derivatives vs raw data, or keep everything together?

[tsalo]

Deprecations are a good workaround for BIDS 1.

I don't think you need the draft to be 100% ready to get a BEP number. Having something basic, but readable, would be sufficient.

And, would you suggest to split a BEP into derivatives vs raw data, or keep everything together?

I'm not sure. @effigies might be better able to answer that.

[effigies]

Note that deprecations generally have meant there are multiple ways of doing things and the old way is now a warning. Making something required means introducing an error, which is essentially forbidden to BIDS 1.x

[effigies]

And, would you suggest to split a BEP into derivatives vs raw data, or keep everything together?

I'm not sure. @effigies might be better able to answer that.

I would need to look to give a recommendation. With derivatives in the spec, proposing changes to raw and derivatives in one go is feasible in a way it wasn't before, but note that derivatives are still not validated with the legacy validator.

[oesteban]

My 2ct - mixing raw and derivatives in a single BEP increases the risk of good/necessary ideas being rejected.

The more I understand the physio specs, the more I can see why experts find it falls short of properly expressing the data. Proposals in the area of "raw" in this case will mostly address those gaps in the spec, and many will be really necessary to better represent the data.

On the other hand, the derivatives aspect of physio is completely open to explore and propose as there is not much about it.

The risk lies in that, as a monolithic BEP, ideas that are urgently needed for "raw" may be stopped back by discussions about "derivatives".

IMHO it is better for everyone (BEP leads, BIDS SC, maintainers, BEP contributors, etc.) to have smaller BEPs with very specific scope, meaning, targeting one aspect at a time.

[smoia]

At the moment we're focusing on derivatives with @me-pic @m-miedema and @rgbayrak, so it's probable that we first propose something on that line. We might even be able to submit a very first draft of a BEP before OHBM (right now we're debating data representation, especially how to indicate peaks and troughs).