Calculating sleep onset latency etc

[Kerstin Blom]

Hi all,

I'm analyzing data for an insomnia treatment study and am trying to calculate the classic parameters: Sleep onset latency (SOL), Wake after sleep onset (WASO), Total sleep time (TST) and Sleep efficiency (SE).

I find this harder than expected with the output files I have from the GGIR package (and my R-expert is unavailable). Perhaps you can help?

The analysis are done using sleep diary data, i.e. guiders.

That is the overall question I have. Specifically I found these things that puzzled me:

I wanted to calculate SOL from the variables  sleeponset minus guider_onset in the file part4_nightsummary_sleep_full, but that resulted in negative values since sleeponset can, apparently, start before guide_onset (I thought all sleep variables were calculated within the guider sleep period time when guider was used). I realize it makes sense that people can remember guider_onset wrongly, but how do you handle that for sleep parameter calculations?

A follow-up question is, if sleeponset can start before guider_onset, how is SleepDurationInSpt calculated for those whose sleeponset precedes the guider_onset, is it within or outside the guider sleep period time? This is crucial to know also for WASO-calculations.

Crossing my fingers that someone can help!

Thanks,

Kerstin

[Vincent van Hees]

Hi Kerstin, see my responses below.

Dr. Vincent van Hees | Independent consultant | https://accelting.com/

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Tuesday, November 9th, 2021 at 14:52, Kerstin Blom <kersti...@gmail.com> wrote:

Hi all,

I'm analyzing data for an insomnia treatment study and am trying to calculate the classic parameters: Sleep onset latency (SOL), Wake after sleep onset (WASO), Total sleep time (TST) and Sleep efficiency (SE).

I find this harder than expected with the output files I have from the GGIR package (and my R-expert is unavailable). Perhaps you can help?

The analysis are done using sleep diary data, i.e. guiders.

That is the overall question I have. Specifically I found these things that puzzled me:

I wanted to calculate SOL from the variables  sleeponset minus guider_onset in the file part4_nightsummary_sleep_full, but that resulted in negative values since sleeponset can, apparently, start before guide_onset (I thought all sleep variables were calculated within the guider sleep period time when guider was used). I realize it makes sense that people can remember guider_onset wrongly, but how do you handle that for sleep parameter calculations?

> By default GGIR only uses the guider to look for overlap with sustained inactivity bouts (the rest periods according to the accelerometer data). Those with overlap are then used to define sleep onset. So, the exact timing of onset is driven by the accelerometer, but the time window to consider is driven by the guider. If you want GGIR to fully rely on the guider for defining onset and wake then use argument relyonguider=TRUE

A follow-up question is, if sleeponset can start before guider_onset, how is SleepDurationInSpt calculated for those whose sleeponset precedes the guider_onset, is it within or outside the guider sleep period time? This is crucial to know also for WASO-calculations.

> If a person falls a sleep before reporting to go to bed, then you will end up with a negative sleep latency, calculated as timing of sleep onset according to lack of movement minus timing of going to bed according to guider. Sleep efficiency is calculated as accumulate sleep divided by time in bed according to guider. Both sleep efficiency and sleep latency are only calculated as endpoint and not used as input for any of the other calculations in GGIR.

> More generally, if you want to better understand the sleep variables then I would encourage you to inspect the nightsummary report and try to recalculate sleep efficiency, sleep latency, and sleep period time window from the other variables.

> If you feel that parts of the documentation are far from clear and need improvement then please say so, preferable with suggestions on how I can improve it.

Crossing my fingers that someone can help!

Thanks,

Kerstin

--

You received this message because you are subscribed to the Google Groups "R package GGIR" group.

To unsubscribe from this group and stop receiving emails from it, send an email to RpackageGGIR...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/RpackageGGIR/79ce258f-6c05-41af-bb56-8a1e757e7029n%40googlegroups.com.

[Kerstin Blom]

Hi Vincent!

Thanks so much for your response! I would be happy to suggest clarifications of the documentation once it's all clear to me. I do indeed plan to do all the calculations myself, I'm however still not clear on one crucial matter:

"Sleep efficiency is calculated as accumulate sleep divided by time in bed according to guider."

So, does this mean that all sleep data in the package output relate to the accelerometer data rather than the guider? I.e. does the accumulated sleep time (SleepDurationInSpt I assume) include any sleep time that occurred prior to guider_onset (and after guider_wake I guess)? I.e. could a very solid sleeper end up with a sleep efficiency > 1 (if the guider bed time is used to calculate it, perhaps it's not)? Or is SleepDurationInSpt only the sleep that occurs within the guider window?

Again, sorry for the trouble but immensely grateful for the help!

/Kerstin

--
You received this message because you are subscribed to a topic in the Google Groups "R package GGIR" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/RpackageGGIR/wLUV-oY0Vu8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to RpackageGGIR...@googlegroups.com.

[Vincent van Hees]

Hi Kerstin,

Sorry for the slow reply, I have been quite busy recently.

> "Sleep efficiency is calculated as accumulate sleep divided by time in bed according to guider." So, does this mean that all sleep data in the package output relate to the accelerometer data rather than the guider?

If relyonguider=false (default) then it is a fusion of both. For sleep latency and sleep efficiency the situation is different, because they always need time of going to bed which at the moment can only come from a sleep log. GGIR does not try to estimate this.

>  I.e. does the accumulated sleep time (SleepDurationInSpt I assume) include any sleep time that occurred prior to guider_onset (and after guider_wake I guess)? I.e. could a very solid sleeper end up with a sleep efficiency > 1 (if the guider bed time is used to calculate it, perhaps it's not)? Or is SleepDurationInSpt only the sleep that occurs within the guider window?

If sleep happens outside the guider window then it is not counted as sleep. If sleep partially overlaps with the guider window then that expands the Sleep period time window. For example, if I fall asleep at 10pm, but report to go to bed at 10.30pm then you will get a negative sleep latency of 30 minutes and if I would sleep non-stop until waking up the next morning then that would results in a sleep efficiency higher than 100%. This may be inevitable as long as we blindly trust on sleep diaries and GGIR. The best solution to me is to always review the results and try to spot these implausible estimates, and then either leave out the corresponding nights or correct the sleeplog if you think that sleeplog correction can be justified. For example if you see 8:30 in the sleeplog but 18:30 in the data you may want to argue that the participant probably forgot to write down that 1. Although, I guess these 'corrections' should be done with caution.

Another route could be to try to improve GGIR's ability to spot and handle situations like this either in an automated way or via some kind visual data check approach.

For example, it could be good to have some visual interface to quickly review and where manually necessary correct the sleep classifications. If know a way to find funding for such development then I would be interested to work on this.

Best wishes,

Vincent

Dr. Vincent van Hees | Independent consultant | https://accelting.com/

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

You received this message because you are subscribed to the Google Groups "R package GGIR" group.

To unsubscribe from this group and stop receiving emails from it, send an email to RpackageGGIR...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/RpackageGGIR/CAPaojeM%2BX%3DLRs4-EvGG7KZpeg9LtH767LVOZ1vTPf3ieLhOw7A%40mail.gmail.com.