PB420E: data discepancies between SilverLining and export

[ozij]

Dear friends
When I look at a single session in the Silverlining software synthesis screen– I get certain results. Last night it was Apeneas 5, Apneas C/A 7 Hyponeas 14.
When I look at the same session in Excel, - whether on the xxxxxxx.se or on the xxxxxx.24H after doing a plain import - the numbers for that same session are different: last night: Apneas 4, Apneas C/A 7 Hyponeas 14.
The night before:
Software: ap=4 ap c/a=4 hypop=4
Excel: ap=2 ap c/a=4 hypop=4
These were both about 6 hour sessions, that started before midnight.
Until recently, I thought it was a software version bug. But today I found the discrepancies on Ver. 3.6 – the latest.
This is weird!
Glassgal ("excel junkie") and anyone else – can you please see what happens with your data?
O.

[ozij]

Another, simple,way of seeing this phenomenon (bug-omenon? bug ominous?):

When you're in the synthesis screen, click on export (lower right hand corner). You'll get a text file, containing totals for the time period.

Then go to the Excel file, based on the session (*.se) or 24 hour period (*.24h) and do a sum of apeneas, hypos and apnea c/a. (Excel gives the same total for both files).

Compare the results with silverlining

Events : Silverlining Excel
Number Apneas : 400 310
Number Apneas/CA : 321 321
Number Hypopneas : 429 429
Number Acoustical Vib. : 35 35

Number Runs (FL): 10438 10438

[glassgal]

Hi Ozij,

That is most peculiar!

The only discrepancy was on the apneas...

I just ran a quick download for last night's data and everything matches up exactly -- including the apneas -- on the *.se opened in Excel, the *.24h opened with Excel, and on the *.txt files opened in word to just today's data on the synthesis report from Silverlining. I am running version 3.6.

I have noticed some averaging going on if you download more than one day, so be sure to just click on the date you want and make sure that no others are highlighted -- but I'm sure that you know that already. I'm thinking that there is something odd about the way that something is set up, but I don't know what that would be.

I'm too tired to think straight right now -- let me sleep on it and mull it over. I find that if I do something else, the answer comes to me when I am least expecting it! I had my brain stuffed full of .NET stuff today by a very bright, fast talking consultant to our company, so I am still processing that info too! It is neat stuff, though!

Sorry to ramble and think out loud!

[ozij]

Thinking out loud is great... and I sure know how sleeping on something helps - those it didn't for me in this case. Except to remind me we have demo data.

Look at the demo420enew3.pat, installed by the 3.6

Total apneas on the demo*.txt file: Number Apneas : 412
The Excel total for the same apnea data: 268

Look at session no. 28 in the synthesis screen, the session that started at 02:31 on the night of Wed. Sept. 10 2003: right click on that session – you'll get 8 apneas.
Compare with the Excel for that one session: you have 4 apneas.

Look at session no. 29 in the synthesis screen, the session that started at 00:09 on the night of Thurdsay. Sept. 11: right click on that session – you'll get 11 apneas
Compare with the Excel for that one session, No. 29: you have 7 apneas.

And if you want to feel very confused and dizzy, do the same for sessions no.1, no. 24 and no. 25!

Notice that the session dates are different for the on screen the presentation and in Excel.
On the sessions screen, Thursday's post midnight sessions are dated Sept. 11. In Excel however, they are give the date of Sept. 12 in the sessions file, but they are counted on Sept. 11, in the 24 hours file….
To make things easier, on the *.se file, I painted all session that belong to one night in one color, and used the same color on the *.24

I think the export - very reasonably - defines 24 hrs. from today's noon to tomorrow's noon, with today's date
O.

[glassgal]

Hi Ozij,

I have to get ready for work, but will be thinking about this today. I think that I have the demo info on my USB flash drive at work, so if I have time I will dink with it today. I was also thinking that if I could export the data directly into Access, that I could get a look at the tables and how they are arranged and populated. That would give us an inkling on what kind of data that they collect and what is being done in the reports and exports. I don't know if I can pull it off, though, and I REALLY need to get ready for work now!

I think that you may be onto something with the way that the data looks at time, though. The reporting calculations may be converting the data from the original to what the viewer is looking at -- or it could be triggered by local settings on our machines. I am set up for English (USA) and I would guess that you are set up for a different locale, which might affect how time (and other things) are handled.

