Respironics / EncoreViewer Data Error ?

[Velbor]

You have to find out where Respironics starts its day and where it ends it, and how it handles sessions.

I did not look at the 9 second days but all the 6 second days (April 5,6,8 &12 and May16). The 6 second apnea was the only one. All had a OA of 0.1. Respirionics starts it's day at 12 noon and runs until the next 12 noon unless there is a segment of more than one hour.

I have come to learn that suggestions by Ozij should never be taken lightly. She has a gift for considering “outside the box” possibilities. Her suggestion that an explanation of apparent “apneas” of less than 10 seconds duration might be explained by “day” or “session” considerations led me on the following path.

Jerry has indicated that the Respironics “day” runs from noon to noon. This is the same protocol utilized by ResMed, which is well documented. I cannot recall having seen as unambiguous a statement from Respironics, but I have no reason to doubt it: the Help file for Encore Viewer, “Patterns of Use” indicates, “Across the bottom of the graph is the time of day starting with 12:00 noon.” And “The usage time is counted over a 24-hour time period ….”.

Here is the schedule of my therapy utilization on the night in question (the evening of 25 May 2009). Entries for “Clock Actual Time” are recorded to the nearest quarter-hour):



Thus it is seen that I was out of bed 5 times during this night; one of my arisings was prolonged and atypically involved the hungries and getting a snack. My experience in analyzing Respironics data is that a break of 1 hour 15 minutes DOES cause the machine to begin counting a new “session”, but a break of 45 minutes, as on this night, does NOT result in a new session. The critical cut-off time is presumably one hour.

What is important to note in this context is that all times were within the same “day” from noon to noon. BUT, that is true only for my local time.

We have on a number of occasions been advised on this Forum that the Respironics internal clock (which, unlike ResMed models, cannot be reset by the user) is set to Coordinated Universal Time (UTC) / Greenwich Mean Time. I think that my own data collection can corroborate this. Extracts from the EncoreViewer .xml file for this date show the following:



The .xml file from which this was extracted is time-stamped as having been created on 26 May 2009 at 9:18am, when I ran EncoreViewer. This is precisely the information contained in line 2 of the .xml file, which presumably obtained the information from my computer’s clock.

My initiation of therapy for the night of the evening of 25 May 2009 was at about 12:15am on 26 May, which would be about 4:15am UTC. According to line 47 of the .xml file, the “Therapy Session Date” entry bears almost exactly this time-stamp, presumably generated by the REMstar’s internal clock. Note that line 46 shows that there was only ONE “Therapy Session”, and that line 47 shows the duration of this session without reference to any of my “blower-off” arisings (equal to the final blower-off relative time). [Remember that my calculation of “average duration of apnea” – and presumably James Skinner’s - is not based on either session time nor blower time.]

With this evidence that the machine’s internal clock is based on UTC, is it possible that the Respironics data management system is constrained to cumulating “Average Time in Apnea Per Day” in terms of a fixed 24 hours based on noon-to-noon UTC? My utilization ranges from 04:15 through 12:30 UTC. Of my eight (or perhaps seven) apneas, one occurred at 8:12:04 local, or 12:12:04 UTC. Might the duration of this apnea not have been counted for 5/25/09, but “held over” for 5/26, even while the presence of the apnea itself was counted during 5/25?

This explanation seems possible, though not at all comforting.

The EncoreViewer, presented with data from the evening of 25 May, but which in fact is generated entirely on 26 May, nonetheless “correctly” presents it as data of 25 May, (since 25 May started at noon and does not end until noon - presumably UTC noon, since that is all the Respironics internal clock knows - of 26 May)



The EncoreViewer is able, once the smartcard is downloaded, to make the “UTC to local time” conversion:



It presumably can get the 4 hour time-difference information (normally 5 hours, now adjusted for DST) from my computer:



