Hide / Delete Session Data Feature Request

[DeepBreathing]

I agree with Michael's position on this. The Oscar team is taking a long term view that Oscar should be automatically accepted (and even used) by the medical profession and regulatory bodies. Hiding data will not be acceptable to these bodies.

While there may well be valid reasons to turn a session off, it does reflect in the statistics page, which is likely the documentary evidence that regulators would be looking for. I think if the turned-off sessions could be isolated from the stats and overview pages, that might be acceptable. Perhaps there could be a more conspicuous flag on the daily page to indicate that a session is turned off.

I've had a look at ResScan and that does not have the ability to turn sessions on or off.

Another thing I've noticed with a bit of experimenting is that turning sessions off obviously reduces the hours used, so if you're close to the edge of compliance it might be enough to make you appear non-compliant. On the other hand, unless it is a particularly bad session there isn't a lot of impact on the average AHIs.

[pholynyk]

I'd like to point out that the session data is removed from the daily calculation, but the session itself is still present in the Session list in the left panel, and in the Session bar at the bottom of the left panel. The session which is ignored changes from light blue or yellow to white surrounded by an outline. This isn't very obvious, compared to the times you aren't using the machine, so I would suggest we change the ignore colour to a bright red.

[Osiris357]

You could put “warning session has been deleted from compliance report” on the compliance report if a session has been turned off

[Osiris357]

You could have a warning on the compliance report saying “warning session has been turned off, report not valid” or something like that on the report itself if any session within the compliance period is off. That would prevent any nefarious use of the ability to shut off sessions.

[Sleeprider]

The correct solution is to allow user session data to be turned off in daily details, but Statistics, Overview and any Reports would disregard session data preferences and be based on all data. This is especially true if we create a "Compliance Report". I think what people are forgetting is that a compliance report is simply based on usage or therapy hours. There is no advantage to turning off session data if the idea is to "alter" a report, because it can only subtract hours. The AHI is generally not very important to usage compliance and it's hard to know how that would be significantly altered by a user excluding session data. For its intended and likely use, the OSCAR handling of session data is not that important in my opinion, but allowing a user to view daily details as they prefer, but not having those choices used in summary data would be the correct solution.

[GuyScharf]

SH and OSCAR have always allowed the user to delete entire days permanently and to disable sessions for the duration of OSCAR execution.  That's most visible on the Overview report and also shows up on the statistics report.  Disabling a session is finer control and has a lesser effect on the usual compliance data (days and hours of use).  Deleting a session or a day will only make the usual compliance data worse.

Remembering that the session is disabled doesn't alter how a user can change the results.

[mjphyi]

I agree with Michael's position on this.

I extracted all except this sentence from DeepBreathing's post, as that's all I wanted to comment on.

I have attempted to NOT take a position on this, while noting that I see both sides of the argument. I suspect I may have failed in that attempt.

It's fairly apparent that this forum has either a hierarchy or at least a variety of status levels within its contributors, and also a group who steer the development of Oscar.   I did assume that this "development group" had already its own discussions on this feature, and I didn't then and don't now want to challenge that decision.
And the reason I don't is that I'm not a member of this development group.

I did intend to express mild surprise at the direction that decision went; it seems to me less conservative than I had expected. But it's hardly a big deal.

But I do have some positions, and I will state some of the relevant ones from the viewpoint of a retired engineer with some involvement in product planning, who has seen different approaches both work and fail.

There is no one true holy way, but my positions are:

1  I am heartened by and I applaud the contributions of the developers and higher level members of this forum to this thread. 

2  With the above in mind, I'd like to see the future plans for Oscar be just a little bit more open. I'd like to know where the developers intend to take it.

3 I'd like there to be some form of read only access to the bug list by non developer ApneaBoard members.

4  I'd like to engage in a discussion with a developer who is very familiar with the design goals of the timer reporting system of Oscar/Sleepyhead. In my usage it gives me problems, and while I suspect the design model is broken, I am well aware that I'm not familiar with the data reporting requirements of machines other than the ResMed ones I have. I'd like to learn more.

I have taken Bonjour at his word that critical comments are welcome as I relate these 4 positions. I could elaborate, but I have come as close to hijacking this thread as I care to.  And after posting this, I will be sending bonjour his promised PM.

Michael

[sawinglogz]

I think you're assuming a lot more planning than there really is!

The reason decisions like this haven't been published is that they largely haven't been made. And they haven't been made because there have been more pressing issues, like (occasionally) wildly inaccurate data import and other clear failings.

That could be why the approach appears "less conservative" to you.

Also, it's worth thinking about threat model: what kinds of errors will clinicians/insurers/employers care about? The big one is total hours of usage (compliance). Hiding/omitting a session only makes your compliance look worse, so if you were hiding significant sessions, you'd only be driving your compliance down, which is a "safe" error as far as the insurers and employers are concerned (since you won't be defrauding them into thinking you're using it more than you are). And if you're hiding small, insignificant sessions, you're simply cleaning up the data and not affecting compliance much at all. So letting people exclude sessions doesn't seem like a concern here.

Now, clinicians might be a little concerned if you're excluding significant sessions with terrible AHI, but why would you do that? You want to know whether the therapy is working or not, so skewing those number isn't in your best interest. And if you have a short mask-on/off session that's not significant, it's not going to be contributing much to your overall AHI. So again, this seems like a concern that's not likely to play out in practice. (If you can think of a problematic scenario that's reasonably likely, by all means raise it!)

Alternatively, one approach overall might be to do what I've seen on official PRS1 reports: evidently you can disable sessions there as well (or at least days), which will show them crossed out on the weekly usage summary, but will exclude them from statistics. That way it's immediately apparent that you're excluding data.

So overall I think I'd favor some way of showing the hidden sessions in the "session times" overview, but with a color (or pattern that works well when printed in B&W) or some marking that indicates they're being excluded. Then you can exclude them from all other stats, because it will be immediately evident from the session times whether you've excluded any major sessions.

But, again, this hasn't really been discussed since we've been focused on shoring up the foundation.

[sawinglogz]

SH and OSCAR have always allowed the user to delete entire days permanently and to disable sessions for the duration of OSCAR execution.  That's most visible on the Overview report and also shows up on the statistics report.  Disabling a session is finer control and has a lesser effect on the usual compliance data (days and hours of use).  Deleting a session or a day will only make the usual compliance data worse.

Remembering that the session is disabled doesn't alter how a user can change the results.

Much better summary than mine!

[SuperSleeper]

Probably stating the obvious, but there's two separate goals in all this, I think:

1.  Make OSCAR as customizable for the end-user as possible for various reporting/analysis purposes.

2.  Make OSCAR as "trustworthy" as any of the proprietary software packages for the benefit of medical professionals.

The challenge is in making sure that any customization for patient use does not negatively affect the trustworthiness of the software for the medical community.

Since the beginning of the original software back in 2011, not much thought was given to #2 at all.  Back then development effort was solely focused upon the needs of patients, with little thought that it might be used by medical professionals at some point.  It's only during the past several months that some on the OSCAR team began thinking about the possibility of OSCAR being used for "official reports" that might be accepted by medical professionals.

Both are worthy goals, but the whole reason for the software to begin with was for patient use.  That should still remain the primary goal, IMHO.  But it would be nice to accomplish both goals.