Let me work on it this evening and over the weekend! This is getting interesting! The thing that bothers me most is that you are seeing something that I am not -- that is what makes me think that it has to do with local settings or individual machine settings.

[ozij]

I was thinking along the same lines, but I don't think it's the computer locale. They might be selling different versions in the States and in Europe. Here's what I've checked:

Tests:
Installed Silverlining on a virtual machine with Win XP Hebrew multilianguage version.
Result: No change.
Changed locale in XP control panel to US – got time and date US style in Windows.
Result: No change.
Uninstalled and reinstalled SL3
Result: No change.

Checked the registry, saw the following in the registry
[HKEY_CURRENT_USER\Software\Nellcor Puritan Bennett\SL\Options]
"Language"="ENGLISH"
"PatientPathName"="D:\\sl3\\Patient\\"
"Mini Comp"="6"
"Mini Pressure"=dword:0000005a

Changed the DMY into MDY
Result: No change
After the program is run, the definition reverts to dmy
Test: Chose French as program language.
Result: Registry changed accordingly.

Hypothesis: Could it be that it’s a different sl.exe file sold in the U.S.?
Looked at *.exe properties – version 1.0.0.1 copyright 2002, language US English.
When you look at the date in the program:
How do your dates look? (mm/dd/yyyy or dd/mm/yyyy? Ours is the latter)
How does your time look (ours shows a 24 hr. clock)
Did your installation include option for French, German, Italian and Spanish? Does you screen have a Language option? Do you have England, France, Germany, Italy, Spain dlls in your sl3 subdirectory?
Test: removed those DLLs from the subdirectory.
Result: The program couldn't function.
Do you have a USA.dll?
Does your "about screen" have CE0459 on it? Does it say it "complies with 93/42/EEC directive?.
How do time and date parameters look on the exported files? – I get European style date and time on the text files already.

Any European user out there with the Silverlining?

[ahujudybear]

OK,

I am no Techie. Not by a long shot.