To review: EncoreViewer presents “days” and “times” correctly for local time (assuming the REMstar internal clock is reasonably accurate). Detail data (e.g. occurrence of an apnea, even if it occurred during the “next” day, after noon UTC) is presented properly, presumably because the Respironics blower firmware is “smart” enough to deal correctly with a single “session”, as Jerry's comment suggested.

But we do not know how the Respironics firmware is cumulating the “Time in Apnea Per Day” data. This is where Ozij’s hypothesis is most intriguing. It does seem possible. If the apnea durations are being cumulated noon-to-noon UTC, and the number of apneas are being counted (per the “Daily Events Per Hour” chart) by session, one could imagine the following scenario:

Three apneas overnight in one session, durations 10, 11, 10 seconds each, but the last one is after noon UTC. So we see 3 apneas, 21 (not 31: the last one is for “tomorrow”) seconds total duration, average duration 7 seconds. The next night there are three apneas, durations 11, 10, 10 seconds each, but the last TWO are after noon UTC. So we see 3 apneas, 21 seconds total duration (10 from night one, and just the first apnea from night 2), for an average duration 7 seconds (with 20 seconds being carried over to night 3). Possible. But sooner or later, this “carrying” will catch up with us.

If this hypothesis is correct, it could presumably become MORE frequent as one’s location is further WEST in the US or Canada, thereby creating a greater differential between local time and UTC. Thus, while noon UTC is 8am on the US East Coast, it would be 5am on the US West Coast, thus allowing more time during which apneas are counted in one “day” but apnea duration cumulated for the next day.

Unfortunately, I don’t believe that I can confirm or rebut Ozij’s hypothesis with my own data. And with Jerry’s data, including consecutive days of single apneas, each supposedly of under 10 seconds duration, it’s hard to imagine conditions under which this explanation would work. To get under 10 seconds average duration, you need to have the machine cumulate LESS apnea time while showing MORE apnea events for the night.

Still I would ask, Jerry, would you be willing to look into the UTC times for your “six second” apneas? This would need to include the data (approximate UTC times and numbers of apneas, and daily “Time in Apnea Per Day”) including the days before and after.

My thanks to you both!! It would be astonishing if this explanation were correct; unfortunately, it would make the "Time in Apnea Per Day" information virtually useless. Other explanations or comments remain very much welcome.

Velbor

[GumbyCT]

I changed my day to be what is normal for me - midnite to midnite. I just found the Respironics day to confusing.

[Velbor]

This issue has been reported to FDA.

A redacted copy of their database entry is found at:
http://www.accessdata.fda.gov/scripts/c ... ID=1404395

EDIT 14 September 2009: As of the latest update of MAUDE, appearing online today, FDA appears to be no longer displaying the detail descriptive text of device complaints. One must wonder ....

EDIT 16 October 2009: It appears that MAUDE displays the detail narrative text of device reports for only the most recent two months.

[cinco777]

Velbor wrote

My thanks to you both!! It would be astonishing if this explanation were correct; unfortunately, it would make the "Time in Apnea Per Day" information virtually useless. Other explanations or comments remain very much welcome.
Velbor

