Description
how to extend 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
Going forward we will need to extend the and modify the 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 arbitrary fixed time or a more intelligently calculated time period based on how old the data is. The cache will have a key which reflects the parameters the calculators are being run with and the name of the calculator. For example RRT_RFBAK_23_6_1.
UKRDC Codes
We have already added a codes to the code_map table to enable grouping of prd. We will include more codes to group the units into regions. This will be something like:
source_code_standard | source_code | destination_coding_standard | destination_code |
|---|---|---|---|
NHS_SENDING_FACILITY | RFBAK | URTS_REGION_GROUPING | London |
Dashboard Stats Refactor
The calculator classes will be refactored to take into account the new system of caching. This will primarily involve reworking the extract patient cohort functions. The input parameters will be defined in terms of scale and time. These will have to be quantised so the calculators can calculate for the following groupings.
Scale | Process of assembling cohort |
|---|---|
Whole Registry |
|
Region |
““ |
Sending Facility | This will work as it currently does however it will snap to the nearest date. I think maybe we should add a calculate from todays date button for this one. |
Satellite | This would be just a filter applied to above. |
Current prototypes for calculating longitudinal stats inherit the calculators for individual sending facilities. This will allow the above to automatically be applied when calculating comparisons in time.
Scheduled Precalculation
This will continue to work in the same way in which it currently works however the date in which all the items are recalculated will need to be coordinated with the fixed dates for which dashboard stats is looking in the cache.
Target User(s)
Components/Dependencies
...
- Create xy model
- Write core query to …
- Write abc function to filter patient cohort …