But is it remotely possible that the clock for recording the parameter that is off in these files might be set for "overnight" or "single usage" on the machine, but interpreted into 24-hour bites by the program? (because a 24-hour bite would be from Midnight to Midnight on day 01, whereas a "session" would run from say 10 PM on day 01 to 7 AM on day 02.

And this might only be in place for the rawest data - how many AHI's. The machine would then break out the rest of that data based on this parameter.

Or maybe it is a hold-over from a previous program that didn't get changed with the rest of it?

I'm just guessing here, but that remark about 24-hour data sort of struck a chord.

- JB

[ozij]

Judy, and any other curious people:

I believe something to do with the clock messed up the apnea counting, but I've actually ruled out machine setup problems:

I've seen the problem on on data from two machines, one of them brand new.
I've seen the problem in two versions of the software...one of them brand new, and installed in what is effectively a brand new operating system with no left overs of an older version.
I've seen the problem in two different operating systems.
I've seen the problem in all data files the the program analysed - including the demo data that the company put on their CD.

So it must be the something where the software works the data to present it for human comsumption...

The fact that it's only apneas and not any other parameters makes me petty sure it's something someone overlooked, and not a major error in the logic of the whole thing.

First session on the demo3 data file shows up as 63 (!) apneas when Silvelining presents it on the screen. But only 40 when the data is exported....

O.

[-SWS]

Sorry for being deft, gang. I'm just getting up to speed on this thread and I have never had to rely on SL3 data exports. My question regards the two types of SL3 data scopes currently up for discussion. My take is that the Synthesized screen and the exported 24 hour file each employ the same time-based data scope when generating individual lines of data output. That time-based scope of data will thus analyze and generate output using roughly midnight to midnight scopes of data. That may or may not entail overlapping ("on/off") data sessions since we often go to bed before midnight and wake up the following calendar day, and because we may sleep several sessions per calendar day. There is also an option on that Synthesized screen to selectively filter calendar nights according to machine settings, but I see no per ("on/off") session scope capability on that Synthesis screen.

By contrast the exported session file with the SE extension will employ a data scope of exactly one "on/off" session per line of data output. Since this latter data scope is session-based versus time based, the resulting exported file will usually contain entirely different sleep event numbers than the 24 hour exported data file.

The SE and 24 exported files may or may not contain identical counts depending on how those sleep sessions happened to concur within each 24 hour calendar period. Again, the SE exported files employ per-sleep-session data scopes while the 24-hour exported files employ per-calendar-night data scopes. Theoretically the exported 24 hour files should each contain data that mirrors the Synthesis reports, which are also based on calendar nights versus those "machine on/off" sleep sessions. It sounds like this data-mirroring is not happening.

Ozi, do I understand correctly from your post above that your SE and 24 hour exported files contain identical sleep-event numbers when these two files are compared?

[-SWS]

Still getting up to speed! The individual lines of sleep-event numbers will be different between the exported 24 hour and SE files. Yet the sum total of sleep-event numbers should add up to the same totals between these two files. So I take it from the above posts there's no discrepancy here.

However, the individual sleep-event sum totals that are summed on the Synthesis screen do not agree with the individual sum totals from the above two files (notably apneas in this case) . Right? If this is true, we should be able to directly compare individual calendar-based data output on the Synthesis screen with individual calendar-based lines within the 24 hour exported file. Overt numeric-based (versus algorithm based )discrepancies just may bear out here during a number-by-number comparison----as well as comparing the total number of data enumerations/lines used to calculate those sum totals. Again these two data sets should exactly mirror each other.

[Janelle]

Just noticed on one of the posts that the differences were by a minus 4 and 44. Seems the Excel is integrated a minus 4 integer as far as it will go and reporting the difference. I have no idea how Excel works and have had little experience with it, but I thought this was "interesting."

[ozij]

. My take is that the Synthesized screen and the exported 24 hour file each employ the same time-based data scope when generating individual lines of data output.

..but I see no per ("on/off") session scope capability on that Synthesis screen

.

You can get a synthesis report of a single session if:
1. You left click on the day you are inerested in
2. Strech the screen with the magnifying glass (just to make things easier)
3. Right click on the session (on/off) that interests you.

That time-based scope of data will thus analyze and generate output using roughly midnight to midnight scopes of data

I actually think the progarm uses mid day to mid day - .

Theoretically the exported 24 hour files should each contain data that mirrors the Synthesis reports, which are also based on calendar nights versus those "machine on/off" sleep sessions. It sounds like this data-mirroring is not happening.

The data mirroring is indeed not happening.

Ozi, do I understand correctly from your post above that your SE and 24 hour exported files contain identical sleep-event numbers when these two files are compared?

Yes, the totals are identical. Namely:
When you take a 24h period as mid day to mid day, you will find the 24H summing of session in all pramaters (on of and all breathing messures) in total agreement with the SE - no problem there. (I have no server to put the files, or images on - ) These two files are consistent, you just have to remind yourself that the session data has real times and dates on it, the 24H one has an overlap, so :
The demo patient went to sleep after midnight on Friday, the 29, His Friday 24H count is dated for 29.8, and has one session to it, despite the fact the it started (time wise) just after midnight on the 30th. The 24H export counts this as Friday night. The session file reports this for the 30 - but again, this in not a problem and when you look at it "night wise" the number of session counted per "night" and the totals of all the parameters int the SE file agree with those on the 24H file.

The numbers I get on the synthesis screen - whether 24 hour totals, or separate sessions do not agree with those in the export files for the equivalent time period.
O.

[glassgal]

Hi Ozij,

Sorry I haven't responded sooner -- been busy!

My dates come out mm/dd/yyyy in all the exports as well as in SL. It does seem that I have seen dates in the European style in the past, but could not find any with looking for them -- typical!

All of the information that you noted on the about screen is the same.

I still see accurate reporting of apneas between all the exports and SL. I have been unable to duplicate your discrepancy.

What -SWS says makes perfect sense -- thanks!

It sounds to me like the different exports are counting differently, because they are using different time frames -- it that right?

Gosh -- this is a clear as mud! Guess the sleep deprivation is getting to me!

[ahujudybear]

Hi Ozij!!

A clarification here.

What I meant was that if you are only getting the discrepancy in one parameter, maybe the PROGRAM ITSELF has a leftover in its set-up from a different (discarded?) format... something that was overlooked when the program was re-tooled to upgrade it?

- JB

[ozij]

-SWS: Yes, that is the problem - your follow up question arrived when I was struggling with my first reply...

Jannelle - the discrepancy is there in the text files generated by SL3 - before the data get's into Excel

glassgal - if you can't duplicate the discrepancy, and we're using the same exe file, then it must be the handling of the european time frame.
Do you get AM and PM in the time column on the SE file?
Can you please check to see which dlls you have in the sl3 subdirectory?

Judy -thanks for the clarification basically, I think something was indeed overlooked - when they switched from one date and time (?) form to the other.

O.