Option for automatic rebasing

[LynHoward]

UHMB have developed a way to automate rebasing their SPC charts in Qlik, could something similar be added as an option to the PTD package?

[ThomUK]

This is similar to issue #142, which we recently decided not to implement inside this package. Automatically rebasing removes the deliberation from the decision to change limits, and while useful in some circumstances (eg. when scanning large amounts of data), the MDC programme tends to encourage deep consideration about the reasons for individual process changes before changing limits.

An auto-rebasing package might make a good companion package to NHSRplotthedots for those use-cases that need it. There are some notes on options to implement this in this comment on the closed issue. That comment also includes a link to some auto-spc code already written in R, which if not already structured as a package could be forked to do that (assuming there's an open license). https://github.com/nhs-r-community/NHSRplotthedots/issues/142#issuecomment-1162205702

Anyone else have views on this?

[Lextuga007]

I've personally only ever rebased in response to a process change or specific circumstance (smoke free or covid as examples).

If an automatic rebase is positive is that just luck or something we've actively done? On the contrary, if a rebase is in response to negative data points then would we just be hiding an ever worsening situation? In other areas of NHS data we are very cautious of automation with no human input, for example, patient lists of those who haven't been seen in the last year cannot be automatically discharged as each case needs to be reviewed. Do rebased charts get reviewed in this way?

Perhaps this could be a good candidate for a review using Data Hazards? One particular term to explore could be the hazard of automating decision making. A hazard doesn't mean it can't be done, just that it's flagged up, discussed and, perhaps, risks mitigated against.

[HanselPalencia]

Jumping off of what @ThomUK I think a companion package is the way to go on this. Perhaps a function like ptd_rebate_check() where you can dynamically change the rebate, say in a Shiny app, and then check to see what the plot would look like with redrawn mean, UCL and LCL, without actually changing the underlying data itself.

[tomjemmett]

had a little bit of a thought about the spc autorebasing... while I personally don't think it's a good approach and would prefer to have sound reasoning for rebasing... that's not to say the method shouldn't exist in the package...

from memory, you use ptd_rebase() to trigger rebasing, all that does though is sanitises inputs (basically turns it into a list). So, ptd_auto_rebase() could infer from the data and return the needed list...

slight issue here is ptd_rebase() is called before the function actually runs - it's just an argument to the function. What we would want to do is somehow defer execution of the argument. And we wouldn't want to run the ptd_auto_rebase() function until we have partially evaluated the spc data...

One way of doing this would be for ptd_auto_rebase() to return a function itself. Now, we would need to at the correct point determing if the rebase argument is a list or a closure. Avoiding if's is good where possible... so we could change ptd_rebase() to return a closure which just returns the initial input... that does break any existing code which passes in list's directly to the spc function though

[ThomUK]

I think as per #142, this is out of scope for the {NHSRplotthedots} package. There is code available for auto-rebasing in this pacakge, and some members of that project are also members of the NHS-R community.