idamtnboy wrote:DreamDiver wrote:Actual therapy trumps quirky data.
You worked on the data skew issue a lot last spring. What's your take on what I present in my thread today about S9 data being a Resscan problem, not a machine or card problem?
idamtnboy wrote:I discovered that Resscan includes several sample data files for various types of machines. I imported the S9 example as another patient and then looked at the graphs. Guess what? Resmed's own detail data file, the rlk files in the patient folder, has a ~40 minute skew when I look at it with the nav window set to 8 hrs and the detail window set to 5 minutes, the same skew I see on my data. Now, you really don't think Resmed would include defective data in the Resscan installation, do you?
Also, if you look at flow and events in the same window, either nav or detail, you will see they are lined up perfectly. The problem is how Resscan applies the timeline to the windows.
They did in fact leave a skew in the example patient data. Remember, they're using the same hardware we are to create their example data. It only makes sense the data would show the skew, even if unintentionally. Falsifying example data might be considered scientifically unethical. Science is all about exposing the warts. You're just seeing that in practice. I'd be
more likely to think twice about Resmed's ethical standards if the skew
didn't show in the example data. I
applaud ResMed for not giving us adulterated example patient data.
Proof of Skew Root Cause:
The data is stored on the SD card in a widely-renowned open-source format (.edf, amongst others) These files are readable in an open-source program like EDFBrowser. Once you figure out how to display the data, it's easy to see that the skew exists in the original format before it even gets imported into ResScan.
ResScan manipulates the data as it pulls it from the SD card and places it in .rlk format (again, amongst others) in the personal data folders within the ResScan program folder on a windows machine. Edited data is not first-hand data.
EDF Browser views the data
unchanged, directly from the
original document (or a duplicate) in which the data was actually recorded. The skew is visible in the
first-hand data just as precisely as it is seen in ResScan's edited version. Since we know EDFBrowser is only
viewing and
not manipulating the data into another file type, we can safely assume the data error is with the S9 firmware - not with ResScan. You can get EDFBrowser for Linux and see the same results, so this glitch is independent of the operating system upon which it is viewed.
Adapting ResScan to 'fix' the problem as an end-user Solution:
Consider the possibility that they could
alter ResScan to look for and adapt the data in an attempt to fix the skew at the second-hand data level. The product of that manipulation then becomes third-hand data. It gets worse because the manipulation involved is a like leap-year calendar fix on an accelerated scale. One 'little' adjustment algorithm may introduce the need for increasingly-more-subtle adjustments over longer periods in an already-questionable adjustment algorithm. From a scientific and medical standpoint, the resulting output will not garner as much trust as first-hand or second-hand data. Over a six-month period, the altered skew would probably show additional anomalies. ResMed will know this if they have attempted to fix it. Either that or they'll find it out when they do attempt it. A poor xerox copy of a poor xerox copy of a xerox copy... Meh.
End Result...
This is a firmware issue*. It will not be readily resolved with software. The only fix is a firmware fix. Unless something in the firmware is found medically unsafe, the machine firmware will remain unchanged for all future production of the current S9 family. A firmware upgrade for existing S9's is very unlikely because the flow-generation part of the firmware is truly an awesome thing -- and entirely independent of the data-recording part of the firmware. Count on it.
Format the SD card every two weeks to avoid gross skew. This is the best we can do as end users.
*While it's only been briefly discussed on this forum there is a remote possibility that it could be a hardware issue. There may be one or more conflicts between integrated circuit chips on the flow generator's circuit board that are hard-wired into the recording end of the system. If that's the case, you can forget even a firmware fix. That said, this consideration is extremely remote. I've only seen something like this once: Some iMacs have a faulty random-number generator due to a hardware issue that makes them vulnerable to all sorts of problems for software developers who aren't aware of the problem.
