Building a model

Building a model

 

The overall shape of your model will obviously depend on the model’s context and purpose — be that provider-focussed demand and capacity planning, new hospital build, re-design of the whole-health-economy, etc.

What follows below is only no more than an outline, without specific context, of the kind of modelling moves you are likely to have to make and the functions of Raedfast best suited to implement these moves.

Baseline and roll-forward

 

Choosing a baseline period

The first step in building a model is to establish a model baseline, to be modified by assumptions about change.

The model function used to establish a Baseline is called BaselineFromHistory.

The model baseline is drawn from the ActivityHistory table, and is typically a period of twelve months’ activity. A good baseline is a representative sample of typical activity. You need not use the most recent available 12 months, if this is considered unrepresentative.

You can use different periods for different types of activity — one period for A&E say, and another for Inpatients.

Scaling up

If a full 12 months of representative data is not available for a given type of activity, you can take less than 12 months and scale the numbers up to a 12 month approximation by setting the Percent column to more than 100. So if only 8 months of data is available, set the percent figure to 150 to simulate 12 months.

Determining the first year of the model

The first year of the model should generally be the last complete year before that for which you wish to model changes. This is so that the ActivityModel table contains a clean historical baseline for comparison with future modelled years. So if the first year for which you wish to model changes is 2021/22, you may wish to load your baseline data into 2020/21.

Naming year elements

You may name the elements of the Year dimension as you please, using real years such as 2021/22 or 21-22, or offsets such as Baseline Year, Year 1, Year 2, etc.

Rolling forward

For each year of the model after your baseline year you will wish to roll forward the total of the preceding years into that year’s baseline.

Use the BaselineFromModel Function to do this. Specify the year to copy from, the year to copy to, and the percentage to copy (normally 100).

Your model may cover as few or as many years as you wish.

Omitting intervening years

It is not necessary to model every year in the period of interest. If you are building a plan over a long period, say 20 years, you may find yourself modelling detailed changes in early years, but little change except demographics in later years. In this situation you may wish to model say Years 1 to 5 individually, then Year 10 then Year 15 then Year 20, omitting the intervening years. This approach can reduce Model processing time. Since the numbers you put into, say, Year 10 will in some cases reflect 5 years of change (for example, 5 years of demographics change), you will need to adjust your Year 10 assumptions accordingly.

Cleaning data

 

The next thing to consider after creating your Baseline is any corrections which may be required to the Baseline data.

Raedfast does not assume that the data available for use as a model baseline is either clean or complete. The system allows you to use the system’s modelling tools to correct and complete historical data.

Such adjustments may include:

  • moving data out of obsolete categories — for example using the Move function to shift activity from a redundant specialty code to a new one

  • deriving missing data — for example using the Move function to shift a proportion of bed days into a critical care POD

  • Using the Copy function to assign bed days to activity with zero length of stay

  • estimating activity for missing data sets — for example, if data for GP consultations is not available the Copy function can be used to model these, as being say three times the volume of outpatient attendances. By copying existing data to generate new data you give that new data the characteristics of the copied data, in terms of distribution across the dimensions of the model: for example, the derived GP data would share the same age distribution as the original outpatient data.

Demand, efficiency, provision, capacity

 

Once you have established a clean baseline, the work of modelling change begins.

Most changes fall into four broad types:

  • demand — how much work will need to be handled?

  • efficiency — can we handle the work more efficiently?

  • provision — in which providers / sites / points of delivery should the work be done?

  • capacity — what resources (beds, theatres, etc.) will be needed?

Demand

Steps which model demand changes are likely to use the Add Function to add to or subtract from a given body of activity.

Efficiency

Steps which model efficiency changes may use the Rate function to change the ratio of say follow-up outpatient attendances to firsts, or the ratio of day cases to elective inpatients. Alternatively, and perhaps more commonly, the Add and Move Functions can be used to achieve the same ends.

For example, the ratio of follow-up to first outpatient attendances can be reduced by setting a lower rate (using the Rate function), or by subtracting a proportion of follow-ups (the Add function), or by moving follow-ups to say a GP Consultation POD (the Move function). The first of these has the advantage of explicitly specifying an expected rate. The last has the advantage of specifying where the subtracted activity is going, if indeed it is to be reprovided. The middle option is probably the simplest to apply, but the least informative.

Provision

Changes in the provider site which delivers the service are likely to be modelled by the Move function, if the activity is to be reprovided, or by the Add function if not. If the model is a provider-focussed one, and you are not concerned to model where the activity is reprovided, only to remove it from your own workload, then you might use the Add function even if the activity will in reality have to be reprovided by someone else.

Capacity

Once you have established the volume and location of service, you will wish to calculate the implied resources. To do this you will use the AllocateResource function.

You can use the function to assign values to any measure you wish, driven by the measures such as Cases and Bed Days already present in the model.

 

Combining steps

 

Often you will wish to combine a sequence of steps to model a change.

For example, modelling the step down of tail-end emergency bed days from acute to community provision may require three steps:

  • first to move the activity out of the acute provider

  • second to allocate the moved activity to a new community provider

  • third to derive the workload associated with each new type of provision

Click through the three screens in the gallery below to see an example …

 

In the first step we use the SplitBedDaysLeaveNDays function to specify the cohorts of patients affected, and the point beyond which remaining bed days are to be moved out. In this step we simply move the activity to a dummy POD called Holding. This POD has nothing else in it, so we can conveniently refer to the step-down activity in subsequent steps simply by specifying the activity in the Holding POD.

In the second step we use the Copy function to copy the activity in the Holding POD to new providers — GP Practice, Home Care Package, Community Health Bed or Care Home.

In the third step we use the Copy function again to derive the activity volumes and points of delivery for the new providers, still referencing the Holding POD, and copying the activity to create numbers of GP contacts, social care contacts and so on. (Note that we can use the Copy function to copy activity more than once.)

The last rule in the third step copies the dummy Holding POD to -100% of itself, so no activity remains in it when the three steps are summed..

Now even if it were possible to carry out all of these moves in a single step, that step would be quite complex to manage. Much better to use a sequence of simple steps, with a temporary holding POD to keep sight of the activity being transformed.