Major upgrade to Gooroo Planner

Major upgrade to Gooroo Planner

05/11/2015
by Rob Findlay

On Monday 23rd November 2015 we released a major upgrade to Gooroo Planner (at no extra cost to you). Apologies for the downtime while the scripts were run and the upgrade put into place.

The centrepiece is “any date” modelling: instead of having to model whole months at a time, you can model from any date to any date. So you can refresh your Planner models every week if you like, and also do that automatically using the Planner API.

We have added some new dataset and results fields too, to help you refine your pathway modelling, automate anticipated changes to demand, and improve theatre and clinic utilisation.

In your patient-level data uploads, we have refined the handling of cancellations, and given you the option of including urgency and removals in the additions data as an alternative to putting them in the activity data.

You will find technical details in the revised Planner documentation on our Publications page after the upgrade is released.

“Any date” modelling

When you upload or update a dataset on-screen, or create a report, you will notice that the old monthly date selector has been replaced with a full calendar date picker. So all your date ranges can run from any date, to any date, without being restricted to the start and end of the month.

This really opens things up, because now you can refresh Gooroo Planner as often as you like, with bang-up-to-date week-by-week capacity planning and patient-by-patient waiting list simulation. So if you’re hit by norovirus, or a short-notice consultant absence, you can model your recovery plan immediately without waiting for the end of the month. And if you are tracking a waiting list recovery plan, you can refresh your planning every week in synch with your outturn monitoring and performance management meetings.

Automating “any date” modelling

On-screen modelling is great for testing scenarios and chucking the numbers around, and for piloting regular monthly planning across a handful of key services. But when you step up to regular weekly modelling across multiple scenarios for a wider range of clinical services, then it’s definitely a job for a computer.

So we’ve upgraded the Planner API to “any date” modelling as well, so that computers can automatically update your planning trajectories overnight, instead of you having to do it yourself.

All our Planner API users have already switched over to our newer REST API, which is faster and doesn’t need updating whenever we add new data fields to Gooroo. It should carry on working as normal for your monthly reporting (although the previous API will stop working after the upgrade). But we recommend you go to our API site and download the new package which will handle “any date” modelling too; it is available free of charge after the upgrade is released, and you can just copy your old Goorooconfig.xml file across into the new package to get it working.

We did have to make one change to accommodate “any date” modelling via the Planner API. In the past, date ranges were set relative to today’s date (for instance -1 meant “last month”), via the config file Goorooconfig.xml. This was fine when the modelling was in whole months, but it just isn’t precise enough for “any date” modelling, especially when you want to fine-tune the future periods in different reports.

So we have created a new upload file called DateSettings.csv which you can create using the same query code that generates all your existing data files. That way, you can be sure that the Planner API is always using exactly the same date ranges as your queries.

(If you don’t provide the DateSettings.csv file, then don’t worry, Gooroo Planner will just fetch the dates from your Goorooconfig.xml as before.)

Here (in table format) is an example of the new DateSettings.csv file:

Setting	ItemNumber	StartDate	InclEndDate
PastPeriod	0	25/12/2013	02/10/2015
DatasetPerformancePeriod	1	05/06/2014	21/01/2015
DatasetPerformancePeriod	2	06/07/2014	22/02/2015
DatasetPerformancePeriod	3	07/08/2014	23/03/2015
ReportFuturePeriod	1	04/10/2015	17/12/2015
ReportFuturePeriod	2	29/11/2015	22/02/2016

Of course the actual file you upload won’t be a spreadsheet, but instead it will be a CSV file like this:

Setting,ItemNumber,StartDate,InclEndDate
PastPeriod,0,25/12/2013,02/10/2015
DatasetPerformancePeriod,1,05/06/2014,21/01/2015
DatasetPerformancePeriod,2,06/07/2014,22/02/2015
DatasetPerformancePeriod,3,07/08/2014,23/03/2015
ReportFuturePeriod,1,04/10/2015,17/12/2015
ReportFuturePeriod,2,29/11/2015,22/02/2016

Trotting through those items one by one (and you will also find definitions in the documentation after the upgrade is released):

The past period is global to the whole API call so it appears only once. All the end dates in this file are inclusive, so an end date of 02/10/2015 includes that date.
Each dataset can have its own performance period (i.e. the period over which things like urgency, length of stay, and theatre utilisation are measured). ItemNumber is just a serial number for each performance period, and the numbering of these periods must exactly match the order of the datasets specified in the Goorooconfig.xml config file.
Similarly each report you generate can have its own future period, and again these periods must be numbered in exactly the same order as the reports are specified in Goorooconfig.xml.

