(10-26-2014, 11:56 PM)retired_guy Wrote: At 2:10, on the pressure graph, see the long squiggly stuff? That's an OA. Shortly after that, see the short squiggly stuff? That's the Hypop. A Hypop is really just an OA that was never allowed to grow up.
p.s. I think the event flags shown on the Flow Rate chart are misplaced. On the event chart it shows the hypop occurs just barely after the OA, which is demonstrated on the pressure chart.
Possibly.
While not an expert by any measure, I am interpreting this slightly differently.
On the flow rate chart, as well as the mask pressure chart, changes in pressure and flow cease completely at 2:09:56, indicating that respiration halted. At 2:10:00, the "short squiggly stuff" on the mask pressure chart indicates the XPAP, responding to the halt in respiration, trying to pulse the system with air to see if the airway is open or closed, sort of like how a WWII sub pings for battleships using sonar. Determining it is closed, it flags an OA once the condition exists for 10 seconds (2:10:06), at which point the patient coincidentally begins breathing spontaneously once again. It's a short OA.
As for the hypop, it is determined by comparison to the IPAP/EPAP pattern in the breaths surrounding a moment where it sees the IPAP/EPAP lower (sees breathing become shallow), and it does that to minimize false positives, since IPAP/EPAP of just a few breaths taken out of this context really does not indicate anything on its own, and IPAP/EPAP over time is fairly dynamic in nature. IOW, it has to determine how shallow the breathing is in comparison to what is "normal" in the moments just surrounding the shallow breathing, in order to determine accurately if it meets the requirements for being flagged as a hypop.
I think the hypop begins at ~2:09:27, and ends at ~2:09:33. If you look closely, the flow and mask pressure charts indicate this change. It is subtle, but it is there. There are 2 or 3 breaths that are significantly shallow.
Then, since the ResMed machine needs 5 breaths to compare this to, to determine if it really meets the requirements for being shallow enough breathing to be flagged as a hypop, it waits for 5 breaths, compares those to what it saw earlier, does the math, and (in this case) flags it at 2:09:51.
IOW, it flags a hypop, but it takes time to figure out whether it really was one or not, which is why the flag was ~27 secs after the actual event, which gives the impression (on the compressed event chart) that both events happened at the very same time (but of course it is impossible for both events to happen at the very same time because they are mutually exclusive events). They actually happened ~25-30 seconds apart, and due to the nature of how the flagging is naturally delayed, they appear on the flow rate graph as if they happened ~15 seconds apart.
To be fair, the important task here is simply to flag THAT an event occurred, and precisely when is really not that important, at least until you begin to try to parse the data and you find an offset between what appears to be an event and when it is flagged. Once that natural behavior is known, it is easier to reference the offset flags to where the events themselves actually occur on the timeline.
To get even more speculative here, the disturbance in mask pressure from ~2:09:04 to ~2:09:24 may have contributed to delaying the flagging, as it may have not allowed the XPAP to have uncorrupted surrounding breaths (those prior to the issue) in enough quantity to aid in determining just whether the shallow breaths were comparatively shallow enough to be flagged.
As wonderful as SH is, it apparently does not have the ability to flag an event "in the past". To be more accurate, it should timestamp in memory (in its algorithm) where an event began, and then once the event is fully determined and flagged, offset the flag time back to the actual event time, even if the XPAP itself is not capable of this. But then all the data it has access to may only consist of when the machine timestamps an event (which is somewhat after the fact), so to do this it may have to make an educated guess about how long the delay might have been. But at least that would be much closer on the timeline to the actual event time.
The XPAP does the heavy lifting of identifying, flagging, and responding to events. SH is only reporting software, meaning it takes that data, perfect or imperfect as it may be, and conforms it into a GUI. If SH could independently identify and flag events, it would be interesting to see if it would identify and flag them differently, but probably would not be either necessary or practical, and could even confuse the issue.
