Flow Limitation Units in Statistics

[cathyf]

This is something that has bothered me for years... In OSCAR (and before that Sleepyhead) the units for FLs in the statistics aren't particularly helpful. My FL graphs all look like wild-ride train wrecks, but the median is 0.01 or 0.02. In this example, the median is 0.02, 95% is 0.21 and "Max" (which appears to be more like 99% rather than the true  maximum) is 0.42
[attachment=31020]

For display purposes, would it be better to multiply these values by 10 or 100 so you could see more precision?

Also, the points displayed as 0.00 flow limits in my data look like a combination of really-zero -- nicely-shaped waveforms -- along with what I would characterize as NDs (no data) rather than zero. Some of these zeros are during apneas, while others are extremely ragged breathing. To my eye, a lot of those "zeros" are just the fourier transform algorithm giving up. 
[attachment=31021]

Does OSCAR calculate the Min/Med/95%/Max statistics from the data, or is it just reporting statistics that the machine calculates? Is there any way to distinguish a true zero value from a wildly-erratic waveform that breaks the algorithm? (This seems like a place where a -999999 should be in the data rather than 0.00) Do you see something like 0.0000123 for a non-flow-limited breath, while exactly 0.0000000 means ND? If you can distinguish NDs from true-zeros then the NDs should probably be excluded from the counts used for the statistics, and should show up as gaps in the graphs.

Part of the problem for me personally is that as long as I am awake I have no FLs at all, but as soon as I am even lightly asleep they take off. So a low median number is simply showing that I was awake with the machine running for a relatively larger fraction of the night. So even if I could make all of the obviously ragged breathing counts go away, the nice even AWAKE breathing would tend to swamp out any meaningful signal in the statistics...

[Gideon]

Especially in a ResMed the charted flow limits are important as that is what ResMed uses in its algorithim to increase pressure. Via a lot of digging it was discovered that this value is actually a flatness index. ResMed devices report this on a scale between zero and one. Since this is what the machine reports OSCAR will not alter these values. If you look at the pressure chart and the flow limits chart you will s| that pressure increases are driven by these flow limits.

The flow rate chart shows different things at different scales. At 15-20 (your 18) minute scale you look at overall breathing patterns such as the periodic breathing in the example you show. You can see attempted breaths between the breathing clusters which I think are recovery breaths from the series of attempted breaths. To confirm this you need to view the flow rate at a 2-3 minute view where you can view and evaluate each individual breath as to it's characteristics.

One of OSCAR's goals is to indicate which values are calculated by OSCAR vs which are reported. We are not there yet. I know that many of the max values are calculated as there is an option to report a 95% value as a Max. This was done in OSCAR's predecessor as a means to not display meaningless high value. Yes when this is done it shouldn't say max simply because that isn't true. Unfortunately we cannot dynamically flag this yet. It is and has been on our work list.

Hope this helps you some

[multicast]

It would be better to scale the "flow limitation" as grades from A to F, see http://www.apneaboard.com/forums/Thread-...light=flow

[Sleeprider]

Cathyf, you should start a thread to discuss your therapy and flow limitation. We can often mitigate flow limits with machine settings and in your case, likely positional apnea. As far as index goes, if ANY flow limitation shows up in the median statistic, it is very severe. For coaching members of this forum, I target less than 0.1 in the 95% flow limitation statistic as a threshold that seems to correspond with reasonable comfort.

[GuyScharf]

My FL graphs all look like wild-ride train wrecks, but the median is 0.01 or 0.02. In this example, the median is 0.02, 95% is 0.21 and "Max" (which appears to be more like 99% rather than the true  maximum) is 0.42

fyi, Max values are 99.5% percentile for ResMed machines. The labels will be changed in the next version of OSCAR to show 99.5% instead of Max.

[Sleeprider]

I want to add that the Resmed interpretation of flow limitation is far from perfect.  The chart below is an example of what we believe to be Class 3 flow limitation, where tissue alternately blocks the airway resulting in the very long inspiratory times with a characteristic opening and closing of the airway at a high frequency.  Resmed does not even register this and improperly counts the fluctuations as separate breaths.  As a result, when we see intermittent periods of abnormally high breathing rate with long inspiratory times, this is what we are finding. These images are from 3 separate individuals currently dealing with this problem on the forum.  I will be writing a wiki on the subject and trying to recruit some professional research into the problem since it appears to be undocumented in the research literature.

