Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 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

  • Get nearest fixed date (for example first of the month)

  • Get list of all sending facilities

  • Iterate through list of facilities checking against Redis cache for precalculated tables, calculating where it doesn’t exist.

  • Assemble dataframe

  • run calculator methods

Region

  • Get nearest fixed date (for example first of the month)

  • Get list of sending facilities based on lookup against code map table

““

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 …

Reviewers

Joel Collins

George Swinnerton