PB420E: data discepancies between SilverLining and export

Hi O,

I have NO AM or PM -- just military time (24 hour).

The dll's are England & France.

It seems like there was a time sync that I did when I set up and again when California went on daylight savings time -- it is in the machine control setup area -- have you done this?

It seems like the reports should be in local time to be meaningful to the user, and I use the clock on my computer to keep track of the time more than the watch on my wrist!

As much as we would all like this to be an exact science, there is still so much to be learned and understood about our OSA, our machines and our software -- not to mention our unique bodies, that if we can get to the ballpark, maybe that is all that we should expect. This statement is really hard coming from a nitpicking perfectionist! With that said -- this has been a really interesting thread!

Thanks all!

Glassgal and I have been pm-ing, and I believe I have narrowed the appearance of the bug to the following conditions:

1. There must be post midnight sessions in the data
2. These additional sessions probably have to occur before midday

Under these conditions, the apnea number received on all the screens, and in all the screen calculations gets blown up. It is never less than that reported by the data export, frequently more.
In my personnal data there are relatively frequent post midnight early mornings awakenings and new sessions, and some post midnight bedtimes. The export data does not mirror the screen data (thanks, –SWS for the that expression). You can see similar things when you work on the demo420Enew3.pat data – that guy (or gal) has really wild sleeping times – and the discrepancies are very clear.

On the other hand, glassgal's sleep sessions almost always start between 9 and 11 pm, and she has the machine on and then off once per day. There were no discrepancies in her personal data.

It you want to see the discerpancies, do the following:
Open the demo420Enew3.pat in the sl3\patient directory.
Left click on the very first session in the synthesis screen, and note the apnea count (it will show 63). Export the data. Then check the apnea count for the first day in the 24H export data, or for the first session in the SEssion export data.
On both glassgal's computer and mine, the export data for apneas, in both files is 40.

O.

Ozi, Glassgal---verrrryy interesting find, indeed! I also see where the calendar sessions go from noon-to-noon exactly as you mentioned, Ozi. The help file even mentions that. I forgot all about right-clicking to render session data from the Synthesis screen. I'm very accustomed to forgetting nifty shortcuts.

I just now had a chance to look at the demo file and now see exactly what you describe. I agree with Glassgal that the bug sure seems to be apnea-index related since all the other non-apnea indices seem to mirror each other perfectly. I performed a very brief comparison against the apnea tick marks (on the detailed report) and noticed that the apnea indices on the synthesis report seem to agree with those tick marks. The exported apnea indices thus seem to be at odds with those other two corroborating data sets. Again, that was only a very brief and preliminary check (which matches the amount of free time I currently have available. ).

Are any other numeric indices ever corrupted in exportation besides the apnea index? Or is this bug limited to just the apnea index? I haven't had a chance to look at my own data for this particular bug yet (I don't normally export) Glassgal, does your exported apnea index ever get corrupted, or are your synthesized and exported data sets always perfect mirrors of each other in every respect?

To be perfectly candid I'm very surprised that PB/Tyco carried this particular (presumably exportation) bug from one release to the next. You'd think this bug would have already been reported by the DME/RT/professional users who rely on data exports and readily fixed by PB/Tyco.

Leave it to Ozi!!!

P.S. Ozi, when I right-click to render session-1 data from the demo420enew3.pat I also yield a reported 63 apneas using Silver Lining 3 version 3.2US. Sorry it took me so long! My free time lately can be measured in nanoseconds.

Ozij was the one that really caught on to the nature of the problem -- with a push in the right direction from you, -SWS!

I just helped corroborate O's findings and let her know what my settings and stuff are.

Good catch O!

Got guested!

Duh -- that was me -- guested twice -- sheeh!

You'd think this bug would have already been reported by the DME/RT/professional users who rely on data exports

LOL, welllllll..... you know what I think about how much interest DMEs and RTs (and sleep doctors, for that matter) have in the overnight data from users' machines.

How many people have been asked by their doctor or DME to send in the smart card for downloading? And the few that have -- probably the DME is just going to look at the overall picture: What's the 90% pressure and is the patient using the machine often enough for insurance to keep paying big bucks.

As for whether they'd even notice a discrepancy... nah. The "professionals" aren't a bit interested in looking at the details. Just my opinion.

Hi RG,

I have had the same thought -- unarticulated.

Thanks for telling it like it is.

Rested Gal, Glassgal- I always knew the "norm" within the RT/DME/professional circles regarding PAP data was very sad. My former doctor's staff looked at me as if I were carrying a plague-infested rat when I proudly brought my first AutoPAP data disk in for a routine check up. If that former doctor ever did take a look at my AutoPAP data, he sure never got back to me regarding my data or therapy.

Regarding this particular bug... Regardless of the "norm" I really would have thought that there would be at least one or two professionals somewhere in this big world who might have exported data and noticed the discrepancy. It really is a big world! Instead, it took one very astute new patient (Ozi) to figure out that a very fundamental error was significantly skewing exported AI data. This bug has been carried right up through the present release. Fixing this bug shouldn't be that tough, so I sure hope PB releases a patch (or at the very least fixes this bug in the next SL software release). I hope Ozi and/or her DME can get this bug information back to PB.

Not one friggin' sleep professional caught this basic bug (unless PB just isn't fessing up). Sorry for the French, but this is a French AutoPAP we're talking about!

Anyways, BIG kudos to Ozi for catching this! Well done!

My former doctor's staff looked at me as if I were carrying a plague-infested rat when I proudly brought my first AutoPAP data disk in for a routine check up.

Having a dog and a cat, I do LOVE that description!! Why do I picture you walking into the doctor's office with your tail wagging?

glassgal, ozij, -SWS ...I do enjoy reading a detective story even when the techy stuff is beyond me. Good job!!