Function Catalogue
The Function Catalogue lists the available Raedfast modelling functions.
Your model is likely to be constructed largely by means of the Add and Move functions, with frequent use of AllocateResource, some use of Copy, and occasional use of the remaining functions.
Immediately below is a list of the functions with a brief description of each, in the approximate order of their likely use. Click on the name of a function to go directly to its catalogue entry, or scroll down to scroll through the catalogue in alphabetical order.
The Add function adds a number, or a percentage, to an area of the model.
The Move function moves a cohort of patients from one part of the model to another, say to a new Site or Pod.
Use the AllocateResource function to calculate additional measures for a record in the Raedfast database. You can use the function to calculate a figure for Beds, Theatres, Outpatient Rooms, Cost / Income, or any other measure you wish to create and calculate.
The Copy function copies data from one area of the model to another.
The BaselineFromHistory function establishes a baseline step by copying data from the ActivityHistory table.
The BaselineFromModel function establishes a baseline step by copying data not (as with the BaselineFromHistory function) from the ActivityHistory table, but from the ActivityModel table.
Use the SplitLosMoveNDays function to split the bed days for a case in two, moving N bed days per case and leaving the rest.
The SplitLosLeaveNDays function resembles SplitLosMoveNDays, except that you specify the number of BedDays to leave, instead of the number to move.
The Rate function adds a given number of one cohort of patients for each of another cohort. It is most commonly used to set the rate of one cohort to another, e.g. of follow-up outpatient attendances to firsts.
Add
The Add function adds a number, or a percentage, to an area of the model.
Using the Add function to add 0.5% to Day Cases etc., for each Year in the Modelling Period
Input Step variable
Often you will wish to apply the change to all the existing data. But sometimes you will want to apply the change to data generated against a specific step only, or against a group of steps. Use the Input Step variable to make this restriction.
Switches
IsAbsolute
The IsAbsolute switch determines whether the Number variable is an absolute number or a percentage, i.e. whether you want to add 10 Cases, or add 10% to the existing number of cases.
Currency
If the IsAbsolute Switch is checked then Currency is required, as the system needs to know the currency of the absolute number entered - i.e. whether it represents a number of Cases, or Bed Days, etc.
If IsAbsolute is not checked, Currency is ignored.
Measures
Use the Measures variable to control which measures are calculated. If this is left blank, all measures are calculated.
If IsAbsolute is checked, the Currency measure is used to turn the Number entered into a percentage, and the percentage is applied to all the measures identified in the Measures variable.
IsReplace
The IsReplace flag determines whether the input number should be added to the existing data or replace it. If it is checked, Raedfast subtracts the existing value from the number added.
For example, if you have 100 Cases and you add 110 then Raedfast will add 110 if IsReplace is unchecked, giving a new total of 210 If IsReplace is checked, Raedfast will add (110 - 100) or 10, giving a new total of 110.
FirstRuleWins
Use the FirstRuleWins switch to prioritise earlier rules in the step over later ones. If the switch is set for a given rule, any model records which are covered by any earlier rule will not be modified by this rule.
So for example:
rule 1 adds 2.4% to Age 18-64, for Commissioner X
rule 2 adds 1.8% to Age 18-64, for all Commissioners
What we want is to add 2.4% to Commissioner X (aged 18-64), and 1.8% for all other Commissioners. But as things stand, Commissioner X is addressed by both rules. Raedfast will add 2.4% to Commissioner X under rule 1, then a further 1.8% to Commissioner X under rule 2, thus adding a total of 4.2%.
There are three ways to avoid this:
create a separate rule for every Commissioner
create a rollup in the Commissioner dimension which includes every Commissioner except Commissioner X, and use the rollup to restrict the application of Rule 2
set the FirstRuleWins switch on rule 2, so that any output area already covered by an earlier rule (Commissioner X, aged 18-64 in this case) will not be affected by rule 2
The simplest of the three approaches is clearly the third, which neither multiplies the number of rules, nor requires the creation of otherwise redundant rollups.
Using FirstRuleWins to exclude areas of the model
You can also use FirstRuleWins to exclude areas of the model from a step, by setting numeric values on a rule to zero. If rule 1 in the example above had specified 0% instead of 2.4%, Commissioner X, aged 18-64 would have been effectively excluded from the step.
Allocate Resource
Use the AllocateResource function to calculate additional measures for a record in the Raedfast database. You can use the function to calculate a figure for Beds, Theatres, Outpatient Rooms, Cost / Income, or any other measure you wish to create and calculate.
Using the AllocateResource function to set TariffValue for different HRGs in the Emergency Department.
Formula
The formula used is:
MeasureToCalculate =
((DriverMeasure * UnitsPerDriverMeasure) + (TurnoverDriverMeasure * UnitsPerTurnoverDriverMeasure))
* (100 / %Utilisation)
* (%ActivityAffected / 100)
/ TimePerSession / SessionsPerWeek / WeeksPerYear
Formula defaults
The following defaults apply:
UnitsPerDriverMeasure defaults to 1
UnitsPerTurnoverDriverMeasure defaults to 0
%Utilisation defaults to 100
%ActivityAffected defaults to 100
TimePerSession, SessionsPerWeek and WeeksPerYear default to 1
Examples
Example 1: Beds
Entering …
DriverMeasure = BedDays
%Utilisation = 85
SessionPerWeek = 7 (i.e. 7 day ward)
WeeksPerYear = 52 (i.e. ward open at week-ends)
… yields this formula:
Beds =
((BedDays * 1))
* (100/85)
* (100/100)
/ 1 / 7 / 52
Example 2: Theatres
Entering …
DriverMeasure = Cases
UnitsPerDriverMeasure = 40 (minutes in theatre)
%Utilisation = 72
%ActivityAffected = 95 (95% of patients goes to theatre)
TimePerSession = 210 (minutes in a session)
SessionPerWeek = 10 (sessions in a week)
WeeksPerYear = 48 (theatre closed for 4 week per year)
… yields this formula:
Theatres =
((Cases * 40))
* (100/72)
* (95/100)
/ 211 / 10 / 48
Using the AllocateResource function to calculate require theatres for different cohorts of patients.
Updates not inserts
Note that the AllocateResource function differs from all other functions in that it updates existing records in the database, instead of inserting new records.
All other functions generate new records, tagged with the ActivityStep element of the rules which generated the records.
The AllocateResource function updates existing records generated by the other functions.
This is so that the impact of each step can be seen not only on the measures which were generated by that step, but also on the derived measures calculated through the AllocateResource function.
So against a step called say Move Elective to Day Case you can see the impact of the move not only on the Cases and BedDays measures processed by the step itself, but also on the Beds measure derived by the AllocateResource function.
It follows that the AllocateResource function must be run after the steps which generate the records the function is intended to complete.
Viewing output
Be aware then that when analysing model output by step, you will not see any output against a step that uses the AllocateResource function. Instead, you will find the output held against other steps, in the measure for which your AllocateResource step set a value.
Precedence of rules
Note that all rules have force with the AllocateResource function, just as for any other function. Since as noted above the function applies updates to existing records rather than inserting new records, if two rules apply to the same record in the ActivityModel table then the two rules are applied additionally: one does not take precedence over the other.
So if for example you were to set a TariffValue in one rule of £50 per case for first outpatient attendances, and in a second rule you set a TariffValue of £40 for all outpatient attendances, your first outpatient attendances would be allocated a TariffValue of £90 (£50 + £40).
If you want an earlier rule to take precedence over a later rule, use the FirstRuleWins switch, as you would for any other function.
Switches
FirstRuleWins
See the description of FirstRuleWins under the Add function above.
Baseline from History
BaselineFromHistory establishes a baseline step by copying data from the ActivityHistory table.
Using the BaselineFromHistory function to define a baseline, by taking 100% of IP and OP data for 2019 into the Baseline year. Note that ED data is scaled up to 120% because only 10 months of data is available. Not too that all data sets are compressed by 90% to increase performance during model development.
The function allows you to:
specify the range of months to copy
specify the first Year of the Model
specify the version(s) to copy
choose any cohorts of patients to bring in
specify the percentage of data to copy
compress data for faster model processing
Uplifting partial data
Use the Percent variable to scale historical data up (or down). For example if you have only eight months of history for a given set of data, you might want to set Percent to 150, to scale the data up to a whole-year equivalent.
If you want to take the historical data asis, set Percent to 100.
Compressing data
Use the Compress by n% field to compress the incoming data to reduce data volumes and speed model processing.
If you set the compression value to 90%, Raedfast will take every tenth record at random, and multiple the measure values (Cases, BedDays, etc.) on that record by 10, so that the volume of data is reduced by 90% but the value of each measure remains approximately the same.
You can turn compression on and off at any time. So you can if you wish use compression to speed up model development and testing, then turn it off when you think your model is complete.
Switches
FirstRuleWins
See the description of FirstRuleWins under the Add function above.
Baseline from Model
BaselineFromModel establishes a baseline step by copying data not (as with the BaselineFromHistory function) from the ActivityHistory table, but from the ActivityModel table.
Using the BaselineFromModel function to roll Baseline Year forward to Year 1, Year 1 to Year 2, etc.
The function allows you to:
specify the year to copy from
specify year to copy to
specify the ActivityScenario(s) to copy
choose any cohorts of patients to bring in
specify the percentage of data to copy
compress data for faster model processing
Rollover of one year to the next
The BaselineFromModel function is most commonly used to copy the total of all steps from one year into the baseline if the next year.
Using one scenario as the baseline for another
The function can also be used to set one scenario as the baseline for another. This can be useful if you have a scenario (call it scenario X) on which you want to model a number of variations. Using the BaselineFromModel function, you can define scenario X as the baseline for each variation, so that you do not need to reprocess the steps of scenario X every time you process the variations.
Recurring and non-recurring activity
Note that you may not want to copy the sum of all steps for the earlier Year. You may have steps which are non-recurring (for example, a waiting list initiative), and which should not feed through into the next year’s baseline. In this case:
create a rollup in the ActivityStep dimension called say Recurring
set values for the rollup of Recurring and Non-recurring
make the Recurring element the top-sorting element so that it is the default for new steps
set the Recurring rollup value for your non-recurring steps to Non-recurring
in your BaselineFromModel step, specify Recurring in the ActivityStep variable: only steps in the Recurring rollup will be rolled forward
Using this approach, you can identify by exception those steps which should not be carried over to the next year’s baseline.
Compressing data
Use the Compress by n% field to compress the incoming data to reduce data volumes and speed model processing.
See under function BaselineFromHistory above for more details.
Switches
FirstRuleWins
See the description of FirstRuleWins under the Add function above.
Copy
The Copy function copies data from one area of the model to another. It operates across all dimensions except for scenario and year. The function therefore has a pair of variables, a From and a To, for each dimension, except scenario and year (and of course step, the output step being determined by the step within which the rule exists).
Using the Copy function to distribute data in the Holding Pod across different sites.
Level of variables
To variables must be at the dimension base level. From variables can be at a base or a rollup level.
Relationship of From and To Variables
It is perfectly legitimate to have a From variable without a corresponding To variable, or a To variable without a corresponding From variable. The table below shows the various possibilities, using as a simple example a Site dimension with three base elements, A, B and C, and a rollup A+B :
Compressing data
Use the Compress by n% field to compress the incoming data to reduce data volumes and speed model processing.
See under function BaselineFromHistory above for more details.
Switches
IsAbsolute
The IsAbsolute switch determines whether the Number variable is an absolute number or a percentage.
Currency
If the IsAbsolute Switch is checked then Currency is required, as the system needs to know the currency of the absolute number entered - i.e. whether it represents a number of Cases, or BedDays, etc.
If IsAbsolute is not checked, Currency is ignored.
IsReplace
The IsReplace switch determines whether the input number should be added to the existing To area data or replace it. If it is checked, Raedfast subtracts the existing value from the number copied.
For example, if you have 100 existing Cases in the To area, and you copy 110 then Raedfast will copy 110 if IsReplace is unchecked, giving a new total in the To area of 210. If IsReplace is checked, Raedfast will copy (110 - 100) or 10 , giving a new total of 110.
FirstRuleWins
See the description of FirstRuleWins under the Add function above.
Move
The Move function is similar to the Copy function, except that the activity is moved instead of copied.
Using the Move function to move a proportion of short-stay activity from the Elective Pod to the Day Case Pod.
So for example activity moved from an Elective Inpatient to a Day Case POD is added to the Day Case POD, and the same number is subtracted from the Elective Inpatient POD.
Switches
The switches for the Move function are the same as for the Copy function.
They operate in the same way, except for FirstRuleWins.
FirstRuleWins with Move
The Move function, unlike all others, affects two areas of the model simultaneously — the area to which activity is added, and the area from which it is subtracted. This complicates the operation of FirstRuleWins. You may have a rule which moves from Site A to Site X, then a second rule which moves from Site B to Site X. If FirstRuleWins is turned on for the second rule, how should the system behave? Rule 1 sets a value for Site X, so rule 2 should be ignored. But Rule 2 also sets a value for Site B, and rule 1 does not, so Rule 2 should not be ignored.
To avoid this difficulty, the Move function insists that:
if FirstRuleWins is checked for any rule in the step, any dimension with a To value different from its From value in any rule must have these same values repeated in every rule.
So with FirstRuleWins checked anywhere in a Move step, if you move from Site A to Site B in one rule, you must move from Site A to Site B in every rule. You cannot move, as in the troublesome example above, from Site A to Site X and then from Site B to Site X.
You are still free to vary the values of other dimensions from one rule to the next as you please. So for example you can have a first rule which moves say 10% from Specialty 100, Site A to Site X, then a second rule which moves 20% from All Specialties, Site A to Site X. In this case the second rule will be ignored for Specialty 100.
Rate
The Rate Function adds a given number of one cohort of patients for each of another cohort. It is most commonly used to set the rate of one cohort to another.
Using the Rate function to create 1.248 follow-up outpatient attendances for each first in specialty 100, replacing the existing follow-ups. And so on for other specialties.
The function uses a pair of variables for each dimension - e.g. Numerator Pod and Denominator Pod. The exceptions are:
ActivityStep, for which the numerator is implicitly the step being processed
ActivityScenario, for which the numerator is implicitly the scenario being processed
Year, for which the denominator is taken to be the same as the numerator
If a numerator value is given, and a denominator value is not, the system defaults the denominator value to the numerator.
Normally then you will define your numerator area, and specify denominator values only where they differ from the numerator.
If a denominator value is given, and a numerator value is not, the system assumes that you intend the numerator to use the total of all elements in the dimension in question. While unusual, this is not illegal.
Rate compared with Copy
At first sight, the Copy function might seem to accomplish the same as the Rate function. Is setting a rate of B to A not the same as copying from A to B? So that the following two moves might seem identical:
use the Copy function with the IsReplace option to copy 200% from first outpatient attendances to follow-up outpatient attendances
use the Rate function with the IsReplace option to set a rate of 2 follow-up outpatient attendances to each first outpatient attendance
In fact the two functions differ significantly.
When you copy from A to B, the newly created B records have the characteristics of the A records copied, in terms of dimensions not specified in the definition of the To area.
When you set a rate of B to A the characteristics of the new B records are the same as the existing B records..
So to pursue the example above, let us suppose that first outpatient attendances have a different distribution across the Age dimension from follow-up outpatient attendances. Using Copy, the new follow-up outpatient attendance records would have the Age distribution of the first outpatient attendances which were copied. By contrast, using Rate, the new follow-up outpatient attendances would have the Age distribution of the existing follow-up outpatient attendances.
Creating new data
It follows that the Rate function cannot be used to create new data: in the example, both first and follow-up outpatient attendances must exist. By contrast, the Copy function would work to create new follow-up outpatient attendances, even if none currently existed.
Switches
IsReplace
The IsReplace switch tells the system to remove existing values for the given patient cohort. This reflects the difference between specifying a new length of stay of 2 days (IsReplace checked on), and adding 2 bed days per case (IsReplace checked off).
FirstRuleWins
See the description of FirstRuleWins under the Add function above.
Formula
The function calculates a percentage change as:
((Sum of Denominator * Rate) / Sum of Numerator * 100) and applies this percentage as an uplift to the Denominator area.
To take a simple example, let us suppose we want to set a rate of 2 follow-up outpatient attendances per first attendance:
And let’s suppose that we have currently 4,000 first attendances, and 12,000 follow-ups. The percentage of follow-up attendances to be added is calculated as:
((4,000 * 2)) / (12,000) * 100
... or 66.66%
So the system will add 66.66% of the existing 12,000 follow-up attendances, which is 8,000, and (since we will have checked the IsReplace switch) the system will also subtract the existing number, which is 12,000, leaving a net number to add of -4,000. So the current step, added to the existing number of 12,000, will result in a net number of follow-up attendances of 8,000, which is the desired 2 per first attendance.
Handling measures
The Rate is the rate for the numerator measure / the denominator measure - e.g. if numerator measure is BedDays and denominator measure is Cases then the specified rate is the average length of stay.
Denominator measure defaults to numerator Measure, just as for the dimension variables.
The CalcMeasures variable determines the measures to which the calculated percentage change is applied. If for example you want to set a new average length of stay of 3.5 days then you enter BedDays as the numerator measure, Cases as the denominator measure, and BedDays (or a rollup of BedDays and Beds) as the CalcMeasures value (since you presumably don’t want to change say Income or Theatres).
If CalcMeasures is left blank then all measures are calculated.
Switches
FirstRuleWins
See the description of FirstRuleWins under the Add function above.
Split LOS Leave N Days
Use this function to split the bed days for a case in two, leaving N bed days per case where they are and moving the rest to the new location.
Using the SplitLosLeaveNDays function to move all emergency bed days after the first 14 to a Holding Pod, for long stay adult patients.
PODs, sub-pods and measures
You can use the function to move BedDays into a specific Pod or SubPod.
Alternatively you can move the days into a new measure. So if for example you wish to move a proportion of BedDays from an acute to a community inpatient setting, you can create the community setting as a new Pod or SubPod, or you could create (say) CommunityBedDays as a new measure.
Days to Leave per Case
Specifies the number of days per case to be retained to the new location. The remaining bed days will be moved.
% ActivityAffected
Specifies the percentage of activity affected by the move.
Switches
CreateNewPartCases
Optionally copies the Cases value to the PartCases measure. If the new care setting is within the same provider as the old, you might use this option to record how many Cases are being part-moved, but record these cases as PartCases instead of Cases, since to record them as Cases would (perhaps misleadingly) increasing the number of Cases in the provider. If the new setting is within a different provider then you will probably wish to record the activity in the new provider as Cases rather than PartCases.
FirstRuleWins
See the description of FirstRuleWins under the Add function above.
Method
Level of operation
The function works out the total number of BedDays to leave, at the level specified by each rule — i.e. for the entire cohort defined by the rule. The function then pro-rates this total for each individual database record in the cohort, according to that record’s BedDays value.
Moving negative BedDays
Within the cohort, each individual record gets its proportionate share of the total to be moved, even if the BedDays value for that individual record is negative (because for example the record sits against an Add step which subtracted activity).
Leaving more BedDays than exist to be left
If at the level of the entire cohort there are fewer BedDays than the number to be left, the function will have no effect and the activity will remain unchanged. For example, if you specify that 10 BedDays per case are to be left and for the cohort as a whole there are only 8 BedDays per case, no BedDays will be moved.
Use of the Los (Length of Stay) Dimension
If you specify an Los element as part of the definition of the cohort (as in the example screenshot above), the function will be applied only to patients whose length of stay has the selected value, or falls within the selected band. So in the example shown, only patients staying over 60 days are affected by the first rule, and so on.
If you do not specify an Los element then the logic applies to all patients in the cohort, irrespective of their length of stay. This could mean that no days are moved, if you try to leave 10 days per case for a cohort of patients whose average BedDays per Case is less than 10, even if that cohort includes patients who did stay more than 10 days. It could also mean that days are moved from patients who stayed less than 10 days, as when days are moved every patient in the cohort gives up its proportionate share (see Method above). In some circumstances, this may be what you want. If it is not what you want, use the Los dimension to tighten the definition of the cohort.
Split LOS Move N Days
Use this function to split the bed days for a case in two, moving N bed days per case to the new location and leaving the rest where they are.
Using the SplitLosMoveNDays function to move 1.25 days per emergency case in medical specialties to the Medical Assessment Unit, creating new PartCases. Note the use of FirstRuleWins to exclude specialties 328 and 320.
PODs, sub-pods and measures
You can use the function to move BedDays into a specific Pod or SubPod.
Alternatively you can move the days into a new measure. So if for example you wish to move a proportion of BedDays to an Assessment Unit, you can create the Assessment Unit as a new Pod or SubPod, or you can create (say) AssessmentUnitBedDays as a new measure.
Days to Move per Case
Specifies the number of days per case to be moved to the new location.
% ActivityAffected
Specifies the percentage of activity affected by the move.
Switches
CreateNewPartCases
Optionally copies the Cases value to the PartCases measure. In the example of the Assessment Unit, you would use this option to record how many Cases are being part-moved to the Assessment Unit, but record these cases as PartCases instead of Cases, since to record them as Cases would (perhaps misleadingly) increasing the number of Cases.
FirstRuleWins
See the description of FirstRuleWins under the Add function above.
Method
Level of operation
The function works out the total number of BedDays to move, at the level specified by each rule — i.e. for the entire cohort defined by the rule. The function then pro-rates this total for each individual database record in the cohort, according to that record’s BedDays value.
Moving negative BedDays
Within the cohort, each individual record gets its proportionate share of the total to be moved, even if the BedDays value for that individual record is negative (because for example the record sits against an Add step which subtracted activity).
Moving more BedDays than exist to be moved
If at the level of the entire cohort there are not enough BedDays to move, the function will take the BedDays which are available, but will not take more than that — i.e. it will not move BedDays which are not there to be moved.
Use of the Los (Length of Stay) Dimension
If you specify an Los element as part of the definition of the cohort, the function will be applied only to patients whose length of stay has the selected value, or falls within the selected band.
In the screenshot shown above, the cohorts are defined without reference to the Los dimension.
If you do not specify an Los element then the logic applies to all patients in the cohort, irrespective of their length of stay. This could mean that no days are moved, if you try to move 2 days per case for a cohort of patients whose average BedDays per Case is less than 2, even if that cohort includes patients who did stay more than 2 days. It could also mean that days are moved from patients who stayed less than 2 days, as when days are moved every patient in the cohort gives up its proportionate share (see Method above). In some circumstances, this may be what you want. If it is not what you want, use the Los dimension to tighten the definition of the cohort.