I use EncorePro not Encore Viewer. There is a "SecondsInApnea" field (Column 16) in the SleepTrendEventLog2 SQL table. I use some data from this table in my CPAP charting spreadsheet. This field shows, for each compliance session (Respironics parlance), the # of Seconds in Apnea. The first thing that caught my attention is that all the values are multiples of 6: 6, 12, 18, 24, ... This Respironics recording/reporting has some similarity to the recorded/reported leak values of 4, 11, 18, 25, 32, 39, ... in which all are 7 apart. After reading your last post in this thread, I created a spreadsheet that shows the number of apneas for each "Seconds in Apnea" value, and how many occurences of each were reported. As input, I used my EncorePro data from 4/30/09 through 7/9/09. For 6 Seconds in Apnea, the apnea count was always 1 for that session - there were 39 occurences in my date range. For 12 seconds in Apnea, the apnea count was always 1 for that session - there were 12 occurences. For 18 seconds in Apnea, the apnea count was always 2 - there were 14 occurences. For 24 seconds in Apnea, there were two results: there was 1 occurence where the Apnea count was 2 and 1 occurence where the Apnea count was 3. For 30 seconds in Apnea, the apnea count was always 3 - there were 5 occurences. For 36 seconds in Apnea, there were two results: there were 3 occurences where the Apnea count was 3 and 2 occurences where the Apnea count was 4. For 42 seconds in Apnea, there were also two results: there were 3 occurences with a count of 4 apneas and 1 occurence with a count of 5 apneas. For all subsequent seconds in my Apnea values - a range from 48 apnea seconds to 156 apnea seconds - there was only one result for the Apnea count. Based on these results, I believe that the avg duration of an Apnea recorded/reported by Respironics/EP/EPA is best predicted by how many Apneas occurred in the session - with the lowest apnea durations being reported for the lowest count of apneas (always 6 seconds when 1 is reported) in a session. I believe that Respironics chose this recording/reporting approach because they did not have sufficient uprocessor power or smartcard memory to process and record at shorter time intervals (I would like 1 second recording/reporting).

[Velbor]

The first thing that caught my attention is that all the values are multiples of 6: .... For 42 seconds in Apnea, there were also two results: there were 3 occurences with a count of 4 apneas and 1 occurence with a count of 5 apneas. For all subsequent seconds in my Apnea values - a range from 48 apnea seconds to 156 apnea seconds - there was only one result for the Apnea count. Based on these results, I believe that the avg duration of an Apnea recorded/reported by Respironics/EP/EPA is best predicted by how many Apneas occurred in the session - with the lowest apnea durations being reported for the lowest count of apneas (always 6 seconds when 1 is reported) in a session. I believe that Respironics chose this recording/reporting approach because they did not have sufficient uprocessor power or smartcard memory to process and record at shorter time intervals (I would like 1 second recording/reporting).

Thank you for a very valuable observation!
I ALMOST thought you provided the key to a complete answer. But my hypothesis based on your information fails, slightly.
Here is my take on your observational data:
Let's assume that the "total time in apnea" recorder is indeed set to work in multiples of six.
And let's assume that it functions like a digital car odometer: until it clicks into the next higher reading, it remains at the previous reading.

When apnea duration hits 10.0 seconds, the counter clicks to 6 seconds. It will stay there until AFTER 11.9 seconds. Thus you see only one apnea under these conditions, with a duration between 10.0 and 11.9 seconds. Reasonable.

When apnea duration hits 12.0 seconds, the counter clicks to 12, and it will stay there until AFTER 17.9 seconds. Thus you see only one apnea under these conditions, with a duration between 12.0 and 17.9 seconds. Reasonable.

When apnea duration hits 18.0 seconds, the counter clicks to 18, and it will stay there until AFTER 23.9 seconds. Thus you see only two apneas under these conditions, each with POSSIBLE durations between 9.0 and 12.0 seconds. In fact, the minimium duration for each apnea is 10.0 seconds. Reasonable.

When apnea duration hits 24.0 seconds, the counter clicks to 24, and it will stay there until AFTER 29.9 seconds. Thus you see either two or three apneas under these conditions. Two apneas each have possible durations between 12.0 and 15.0 seconds. Three apneas each have possible durations of between 8.0 and 10.0 seconds. In fact, the minimum duration for each apnea is 10.0 seconds. A tight fit, but possible and reasonable.

When apnea duration hits 30.0 seconds, the counter clicks to 30, and it will stay there until AFTER 35.9 seconds. Thus you see three apneas under these conditions, each with possible durations of between 10.0 and 12.0 seconds. Reasonable.

When apnea duration hits 36.0 seconds, the counter clicks to 36, and it will stay there until AFTER 41.9 seconds. Thus your see either three or four apneas under these conditions. Three apneas each have possible durations between 12.0 and 14.0 seconds. Four apneas each have possible durations between 9.0 and 10.5 seconds. In fact, the minimum duration for each apnea is 10.0 seconds. Reasonable.