[cathyf]

I should start by saying that I am getting my act together and working on a post about my sleep problems, but the reason that I posted over here on the software support forum is that I'm thinking about the software and how to make the display of information better. Because I was writing when I was sleepy I wasn't really very coherent!

My point about the "Statistics" table is purely a matter of the data being shown in the wrong form for the values that are there. When I look at my data from last night, for example, it has about a half-hour to 45 minutes that I would characterize as a "flow limitation freak show" but I look over on the left and the statistics show a ho-hum-no-worries-mon-nothing-to-see-here

Code:

Channel       Min     Med    95%    Max
Flow Limit.   0.00    0.00   0.29   0.61

Likewise, when I go over to the graph itself if I mouse-over a point on the graph the data associated with that point appears above the graph. The format of those numbers is to show 2 decimal places, although there is nothing to the right of those numbers and plenty of room to show a lot more digits.

I haven't looked at the OSCAR code, so what I'm doing here may be your typical ignorant kibbittzing When you read the data files, are the values being written out in the files as floating point numbers, where "0.29" might be something like 0.286378 if it's single precision float, 0.29432898724799 if it's a double-precision float? Or is ResMed playing brain dead and giving you a 4-character string -- '0' followed by '.' followed by '2' followed by '9'?

Obviously if they are doing the brain-dead string thing then you don't have any more information than that.

Very specifically what I'm interested is what happens in those places where my breathing is not flow limited at all vs those places where my breathing is so wildly abnormal that no calculation is even meaningful. Because it looks to me like the machine is reporting both of those as zero at least to 2 decimal points. If I understand the calculation being done, what I would expect is that for those "boring" breaths the FL would be reported as a whole series of "not exactly zero but very close" values. On the other hand, those places where my breathing is wildly gyrating around (like when I'm coming out of an event) if the algorithm just doesn't work then I would expect the machine to report "exactly zero to all decimal points". (Ok, that's the more stupid thing to report. The much smarter thing is to report something like a giant negative number -- the biggest negative number in machine precision is a customary thing to do, as is something like -9999999.9999999. But is this case exactly zero is not natural biology, so you could signal failure of the algorithm by an exact zero.)

Here's what I mean by "boring" not-flow-limited breathing:
[attachment=31029]

as opposed to all-sorts-of-crap going on breathing:
[attachment=31030]

Clearly there are two very different meanings of "0.00 flow limitations" going on here!

This is my question -- I can SEE those two different kinds of FL zeros by looking at the Flow Rate graph. Can you likewise see the difference in the reported Flow Limit numbers that the machine reports, in that the least significant digits follow distinct identifiable patterns?

[Sleeprider]

I think when we get into your Oscar charts you will hear me talk about positional apnea (chin-tucking) and a possible need for a soft cervical collar. Clearly, chronic flow limitation has a characteristic appearance and scoring in the charts, but when we see events are clustered, and flow limitation increases steadily into apnea and arousal, that is positional. It is caused by your cervical spine (neck) flexing in any axis and restricting your airway.

[GuyScharf]

fyi on the internals: ResMed machines report a flow limit number every 2 seconds. The number is a 16-bit (unsigned?) integer (I think). This gets converted to a floating point number for the OSCAR database during import. (Phil can correct me if I am wrong about this.)

CPAP machines cannot measure the actual flow limit -- they compute it based on the values they can measure, notably pressure and flow rate. So if you see a graph with lots of squared-off tops, you will usually see an increased flow limit. I suggest http://www.apneaboard.com/wiki/index.php...limitation for a discussion of how different CPAP machines handle flow limits. For example, Respironics machines report flow limitations as events and Intellipap BLUE machines report limitations as events of values 0, 1, 2, or 3 (none, some, moderate, severe). I think any precision beyond a few digits is probably imaginary.

You showed a 95% flow limit of 0.29. My understanding is that is considered high.

[pholynyk]

To be exact, here is the signal definition for Flow Limitation:

Code:

Label      FlowLim.2s      
Transducer                                                                                
Units              
Min        0.000000
Max        1.000000
Dmin       0
Dmax       100
PreFilter                                                                                  
Smp/Rec    30

So the digial values run from 0 to 100 and get scaled to values between 0.0 and 1.0. As you can see, only two digits of precision is appropriate, and there are no dimensional units supplied.
While every signal in an edf file uses 16 bits, in this case, only 7 bits are required.