Reverse-engineering CPAP Pressure Algorithms

[spacewrench]

Has there been any effort to figure out how the various CPAP manufacturers' software decides to adjust pressure based on monitored data?  My Dreamstation used to do ramp-ups occasionally when nothing else appeared to be going on (which, I think, would wake me up).  My current AutoSense appears to be smoother (and doesn't wake me up as much) but it still runs the pressure up at times that don't always correspond to an apnea event.

I know there are a lot of parameters that the machines monitor, that don't have an obvious (at least to me) correlation to an apnea event, but the machines must be looking at _something_ to decide how to set pressure.

If there's no descriptions of how the algorithms work, it seems like one could at least run some statistical studies on patient data to look for correlations and make a guess from that.  But before I set off to learn that sort of statistics, I figured I'd ask whether anybody has already done it?

[Gideon]

Others will add to this but ResMeds respond to Flow Limits, PR machines respond to snores, they also appear to respond to some extent to flow limits though not as quickly as ResMed.

[Sleeprider]

For some very good reasons, the OSCAR development team does not reverse engineer or study any machine firmware. The information on SD cards contains the therapy data and considerable effort is required to identify what lines of the code contain critical information. I will offer that Philips Respironics machine algorithms are mostly described in a number of patent documents and are otherwise very poorly documented for public or professional consumption, while Resmed is relatively open with interpretations of how their machines work. Your Resmed is very responsive to flow limitations, and while we don't know exactly how that is measured, we know it gets ahead of events and sometimes needs to be controlled by either using the "soft" algorithm or a maximum pressure.

[slowriter]

Isn't what we need pretty simple conceptually: positive air pressure, adjusted based on airflow resistance (the key variable)?

[Sleeprider]

Slowriter, I don't think "airflow resistance" can be measured non-invasively. Restricted airflow has certain characteristics in how rapidly the inspiratory flow increases or if it reaches a prolonged peak, and we recognize that as flow limitation. That is very effectively detected and used by Resmed to drive the auto pressure algorithm. Philips seems to use more of a volume to detect hypopnea and flow limitation. It does not seem to take into consideration "flatness" or that a longer inspiratory period is being used to get the same volume. As a result, flow restriction can develop into an event without the machine being able to make a proactive pressure adjustment. Until it becomes acute, flow limitation may not affect tidal volume or minute vent, which is how Philips flags flow reductions and classifies them as hypopnea or apnea. Philips does rely on snores as an indicator of flow restriction, but once snoring is going on, the flow limitation is already well advanced. This is my conjecture based on observed operating characteristics and the reading of patent rights documents.

I probably need to do some better documentation on Philips in the wiki, but the Wiki has this entry for Variable Breathing which is part of the Philips algorithm. I think the 4-minute moving average is far to slow to respond when restriction can build very quickly:
Variable Breathing - Philips Respironics variable breathing algorithm seeks to develop a peak inspiratory flow trend on a 4 minute moving average, and measure the deviation above or below that trend. The system is designed to identify variable breathing and to turn over control of the pressure support system, from the auto CPAP controller to the Variable Breathing controller. Without figures, we don't know what that controller response is, but it seems if VB is detected while the pressure is steady, the VB controller will maintain that pressure, but if pressure was increasing before VB controller took control, the pressure is reduced up to 2-cm. Similarly if pressure was decreasing ahead of VB detection, the VB controller will in increase pressure up to 2-cm. The duration of VB controller action is 5 minutes unless VB is still detected. http://www.apneaboard.com/wiki/index.php..._Breathing

For a real-life idea of how the VB algorithm actually interferes with therapy, take a look at this recent post with an example graph http://www.apneaboard.com/forums/Thread-...#pid364069

[spacewrench]

For some very good reasons, the OSCAR development team does not reverse engineer or study any machine firmware.

Right...I was thinking "reverse engineering" as in "look at the data the machine reports and see if you can figure out why this reading over here leads to that pressure change over there...

I'll look closer at the flow limits, and peak inspiratory flow on my older Dreamstation traces.  I'm a patent attorney myself, and have actually read through patents to try to learn how some things work (as well as to help my clients avoid allegations of infringement), but I haven't yet had any reason to look at CPAP patents.