OSCAR Zero duration events

[happydreams]

Not sure if this is real or not, but I am seeing OSCAR reporting zero duration events, for some hypopnea and obstructive apneas.  It may have always done this, but I sure don't remember it (or SH) doing this before.  Is this new?  A feature?  I did a build from git this week.  Curiously I do not see this in my user flags.  There, the event length always has a duration.

1.1.0-testing-4
[attachment=16792]
Is this expected behavior for OSCAR?  Is it impending APAP failure?  None of the above?

[GuyScharf]

ResMed Airsense 10 machines do not report any duration for hypopneas.  SH and OSCAR 1.0.1 arbitrarily added 10 seconds to hypopneas presumably because a hypnopnea is defined as a breathing reduction of 10 seconds or more.  But SH and OSCAR 1.0.1 had no idea at all of the actual duration, so adding 10 seconds results in a very artificial and misleading number.

OSCAR is now reporting the exact duration that your CPAP machine is reporting.  If the machine reports zero seconds, that is what we show.  (If a duration field is zero, we omit the duration entirely rather than showing it as "[0]", which we think would be confusing.  We think that is a more accurate reflection of what the machine is telling us.

[qwerty42]

Hi, using the latest OSCAR 1.1.0 build, all of my obstructive events are being reported without durations (see image). If I hover over the flags in the waveform view, they say "Obstructive (0)".

With SleepyHead, obstruction events had durations for this same machine, and they were generally very close to the observable duration in waveform view. Old data that was migrated to OSCAR, which used to have durations in SleepyHead, also show no durations in OSCAR.

Machine is a Philips Respironics DreamStation Auto CPAP. Firmware is v1.1.1 if it matters.

   

[GuyScharf]

It turns out that PRS machines do not report the duration for events.  Previously, SleepyHead and OSCAR reported a number they found but the actual meaning of that number is unknown.  Thus, in the latest version of OSCAR, no duration is reported for events on PRS machines.

Regarding showing "(0)" after the event in the flow graph, the (0) is being removed in OSCAR 1.1.1 since it is has no meaning.  It was an oversight that this was not removed when the (0) values were removed earlier in the event list and event graph; we're fixing that in 1.1.1.

[qwerty42]

Hi, thanks for the reply. I'm curious how it was determined that the 'unknown number' wasn't actually the event duration. Like I mentioned, it tended to be consistently very close to the length of obstructive events on my waveform views, in seconds. It certainly matched the waveform data as closely as the reported durations for hypopneas, which are still present in OSCAR.

I found it very useful for tracking long obstructive events and trends. I can give examples if it would help...

EDIT: here's an example from SleepyHead. Here's the waveform with the flagged event -- shown as (31):
   

And here's that exact same event, if I highlight 31 seconds of time:
   

You can see they match up really closely. This is just one example, but this is what I always saw, and I've been keeping an eye on this for a couple years. Short events and long events both always matched that number within a couple seconds or less.

[qwerty42]

I was mistaken above about hypopnea event durations -- those also are not in OSCAR anymore. But, in SleepyHead, they too agree very closely with the waveform data.

Can we revisit the conclusion that the DreamStation isn't reporting durations for these? Maybe it doesn't 'officially,' but in all my data it's been way too close to be coincidence, consistently.

[sawinglogz]

Hi, thanks for the reply. I'm curious how it was determined that the 'unknown number' wasn't actually the event duration. Like I mentioned, it tended to be consistently very close to the length of obstructive events on my waveform views, in seconds.

Great question.

The number that's reported internally for an OA/CA/H event is the number of seconds before the event timestamp that the event started. This was established by examining official waveform reports for sample data, correlating the shown events with the timestamps in the data stream.

The problem is that an OA/CA/H event can't be identified as over until some amount of time after the flow returns to "normal" (or at least below the OA/CA/H threshold), so the timestamp at which an event is reported isn't the end of the event -- it's some unknown interval afterwards. Therefore, the interval between event start and when it's reported isn't its actual duration.

You're right that it's loosely related, but it's not actually the true duration that the machine reports.

To establish the true duration, we'd need to analyze the flow ourselves using the PRS1 metrics for OA/CA/H and identify when those metrics indicate that the event has actually ended. It's possible that in doing so we might find a fixed interval after the end of an event at which the event is reported, but we currently have no evidence to support any particular interval.

So, since the data we have is known not to be the duration, we don't report it as the duration.

A big focus for this version has been accuracy rather than approximation or guesswork. If we can calculate things like duration accurately when they're not natively reported, I'd love to do so. But we're not there yet.

[sawinglogz]

p.s. Looking at your 31-second event, it would have been reported at 07:44:37, which is clearly past the OA event. The OA flag is drawn 31 seconds before 07:44:37, at 07:44:06.

Also note that your OA actually appears to begin well before 07:44:06.

I'm not sure off the top of my head what definition PRS1 uses for flagging OA events. I recall that H events are a 40% reduction in flow for at least 10 seconds. Given that, I suspect that your reduction in flow began at 07:43:56 and the OA mark is the point at which the 10-second requirement for reduced flow has been met.

By that reasoning it's possible that your OA is really 36+ seconds (from 07:43:56 through 07:44:32). Or maybe it ends even later, given the pressure pulse we see at 07:44:33...

[qwerty42]

Hi, and thanks for taking the time to write out those detailed replies. Much appreciated. I'm an engineer myself, so I always enjoy technical details

I understand what you're saying. It sounds like the missing piece we really need to know is why it sets the event timestamp when it does.

It's known to be detecting the start of the event, somehow (probably a % flow reduction and time interval, as you stated). But it's setting the timestamp somewhere out beyond that, and that distance is always correlated to the total length of the event, in my years of data. Based on that, I think it's very likely that it's somehow detecting a start and an end, because if it were timestamping it based on a fixed interval after detection, you wouldn't see time offsets varying from 1 second to 1 minute and everything in between.

To clarify:

• Machine detects an event start (probably based on flow reduction % and a fixed time interval threshold, combined)
  
• Machine does not actually timestamp the detected event until some variable time after this
  
• The variable time after detection when it gets stamped strongly correlates to the total event duration, for both very short and very long events, consistently
  
• The variable time window would not fluctuate that much if it were using a fixed-time offset to actually do the flagging. It must somehow be related to the end of the event.
  

If it'd help, I'd be willing to try to figure out how it actually correlates based on my own data. I might be able to test it in a more controlled way by running the machine and intentionally blocking flow over a range of time intervals. Based on the logic above, it must be setting that gap between detection and timestamp based on flow start and flow re-start, IMO.

PS -- the reason I care about this is it made it really easy to quickly see and select long events from the Events pane in the Daily view. If I saw something in there that said Obstruction(42), I could click it and know for sure it was going to be a longer one close to 40 seconds, whereas one labeled (3) would for sure be a much shorter one.

[sawinglogz]

That's an interesting use case to find significant apneas. I can definitely see why you'd want duration back!

When I said "fixed interval," I didn't mean from the start, but from the end. For example, if their definition of OA-end were "normal flow for at least 5 seconds," then I'd expect to see the event reported 5s after the end of the OA.

But as with all such metrics, I suspect detecting the end is a little more complicated than that. Is it a rolling flow average that needs to reach a previous threshold? Is it breath amplitude reaching some minimum? Something else?

p.s. If you can really hold your breath for the time needed to track this, you've got some pretty good physical conditioning! I also don't know if holding your breath will show up as breathing-not-detected vs. OA.