Pulse Oximeters in CPap machines.

[dataq1]

Everything else he said about the app tho I agree with and resmed wants you to use it but it’s useless. Sounds like he is creating his own scale by which he “scores” your data.
Personally I don’t need that. I can score it on my own.

I think that we (here) all agree that the Myair app is essentially useless.

You say that you can score in your own. I've no doubt that you feel that level of confidence, the the question I'd pose to you is:

Would you disregard valid oximetry data if you had that along with flowcurves?

[robysue1]

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.

[lynninnj]

Everything else he said about the app tho I agree with and resmed wants you to use it but it’s useless. Sounds like he is creating his own scale by which he “scores” your data.
Personally I don’t need that. I can score it on my own.

I think that we (here) all agree that the Myair app is essentially useless.

You say that you can score in your own. I've no doubt that you feel that level of confidence, the the question I'd pose to you is:

Would you disregard valid oximetry data if you had that along with flowcurves?

I wouldn’t disregard oximetry data at all. I agree it would be quite useful. Especially side-by-side with the regular data from your flow curves, etc.

The only reason I feel comfortable grading my own data is because of this board and I’m sure the average layperson would not feel so confident.

The point I was trying to make however, it was that selectively quoting Nick when he says “resmeds data sucks” or thereabouts is disingenuous because he was only speaking of the app. at least that’s what I got out of it.

It sounds like he’s creating an app as a replacement for the my air app.

[lynninnj]

I'll try to climb down off my soapbox now.

just to be clear Ruby, Sue I’m not sure if you think I’m disagreeing with you per se. I really don’t disagree with you at all. I was trying to give an example of how even the best laid plans sometimes don’t work out.

Like you say, they are algorithms written by humans and we are fallible . The long and short of it was that there is a certain margin of error in the data. I find that margin of error acceptable. I find the data extremely helpful in spite of that.

I don’t think the doctor dataq mentioned should be throwing out the baby AND the bathwater. there is far too much useful information to be gleaned.

[dataq1]

I don’t think the doctor dataq mentioned should be throwing out the baby AND the bathwater. there is far too much useful information to be gleaned.

@Lynninni, if you are referring to the anecdote I passed along in GeneMpls's thread, I only recounted that exchange to relay that the doctor (and by his extension that hospital staff) are cautious about taking Respironics (or Resmed's or Devilbus') interpretation as "Gospel Truth".
While I did not interrogate him about it, (as I said I was somewhat taken aback) I think he was referring to the analysis rather than the raw data.
Having worked in medical facilities (some time ago) I know that they can be wary of accepting "outside" interpretations or analysis of data.

Anyways, I simply assign it as a difference in perspective. There is no reason for me to expect that the doctors perspective and mine should be exactly the same. Said another way, I can choose to place faith in my home blood pressure cuff, and the doctor may have more faith in the mercury aneroid sphygmomanometer with stethoscope on his wall. I don't necessarily that translate that to "throwing out the baby".

[dataq1]

above

Are you saying that SleepHQ is misrepresenting flow-rate curves? (FOT present in OSCAR's depiction but not in SleepHQ's depictions for the same time period)?

[Rubicon]

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:

See what the FOTs look like in Oscar. I'm finding that SleepHQ waveforms do have have the same level of definition as ResMed/Oscar.

Also I hate that you can't change y-axis scale.

I *think* FLs are a little dampened, too. Don't have anything in both programs tho to do a correct compare.

[Rubicon]

And I think Nick is running a game with that oximetry download. Really doesn't make sense compared with the respiratory parameters. The landmarks seem to line up but the oximetry looks a lot like wake artifact. Plus he's got a tell at 4:07 when he introduces the oximeter waveforms and again and at 5:22 . There's lies there.

[Rubicon]

I mean, if there's respiratory stuff there, let's see the waveforms!! What are you hiding?

[robysue1]

@Lynninni, if you are referring to the anecdote I passed along in GeneMpls's thread, I only recounted that exchange to relay that the doctor (and by his extension that hospital staff) are cautious about taking Respironics (or Resmed's or Devilbus') interpretation as "Gospel Truth".

There's enough going on in GeneMpls's daily data that screams, "Something is WRONG" even if you don't accept ResScan's presentation of the raw data written to the SD card as "the Gospel Truth."

And any decent sleep doctor seeing GeneMpls's data would start to ask the same kinds of questions that Rubicon is asking and start looking at the flow rate data itself (rather than the labels). And hopefully any decent doctor would conclude that the problem might well be an issue with pressure induced central hypopneas and CAs and general ventilation stability that probably needs to be addressed by moving GeneMpls to an AVS machine since GeneMpls is now 2 or 3 months into therapy and those centrals are not resolving.

