Pulse Oximeters in CPap machines.

[dataq1]

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.

Re your OT: I agree. In fact I was sufficiently irritated when this happened to me that I challenged the nurse about it. She explained - and showed me - that cuff actually senses the the change in pressure (some sort of sensor in the cuff) and reports the BP to the screen before the cuff pressure even begins to be released. She said she only uses the stethoscope to be sure the cuff is correctly placed.
I hope my embarrassment wasn’t too apparent!

[lynninnj]

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.

Re your OT: I agree. In fact I was sufficiently irritated when this happened to me that I challenged the nurse about it. She explained - and showed me - that cuff actually senses the the change in pressure (some sort of sensor in the cuff) and reports the BP to the screen before the cuff pressure even begins to be released. She said she only uses the stethoscope to be sure the cuff is correctly placed.
I hope my embarrassment wasn’t too apparent!

Well- if you watch the display you can get a reasonable idea.

BP numbers are the upper and lower numbers of when you start to get blood flowing thru the arm and when it’s flowing freely without cuff pressure.

watch the numbers. when you can feel the pulse is top number and when you can’t it’s bottom.

not totally accurate but it’s fair that a ballpark can be obtained

Edit: forgot to add that the numbers on the sphygmom bounce around when the blood vessel is pulsing.

[dataq1]

.... forgot to add that the numbers on the sphygmom bounce around when the blood vessel is pulsing.

I suspect that you and I are talking about two different systems. In the system I was referring to there is no "bouncing number" displayed, just a systolic and diastolic value.
In the physician's office, it appears on the computer screen and is automatically included in the patient's record.

I think that it might be the same technology used in a monitored bed in hospital where the BP cuff inflates every 15 minutes or so and records the BP and relays that info to the nurses station.
Other than placing the cuff initially, there is no human contact, no sphygmo at all.

Apparently that level of technology has made it way into the local physicians office.
"We've come along way baby" - whether that's good (preventing human error) or bad - I just don't know.

[dataq1]

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.

Allow me to make a distinction here. I don't think that my doc was referring to the raw data (that is the primary measured source data* , rather I believe he was referring to the interpretation of that data. For example, Is this epoch of breathing actually a hypopnea as assessed by the machine's algorithm, or does it require a closer look to validate this event as an actually hypopnea as defined by AASM.

After all, even the in-lab raw data is reviewed and edited by a human in the case of PSG or home studies for "algorithmic" (a word I just made up) mistakes.

So what I'm saying is that while the doc may find the flow-rate and pressure readings trustworthy, he is expressing less confidence in the accuracy of analysis.

Which, in a way, kind of brings me back to my premise that inclusion of oximetry data as an additional raw or primary source may have potential in the evaluation of "events" or at least insight into what is happening physiologically.

Does it help you, where you seem to experience no desaturation subsequent to a significant flow reduction - probably not..... but having the saturation data is likely better than not having it.


* My understanding that the only primary source data for the CPap machines is air flow, pressure and time. All others are derived data streams.

[robysue1]

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)?

I'm saying that the two apnea-like "missed" events in lynninnj's data that she posted at https://sleephq.com/public/3a22af32-0e9 ... a5466f4010 don't look like CAs to me. They look like OAs: There are no FOT oscillations in the flow rate and the machine responds to these two "missed" events by increasing the pressure right after they end.

I have no idea how these two events look in Oscar. But I would suspect they look much the same. If there had been oscillations in the flow rate graph, I don't think the machine would have increased the pressure since there was no activity to speak of in either the flow limitation graph or the snore graph that could explain the pressure increase.

The Mask Pressure graph as drawn at SleepHQ is clearly way, way off. As drawn in both ResScan and Oscar, the Mask Pressure graph shows the transition of pressure caused by EPR on each and every breath and the "height" of the bumps is roughly equal to the EPR setting---i.e. if EPR = 2, the height of the bumps from bottom to top will be approximately 2 cmH2O units in height. SleepHQ's Mask Pressure graph does not show the individual bumps once you zoom in close enough to see the individual breaths.

Here's a snippet of a CA flagged in my own Flow Rate data from last night, along with the Pressure graph and the Mask Pressure graph as displayed in Oscar:


Because you can't reorder the graphs in SleepHQ, I have to show these three graphs in two screen shots. The first screen shot shows the Pressure Graph and the Flow Rate Graph:

And here's the Mask Pressure Graph:


It should be quite clear that the Mask Pressure graph from SleepHQ is not displaying (all) the data that was written on the SD card correctly. So clearly you can't use the Mask Pressure graph from SleepHQ to help check whether an event (or a "missed event") ought to be considered a "central" event or an "obstructive" event because you can't see the FOT oscillations in the Mask Pressure graph to compare them to oscillations in the Flow Rate graph.

It's also worth noting that I am using a bi-level machine---i.e. an AirCurve 10 VAuto running in Auto mode and PS = 4. That's why the bumps in the Mask Pressure graph in Oscar all have height about 4 cm H2O. The Oscar Pressure graph correctly shows the current "set" IPAP and EPAP pressures throughout this whole snippet, and the fact that the machine's program identifies this bit of troubled breathing as "central" explains why there is no pressure increase in response to this bit of bad breathing.

Finally, if you'd like to look at my data in SleepHQ, here's the link: https://sleephq.com/account/teams/vWDQle

[ozij]

Edit: Bad response from me. Deleted.

[robysue1]

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.

Not as of this evening. The full night view looks sort of accurate, but when you zoom in to in to something like a 5 minute window in the Flow Rate graph, the characteristic bumps in the Mask Pressure graph are either much diminished (i.e. not the right height) or glaringly absent if you zoom in far enough.

