Medical Rosters in the NHS— a tech solution.
I have been an NHS Consultant for nearly 10 years. I work in a big teaching hospital in London. It has been a long journey, from medical student: 5 years of university medical school, a year of house jobs, 3 years of senior house office, 7 years of registrar. Throughout that time, like many others, I got married, had kids, bought a house: all tricky things to do when you are moving posts every 6 months during training.
And I start here to illustrate a point: a person’s working pattern is not just about their work, it is about their whole life actually. Like a strong smell, it fills a space, expecting every aspect of a person’s life to acknowledge and take account of its presence, its primacy. I have lost count of the important things in my life that have had to take a back seat for my job. I got married on a Saturday and was back at work on Monday because I could not get time off work; for the birth of my first child, I was forced to book my paternity leave, because the uncertainty of an estimated delivery date did not fit in with the roster (ironically while I was doing a neonatal job); and the few episodes of unavoidable illness I have had (tonsillitis, flu) which have fallen when I was on nights, or ‘long days’, left me feeling guilty and shamed that I would leave my colleagues a man down at short notice. I navigated the death of my father with minimal fuss — I never told my colleagues, never took a day off, instead travelling back and forth to the hospice in the evenings I was not working or stepping out of ward rounds or clinic to answer the phone to my mum, or the hospice staff where he was was a patient as he deteriorated.
Make no mistake: the medical rota is not just a rota.
In 2018 the British Medical Association published that 70% of ‘junior’ doctors reported working on a rota with a permanent gap; 10% of medical rosters are currently not fully staffed. And I know from my own hospital trust that we would not be able to provide a safe service were it not for the good will week in week out of people cross-covering, stepping in to fill weekend and night shifts at the last minute, cancelling personal plans and moving child care. The NHS functions on this — across the specialties, across the training grades, across the disciplines.
So whilst this is not a polemic about chronic staff shortage, it is important to recognise the personal cost of the rota. When we focus on solutions, we should acknowledge that good rosters are not just about creating a safe and positive environment; they are about allowing people to have a life outside of work. Any solutions (technological or otherwise) are only about making the system work better: but the solutions to rota gaps themselves are political, not technological. Apps cannot fill gaps.
What happens now
Ever since I can remember, the medical rota has been on Microsoft Excel. In fact, I have rarely known spreadsheets be used for accounting, which is what they were designed for. Usually there are rows for days, columns for ‘slots’ or clinical areas and cells filled with shifts of different colours or doctor names. Rota coordinators used to be senior administrators, but now that that teams are so big, and the working patterns are so complex, it is usually a consultant who manages it — just another tedious management task for which there is no remuneration but which no one else can do. Requests for leave are made by email, swaps are made by cutting and pasting cells in the spreadsheet. The department is constantly plagued by multiple versions of the same document. And version control of a single document constantly updated in the cloud is impossible, since trust systems prevent access to any cloud file sharing systems, citing security as their reason. Crazy biscuits. It is this sort of system that runs our NHS hospitals day in day out.
Another way?
When I started looking into this a few years ago, I discovered that in fact rotas and rosters are not the same thing:
Roster
(/ˈrɒstə/ noun/verb)
A list or plan showing turns of duty or leave for individuals or groups in an organisation. It differs from a rota in that it has names attached to it. It is also affected by real time events such as absence (planned or unplanned), on call commitments, and the actual demands of the department / team on the day.
Rota
(ˈrəʊtə’ noun)
The pattern of shift work which has no individuals attached to it. It is designed according to rules relating to safe working practices, governed by the European Working Time Directive, and must be ‘compliant’. It usually defines a single cycle of rolling weeks of shifts. Typically (though not always) the number of weeks in a cycle is the same as the number of slots.
So the ‘rota’ is only a template which cycles. It becomes a ‘roster’, a living breathing thing, when rolled over months and populated with real people. Although it may start off as a cycle of shifts, as people swap, take leave and so on, it becomes an ever changing document. In a full shift system, rota’s are made up of rota weeks, each week itself comprising days of different shifts — as examples: long days (8:30–2100), nights (20:30–0900), short days (0900–17:00) and so on, covering different clinical areas (wards, clinic, emergencies, admin etc.). Different departments have different shifts: twilight shifts, half days and so on. A huge amount of effort goes into the design of these templates, and whole departments are scrutinised by them. In these pressurised times, it is clear that without the safeguards of the European Working Time Directive we would go back to the bad old days of 100 hour weeks.
Tech solutions
Most tech solutions to rosters try to do too much, or to offer a system that is not sufficiently adaptable to different use cases. There are systems in place currently live across the UK, but few of them are positively viewed by their users. In my own trust we have a system called ‘RotaWatch’, a clunky system administered through the hospital switchboard, which can only be viewed when at work. It is really only a status board, leaving the day to day running of rosters to the different hospital departments and teams.
Although most full-shift medical rosters are similar, they are not the same. Anaesthetists work different patterns to surgeons; paediatricians work different patterns to adult physicians. Many solutions seek to keep track of hours worked, rota compliance and so on. Actually though for a working solution, none of that is needed. What is needed is a backend that stores a record of the shifts rostered, and a front end that displays them. There should be user accounts for clinicians, and admin accounts for senior clinicians and roster administrators. Shifts should be visible to all and filterable so that it is possible to know where a given person is allocated on a given day, what staffing looks like across the floor, and where the gaps are, who is away. This allows managers and others to plan in advance to prevent the looming gaps. It should also provide a platform for clinicians to request leave of different types, and for administrators to view requests and approve or reject them based on leave policy and staffing across the department on the day in question.
I have had a go at developing a system along these lines and am trialling it at the moment: www.rota.ninja
Design
Like most coders, I find one of the biggest decisions before launching out on a project is to pick the right tools. RotaNinja needed to be mobile first, since most people live on their phones these days — you want your roster there too, where you can check who is where in handover, negotiate swaps with people and put in the request at the same time.
A huge debate in the blogs currently is native versus cross-platform solutions. Native solutions (apps written in android/kotlin or swift for iOS) are quicker and work best on their native platforms, but each needs writing from scratch, maintaining, and putting through the often subjective evaluation processes of the App Store or Google Play. Cross platform solutions by contrast have the benefit of a single code base which can compile to either iOS or Android, but are not as quick, and the compile process is not always problem-free: hopefully Flutter maybe changing that. A third option is increasingly available: Progressive Web Apps (PWA). These are essentially websites that use the phone browser, but have small bits of code called ‘service workers’ which can access some of the phone’s hardware (camera, accelerometer etc), allowing them to function very likely native apps. If performance/speed is not critical, PWAs can be amazing. They are capable of caching when data signal is poor. Newer browsers now support PWAs across android and iOS so are an option for those, like most medics, who upgrade their phones every 2–3 years. And there are other benefits too: pushing updates is easy, and they don’t have to go through the clunky review process of the AppStore which is great when a project is in beta.
So I settled for Ionic and Angular using Firestore for the backend. Firestore is Google’s NoSQL cloud solution, and has an authentication API which wires up easily using the angularfire2 library. This allowed me to have a simple authentication process and create accounts for users and administrators, who could view different parts of the app depending on their role. Clinicians needed only to see the rosters live in their departments, whilst administrators needed to have access to rota and roster design function as well.
Administrators needed to be able to create rota templates, and use these to generate rosters, on the basis that rota templates don’t tend to change very much. Rota templates are made up of rota weeks:
Once the rota weeks have been created, the rota template can be populated:
In order for it potentially to scale, I built it with the ability to function in different hospital trusts, and within different departments within those trusts. Additionally, most departments have multiple teams within them, often who work very different shift-patterns, so there needed to be a structure taking all this into account.
A difficulty with firestore is that it does not allow queries across subcollections, and they have made it very clear that this is unlikely to become a feature in the near future. The database structure therefore had to be denormalised to some extent to allow this to work.
Once the rota template has been created it can be used to generate a roster. This involves selecting a rota template, entering a start and an end date, and letting it happen. This relies on Google Cloud Functions which can be called on creation of a new roster document, and iterate through the rota weeks and rota slots to generate corresponding roster slots and shifts that roll between the dates chosen.
The new roster is then ready to allocate clinicians to slots, so that when they sign in, they can see their roster, their shifts and those of their colleagues.
So does it work?
RotaNinja is still in testing so we shall see. It will not fix the lack of doctors but it will hopefully help staffing coordinators at least see where the gaps are in a timely way. And hopefully it will improve the lives in some small way of those trying to plan their busy lives around their career.