? inconsistency in reporting vibratory snores

[Dr.Bob]

I'm trying to make sense of some vibratory snore reports. These are from a Phillips Respironics Dreamstation APAP machine. I am familiar with the posts about VS1 and VS2 but I don't think that the difference between these is the cause of the inconsistencies I'm seeing.

I'm looking at the vibratory snore index for one night, comparing different reports in OSCAR with reports in Encore. Here's what I see:

OSCAR daily report: VS 19.25. VS2 130.59
Encore daily report: VS index 125.7
OSCAR Overview graph: VS2  30.12
Encore overview graph: VS less than 5

I also downloaded the "Daily" CSV export from OSCAR. For that night, it reports:
Total time 6:26:24
VS Count 124
VS2 Count 194

I would be extremely grateful if you can help me interpret these results. I'm happy to upload files if you tell me which ones would be of use.

THANKS!

[LindanHotAir]

Some have reported that VS2 is often reported when you move the tube across something and the ridges cause vibration. It is often a false alarm and can be ignored.

[Dr.Bob]

Lindan,

Thanks. I was asking a question about the software and how it calculates vibratory snore index - not so much about the causes of vibratory snores.

Sleep well!
Bob

[sawinglogz]

The OSCAR daily VS2 (130.59) roughly corresponds to the Encore VS index (125.7). It's common to see slight differences due to rounding: Encore tends to round every interval to the nearest minute, whereas OSCAR calculates things down to the second. This is especially noticeable in events with durations (LL and PB), since Encore's number correspond to rounding *each event* to the nearest minute before summing them to calculate the index.

OSCAR's VS2 corresponds to the "VS" markings in the "sleep therapy flags" chart. Each marking has a number (1 or higher), so OSCAR's VS2 index (corresponding to Encore's VS index) sums those numbers before dividing by the session time.

OSCAR's VS corresponds to the "VS" marking in the waveform chart. These appear to be "severe" snores, as they appear to be a subset of VS2 occurrences (though with more precise timing). OSCAR's VS index is the number of those events divided by the session time. Encore daily reports appear to have no equivalent.

Nice catch on the OSCAR overview graph: that's a bug. It's only counting the number of VS2 markings, not their magnitude like the VS2 index does. That's what we get for having that disabled from overview by default.

I don't know what you mean by an "Encore overview graph".

[Dr.Bob]

Thanks a million!

I recognize that I may be the only OSCAR user who cares about this, but what's the chance of fixing that bug in the next couple of weeks? I need to generate a report and am facing a deadline mid-May.

I'd be happy to make a donation to the Apnea Board in recognition of this work. Thanks again,

[Dr.Bob]

Turns out I was able to generate the graph I need. Since the only export file that contains VS2 counts is the detail file, I had to export the daily, session and detail CSV files, massage them a bit, sum the VS2 counts by session and the session counts by date, and then divide by the usage time. I spot-checked values along the way to confirm that my values match the ones in the Daily views.

In case you're interested, I'll attach the graphic I created plus the OSCAR graphic. And I'm sure that at some point you'll fix the graphic in OSCAR. If you have a minute to drop me a note when you do, I'd appreciate it.

Thanks for all that you put into this. Your work is, quite literally, a life-saver.

Bob

[sawinglogz]

Interesting that we see variance between low-count-per-event and high-count-per-event days. Most of the low-end lines up pretty closely, and only a few high ones really spike on your graph.

I did take a look at this to see if it might be fixed quickly, but it's running into a silly limitation deep within OSCAR whose fix won't make it into this beta cycle. (Specifically, the only sum-per-hour summary type is being treated as a percentage and assuming the values are duration in seconds. This works fine for LL and PB, but not as a general type. We'll need to add a new summary type and test to make sure we haven't broken anything.)