Here's what what an 18-minute snippet of my data from last night looks like in SleepHQ:



Note: My PS = 4, so all those tiny little bumps in the Mask Pressure graph ought to be 4 units high, with tops at about 8.72 and bottoms at about 4.72, given that the IPAP pressure is around 8.72 during this snippet. Clearly Nicko&Co. are using some kind of moving average to draw that graph instead of whatever data is used in ResScan and Oscar to draw that graph.

[lynninnj]

.... forgot to add that the numbers on the sphygmom bounce around when the blood vessel is pulsing.

I suspect that you and I are talking about two different systems. In the system I was referring to there is no "bouncing number" displayed, just a systolic and diastolic value.
In the physician's office, it appears on the computer screen and is automatically included in the patient's record.

I think that it might be the same technology used in a monitored bed in hospital where the BP cuff inflates every 15 minutes or so and records the BP and relays that info to the nurses station.
Other than placing the cuff initially, there is no human contact, no sphygmo at all.

Apparently that level of technology has made it way into the local physicians office.
"We've come along way baby" - whether that's good (preventing human error) or bad - I just don't know.

Considering you seem to be skipping around between an electronic cuff and a sphygmo It seems like you aren’t quite following me.

Next time you use your home cuff watch and note the pressure number on the digital screen when you first feel your heart beat in your arm and when it stops.

The analog version of this is the sphygmo (there may be a non mercury version of this nowadays but I am not sure). You absolutely CAN see what I refer to as bouncing around. It’s subtle but the heart is beating the entire time pushing blood thru the cuff while doing so, with slight variations in pressure within the cuff.

Neither will give a wholly accurate number but it will give a ballpark with careful observation.

[dataq1]

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.

Yes, we were taking about the same clinical experience.

Back in the day, when we clinicians used either a mercury manometer or a pressure gage it was important to
(1) listen carefully thru the stethoscope to hear sound changes.
(2) release the cuff pressure slowly enough be able to associate the sound changes with a pressure we were seeing on manometer or pressure dial gage.

I agreed that if the nurse is talking that impairs the ability to detect changes in sound. Further, I was taught to apply sufficient cuff pressure to cut off arterial flow and then detect the sound changes (first systolic then diastolic) as atrial flow was being reestablished (i.e. as the cuff pressure was being relived) - so yes, I thought we were talking the same scenario.

However, apparently the today's technology has advanced so that:
1) the clinician doesn't have to listen to anything (no stethoscope needed) and
2) the diastolic pressure is recorded first, then the systolic ,,,, meaning that the readings are being taken as the cuff pressure is being increased.

Additionally, and incidentally, digital display home cuffs with (without stethoscope), of which I have two, seem to be a mixed bag. One records the pressure readings as the cuff pressure is being reduced, the other reports the pressure readings as the cuff pressure is increasing.

[Tec5]

Circling back to the original post of this thread, I certainly believe that Oximetry data should be a routine data stream collected by xPaP machines.
It's not really that difficult and can add important clinical information, not only on a event basis but also on a continuing or trend basis.

As far as I am aware sleep studies of all types 1 thru 4 (the simplest) acquire O2 data in assessing AHI. Seems to be easy enough.

Whether that 02 data ought to be used by therapy machines (incorporate into indexing algorithms or not) is debatable.

[lynninnj]

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.

Yes, we were taking about the same clinical experience.

Back in the day, when we clinicians used either a mercury manometer or a pressure gage it was important to
(1) listen carefully thru the stethoscope to hear sound changes.
(2) release the cuff pressure slowly enough be able to associate the sound changes with a pressure we were seeing on manometer or pressure dial gage.

I agreed that if the nurse is talking that impairs the ability to detect changes in sound. Further, I was taught to apply sufficient cuff pressure to cut off arterial flow and then detect the sound changes (first systolic then diastolic) as atrial flow was being reestablished (i.e. as the cuff pressure was being relived) - so yes, I thought we were talking the same scenario.

However, apparently the today's technology has advanced so that:
1) the clinician doesn't have to listen to anything (no stethoscope needed) and
2) the diastolic pressure is recorded first, then the systolic ,,,, meaning that the readings are being taken as the cuff pressure is being increased.

Additionally, and incidentally, digital display home cuffs with (without stethoscope), of which I have two, seem to be a mixed bag. One records the pressure readings as the cuff pressure is being reduced, the other reports the pressure readings as the cuff pressure is increasing.

I can see how it is possible to take the pressure while you’re pumping it up but I just hadn’t heard about it being used in practice that often or at all really.

Thanks for taking the time.

[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.

Not as of this evening. The full night view looks sort of accurate, but when you zoom in to in to something like a 5 minute window in the Flow Rate graph, the characteristic bumps in the Mask Pressure graph are either much diminished (i.e. not the right height) or glaringly absent if you zoom in far enough.

Here's what what an 18-minute snippet of my data from last night looks like in SleepHQ:



Note: My PS = 4, so all those tiny little bumps in the Mask Pressure graph ought to be 4 units high, with tops at about 8.72 and bottoms at about 4.72, given that the IPAP pressure is around 8.72 during this snippet. Clearly Nicko&Co. are using some kind of moving average to draw that graph instead of whatever data is used in ResScan and Oscar to draw that graph.

The last time I looked at it, I made this comparison:
viewtopic/t185243/Flow-vs-Pressure.html ... 5#p1422990
in other words, the mask pressure chart on sleephq is useless.