When apnea duration hits 42.0 seconds, the counter clicks to 42, and it will stay there until AFTER 47.9 seconds. Thus you see either 4 or 5 apneas under these conditions. Four apneas each have possible durations between 10.5 and 12.0 seconds. Reasonable. But then we hit a snag. If there are five apneas, each have possible durations between 8.4 and 9.6 seconds. These are too short. A counter value of 42 should not occur with five apneas; five apneas should demand a minimum counter value of 56; even 48 is too low. Your finding of even one instance of this situation destroys this explanation.

Your thoughts on my approach to and analysis of your data would be welcome. Is there any way in which we can "salvage" this or a similar approach, which would at least restore some confidence in accuracy, even if not in the precision, of the data?

Again, many thanks for sharing your careful observations. Regards, Velbor

[Velbor]

The first thing that caught my attention is that all the values are multiples of 6: ....

I've now had some time to look at my own data in light of the information provided by cinco777.

I have been collecting data relevant to average apnea durations on the Respironics M-Series Auto, with EncoreViewer, for about 75 days. I have run into average nightly apnea durations of less than 10 seconds on 11 of these days. Thus, about 15% of the time, I have had a "problem" with the data. The following table summarizes the eleven "problem" nights:



Several observations call my attention:
-- All durations are, as observed by cinco777, exact multiples of 6 seconds.
-- The "shortages" in duration tend to be small, even numbers.
-- Six of the eleven occurrences (three pairs) occur on consecutive nights.

However, it is not as simple as needing to "round up" to the next nearest six-second interval. While in three of the cases such rounding up would resolve the discrepancy (to add at least 2 or 6 seconds), seven instances require addition of at least two multiples of six (to add 8, 10 or 12 seconds), and one instance requires the addition of at least three multiples of 6 (to add at least 14 seconds).

So it seems to me that while the "multiples of six" issue likely plays a role in this issue of "short average apnea durations", it does not appear to provide the complete answer. At the same time, the high incidence of back-to-back nights with this problem do suggest, as previously suggested by ozij, that at least part of the issue may lie in way a "day" is defined for apnea duration cumulation. The possibility of two independent factors contributing to the problem is not reassuring. Velbor

[cinco777]

Velbor wrote

When apnea duration hits 42.0 seconds, the counter clicks to 42, and it will stay there until AFTER 47.9 seconds. Thus you see either 4 or 5 apneas under these conditions. Four apneas each have possible durations between 10.5 and 12.0 seconds. Reasonable. But then we hit a snag. If there are five apneas, each have possible durations between 8.4 and 9.6 seconds. These are too short. A counter value of 42 should not occur with five apneas; five apneas should demand a minimum counter value of 56; even 48 is too low. Your finding of even one instance of this situation destroys this explanation.

I rechecked my results for 42 seconds in Apnea and, indeed, there are two results: either 4 apneas or 5 apneas. Additionally, for 48 seconds in Apnea, there is one result: 5 apneas. I hope you can make sense of this. I have not been able to find any start/end time-stamped data for Apneas so suspect that all we get from our Respironics machines is the accumulated apnea seconds (duration) per session. I do process the apnea events which are time-stamped but an apnea, like all other sleep events, does not have an ending time-stamp. Sessions, Leak, and Pressure do have a start and end time-stamp, but I have seen instances of sleep events occurring after the session ends (which kinda defeats the meaning of session end time). I suspect, again, that the limited uprocessor power and/or limited smartcard memory keeps Respironics from reporting on 1-second intervals (or even something less than 30 second intervals). With uprocessors being so inexpensive and so powerful, I really think that the limitation is the smartcard memory size!

It is also possible that Respironics added the Apnea Seconds per session to have "something" similar to what Resmed reports. From what I have seen, Resmed actually knows and reports the duration of each Apnea and Hypopnea. I guess that I need to look at the Resmed reported data to learn more about their processing.