lynninnj wrote: ↑Tue Nov 15, 2022 8:29 am
https://sleephq.com/public/3a22af32-0e9 ... a5466f4010
The machine (not oscar and not sleephq show zero ahi. Around 1am and 120ish am you can see the pressure line jumps. When you zoom in you can see what are probably CAs (judging by oscillations from the machine at those times). They are greater than 10s but were not marked.
Because of the Time Zone issue in SleepHQ, there are two possible places where the apnea that lynninnj is talking about could have occurred.
There's a missed apnea-like event with a pressure increase that happened at roughly 1:00 AM EST. It looks like this:
I sure don't see the FOT oscillations in flow rate graph during the apnea that would indicate this is a central event. I'll also add that when I zoom in on the Mask Pressure graph in SleepHQ, that graph also does not show the FOT oscillations that are present in the Mask Pressure graph when drawn in either ResScan or Oscar.
There is a second missed apnea-like event with a pressure increase that happened at roughly 2:00 AM EST. It looks like this:
I'm still not seeing clear evidence of FOT oscillations in the flow rate graph during this apnea either. And again, when I zoom in on the Mask Pressure graph in SleepHQ, while there is a gentle increase and decrease in pressure over the interval, it's not like the
rapid small oscillations pressure that are
accurately portrayed in both ResScan and Oscar. Again, if SleepHQ is displaying the data in the flow rate graph with the same accuracy as Oscar and ResScan, there's evidence that the upper airway is obstructed during this (unflagged) event. And even though the event is not flagged as an OA, the machine does respond to it by a slight increase in pressure.
It seems to me that
if either of these events had been flagged by the machine, they should have been flagged as OAs. And yes, in my opinion, the machine should have flagged both events as OAs, but no machine algorithm is perfect. If an APAP flags things that should not be flagged, then we also get places where the machine doesn't flag an event when it looks like it should have been flagged. It also looks like (to my eyes) that the auto algorithm responded to these events as if the were OAs: Both times, the machine increased the pressure
after the event was over. In other words, the problem seems to be "transcription" errors rather than the machine not accurately detecting an obstruction apnea occurred. In other words, the problem is that the flag on the event didn't get written, not that the machine didn't detect and respond appropriately to the event.
Having said that, I'll also add that
if the event had been scored and
if this were my data, I'd be inclined to write the first (1:00 AM EST) event off as a post-arousal event because of the big breath preceding the event. The second one? It may be a real event. Or it may be an other post-arousal event---if you zoom out just a bit, the breaths immediately before the 2:00 EST event look just a wee bit larger, but the increase is not so dramatic as to scream "arousal".
Now to get into some nitty-gritty details about how Oscar (and ResScan) show the FOT oscillations when they occur---regardless of whether an event is "flagged" as an OA or a CA or not at all.
To understand what the machine is looking for when it runs the FOT algorithm, you need to look at
both the Mask Pressure graph and the Flow Rate graph, and the Mask Pressure graph as drawn by SleepHQ is not accurate enough to show the stuff we're interested in seeing. Here's an example of a CA that was flagged by my machine last night, along with two other areas (not flagged) that looked like they might last long enough for an apnea where the machine started the FOT oscillations:
The fact that you can see oscillations in the flow rate that correspond (exactly) to the FOT oscillations in the mask pressure graph is what Resmed uses as clear cut criteria to flag a CA. Also notice that there is
no increase in pressure following the breathing that did get flagged as a CA. (Zooming out a bit reveals that this CA and the funky breathing before and after are most likely normal transition to sleep breathing.)
Here's what happens when the FOT algorithm classifies an event as an OA:
Note that when the FOTs start in the Mask Pressure graph, there are no corresponding oscillations in the flow rate graph. (That's the stuff in the red box.) Also note that
after the event is over, the machine increases both my IPAP and EPAP by 1cm and that 1cm increase is reflected in both the pressure graph and the mask pressure graph. (Zooming out a bit reveals that this OA most likely part of SWJ: I had turned the machine off and then back on at 6:20---about a minute before this event happens---and sleep breathing doesn't clearly start until about 30-40 seconds after this OA is over.)
The hard thing for the programmers is deciding how much oscillation in the flow rate graph is needed to indicate the airway is
probably clear (i.e. unobstructed). In other words, there are cases where the results of the FOT are not as clearcut as the two previous examples:
My machine flagged this as an OA, but there are clear oscillations in the flow rate graph, both in the
unflagged event that precedes the OA that a bit too "short" to be scored, and in the OA itself. I've restricted the y-range to make it clear that there are some oscillations. Why is this scored as an OA instead of a CA? I'll be honest, I don't know.
Point Number 1: Algorithms are designed by human beings and executed by computers. And no algorithm is perfect. Sometimes our machines will flag something as an event and we'll scratch our heads about why. Sometimes our machines will fail to flag something that we look at and say, that should have been flagged. All of this is why the manufacturers of our machines stress the importance of
trending data. Overall
if there is a genuine problem with ineffective xPAP therapy and too many events are occurring, the trending data will show elevated AHIs over a period of multiple days (weeks or months). But an individual night with an elevated AHI? It's probably not something to worry too much about. Conversely, if xPAP is working well and the patient is sleeping well, the over all trending data should show reasonably low AHIs over a period of multiple days (weeks or months) even though the person may never actually record an overnight AHI = 0.0.
Point Number 2: Yes, if you want to you can scroll through your data every day and the flow rate data itself will give you an idea of what your "true" AHI might be, once you mentally correct for SWJ/probable arousals as well as unflagged events that look "real". But unless something is significantly off in the quality of your therapy, there is unlikely to be a statistically significant difference between the machine calculated AHI and the "real" AHI found by scrolling through the data epoch by epoch and deciding for yourself, "this is a real, but unflagged event" and "this is a flagged event, but it's also probably SWJ/post arousal." Sure, scrolling through the flow rate data can be fun (for us data nerds), but there is a point of diminishing returns in trying to tease out whether each and every single potential event (flagged or unflagged) is a "real" event that would have been scored on a PSG.
Point Number 3: If xPAP is not (yet) working for a particular patient, the nightly detailed data, even though it's "dirty data" is of some use in teasing apart what the problems actually are and consequently how to come up with ideas to fix those problems. If a patient's AHI is well above 5 every night and most of the flagged events are OAs and Hs, that's a pretty good indication that the pressure setting is most likely too low, everything else being equal. If a patient's AHI is well above 5 and the number of CAs vastly outnumber the number of OAs, that can point to the need for further investigation being needed. GeneMpls is a good example of this: His machine's data, even if that data is "dirty", clearly points to something being wrong and that the "something" is not a simple as "the pressure is not enough to keep his airway open."
I'll try to climb down off my soapbox now.
Joined as robysue on 9/18/10. Forgot my password & the email I used was on a machine that has long since died & gone to computer heaven.
Correct number of posts is 7250 as robysue + what I have as robysue1
Profile pic: Frozen Niagara Falls