But if a doc simply dismisses ResScan's presentation of the data as "not trustworthy" (as you have suggested in the past), that doc is not likely to have enough curiosity to use ResScan to scroll through the flow rate data at a level where you can see what the problem is---if you know what you are looking for in terms of possible CompSAS.

And had GeneMpls been set up with a CPAP "brick" that records nothing but usage data? All he and his docs would have to on is that he's still not feeling well. And sad to say, when a patient says they are still not feeling well and there's no data (regardless of how dirty that data might be) to base a guess on, most sleep docs will simply assume the problem is either related to leaks or is related to the pressure setting not being high enough to prevent the obstructive events.

There was a reason GeneMpls's sleep doc reduced his pressure from 15 to 12. (See the very first post in GeneMpls's thread.) But the doc must not have told GeneMpls why he was ordering the pressure reduction because GeneMpls hasn't told why that pressure reduction was done. My guess is that GeneMpls's doc saw a ResScan printout (perhaps from the DME) that showed almost no OAs, but lots and lots of CAs as well as lots of Hs, and ordered a pressure reduction to see if the CAs would resolve. But they haven't.

Anyways, I simply assign it as a difference in perspective. There is no reason for me to expect that the doctors perspective and mine should be exactly the same. Said another way, I can choose to place faith in my home blood pressure cuff, and the doctor may have more faith in the mercury aneroid sphygmomanometer with stethoscope on his wall. I don't necessarily translate to "throwing out the baby".

These days, most docs treating folks with high blood pressure strongly encourage their patients to regularly take their blood pressure using a home blood pressure cuff and even keep a record of it. And many of them will ask some cursory questions about whether that data indicates the BP is behaving itself at home when they see the patient at an appointment. Yes, the home device might not be as accurate as a mercury aneroid sphygmomanometer with stethoscope in the hands of a good nurse, but the home device gives you and the doctor important trending data that cannot be ignored in terms of making sure that the blood pressure is genuinely under control every day.

[lynninnj]

I mean, if there's respiratory stuff there, let's see the waveforms!! What are you hiding?

Aye! I see what you mean now. Thanks.

Re my prior comment about seeing oscillation on my own zero ahi night- I didn’t realize I didn’t have it zoomed in as much as Robysue did and thought it was oscillating. Thanks RS for pointing it out.

Twas an honest mistake but the jist was still intact-sometimes the machine doesn’t mark as it should and there’s a margin of error.

[lynninnj]

I don’t think the doctor dataq mentioned should be throwing out the baby AND the bathwater. there is far too much useful information to be gleaned.

@Lynninni, if you are referring to the anecdote I passed along in GeneMpls's thread, I only recounted that exchange to relay that the doctor (and by his extension that hospital staff) are cautious about taking Respironics (or Resmed's or Devilbus') interpretation as "Gospel Truth".
While I did not interrogate him about it, (as I said I was somewhat taken aback) I think he was referring to the analysis rather than the raw data.
Having worked in medical facilities (some time ago) I know that they can be wary of accepting "outside" interpretations or analysis of data.

Anyways, I simply assign it as a difference in perspective. There is no reason for me to expect that the doctors perspective and mine should be exactly the same. Said another way, I can choose to place faith in my home blood pressure cuff, and the doctor may have more faith in the mercury aneroid sphygmomanometer with stethoscope on his wall. I don't necessarily that translate that to "throwing out the baby".

ot- I find it particularly annoying when the clinician taking my BP lets the air out very quickly or is speaking to me. I know how to take bp and that aint it. There’s plenty of room for a human margin of error there also.

I understand what you are saying though.

[lynninnj]

And I think Nick is running a game with that oximetry download. Really doesn't make sense compared with the respiratory parameters. The landmarks seem to line up but the oximetry looks a lot like wake artifact. Plus he's got a tell at 4:07 when he introduces the oximeter waveforms and again and at 5:22 . There's lies there.

trying way to hard to sell it when really it would gain more traction to be accurately presenting the product even if it takes a few extra days.

[palerider]

sometimes the machine doesn’t mark as it should and there’s a margin of error.

Sometimes you *THINK* the machine doesn't mark as it should, because you're not accurately measuring the duration of the event.

[palerider]

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.

When I looked at sleephq recently, checking the mask pressure chart, it was *TOTALLY* wrong.
Maybe they've fixed it in the last couple weeks.