Rule-writing in depth

Understanding model processing

Order of processing

When you process the model you do so for a selection of scenarios, and up to a given end year. The system processes the model rules in the order of step within year within scenario. That is, the system begins with the first of the selected scenarios, in order (the order is given by the sequence of the scenarios left-to-right on the Steps and Scenarios screen). Within that scenario the system takes each year in order (the order is given by the YearSeqno value, and if two of these are identical that by the year value itself, in the year dimension table). Within that scenario and year each step is processed in order (the order is the order displayed on the Rules Editor screen for that step).

Output from processing

Processing generates data in the ActivityModel table. Each rule creates records in the ActivityModel table, stamped with that rule’s step, and the scenario and year under which the rule was executed.

There is one exception to this statement. The AllocateResource Function, which is used to derive resource measures such as Beds, Theatres, etc. on the basis of other measures such as Cases and Bed Days, does not create new ActivityModel records, but rather sets the value of measure fields on the existing records.

Forward references in rules

Data for a scenario to be processed is deleted at the beginning of processing, so no data exists in the ActivityModel table for the scenario except what has been generated by this processing run. Note that data for the scenario is deleted for all years, including for years later than the selected processing end year.

It follows that no rule can usefully refer to a scenario or a year or a step which is later in the processing sequence than the rule itself, since there will at the time of execution of the rule be no data for it to operate on.

Unit of work

All rules for a given step are executed before the output data for any rule of the step is written to the ActivityModel table. Consequently the output from one rule does not furnish input to a subsequent rule in the same step.

Data for existing processed scenarios

Data for scenarios not flagged for inclusion in a processing run is not deleted. You do not need to rerun processing for a scenario if you have not changed the rules or the baseline data or the dimension rollups which define it.

Processing only those scenarios which have changed and are of current interest can deliver big performance gains.

You may of course choose not to reprocess a scenario even if the rules which determine it have changed, if that scenario is not of interest at this time.

When has a scenario changed?

A scenario can be said to have changed, i.e. to need to be reprocessed, when:

the selection of steps has been changed which comprise the scenario
the rules have been changed in one or more of the steps which comprise the scenario
the definition has been changed of one or more dimension rollups which are used in any of the steps comprising the scenario
the ActivityHistory table data which provides the scenario with its baseline has been augmented or reloaded
a scenario on which this scenario depends for its baseline data has been changed in one of the ways above

To clarify the last case above, you may have a scenario which takes its baseline data not from the ActivityHistory table but from another scenario in the ActivityModel table. In this case you will need to reprocess the dependent scenario if the scenario on which it depends has changed, even if the dependent scenario has not.

Using the rules-editor screen

Hiding and showing blank columns

Use the buttons at the bottom of the screen to hide and show columns in which no data has been entered.

Mandatory fields

Depending on the model function in use with the step, some fields are mandatory. Hiding blank columns will not hide mandatory fields.

Which fields are mandatory depends on the Function, but generally includes Year, and the function’s quantitative variable variously called Number, Percent, etc.

Inactive flag

Use the Inactive Flag on the left of the screen to mark a rule as inactive. Inactive rules are ignored in model processing. Sometimes it may be helpful to enter into a step a rule for every element of a dimension, perhaps for every specialty, even though for many specialties no rule is wanted. You can then flag the redundant rules as inactive. This approach makes it easier to see at a glance which specialties have been assigned a rule in the step and which have been omitted.

The year dimension and compounding

The year dimension behaves differently from the other dimensions, because it is the model’s Time Dimension. Model processing proceeds in a specific sequence: the system processes each scenario in order, then within each scenario it processes each year in order, then within each year it processes each step in order. So if a rule refers to a single base-level year then the rule will be executed only once, in the specified year. But if the rule refers to a rollup in the year dimension then the rule will be executed repeatedly for each year in the rollup.

For example — if a Rule uses the Add function to add 1% to emergencies in each year of a rollup called Modelling Period, then 1% will be added to emergencies in each year included in the Modelling Period rollup.

This has the effect of compounding the change, as the 1% added in the second year is also added to the 1% added in the first year.

Rules using different dimensions

In general, a rule may define the body of activity to which it applies using all or any dimensions of the ActivityModel table.

Different rules in the same step may use different combinations of dimensions.

Base and Rollup level selections

Selection from dimensions may be made at a base or a rollup level.

There is one exception to this rule: the “To” variables in the Copy, Move, SplitLosMoveNDays and SplitLosTakeNDays functions must be base-level as these functions are creating new data from existing data, and therefore have no basis on which to prorate the new data across rollup elements.

You can type a dimension element name directly into a cell on the Rules Editor screen, or double-click to select from the Dimension Browser.

Two rules which affect the same ActivityModel record

Raedfast allows you to write two rules which affect the same ActivityModel record. For example, Rule #1 might apply to General Surgery and Rule #2 to Adults. Clearly both rules apply to Adults in General Surgery.

When this happens, both rules are applied, additively, unless you use the FirstRuleWins flag described below.

For the most part you will want to avoid writing rules which apply additively in this way, but there are occasions when you may choose to. It is perfectly legitimate to add say 1% to all specialties in one rule, and then a further 1% to surgical specialties in another rule, thus adding in total 2% to surgical specialties.

FirstRuleWins

In Functions which support it, the FirstRuleWins flag can be used to specify that a Rule should not be applied to any body of activity to which a previous Rule in the same Step has already applied.

