Release 53: more power to administrators
It has been a while since we have done a general release blogpost…the last one was for Release 44 in July: these days our users can check them out for themselves at our release notes updates page here. But there are a few features in this release - the last for 2024 - that we know some users will love. Many of them are in response to requests we have had from existing customers or from customers we have spoken to in recent sales-related discussions.
There are over 50 changes in this release, but the major ones are outlined below.
Dynamic permissions
One of our customers wanted to allow their doctors to be able to edit the roster when they are the designated Duty Anaesthetist (‘DA’) so they can make amendments when someone calls in sick or there are other clinical issues, but at other times they are treated like any other doctor and can only read the roster. This gives greater freedom to allow senior doctors to make necessary and urgent amendments to a small number of shifts without the risk that they could do damage to the overall roster.
HosPortal can now do this, and has two new functions that customers can use to define permissions. These functions can be used independently or together.
Duty-related permissions, so that someone gains a permission only when they are staffed on a specified roster. Without any further constraint, for the period of time they have that permission they can edit any shift on any roster even if that shift was last week or scheduled for next month.
Time-limited permissions, so that someone can only edit current shifts. In its simplest form someone with this permission can only edit a shift that is happening right now. But you can also extend the time limit, for instance to allow people to edit any shift that happens today.
If you use these permissions in combination you can limit someone’s permission so that they can only edit shifts while they are staffed on a particular roster, and they are limited in the shifts they can edit to only today’s shifts.
Improved ability to use FTE status in work rules
For some time we have allowed a user’s full-time equivalent (FTE) work status to influence the number of hours they can work. For instance, if the general rule is that users can work 80 hours per 2-week payroll period then someone with a 0.5 FTE status would only be allowed to work 40 hours over the same 2 weeks. We have now extended this pro-rata function to rules that define the number of days or shifts people work (‘can only work 10 clinical sessions per week’, or ‘can only work 20 days per 4-week cycle’).
Because there are many contractors, such as VMOs, that do not have an FTE status, you can now define that a user is exempt from the FTE status but still allow them to be captured by over-working rules as if they are a full-time employee, so that zero-hours contract VMOs can still be limited to safe working hours.
Staff count on the roster page
Some user like to have a readily-viewable count of the number of people working each day. Administrators can now get a staff count summary on the roster page, to show the number of people of each role (e.g. Consultant) who are available to work each day, the number of staff required of each role, and the balance, whether it is a shortage or surplus. Because some assignment can be filled by people of different roles, we use the Hungarian algorithm to optimally calculate the deployment of available staff before reporting whether the roster is under-staffed.
‘Before’ and ‘after’ rules
When we rebuilt our shift conflict rules engine to make it more powerful in in December 2023 as part of Release 35 we decided to simplify the rules so that the assumption was any rule that needed a time direction would defined by an ‘after’ rule (flag a conflict if shift A is less than a certain time after shift B). We have realised that this is a bit limiting, and there are some circumstances where you cannot just reverse the order to create the equivalent of a before rule. So now you can: we have the ability to define rules where shift A cannot be before shift B, or after shift B, or either before or after shift B.
