Description
how Going forward we will need to extend the and modify the calculators, the just-ahead-of-time/ukrdc stats database? to allow efficient longitudinal calculations and user interactivity. This is going to require some careful thought about how to modify the whole stack to enable us to go beyond the idea of an instant annual report and move towards an actual ui which can be used to interact with the data.
Permissions
users should be able to see top level data from other centres for comparison but only be able to interrogate own data
longditudi
Multiscale Comparison
...
way the caching works to allow for multiscale comparisons between larger unit groupings and the same unit over time. This is a bit of a change because it will involve the dashboard stats library directly communicating with a cache of data. This will not change the way the precalculation works. There will also need to be a significant refactor of the calculators to allow the assembly of the patient cohort.
Caching
Going forward the dashboard stats will have its own redis database. This will not be exposed to the api since it will be unaggregated ukrdc data. It will store dataframes with keys based on the input required to calculate them. The calculators will check against the cache when query the ukrdc this will speed up the calculation since the database queries will only be run when they do not exist in the cache. The cache will expire either after an arbitary fixed time or a more intelligently calculated time period based on how old the data is.
Dashboard Stats Refactor
Target User(s)
Components/Dependencies
...