In the example below, Rule 3 specifies that Elective Critical Care BedDays are to be increased by 20%. But Rules 1 and 2 have already specified that if the Specialty is Cardiac Surgery or Neurosurgery then no BedDays are to be added. Since Rule 3 has FirstRuleWins checked, Rule 3 will have no effect in respect of these two Specialties.

Copy / paste / insert / move

You can use CTRL+C and CTRL+V to copy and paste cells from one part of the Rules Editor screen to another.

To copy an entire rule, highlight the rule by clicking on the row header, then right click and click on Copy. The rule is copied below.

To insert a blank rule, highlight the row above which you want the new rule to be inserted, then right click and click Insert.

To move a rule, click on the rule’s row header and drag the row to its new position.

Entering more than a hundred rules

The Rules Editor screen is a canvass of one hundred rows. If you need to enter more than a hundred rules in a step, you can insert a new row by right clicking on a row header and clicking Insert.

To insert many new rows at once, select a set of rows using the shift and arrow keys (just as you would do in Excel), then right click on any of the selected rows and click Insert.

Save and refresh

Changes are not saved to the database until you click the Save button.

Click the Refresh button to retrieve the last-saved values from the database. you will lose any unsaved changes on the screen.

The Refresh button is useful if you find yourself getting confused about the changes you have made to the rules, and you want to back the changes out and start again.

Saving a backup of a step before you start editing

Sometimes it may be convenient to save a copy of a step as it is, before you start to make changes. Then if you need to you can check back to the way the step was before your changes, and restore the original if you want.

To do this, use the Copy All to Clipboard button, and paste into Excel. See Editing Rules in Excel below for more details.

Editing rules in Excel

You can edit existing rules in Excel, or create rules in Excel from scratch, then paste them into the Rules Editor screen.

This allows you to load Excel data into Raedfast steps, and to use Excel techniques to create or modify rules. For example you might have a set of ONS population figures in Excel which you want to paste into a step.

To edit existing rules in Excel, click on the Copy all to Clipboard button. Then paste the data into Excel.

When you have finished developing the rules in Excel, place the data on the clipboard — use Ctrl + A to select the whole table, then CTRL + C to copy. Then in the Raedfast front-end click on the Past all from Clipboard button.

Raedfast will look through the clipboard data for columns with names matching field names available to the function in question. The order of matching columns on the clipboard need not match the order on the Rules Editor screen. Columns on the clipboard data with names not present in the fields of the function are ignored.

All existing data in the Step is replaced.

Documenting scenarios

Documenting a single scenario

When you are ready to publish a scenario for discussion with colleagues, you can document the steps and rules which comprise the scenario in Excel. To do this, right-click on the scenario in the steps and scenarios screen and click on Document last processed Rules in Excel.

The system will generate an Excel workbook with a worksheet for each step, an index sheet listing the steps in processing order, and a final sheet documenting the dimension rollups used in the scenario’s rules and their definition in terms of their child elements.

Note that the rules and rollups documented are as they were when the Scenario was last processed.

That is, they are the rules that generated the output data in the ActivityModel table for that scenario, even if the live rules in the steps have been modified since then.

This is possible because, at the end of every model processing run, Raedfast records in an archive table the state of the rules and dimension rollups as they were at the time of processing, for all scenarios included in the processing run.

Documenting all scenarios

You can also document all Scenarios, by clicking on the Document all Scenarios in Excel button on the Steps and Scenarios screen.

This option creates a workbook with the steps and scenarios matrix as the top worksheet, plus a worksheet containing the rules each step, plus a final sheet containing rollups used in defining rules.

Note that this option documents the rules and rollups as they are now.

The rules and rollups documented may therefore be different from the rules and rollups in force when a given scenario was last processed, if you have changed any rules or rollups since the point of processing.

Freezing published scenarios

The ability outlined above to document a scenario’s rules, as they were when the scenario is processed, provides one way to “freeze” a scenario once it has been published and circulated to colleagues.

The system will not of course prevent you from changing that scenario and reprocessing it. If you want to freeze a scenario rigorously and protect it from subsequent change then you should create a copy of the entire Raedfast database containing the scenario, and leave that copy unchanged.

To do this you will need to back up your database in SQL Server, and restore it with a new name. Please consult your system administrator if you want to do this.

Adding, renaming and deleting Measures

You can add new measures to the model, and rename or delete existing measures.

These operations are carried out using Tasks. Please refer to the relevant tasks in the Task Catalogue.

The addition, renaming or deletion of measures is not reflected automatically in the Raedfast Analysis Services database.

You will need to execute the Task Rebuild Analysis Services database when you have finished changing your measures.

Testing Rules

When testing rules, you will want to restrict the time it takes to process the model and check the results of your rules.

Compression

As described above (Compressing your baseline data), you can compress the model data using the option Compress by n % on the BaselineFromHistory and BaselineFromModel functions. You can turn this on for testing, and turn it off for final processing when you are sure your rules are doing what you need them to do.

Restricting your baseline

You might also wish to restrict your baseline temporarily for testing purposes — e.g. by pulling in a single specialty. This means the model is processing fewer records.

Creating a test scenario with minimal steps

It can be helpful to create a simple scenario for testing — minimally this might have only a baseline step plus the step you want to test. Sometimes other intervening steps will be required to make the test realistic.

Flagging rules as inactive

It may be helpful when testing to flag some rules in a step as inactive — perhaps all rules except the one in which you are particularly interested. This can make it easier to understand the effect of the rule, as all the output generated from the step will have been generated by that single rule and the effect of the rule will therefore be more readily apparent.