eRostering New Features
The last few months have been rather odd; the world has stopped turning and everyone at SARD has continued as normal from our remote bunkers. The eRostering Team has continued to flesh out the platform. The last few months have presented us with a few challenges, firstly managing building Rosters for the August 5th rotation and also investigating new requirements from other prospective clients to enrich the current platform - all this while only going out for milk every two weeks.
Building Rosters
While our current system allows us to present shift patterns and manage shifts as an admin, up until now, we had worked by importing existing data from other systems. As developers we have all faced the challenges of taking, sometimes tricky, data from one source and converting it into another format, getting it wrong, hitting it with a virtual rolling pin to allow it to work in another system. We almost enjoy the process. From the outset, however, we have worked to carve out a system to build our own Rosters from scratch. This is no small task.
Our primary goal is to look at what tasks an administrator would need to perform in order to take a simple rota template, assign users and turn that into a six-months’ worth of shifts whilst taking into account a Junior Doctor’s training preferences, holidays, life events or indeed any other factors that could restrict what days a doctor could work.
What we have proven is that building multiple Rosters with the right data can reduce the manual process taking weeks to a matter of minutes, whilst still giving administrators the ability to make manual amendments before making a Roster live.
We’ve prepared a quick video to demonstrate this process. There are any number of ways in which this may need customising for different clients and circumstances. From the outset, we have in mind that we want to build something presentable, flexible and easy to use.
New Features
You have been warned
To bring order to the often chaotic world of placing people at the right place at the right time, it’s important we adhere to a set of rules or guidelines to give us structure. We do build Rosters from pre-defined templates, but what if something goes wrong or things change, we want to know if our shifts are still valid. If Doctor A is working two shifts at the same time or Doctor Z is working 10 nights in a row we need to know that this is a problem. We’ve now implemented warnings, a whole host of checks on shifts which allow Administrators to keep check of problematic changes and management them from their dashboard. The dashboard will moan at you, but you’ll thank it later. Fist bumps to Artur and Pedro for undertaking this monsterous task.
I don’t think anyone would be best pleased to be working days and nights on the same day, we can warn you before a Junior Doctor attempts to follow the Roster to the letter.
Maintenance Personnel should not perform brain surgery
Coupled with managing rules and warnings, it was important for us to be more specific about the requirements for particular shifts. If a shift needs to be taken by a Doctor with a Grade of ST6+ or with a particular Employment Role, the new system can account for those kinds of requirements by blocking assignment unless those rules are met (compulsory) or allow it and create a warning (optional) which fits in with the above workflow.
Bulk Reassign
We’ve improved our Bulk Reassign tool to assist with large changes, such as unassigning/re-assigning multiple shifts for single users, saving hundreds of clicks. Admin, keyboards and mice will all thank us.
In Your Interface
The interface is evolving, there’s a whole host of new features under the hood and workers keeping a close eye on your data. We are constantly working on making sure the interface doesn’t suffer on the weight and leave our users struggling to find the right tool for the job. We’re working on every piece of navigation on every page, every link, every button to make sure everything has a place, and everything is in it place. High fives to Simon for doing what he does best.
Learning never stops
Every few months we need to stop what we’re doing and look back at where we are. Look at the new features, recall how we got here, review if we did the right thing and take a look at that test suite. Are we fully tested? Are we going to look back in six months and wonder why we did something a certain way? Code review is an important process to look back and make sure we’re ready to move on to the next tasks with confidence and learn a thing or two about what we achieved. So that is the point we are at today. We’re going to take a breath.
And what then, well, the way forward is sometimes the way back. It may look like we’re not getting anywhere when in fact we are. How about a bit of a refresh on the Theory of how we solve complex problem solving and use all of those rules we just defined to write our Rota / Roster patterns for us. This book was first published in 1967, the maths is solid but the Technology changes.