This gives you complete and automatic control over all the date ranges, with all the flexibility you need if (for instance) your theatres data is only reliable since April, or if you always want to run a model up to the end of the current financial year.

Better pathway modelling

We have added a new dataset field “StreamWeighting”, which allows you to adjust the relative conversion rates for different services.

For instance, if half your elective orthopaedic patients start their pathways in new outpatients, and the rest start their pathways in fracture clinic but convert one-tenth as often, you can now model both those pathways in parallel by setting StreamWeighting = 0.1 for the fracture clinic service.

This provides a lot of flexibility, but it also makes conversion rates more complicated in the modelling, so we have added two new results fields to help you make sense of it. ResConvertIn is proportion of upstream activity converting to demand in this service, and ResConvertOut is the proportion of activity in this service converting to demand downstream.

It can get confusing when you are giving different weightings to different services, so here is a spreadsheet example of conversion rates showing how it all works. It looks like this:

We’ll provide a fuller explanation of this powerful new functionality in a separate post.

More capacity information

Which do you prefer: theatre utilisation, or the turnaround interval between patients? It’s your choice, and although utilisation is the NHS’s usual measure (and therefore the default in Gooroo) I personally find it a bit “benchmarky”. Turnaround intervals are more crunchy and practical – you can picture the time it takes for a theatre to be cleaned, and for the anaesthetist to change meds and check consents. So we’ve added some new results fields, to convert utilisation rates into turnaround intervals, and vice versa.

Let’s say your theatre utilisation is 65 per cent (based on anaesthetic start to patient out of theatre). You know that isn’t great, but what does it mean in practice? With the new results fields, you can readily see that this is equivalent to (say) a 20 minute turnaround interval between patients. That is a number you can get your teeth into more easily, and it can form a better basis for discussions with anaesthetists and surgeons about how the session is used – such as whether some tasks could be done before or after the session, when you aren’t paying £25 per minute or whatever for a fully-staffed theatre.

The new results fields are:

ResThtEquivChg: Equivalent theatre changeover time at full utilisation
ResThtEquivUtil: Equivalent theatre utilisation at zero changeover time
ResClinEquivChg: Equivalent clinic changeover time at full utilisation
ResClinEquivUtil: Equivalent clinic utilisation at zero changeover time

and they all take account of both the existing utilisation and changeover data when working out each separate statistic.

We’ve also added for convenience

ResThtClinHrsWk: the total of theatre and clinic hours per week

for easier comparisons against consultant job plans.

More automated demand changes

You have always been able to throw extra demand into your future modelling, using the dataset field FutExtraDem (future extra demand). But what happens if you want to model a different length of future period? It’s annoying to have to adjust this value to match different time periods, especially when you’ve automated your planning using the Planner API and want to model different periods routinely.

We’ve solved that problem by adding an extra field: PastExtraDem (past extra demand). So now you have the option of expressing an anticipated change in future demand as being relative to the length of the past period instead. Because the past period is fixed in any given dataset, this demand will automatically be adjusted when you change the length of the future period.

Of course, if you don’t want your extra demand to change when the future period changes, you can always use the existing FutExtraDem field instead.

Better handling of cancellations

The statistical datasets have always allowed you to specify separately the different ways in which patients are cancelled and removed:

Some patients are removed in advance of their appointments, so that you can re-use their appointment for somebody else; this pushes up waiting times but does not waste capacity.
Some are removed at short notice so that you can’t re-use their appointment (e.g. DNAs who are referred back); they don’t push up waiting times but do waste capacity.
Some are cancelled at short notice but are not removed, and instead are returned to the waiting list to be rebooked; they affect patient scheduling and waste capacity.

That’s always been available when uploading statistical data, but what about patient level data?

Gooroo Planner can already measure the first two items from your patient-level data, and after the upgrade it can measure the third one as well. We’ve done this by adding a new option to the RemovalReason field (3 = cancelled at short notice but not removed). So now you can model DNAs more accurately than ever before.

Better fit with your databases

Many hospitals record clinical urgency, and the reasons why patients were removed from the waiting list, in the same database as activity. We originally built the patient-level uploads on that assumption. But we have found that not all hospitals do this: some keep that data in a waiting list movements database instead, and would find it easier to extract that data alongside additions to the list.

So we’ve extended our patient-level uploads to accept urgency and removal reasons in the additions file, as an alternative to putting that data into the activity file. So however your databases work, it’s easier to get that data into Gooroo Planner.

Support

As always, we are here to help you. Just email support if you have any questions or would like to make better use of Gooroo.

Return to Post Index